On Sun, Sep 4, 2011 at 3:32 AM, 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. Use git notes[1] to attach additional info to existing commits. Git notes will by default be copied when using git rebase or git commit --amend (cf. notes.rewrite.<command> config) > 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"? "Rebase" takes commits and creates new commits from those. The new commits are not the same as the old, although they might have associated the same tree or changeset. > 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? Tags can point to any git object (commits, trees, blobs, notes, even to other annotated tags). There's nothing wrong with that. [1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html -- typed with http://neo-layout.org myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released! -- 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