[haiku-development] Re: Git/Hg: some speed tests

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 04 May 2011 21:51:29 +0200

On 2011-05-04 at 18:21:56 [+0200], Brecht Machiels <brecht@xxxxxxxxxxx> 
> On Wed, 04 May 2011 18:02:18 +0200, Ryan Leavengood <leavengood@xxxxxxxxx>
> wrote:
> > On Wed, May 4, 2011 at 11:50 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> > wrote:
> >>
> >> If someone has an idea how to create consistent revision IDs in
> >> Mercurial,
> >> please speak up, as otherwise, IMO, Mercurial won't do, no matter the
> >> vote.
> >
> > Even though I'm in favor of Git, the majority at this point seem to
> > prefer Mercurial. I wonder if we could just drop the global revision
> > ID concept and just deal with the SHA1 hashes for commits. Of course I
> > feel the same on this regardless of whether we use Git or Mercurial.
> > We are changing tools and may have to change a few other aspects of
> > how we work. Saying Haiku revision 4d5b6789 is not as pretty as Haiku
> > r43215 but it isn't unworkable.
> When talking about consistent revision IDs in Git, are these the same as
> what is output by 'git describe' (tag name + number of commits since then
> + hash)?

I think those are indeed consistent (i.e. they never change between repos), 
but they are still a bit clumsy (long and not easy to compare). 
I was referring to IDs like 'hrev40283' (or indeed 'r40283' as we use in 
Trac) that sticks to a specific changeset and gets moved alongside of that 
changeset wherever it goes, i.e. that changeset can be referred by that 
name in any repo. 
I have implemented that with git via lightweight tags that are being added 
to every changeset that comes in on the server. When the committer pulls 
afterwards, those tags will be pulled, too (although the changesets are 
already available locally). So, everyone pulling from the central repo will 
have those tags pointing at the corresponding changesets - the tags can be 
used just like the hash, it's just an alias.
Having a lot of those tags sitting in a repo may or may not slow down 
git-related tools, I don't know yet (but will try with gitk later today).


Other related posts: