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