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


Am Freitag, den 28.10.2011, 19:33 +0200 schrieb Alex Wilson <yourpalal2@xxxxxxxxx>:
On Fri, Oct 28, 2011 at 4:59 PM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:

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

Once you've deleted all the tags locally, git push --mirror forces a remove of all those tags on the remote site (it basically does an exact copy of your local repo). But please note that you need to have cloned the respective repo with --mirror, too,
as otherwise you'll change the github repo in unintended ways.

Out of curiosity what made you delete the tags from those repos?

Because of the performance problems they cause for github (and gitorious, too). It doesn't make sense to keep them if they make the site unusable, since in the end, we'd like to encourage other developers to take part, which certainly
won't happen if github/gitorious aren't working.

[ ... ]

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)

Please don't forget that the changeset-ID changes when the parent of a changeset
changes, so if you move a changeset around such that its ID is changed
(like usually is the case with cherry-picking), the corresponding tag will disappear. That's why I don't think that the order of tags can be messed up.

cheers,
    Oliver


Other related posts: