On Sun, Sep 4, 2011 at 10:02, PJ Weisberg <pj@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban <urbanjost@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html