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

[Alex Schuilenburg <alexs at ecoscentric dot com>]

Sergei Organov wrote on 2009-10-15 13:42:
> 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.
>   
[...]
Sorry, yes.  I did mean purely in the context of existing development
before a merge, not permanent propagation.  Sorry for the confusion - I
did not intend to mislead.

As this is all in the context of shared local development, you would
only expect changes in the merge and subsequent push back to the
official eCos repo when the contribution is to be made.  This is what
makes it a useful feature IMHO.

But similarly, I can see a point to octopus merges...

>   
>> 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.
I disagree.  During development stages, lets take for example NAND since
it is currently topical, it is our policy to use a template for device
drivers and develop at least one driver for a real platform before we
contribute.  So if any bugs were found in the template or changes to the
API were made, the merge would propogate these changes.  It is not
unheard of in our company for someone to make a change or fix in one
place and forget to tell everyone else ;-)


>  [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.]
>   
I did, but only upto the first merge/commit which IMHO is a good place
to cut off further propagation.  After then I agree it is a bad 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.
I believe hg has always had named branches - I can google hg named
branches references back to 2006 where it is described as a feature, not
an addition.  Given both git and hg were started in 2005, that is hardly
recent.  For example, here is a article in Feb 2007 talking about
branches: http://blog.medallia.com/2007/02/a_guided_tour_of_mercurial.html


>  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).
>   
I agree.  No sooner than I mention that you can refer locally to a
changesets by an alias (shorter id) instead of the SHA3 key, while git
AFAIK requires the full key, will somone in git-land go ahead and
implement it.  Or maybe they already have? ;-)

FWIW I found this alias very very useful when navigating our own
conversion from CVS to hg through branmches and CVS rebasing, especially
since I am mildly dyslexic, a poor typist and had two cats and a 5
year-old floating around while I was doing the work.  Incremental local
aliases good!!

> 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.
>   
Will they really?  There is so much feeding off ideas between the two
camps I don't think so.  Nothing stands out as a definitive
deal-breaking feature-grabbing feature. IMHO we are really just talking
about two variants of the same class of car.

Of course this does make it a continual moving target when both are
playing catchup against each other which makes it harder to evaluate
between the two. The deciding factor IMHO for eCos will probably come
down to being a non-technical one, like maintenance cost or colour or
upholstery finish or drive ability or user manual.


>> 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.
>   
:-)  Both git and hg were initially written to manage Linux source
trees. Linus should have thought of that when he started ;-P

IMHO the main reason why git is so popular is that it is pretty much
mandated if you want to develop and contribute to Linux. With so many
linux developers using it, when they come to use eCos it is not
surprising that they also insist on using git. It also should then come
as no surprise that so far I have found the interoperability between hg
and git a lot easier than git to hg since, as above, hg too was
initially written to manage Linux source trees and all the patches that
float around.

But in our experience, 80% of eCos developers are Windows based, and
roughly the % same prefer GUI development than CLI-based. This differs
largely from what the core eCos maintainers use as well as most of the
eCos experts on this list, so I suspect there may be a large leaning
towards git anyway.  I would hope not though because I still believe hg
is simpler, easier to use, is better documented and _currently_ has
better GUI and Windows support than git.  But that is just my subjective
experience having used both fairly deeply (no octopus merges, but wry
did one behind me not long ago). I also admit to having used hg more
than git, even though I started with git, but this was simply because I
could figure out how to do something on hg easier than how to do it on
git.  Otherwise I may be singing git's praises now as well since on a
fundamental level they are so similar.

Incidentally, I managed to get hg 1.3.1 running on RH7.2 (dont ask
why!!!) with little effort but have not yet succeeded getting all of git
built and think I may just give up for now.  So if anyone has already
done it, please let me know if you are willing to share.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com


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