[ECOS] Re: Tracking eCos as a hg/git submodule

Sergei Organov osv@javad.com
Thu Oct 15 12:42:00 GMT 2009

Alex Schuilenburg <alexs@ecoscentric.com> writes:
> As someone pushing for git, maybe you can give me an answer on this
> since I have not yet found a git equivalent.

As yet another git proponent, I'll try to answer this.

> Does git allow changesets to follow copied files?

I don't think it does, but neither does Mercurial, see below.

> i.e. if you copy file a to file b, and then modify b, but later
> someone finds a bug in a and fixes it, does git propogate the fix
> automatically to b? hg does this and IMHO it is a very useful feature
> since many device drivers and BSPs in ecos are clones of others. It
> would cover not only bugs, but changes in APIs and suchlike which
> means the risk of conflict would be small. So for example if a
> template device driver or API were provided in hg, updates to the
> template would be propogated automatically to copies making major API
> changes a lot easier.

It seems you've missed the point of "hg copy". (Caveat: I didn't use it,
it's just how I understand it from documentation.) It's not a way to
permanently automatically propagate changes made to a file to a (set of)
other file(s). A change will propagate to the copy only on the first
merge (never on commit) and then propagation will stop.

Here are quotes taken from here:

"First of all, remember that this propagation only happens when you
merge. So if you hg copy a file, and subsequently modify the original
file during the normal course of your work, nothing will happen."

"Once your change history has a record that the copy and subsequent merge
occurred, there's usually no further need to propagate changes from the
original file to the copied file, and that's why Mercurial only
propagates changes across copies at the first merge, and not

Based on the above, as soon as public repository has "the copy" and a
cloned repository see it, a change won't propagate anymore even on

The nice thing about "hg copy" is that "hg log" will be able to show
history back including the history of origin of the copy. And yes, "git
log" will also learn this soon (if not already, as I've already seen a
patch). However, git doesn't have "git copy" as it auto-detects the
copies. Yes, it will be able to figure them out even if you just applied
a raw patch to you working tree using 'patch' utility and committed the
result ;-) (this is a note to the question of what system is better
suited for patch-based workflows).

> FAOD, I am trying to track down a genuine set of useful technical
> differences between git and hg to help the maintainers make their mind
> up.  For example, git octopus merges have no current equivalent in hg,
> though somehow I don't see that git super-power user feature will have
> much, if any, use in eCos.  However, changeset tracking copies of files
> IMHO is very useful.

[Un]fortunately, there is no such thing in Mercurial either, see above.
"hg copy" seems to be useless for this purpose and is at the same
category of usefulness as git octopus merges. [BTW, do you really mean
you'd like a commit to be able to change a lot of files when you did
modification to only one? I seriously doubt it's a good idea.]

On the other hand, for example, "git blame" has an ability to
automatically detect and follow copied and moved pieces of code without
any additional steps taken at commit time. You see, power becomes
visible in deep details. Does Hg have 'blame'? Yes, it does, but that
doesn't mean it is as powerful as git's. The same is with named branches
inside repository. Does Hg have them? Yes, it does, but it is rather
recent addition, while git was born with this, so I suspect gits'
support for such branches is superior. Such things makes comparisons of
the tools even more difficult (for example, it could be the case that Hg
already has copy/move detection I'm not aware of).

Another thing is tagging. Both have tagging, but it's implemented very
differently. Me personally likes git's idea of tags more.

Yet another thing is copy/rename tracking/detection and merges
propagation over them. Its deep subtle details that actually make
difference in this field.

> The other difference I have found is that git repos tend to grow in size
> and become inefficient if left unattended for long periods and require
> packing, while hg repos dont.

Well, git manages Linux source trees just fine, you know. eCos is very
small compared to that. But even if git repos tend to grow indeed, a
cron job on public repositories should do the trick, I think.

-- Sergei.

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list