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

[PJ Weisberg <pj@irregularexpressions.net>]

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"?

When Old Biff Tannen traveled back to the year 1955 and gave his
younger self a copy of Grays Sports Almanac, which listed the outcomes
of every major sporting event from the years 1950-2000, the timeline
skewed, creating an alternate reality in which he had won enough money
through gambling to take over the town of Hill Valley.  If Marty McFly
had kept a reflog, like Git does, he could have backtracked in his
personal history and just not left the almanac and the time machine
where Biff could find them.  Instead, he had to go back to 1955 and
steal the almanac from young Biff after old Biff had given it to him.
But this metaphor is getting silly, and alienating anyone who wasn't
watching American movies in the late 1980s.

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.

> Also, I have some commits with multiple tags pointing to them. It has come
> to my attention that might not be an intentional feature. I could find
> nothing in the documentation explicitly stating multiple tags were allowed
> to point to a commit; but the tags seem to be unique "objects" so I
> see no reason this should not be an expected feature?

There's no reason you can't have multiple tags pointing to the same commit.

> Thanks for any insights. Other than loosing association between the tags and
> the commits with rebase (which I was hesitant to use; and am now
> doubly so) I found git(1) to be the first version control system better than
> "be careful and make tar-balls of major releases"; although I am just
> starting to get an idea of how the pieces work.

It's generally accepted that rebasing commits that other people have
had access to is a bad idea. :-)

-PJ