[haiku-development] Re: Begeistert warmup: Git migration, releases

  • From: Alex Wilson <yourpalal2@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 28 Oct 2011 19:33:07 -0600

On Fri, Oct 28, 2011 at 4:59 PM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>
> Am Freitag, den 28.10.2011, 16:24 +0200 schrieb Alex Wilson
> <yourpalal2@xxxxxxxxx>:
>>
>> On 10/28/11, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
>
> [ ... ]
>>>
>>>  Just a couple of days ago, I have dropped all tags from Haiku's github
>>>  and gitorious mirrors,
>>>  so one way to get rid of the tags is to fork again.
>>
>> Yeah, that's what I ended up doing. (For future reference, how did you
>> drop all the tags? The only method I could find was to delete them one
>> by one, and even with a script, this seemed pretty slow).
>
> As git's lightweight tags are just files (non-packed) or lines in a single
> file (packed-refs),
> you can delete them via shell tools - there's no need to 'git tag ...'
> I usually do something like this:
>
>    grep -v refs/tags .git/packed-refs >.git/packed-refs-new
>    mv .git/packed-refs-new .git/packed-refs

Right, I deleted them with vim locally, but I couldn't find how to
delete them in my fork without `git push`ing to each ref. Out of
curiosity what made you delete the tags from those repos?

>>>  I don't know what makes git so slow for you, maybe it's the slow CPU,
>>>  but I haven't
>>>  experienced anything like that with packed tags. Just to check - after
>>>  you've packed
>>>  the tags, the folder .git/refs/tags should be empty and all the tags
>>>  should be in
>>>  .git/packed-refs - is that the case?
>>
>> It is indeed. It could be a combination of slow stat(), slow processor
>> and tags that was causing problems for me. At any rate, after packing
>> the tags, I deleted them all, and things _felt_ faster (doesn't mean
>> they were, of course).
>>
>>>> What frustrates me the most about these tags is that they are
>>>> basically useless.
>>>
>>>  As is obvious from my previous posts on that topic, I don't agree.
>>
>> I think I could have phrased that better. The goal in creating the
>> tags is admirable, but they simply don't meet the intended purpose.
>> You can't tell much at all about the configuration of a build by
>> looking at such a simple tag unless you know that the builder hasn't
>> made any modifications.
>
> Well, there's code in the build system
> (build/scripts/determine_haiku_revision)
> that is supposed to determine the hrev that a certain haiku built from a git
> repo
> is based on and describe any additional changes (plus a dirty marker for a
> checkout
> with local changes). I dunno if this works currently, but it should give a
> pretty
> decent description of the code's state. That description is shown in
> AboutSystem, so
> it's available to users for reports.

This string will only really be useful when there are little to no
modifications (most likely from a user on a nightly). If there are
significant modifications, they can't be reflected in this string, but
we can simply ask for the user (who probably has built their own
image) to run a few git commands for very detailed information on
their build. If a user has problems using some weird build that they
can't tell us anything about, and we can't replicate, then there is no
reason we should try to fix their bug.

It comes down to users with a standard build, which we know everything
about, and users with a non-standard build, which we know only what
they'll tell us. If it's that important, we could add a file at build
time somewhere with detailed info on exactly what their build
contains.

>> Essentially, these tags only do their jobs on
>> nightly builds, which means that having a tag on every single revision
>> is overkill.
>
> Hm, I'm never using nightly builds, when I'm working on a bug, I usually
> switch my
> checkout to the mentioned revision (or a later one) and rebuild. So those
> tags certainly
> do a fine job for me.

Right, but you could do the exact same thing with a git sha-1 id, so
in this case, there is no benefit to having these tags.

>> The other problem is that a commit in my fork that gets pushed to
>> master might be tagged as 'hrev43210', but in my repo, it could come
>> before 'hrev43200' for instance.
>
> AFAICS, that can only happen if you push --force (which we won't allow in
> our repo).
> Normally, you have to merge the branch containing your changes into 'master'
> and then
> push that upstream. So the order should be just fine.

Hmm.. I'm not a git wizard, maybe you're right. It seems to me though,
that if I make my changesets available in my repo, then pull & merge
from upstream, then push to my repo and upstream, the order will be
different.

Alternatively, if a user cherry picks some changesets from my fork,
and continues updating from the master repo, once I push those changes
upstream, the order in that user's repo will be messed up. (I think)

> Well, the reason for switching away from svn never was that git had better
> support
> for monotonically increasing revision numbers. There are other reasons for
> that,
> and we just try to mimick what was a good attribute of the subversion
> workflow.

Yes, there are many reasons to switch to git, but we may have to give
some things up if we want to get the full benefits. If we really
*need* (I don't think so) a single master repo with canonical,
monotonically increasing revision numbers, we might as well stay with
svn and have developers use git-svn if they feel like it.

Anyway, I feel like I'm just saying the same things over and over, and
you probably feel the same way :) This doesn't have to be resolved
now, but it's something that will have to be dealt with eventually.
Maybe a solution will present itself organically :)

--Alex

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 10-2011