From: Michael Witten Date: Sun, 04 Sep 2011 13:40:19 GMT Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1) repository Message-ID: In-Reply-To: On Sun, Sep 4, 2011 at 10:02, PJ Weisberg wrote: > On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban 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.