Re: Lost association between TAGS and COMMITs when rebased a git(1) repository

[Michael Witten <mfwitten@gmail.com>]

On Sun, Sep 4, 2011 at 10:02, PJ Weisberg <pj@irregularexpressions.net> wrote:
> On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban <urbanjost@comcast.net> wrote:
>> With my first use of git(1) I  created a small project with about 200
>> "commits".  When this was complete, I needed to label each commit with
>> information pointing it to a section of a document. I used tags for this. So
>> far, everything was fine. I was then asked to merge two commits
>> into one. I then did a "rebase" (for the first time). I then appear to have
>> lost all association between the tags and the effected commits; as all
>> commits after
>> the ones I modified no longer see "their" tags. Was there a way to have kept
>> the tags associated with the original commits as they were "rebased"?
>
> ...
>
> My point is that the tags are still there, and they still point to the
> same commits they always pointed to.  It's just that those commits are
> part of the original history, not the alternate history created by the
> rebase.  People say that Git can "rewrite" history, but really it
> creates a new history for the branch.  The old history is still around
> as long as there are references to it, until the garbage collector
> picks it up.
>
> Once a tag points to a commit, it isn't meant to be easy to make it
> point to a different commit.  For the same reason that you wouldn't
> release version 1.8.3 of some software, and then later make a new
> release also called 1.8.3.

Perhaps `git rebase' should accept a `--tags' flag to tell it to
rewrite tags (or should I say `recreate' in the case of tag objects).

Git should not get in the way of people who know what they are doing.