This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracking eCos as a hg/git submodule


Alex Schuilenburg <alexs@ecoscentric.com> writes:

[...]

> 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? ;-)

No, they believe git doesn't need them and I tend to agree. Not only you
can use just first few digits of SHA to reference a revision in git, but
also git has nice syntax to refer to revisions back in history
relatively, i.e., HEAD~3 means 3 revisions back from HEAD (for those who
doesn't know git, HEAD is the symbolic name for the commit your current
working tree is based on).

> 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?

I believe yes.

> 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.

Hg insists on recording copies and renames at commit time, while git
detects copies and renames at the time of execution of particular
operation that needs this information. And yes, both have their pros and
cons.

>From the user point of view it means that in hg you must remember to use
"hg rename" and "hg copy" when appropriate (and blame yourself should
you forget to do it), while in git you are free from this duty (now tell
me which one is easier to use ;))

>From behavior point of view, the results of merge will be different in
corner cases.

-- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]