Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
- From
Michael Witten <mfwitten@gmail.com>
- Date
- Sep 4, 2011, 13:40 UTC
- Message-ID
- <CAMOZ1Bv+Lm34Q76FebEe5-VZaLim9j4rrRtke1iCqtP19fjY1Q@mail.gmail.com>
- In-Reply-To
- <CAJsNXTmJo6UXYS4AXygSLq2+T8MV0Sp0KhUt_mvgMqxC_k27ig@mail.gmail.com>
On Sun, Sep 4, 2011 at 10:02, PJ Weisberg <pj@irregularexpressions.net> wrote:
Show 25 quoted lines
> 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.