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

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

[John S. Urban]

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

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?

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.

 

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

[PJ Weisberg]

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

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

[Michael Witten]

On Sun, Sep 4, 2011 at 10:02, PJ Weisberg <pj@irregularexpressions.net> wrote:
> 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"?
>
> ...
>
> 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.

Perhaps `git rebase' should accept a `--tags' flag to tell it to
rewrite tags (or should I say `recreate' in the case of tag objects).

Git should not get in the way of people who know what they are doing.

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

[Michael Witten]

On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban 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.

What exactly does that mean?

> I used tags for this.

It sounds like `git notes' or rewritten commit messages would be what is
appropriate.

> So far, everything was fine. I was then asked to merge two commits
> into one. I then did a "rebase" (for the first time).

You mean `squash'; the term `merge' has a specific meaning in git
nomenclature.

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

Well, everybody, it sounds like John's confusion is a good example for
why `tag' is another TERRIBLE choice of terminology.

See here:

  http://article.gmane.org/gmane.comp.version-control.git/179609
  Message-ID: <CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com>

  http://article.gmane.org/gmane.comp.version-control.git/179942
  Message-ID: <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>

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

[knittl]

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!

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

[Michael Witten]

On Sun, Sep 4, 2011 at 14:16, Brandon Casey <drafnel@gmail.com> wrote:
> That's true, but git is also a tool with a purpose and tags are intended to
> be permanent.

Tag *objects* are intended to be permanent (like commit objects);
however, don't forget about `lightweight' tags.

> A valid workflow would need to be demonstrated before such a
> high-level operation as rebase made it so trivial to rewrite tags methinks.

How is it any different than doing the same with commits?

Let's say I have a private repository with an appreciable graph of
commits and collection of tags, and that I want to clean up the
history a bit before publishing it publicly. Well, it might save me
a lot of trouble if I could use `rebase' to create an alternative
history without also having to dicker around with creating the
associated tags.

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

[Michael Witten]

On Sun, Sep 4, 2011 at 14:30, knittl <knittl89@googlemail.com> wrote:

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

According to `git help glossary':

  changeset
      BitKeeper/cvsps speak for "commit".
      Since git does not store changes, but states,
      it really does not make sense to use the term
      "changesets" with git.

Git's erroneous nomenclature is bad enough as it is, so please try
not to explain things using such spurious terminology.

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

[Jakub Narebski]

Michael Witten <mfwitten@gmail.com> writes:
> On Sun, Sep 4, 2011 at 14:30, knittl <knittl89@googlemail.com> wrote:
> 
> > "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.
> 
> According to `git help glossary':
> 
>   changeset
>       BitKeeper/cvsps speak for "commit".
>       Since git does not store changes, but states,
>       it really does not make sense to use the term
>       "changesets" with git.
> 
> Git's erroneous nomenclature is bad enough as it is, so please try
> not to explain things using such spurious terminology.

Actually "changeset", at least in the original meaning as the set of
changes (the difference between two snapshots), is perfectly in place
here: rebase operation preserves changes which means that it copies
changesets, at least if there are no conflicts.

-- 
Jakub Narębski

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

[John S. Urban]

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!

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

[Philip Oakley]

From: "Michael Witten" <mfwitten@gmail.com>
> On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:
>> 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?
>
> Well, everybody, it sounds like John's confusion is a good example for
> why `tag' is another TERRIBLE choice of terminology.
>
> See here:
>
>  http://article.gmane.org/gmane.comp.version-control.git/179609
>  Message-ID: 
> <CAMOZ1Btmk86vmp1gRuCfG7yRuc6fD3_oYBvtq2VKK9Ywu8ay0A@mail.gmail.com>
>
>  http://article.gmane.org/gmane.comp.version-control.git/179942
>  Message-ID: 
> <CAMOZ1Bti3ZtAEOtLiUYSkWE+rO_VQd09NAn58Cn4hZBu8f-aFQ@mail.gmail.com>
> --
In terms of things understood and misunderstood, I found that Branches and 
Tags were reasonable terms for use within Git at the time I read about them 
(I'm still getting to grips with git in a hostile Windows environment).

There were other areas of confusing (to me) terminology, such as heads, 
tips, and refs, which are 'the same' within particular contexts. In the same 
way the Index/Staging area can be confusing without a good visualisation.

The fact that Git has both Trees, and Branches but relating to different 
parts of the architecture can be a bit confusing, but wasn't too much of a 
hassle.

The fact that git does merging with relative ease is one reason that brings 
on the 'branch' problem. If merging is a major activity that is kept 
independent of the SCM, as it often is, then branches take on a bigger 
meaning as being proper sub-projects with all the attention that comes from 
there. If they are simple, lightweight, easy to use, and 'discard' then the 
concerns should reduce, unless that is, local customs keep worrying the 
issue. Most SCM systems are built on archaic principles that pre-date 
computers, so a new methodology has an uphill battle.

In terms of Figure 0 in Sourceforge, It doesn't fully represent the 
information that Git would have, because the order of parentage would be 
available, though Git doesn't mandate that branch names are remembered (but 
is normally within merge commit messages). This means that some folks would 
feel unhappy about the bundle of diverge/merge links in the DAG that don't 
have Names, which is a very human concern.

Overall, I'm not too unhappy with the terminology, and yes I would like 
filter-branch to be able to copy across tags when creating a publishable 
history - it probably just need me to understnd the right --tag-name-filter 
<command>.

Philip

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

[knittl]

On Sun, Sep 4, 2011 at 7:20 PM, Philip Oakley <philipoakley@iee.org> wrote:
> Overall, I'm not too unhappy with the terminology, and yes I would like
> filter-branch to be able to copy across tags when creating a publishable
> history - it probably just need me to understand the right --tag-name-filter
> <command>.

filter-branch --tag-name-filter 'cat' ;) – it's even mentioned in the
manpage of filter-branch:

> The original tags are not deleted, but can be overwritten; use
>  "--tag-name-filter cat" to simply update the tags. In this case, be
> very careful and make sure you have the old tags backed up in case
> the conversion has run afoul.

unless you meant rebase with filter-branch?

-- 
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!

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

[Tor Arntsen]

On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>
> 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)

Is that true? I've always lost the notes when rebasing. I just tried
that again now (1.7.5.4), and after a rebase the notes attached to any
commit that was rebased just disappeared. I've always had to hunt down
and re-create the notes. It would indeed be much more convenient if
the notes would tag along.

-Tor

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

[Thomas Rast]

Tor Arntsen wrote:
> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
> >
> > 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)
> 
> Is that true? I've always lost the notes when rebasing. I just tried
> that again now (1.7.5.4), and after a rebase the notes attached to any
> commit that was rebased just disappeared. I've always had to hunt down
> and re-create the notes. It would indeed be much more convenient if
> the notes would tag along.

Yes, that support has been present since 1.7.1, but it's not enabled
by default: you need to configure notes.rewriteRef.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

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

[Tor Arntsen]

On Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Tor Arntsen wrote:
>> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>> >
>> > 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)
>>
>> Is that true? I've always lost the notes when rebasing. I just tried
>> that again now (1.7.5.4), and after a rebase the notes attached to any
>> commit that was rebased just disappeared. I've always had to hunt down
>> and re-create the notes. It would indeed be much more convenient if
>> the notes would tag along.
>
> Yes, that support has been present since 1.7.1, but it's not enabled
> by default: you need to configure notes.rewriteRef.

Thanks. Got it working. So it's not by default, as was suggested by
knittl, it has to be enabled. BTW, it's not at all obvious from the
manpage what it should be set to, there's no actual example. Found it
by trial&error plus finding a diff for a test.

-Tor

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

[John S. Urban]

Thanks for catching how this is not the default, and that it needs set. But 
exactly what is the value that works?
----- Original Message ----- 
From: "Tor Arntsen" <tor@spacetec.no>
To: "Thomas Rast" <trast@student.ethz.ch>
Cc: "knittl" <knittl89@googlemail.com>; "John S. Urban" 
<urbanjost@comcast.net>; <git@vger.kernel.org>
Sent: Sunday, September 04, 2011 3:11 PM
Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1) 
repository


On Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Tor Arntsen wrote:
>> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>> >
>> > 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)
>>
>> Is that true? I've always lost the notes when rebasing. I just tried
>> that again now (1.7.5.4), and after a rebase the notes attached to any
>> commit that was rebased just disappeared. I've always had to hunt down
>> and re-create the notes. It would indeed be much more convenient if
>> the notes would tag along.
>
> Yes, that support has been present since 1.7.1, but it's not enabled
> by default: you need to configure notes.rewriteRef.

Thanks. Got it working. So it's not by default, as was suggested by
knittl, it has to be enabled. BTW, it's not at all obvious from the
manpage what it should be set to, there's no actual example. Found it
by trial&error plus finding a diff for a test.

-Tor

[PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Thomas Rast]

Users had problems finding a working setting for notes.rewriteRef.
Document how to enable rewriting for all notes.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[Sorry for the spam; the first one lacks my reply blurb and the
in-reply-to. :-( ]

Tor Arntsen wrote:
> Thanks. Got it working. So it's not by default, as was suggested by
> knittl, it has to be enabled. BTW, it's not at all obvious from the
> manpage what it should be set to, there's no actual example. Found it
> by trial&error plus finding a diff for a test.

Let's document it then.  This still won't help you find out about the
option/feature in the first place, though.  Maybe we should flip the
default to enabled?

 Documentation/config.txt |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0ecef9d..302b2d0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1464,7 +1464,8 @@ notes.rewriteRef::
 	You may also specify this configuration several times.
 +
 Does not have a default value; you must configure this variable to
-enable note rewriting.
+enable note rewriting.  Set it to `refs/notes/*` to enable rewriting
+for all notes.
 +
 This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
 environment variable, which must be a colon separated list of refs or
-- 
1.7.7.rc0.420.g468b7

Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Tor Arntsen]

On 04/09/2011 22:28, Thomas Rast wrote:
> 
> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for all notes.
> 
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> [Sorry for the spam; the first one lacks my reply blurb and the
> in-reply-to. :-( ]
> 
> Tor Arntsen wrote:
>> Thanks. Got it working. So it's not by default, as was suggested by
>> knittl, it has to be enabled. BTW, it's not at all obvious from the
>> manpage what it should be set to, there's no actual example. Found it
>> by trial&error plus finding a diff for a test.
> 
> Let's document it then.  This still won't help you find out about the
> option/feature in the first place, though.  Maybe we should flip the
> default to enabled?
> 
>  Documentation/config.txt |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 0ecef9d..302b2d0 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1464,7 +1464,8 @@ notes.rewriteRef::
>  	You may also specify this configuration several times.
>  +
>  Does not have a default value; you must configure this variable to
> -enable note rewriting.
> +enable note rewriting.  Set it to `refs/notes/*` to enable rewriting
> +for all notes.
>  +
>  This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
>  environment variable, which must be a colon separated list of refs or

Looks good to me, it would have been sufficient for me to find it 
right away. But, as you say, it requires you to know or be told about 
the feature in the first place.. 
As far as I'm concerned it would be perfect if it was set to refs/notes/*
by default, but people are using notes for all kinds of things. Maybe there
are issues with using that default that I don't know about.

-Tor

Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Jeff King]

On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:

> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for all notes.

Hmm. Is this a safe thing to recommend?

I think the idea of storing something like generation numbers in
git-notes is dead at this point, but it would be quite disastrous to
have generation numbers copied to rebased commits. Ditto for something
like a patch-id cache. Should these sorts of immutable cache notes, if
and when they do come about, go into a separate hierarchy?

-Peff

Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Thomas Rast]

Jeff King wrote:
> On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:
> 
> > Users had problems finding a working setting for notes.rewriteRef.
> > Document how to enable rewriting for all notes.
> 
> Hmm. Is this a safe thing to recommend?
> 
> I think the idea of storing something like generation numbers in
> git-notes is dead at this point, but it would be quite disastrous to
> have generation numbers copied to rebased commits. Ditto for something
> like a patch-id cache. Should these sorts of immutable cache notes, if
> and when they do come about, go into a separate hierarchy?

Admittedly I never considered the problem of supposedly-immutable
notes here.  The whole point was to help users who had no idea that
the string put there should probably start with refs/notes/.

So maybe the patch should instead say something along the lines of, to
enable rewriting for the notes ref called foo, put refs/notes/foo --
which to a core gitter of course sounds extremely redundant.

But what about the general issue of users who *have* put refs/notes/*,
and then some software comes along that does not expect them to be
rewritten?  Do we declare the software broken, or discourage from such
blanket rewriting?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef

[Jeff King]

On Wed, Sep 07, 2011 at 11:29:17PM +0200, Thomas Rast wrote:

> Admittedly I never considered the problem of supposedly-immutable
> notes here.  The whole point was to help users who had no idea that
> the string put there should probably start with refs/notes/.
> 
> So maybe the patch should instead say something along the lines of, to
> enable rewriting for the notes ref called foo, put refs/notes/foo --
> which to a core gitter of course sounds extremely redundant.
> 
> But what about the general issue of users who *have* put refs/notes/*,
> and then some software comes along that does not expect them to be
> rewritten?  Do we declare the software broken, or discourage from such
> blanket rewriting?

I think putting "refs/notes/*" is a perfectly reasonable thing from the
user's perspective, and I'd hate to take away that convenience (and
especially, I think in the long run, we'd like to have a hierarchy of
notes that have rewriting turned on by default).

The cache code is probably what should be changed, then. It can move to
"refs/cache", I guess, though I'm not too happy with that. The notes
code assumes refs/notes in several places, and it's nice to be able to
look at the cache trees with "--notes=cache/foo".

Maybe some way of saying "every notes tree gets rewriting, except ones
in refs/notes/cache"?

Right now it's not a big problem. The only such immutable cache in a
released version of git is the textconv cache, and it only contains
blobs. Which, AFAIK, cannot be subject to rewriting. So we could put it
off until another such cache comes along.

-Peff