[haiku-development] Re: Git/Hg: some speed tests
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 05 May 2011 15:42:02 +0200
On 2011-05-05 at 01:58:12 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On Thu, 05 May 2011 01:44:43 +0200 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
> wrote:
> > We could tag the very first changeset of every branch (i.e. in master and
> > every release branch) and then use 'git describe' to work out a revision
> > descriptor that would look like this:
> >
> > master-39148-g206031c [in the master branch]
> > r1a3pre-21-g1234567 [in the r1a3 release branch, before
> > the release]
> > r1a3-4-g1234567 [in the r1a3 release branch, after
> > the release]
> >
> > The numbers in the second column always indicate the distance the specific
> > revision has from the tag given in the first column (the third column
> > being
> > git's short hash for the changeset).
> >
> > This would require only one tag for each branch plus one per release.
> >
> > Additionally, incorporating these descriptors in AboutSystem would clearly
> > indicate "foreign" builds (e.g. done from a feature branch available on
> > github/gitorious), as those descriptors wouldn't match any in the central
> > master.
>
> Maybe I misunderstand something, but when I clone the haiku-central master
> master-39148-g206031c and make three local commits I get something like
> master-39151-g0329483, right? So that doesn't really tell us which
> haiku-central version my version is based on -- it could just as well be 5
> local commits after master-39146-... or 10000 local commits after
> master-29151-....
Hm, 10000 local commits in master - you're kidding, right? 5 is more like it,
and those should be dealt with before starting a new task (which is most
probably what's hiding behind the need to interpret revision numbers).
I could live with revision IDs only being 100% reliable on a clean master.
Anyway, I think the problem you're describing is a non-issue: Whenever you
encounter a revision descriptor (e.g. in Trac) and you can't find it in your
(up-to-date) local master, that revision is not from the central repo (there
may be one with the same distance, but the short-hash won't match).
Additionally, it doesn't really matter which upstream the hacked revision is
based on, since you can never be sure that the local changes are not the
cause for the problem. So, I'd strongly advise people (and we could add a
check) to only ever use revision descriptors from the central repo in Trac.
cheers,
Oliver
Other related posts:
