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

["John S. Urban" <urbanjost@comcast.net>]

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" <knittl89@googlemail.com>
To: "John S. Urban" <urbanjost@comcast.net>
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 <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.

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!