On Thursday, 16 August 2012 09:28:52 UTC+1, Thomas Ferris Nicolaisen wrote:
> On Thursday, August 16, 2012 12:57:47 AM UTC+2, Andrew Gavin wrote:
>> I'm new to the group but have been using git for a while. I have a
>> question about rebasing and tags. We have a bridge which we use to bridge
>> a svn repository with a git repository using a script that is run on a
>> regular basis. This bridging script fetches changes from a remote git
>> repository and rebases each fetch-head in turn onto the svn branch.
>> I would like to reliably carry over the tags from the fetch branches to
>> the respective branches that I'm going to dcommit. I thought I could do a
>> rev-list checking the tree-hash of the commit and making sure that they are
>> the same for the commit on the fetch-line with the one on the branch I'm
>> rebasing onto. But for some reasons, git svn might be part of it, this
>> isn't reliable.
>> How can I determine which commits correspond to the tagged commits on the
>> fetch branch (I'm doing a manual rebase -onto at the moment)? Or even
>> perform a rebase where the tags get copied across?
>> Is there an easier way that getting deeper into the rebase command itself?
> This sounds to me like a good idea that hasn't been implemented in git.
> Kinda like --preserve-merges, there could be be a --preserve-tags in the
> rebase command.
> However, there is no such thing. A tag is an alias for a SHA, and when the
> SHA is rewritten, the tag is pointing at something else. Annoyingly correct
> What I would do is to use something else than tags for this purpose. You
> know how Gerrit recognizes commits across rebasing through their
> Upon committing, a unique id is generated and noted in the commit message,
> and this is used to recognize that one commits is the same as another after
> it has been rewritten during code-review.
> I would just blatantly copy Gerrit's Change-id commit
> and go from there. Note that they generate this id for all commits, not
> just the tagged ones like you want (maybe you can adapt the commit hook for
> your own purposes, and build something on top that creates tags from these
Thomas very interesting idea, thanks. I'll have a play with the hook.
I note there was a patch for --preserve-tags that doesn't seem to have made
it into git. Probably for the reason you said (tag is an alias for a sha).
It did make me think of rolling a version of rebase in the bridge.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at