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

Thanks to all for the replies. Perhaps the tutorials should mention notes 
more often. I used several introductory
manuals; all of which mentioned tags and none of which mentioned notes. The 
tags seem (in retrospect) useful when
I want additional sign-off capabilities. If the tags are seen only as a 
sign-off mechanism I understand why they do not
retain their associations when you "rewrite history"; but I really would 
like to see a --tags option on the rebase option
that lets tags keep their associations when they are not signed, as one 
reply suggested.

Notes are definitely more appropriate for my purpose than tags, however. I 
haven't tried them yet but will shortly.
 I hope to see that
they show up in gitk(1) as nicely as the tags do. I've been using the line 
mode but the reviewers are very happy with
gitk(1) as an efficient way to review and sign changes (especially simple 
ones).

Now that I've used the basics enough to find git(1) useful I guess it's time 
to read the complete manual before I shoot
myself in the foot again (yeehh, like that will happen!).

Much appreciated!

----- Original Message ----- 
From: "knittl" <redacted>
To: "John S. Urban" <redacted>
Sent: Sunday, September 04, 2011 3:55 AM
Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1) 
repository


On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban [off-list ref] 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!