{"thread":{"id":"28295","subject":"Lost association between TAGS and COMMITs when rebased a git(1) repository","startedAt":"2011-09-04T01:32:03Z","lastAt":"2011-09-07T21:35:42Z","messageCount":20,"participants":["John S. Urban","PJ Weisberg","Michael Witten","knittl","Jakub Narebski","Philip Oakley","Tor Arntsen","Thomas Rast","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174799","messageId":"FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC","threadId":"28295","inReplyTo":null,"subject":"Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"John S. Urban","fromEmail":"urbanjost@comcast.net","sentAt":"2011-09-04T01:32:03Z","receivedAt":"2011-09-04T01:32:03Z","isPatch":false,"sender":{"key":"urbanjost@comcast.net","avatar":null},"body":"With my first use of git(1) I created a small project with about 200 \n\"commits\". When this was complete, I needed to label each commit with\ninformation pointing it to a section of a document. I used tags for this. So \nfar, everything was fine. I was then asked to merge two commits\ninto one. I then did a \"rebase\" (for the first time). I then appear to have \nlost all association between the tags and the effected commits; as all \ncommits after\nthe ones I modified no longer see \"their\" tags. Was there a way to have kept \nthe tags associated with the original commits as they were \"rebased\"?\n\nAlso, I have some commits with multiple tags pointing to them. It has come \nto my attention that might not be an intentional feature. I could find\nnothing in the documentation explicitly stating multiple tags were allowed \nto point to a commit; but the tags seem to be unique \"objects\" so I\nsee no reason this should not be an expected feature?\n\nThanks for any insights. Other than loosing association between the tags and \nthe commits with rebase (which I was hesitant to use; and am now\ndoubly so) I found git(1) to be the first version control system better than \n\"be careful and make tar-balls of major releases\"; although I am just\nstarting to get an idea of how the pieces work.\n\n \n"},{"id":"174802","messageId":"CAJsNXTmJo6UXYS4AXygSLq2+T8MV0Sp0KhUt_mvgMqxC_k27ig@mail.gmail.com","threadId":"28295","inReplyTo":"FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"PJ Weisberg","fromEmail":"pj@irregularexpressions.net","sentAt":"2011-09-04T10:02:27Z","receivedAt":"2011-09-04T10:02:27Z","isPatch":false,"sender":{"key":"pj@irregularexpressions.net","avatar":"https://gravatar.com/avatar/aa2c1edcc61b536cc5c9f37fbce084e655446e2309f9818d43f13d47304a602b?d=mp&s=160"},"body":"On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban wrote:\n> With my first use of git(1) I  created a small project with about 200\n> \"commits\".  When this was complete, I needed to label each commit with\n> information pointing it to a section of a document. I used tags for this. So\n> far, everything was fine. I was then asked to merge two commits\n> into one. I then did a \"rebase\" (for the first time). I then appear to have\n> lost all association between the tags and the effected commits; as all\n> commits after\n> the ones I modified no longer see \"their\" tags. Was there a way to have kept\n> the tags associated with the original commits as they were \"rebased\"?\n\nWhen Old Biff Tannen traveled back to the year 1955 and gave his\nyounger self a copy of Grays Sports Almanac, which listed the outcomes\nof every major sporting event from the years 1950-2000, the timeline\nskewed, creating an alternate reality in which he had won enough money\nthrough gambling to take over the town of Hill Valley. If Marty McFly\nhad kept a reflog, like Git does, he could have backtracked in his\npersonal history and just not left the almanac and the time machine\nwhere Biff could find them. Instead, he had to go back to 1955 and\nsteal the almanac from young Biff after old Biff had given it to him.\nBut this metaphor is getting silly, and alienating anyone who wasn't\nwatching American movies in the late 1980s.\n\nMy point is that the tags are still there, and they still point to the\nsame commits they always pointed to. It's just that those commits are\npart of the original history, not the alternate history created by the\nrebase. People say that Git can \"rewrite\" history, but really it\ncreates a new history for the branch. The old history is still around\nas long as there are references to it, until the garbage collector\npicks it up.\n\nOnce a tag points to a commit, it isn't meant to be easy to make it\npoint to a different commit. For the same reason that you wouldn't\nrelease version 1.8.3 of some software, and then later make a new\nrelease also called 1.8.3.\n\n> Also, I have some commits with multiple tags pointing to them. It has come\n> to my attention that might not be an intentional feature. I could find\n> nothing in the documentation explicitly stating multiple tags were allowed\n> to point to a commit; but the tags seem to be unique \"objects\" so I\n> see no reason this should not be an expected feature?\n\nThere's no reason you can't have multiple tags pointing to the same commit.\n\n> Thanks for any insights. Other than loosing association between the tags and\n> the commits with rebase (which I was hesitant to use; and am now\n> doubly so) I found git(1) to be the first version control system better than\n> \"be careful and make tar-balls of major releases\"; although I am just\n> starting to get an idea of how the pieces work.\n\nIt's generally accepted that rebasing commits that other people have\nhad access to is a bad idea. :-)\n\n-PJ\n"},{"id":"174809","messageId":"CAMOZ1Bv+Lm34Q76FebEe5-VZaLim9j4rrRtke1iCqtP19fjY1Q@mail.gmail.com","threadId":"28295","inReplyTo":"CAJsNXTmJo6UXYS4AXygSLq2+T8MV0Sp0KhUt_mvgMqxC_k27ig@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-04T13:40:19Z","receivedAt":"2011-09-04T13:40:19Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Sep 4, 2011 at 10:02, PJ Weisberg wrote:\n> On Sat, Sep 3, 2011 at 6:32 PM, John S. Urban wrote:\n>> With my first use of git(1) I  created a small project with about 200\n>> \"commits\".  When this was complete, I needed to label each commit with\n>> information pointing it to a section of a document. I used tags for this. So\n>> far, everything was fine. I was then asked to merge two commits\n>> into one. I then did a \"rebase\" (for the first time). I then appear to have\n>> lost all association between the tags and the effected commits; as all\n>> commits after\n>> the ones I modified no longer see \"their\" tags. Was there a way to have kept\n>> the tags associated with the original commits as they were \"rebased\"?\n>\n> ...\n>\n> My point is that the tags are still there, and they still point to the\n> same commits they always pointed to.  It's just that those commits are\n> part of the original history, not the alternate history created by the\n> rebase.  People say that Git can \"rewrite\" history, but really it\n> creates a new history for the branch.  The old history is still around\n> as long as there are references to it, until the garbage collector\n> picks it up.\n>\n> Once a tag points to a commit, it isn't meant to be easy to make it\n> point to a different commit.  For the same reason that you wouldn't\n> release version 1.8.3 of some software, and then later make a new\n> release also called 1.8.3.\n\nPerhaps `git rebase' should accept a `--tags' flag to tell it to\nrewrite tags (or should I say `recreate' in the case of tag objects).\n\nGit should not get in the way of people who know what they are doing.\n"},{"id":"174810","messageId":"3c10d6593152436c9dd3a5b5773e3c79-mfwitten@gmail.com","threadId":"28295","inReplyTo":"FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC","subject":"Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":null,"receivedAt":"2011-09-04T13:40:19Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:\n\n> With my first use of git(1) I created a small project with about 200\n> \"commits\". When this was complete, I needed to label each commit with\n> information pointing it to a section of a document.\n\nWhat exactly does that mean?\n\n> I used tags for this.\n\nIt sounds like `git notes' or rewritten commit messages would be what is\nappropriate.\n\n> So far, everything was fine. I was then asked to merge two commits\n> into one. I then did a \"rebase\" (for the first time).\n\nYou mean `squash'; the term `merge' has a specific meaning in git\nnomenclature.\n\n> Also, I have some commits with multiple tags pointing to them. It has come\n> to my attention that might not be an intentional feature. I could find\n> nothing in the documentation explicitly stating multiple tags were allowed\n> to point to a commit; but the tags seem to be unique \"objects\" so I\n> see no reason this should not be an expected feature?\n\nWell, everybody, it sounds like John's confusion is a good example for\nwhy `tag' is another TERRIBLE choice of terminology.\n\nSee here:\n\n http://article.gmane.org/gmane.comp.version-control.git/179609\n Message-ID: \n\n http://article.gmane.org/gmane.comp.version-control.git/179942\n Message-ID: \n"},{"id":"174811","messageId":"CACx-yZ3tav1sJnLtJOn_YugQOsM9ERi7Cc7SowunyobxxX5YdA@mail.gmail.com","threadId":"28295","inReplyTo":"FF0364F3D5244CA4987EDDCFE7244BF3@urbanjsPC","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2011-09-04T14:30:26Z","receivedAt":"2011-09-04T14:30:26Z","isPatch":false,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban wrote:\n> With my first use of git(1) I created a small project with about 200\n> \"commits\". When this was complete, I needed to label each commit with\n> information pointing it to a section of a document. I used tags for this.\n\nUse git notes[1] to attach additional info to existing commits. Git\nnotes will by default be copied when using git rebase or git commit\n--amend (cf. notes.rewrite. config)\n\n> So far, everything was fine. I was then asked to merge two commits\n> into one. I then did a \"rebase\" (for the first time). I then appear to have\n> lost all association between the tags and the effected commits; as all\n> commits after\n> the ones I modified no longer see \"their\" tags. Was there a way to have kept\n> the tags associated with the original commits as they were \"rebased\"?\n\n\"Rebase\" takes commits and creates new commits from those. The new\ncommits are not the same as the old, although they might have\nassociated the same tree or changeset.\n\n> Also, I have some commits with multiple tags pointing to them. It has come\n> to my attention that might not be an intentional feature. I could find\n> nothing in the documentation explicitly stating multiple tags were allowed\n> to point to a commit; but the tags seem to be unique \"objects\" so I\n> see no reason this should not be an expected feature?\n\nTags can point to any git object (commits, trees, blobs, notes, even\nto other annotated tags). There's nothing wrong with that.\n\n[1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html\n\n--\ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"174813","messageId":"CAMOZ1Btu=TOSqJu9uu3if_RFH6UQco+dFv-edVNoW9SauVQdmQ@mail.gmail.com","threadId":"28295","inReplyTo":"CA+sFfMcMgPDyCi6SCS=Sc4XFrug_Ee7vbmBBkmkwfwwpXg8yCg@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-04T14:38:30Z","receivedAt":"2011-09-04T14:38:30Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Sep 4, 2011 at 14:16, Brandon Casey wrote:\n> That's true, but git is also a tool with a purpose and tags are intended to\n> be permanent.\n\nTag *objects* are intended to be permanent (like commit objects);\nhowever, don't forget about `lightweight' tags.\n\n> A valid workflow would need to be demonstrated before such a\n> high-level operation as rebase made it so trivial to rewrite tags methinks.\n\nHow is it any different than doing the same with commits?\n\nLet's say I have a private repository with an appreciable graph of\ncommits and collection of tags, and that I want to clean up the\nhistory a bit before publishing it publicly. Well, it might save me\na lot of trouble if I could use `rebase' to create an alternative\nhistory without also having to dicker around with creating the\nassociated tags.\n"},{"id":"174812","messageId":"CAMOZ1BtxZ5C+pH_eEBu8=oqOyY6JkP8wiFmauyqcSOeijvgA+g@mail.gmail.com","threadId":"28295","inReplyTo":"CACx-yZ3tav1sJnLtJOn_YugQOsM9ERi7Cc7SowunyobxxX5YdA@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-09-04T14:43:56Z","receivedAt":"2011-09-04T14:43:56Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Sep 4, 2011 at 14:30, knittl wrote:\n\n> \"Rebase\" takes commits and creates new commits from those. The new\n> commits are not the same as the old, although they might have\n> associated the same tree or changeset.\n\nAccording to `git help glossary':\n\n changeset\n BitKeeper/cvsps speak for \"commit\".\n Since git does not store changes, but states,\n it really does not make sense to use the term\n \"changesets\" with git.\n\nGit's erroneous nomenclature is bad enough as it is, so please try\nnot to explain things using such spurious terminology.\n"},{"id":"174814","messageId":"m362l848sw.fsf@localhost.localdomain","threadId":"28295","inReplyTo":"CAMOZ1BtxZ5C+pH_eEBu8=oqOyY6JkP8wiFmauyqcSOeijvgA+g@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-09-04T15:39:24Z","receivedAt":"2011-09-04T15:39:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Witten writes:\n> On Sun, Sep 4, 2011 at 14:30, knittl wrote:\n> \n> > \"Rebase\" takes commits and creates new commits from those. The new\n> > commits are not the same as the old, although they might have\n> > associated the same tree or changeset.\n> \n> According to `git help glossary':\n> \n> changeset\n> BitKeeper/cvsps speak for \"commit\".\n> Since git does not store changes, but states,\n> it really does not make sense to use the term\n> \"changesets\" with git.\n> \n> Git's erroneous nomenclature is bad enough as it is, so please try\n> not to explain things using such spurious terminology.\n\nActually \"changeset\", at least in the original meaning as the set of\nchanges (the difference between two snapshots), is perfectly in place\nhere: rebase operation preserves changes which means that it copies\nchangesets, at least if there are no conflicts.\n\n-- \nJakub Narębski\n"},{"id":"174816","messageId":"E06C306119F84928B8D84D5DEC7A024C@urbanjsPC","threadId":"28295","inReplyTo":"CACx-yZ1Ce3x=ZSdm5iY3JqYjVGVs5uPnb12-tMJP7zWsGuMK_Q@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"John S. Urban","fromEmail":"urbanjost@comcast.net","sentAt":"2011-09-04T16:40:56Z","receivedAt":"2011-09-04T16:40:56Z","isPatch":false,"sender":{"key":"urbanjost@comcast.net","avatar":null},"body":"Thanks to all for the replies. Perhaps the tutorials should mention notes \nmore often. I used several introductory\nmanuals; all of which mentioned tags and none of which mentioned notes. The \ntags seem (in retrospect) useful when\nI want additional sign-off capabilities. If the tags are seen only as a \nsign-off mechanism I understand why they do not\nretain their associations when you \"rewrite history\"; but I really would \nlike to see a --tags option on the rebase option\nthat lets tags keep their associations when they are not signed, as one \nreply suggested.\n\nNotes are definitely more appropriate for my purpose than tags, however. I \nhaven't tried them yet but will shortly.\n I hope to see that\nthey show up in gitk(1) as nicely as the tags do. I've been using the line \nmode but the reviewers are very happy with\ngitk(1) as an efficient way to review and sign changes (especially simple \nones).\n\nNow that I've used the basics enough to find git(1) useful I guess it's time \nto read the complete manual before I shoot\nmyself in the foot again (yeehh, like that will happen!).\n\nMuch appreciated!\n\n----- Original Message ----- \nFrom: \"knittl\" \nTo: \"John S. Urban\" \nSent: Sunday, September 04, 2011 3:55 AM\nSubject: Re: Lost association between TAGS and COMMITs when rebased a git(1) \nrepository\n\n\nOn Sun, Sep 4, 2011 at 3:32 AM, John S. Urban wrote:\n> With my first use of git(1) I created a small project with about 200\n> \"commits\". When this was complete, I needed to label each commit with\n> information pointing it to a section of a document. I used tags for this.\n\nUse git notes[1] to attach additional info to existing commits. Git\nnotes will by default be copied when using git rebase or git commit\n--amend (cf. notes.rewrite. config)\n\n> So far, everything was fine. I was then asked to merge two commits\n> into one. I then did a \"rebase\" (for the first time). I then appear to \n> have\n> lost all association between the tags and the effected commits; as all\n> commits after\n> the ones I modified no longer see \"their\" tags. Was there a way to have \n> kept\n> the tags associated with the original commits as they were \"rebased\"?\n\n\"Rebase\" takes commits and creates new commits from those. The new\ncommits are not the same as the old, although they might have\nassociated the same tree or changeset.\n\n> Also, I have some commits with multiple tags pointing to them. It has come\n> to my attention that might not be an intentional feature. I could find\n> nothing in the documentation explicitly stating multiple tags were allowed\n> to point to a commit; but the tags seem to be unique \"objects\" so I\n> see no reason this should not be an expected feature?\n\nTags can point to any git object (commits, trees, blobs, notes, even\nto other annotated tags). There's nothing wrong with that.\n\n[1]: http://www.kernel.org/pub/software/scm/git/docs/git-notes.html\n\n-- \ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"174817","messageId":"1B5C619E91F7437EA844D1D3DD3E6798@PhilipOakley","threadId":"28295","inReplyTo":"3c10d6593152436c9dd3a5b5773e3c79-mfwitten@gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-09-04T17:20:10Z","receivedAt":"2011-09-04T17:20:10Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Michael Witten\" \n> On Sat, 3 Sep 2011 21:32:03 -0400, John S. Urban wrote:\n>> Also, I have some commits with multiple tags pointing to them. It has \n>> come\n>> to my attention that might not be an intentional feature. I could find\n>> nothing in the documentation explicitly stating multiple tags were \n>> allowed\n>> to point to a commit; but the tags seem to be unique \"objects\" so I\n>> see no reason this should not be an expected feature?\n>\n> Well, everybody, it sounds like John's confusion is a good example for\n> why `tag' is another TERRIBLE choice of terminology.\n>\n> See here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/179609\n> Message-ID: \n> \n>\n> http://article.gmane.org/gmane.comp.version-control.git/179942\n> Message-ID: \n> \n> --\nIn terms of things understood and misunderstood, I found that Branches and \nTags were reasonable terms for use within Git at the time I read about them \n(I'm still getting to grips with git in a hostile Windows environment).\n\nThere were other areas of confusing (to me) terminology, such as heads, \ntips, and refs, which are 'the same' within particular contexts. In the same \nway the Index/Staging area can be confusing without a good visualisation.\n\nThe fact that Git has both Trees, and Branches but relating to different \nparts of the architecture can be a bit confusing, but wasn't too much of a \nhassle.\n\nThe fact that git does merging with relative ease is one reason that brings \non the 'branch' problem. If merging is a major activity that is kept \nindependent of the SCM, as it often is, then branches take on a bigger \nmeaning as being proper sub-projects with all the attention that comes from \nthere. If they are simple, lightweight, easy to use, and 'discard' then the \nconcerns should reduce, unless that is, local customs keep worrying the \nissue. Most SCM systems are built on archaic principles that pre-date \ncomputers, so a new methodology has an uphill battle.\n\nIn terms of Figure 0 in Sourceforge, It doesn't fully represent the \ninformation that Git would have, because the order of parentage would be \navailable, though Git doesn't mandate that branch names are remembered (but \nis normally within merge commit messages). This means that some folks would \nfeel unhappy about the bundle of diverge/merge links in the DAG that don't \nhave Names, which is a very human concern.\n\nOverall, I'm not too unhappy with the terminology, and yes I would like \nfilter-branch to be able to copy across tags when creating a publishable \nhistory - it probably just need me to understnd the right --tag-name-filter \n.\n\nPhilip\n"},{"id":"174818","messageId":"CACx-yZ0MJq45yUBK5T1mLwXh-maVM0WDwAz7Q4Aswh=PWQYsHg@mail.gmail.com","threadId":"28295","inReplyTo":"1B5C619E91F7437EA844D1D3DD3E6798@PhilipOakley","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"knittl","fromEmail":"knittl89@googlemail.com","sentAt":"2011-09-04T18:15:07Z","receivedAt":"2011-09-04T18:15:07Z","isPatch":false,"sender":{"key":"knittl89@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/2149217?v=4"},"body":"On Sun, Sep 4, 2011 at 7:20 PM, Philip Oakley wrote:\n> Overall, I'm not too unhappy with the terminology, and yes I would like\n> filter-branch to be able to copy across tags when creating a publishable\n> history - it probably just need me to understand the right --tag-name-filter\n> .\n\nfilter-branch --tag-name-filter 'cat' ;) – it's even mentioned in the\nmanpage of filter-branch:\n\n> The original tags are not deleted, but can be overwritten; use\n> \"--tag-name-filter cat\" to simply update the tags. In this case, be\n> very careful and make sure you have the old tags backed up in case\n> the conversion has run afoul.\n\nunless you meant rebase with filter-branch?\n\n-- \ntyped with http://neo-layout.org\nmyFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!\n"},{"id":"174819","messageId":"CABNEGjyXLnSvjhBewNDsjW=rthRh0HY+KgC05vPNPu5QCaAgXQ@mail.gmail.com","threadId":"28295","inReplyTo":"CACx-yZ3tav1sJnLtJOn_YugQOsM9ERi7Cc7SowunyobxxX5YdA@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2011-09-04T18:16:50Z","receivedAt":"2011-09-04T18:16:50Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Sun, Sep 4, 2011 at 4:30 PM, knittl wrote:\n>\n> On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban wrote:\n> > With my first use of git(1) I  created a small project with about 200\n> > \"commits\".  When this was complete, I needed to label each commit with\n> > information pointing it to a section of a document. I used tags for this.\n>\n> Use git notes[1] to attach additional info to existing commits. Git\n> notes will by default be copied when using git rebase or git commit\n> --amend (cf. notes.rewrite. config)\n\nIs that true? I've always lost the notes when rebasing. I just tried\nthat again now (1.7.5.4), and after a rebase the notes attached to any\ncommit that was rebased just disappeared. I've always had to hunt down\nand re-create the notes. It would indeed be much more convenient if\nthe notes would tag along.\n\n-Tor\n"},{"id":"174820","messageId":"201109042043.01159.trast@student.ethz.ch","threadId":"28295","inReplyTo":"CABNEGjyXLnSvjhBewNDsjW=rthRh0HY+KgC05vPNPu5QCaAgXQ@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-09-04T18:43:00Z","receivedAt":"2011-09-04T18:43:00Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Tor Arntsen wrote:\n> On Sun, Sep 4, 2011 at 4:30 PM, knittl wrote:\n> >\n> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban wrote:\n> > > With my first use of git(1) I created a small project with about 200\n> > > \"commits\". When this was complete, I needed to label each commit with\n> > > information pointing it to a section of a document. I used tags for this.\n> >\n> > Use git notes[1] to attach additional info to existing commits. Git\n> > notes will by default be copied when using git rebase or git commit\n> > --amend (cf. notes.rewrite. config)\n> \n> Is that true? I've always lost the notes when rebasing. I just tried\n> that again now (1.7.5.4), and after a rebase the notes attached to any\n> commit that was rebased just disappeared. I've always had to hunt down\n> and re-create the notes. It would indeed be much more convenient if\n> the notes would tag along.\n\nYes, that support has been present since 1.7.1, but it's not enabled\nby default: you need to configure notes.rewriteRef.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"174824","messageId":"CABNEGjy8M-pFTOs504Q1+G_DtocJwvzDyOAsJp9cn4BOSkv1TQ@mail.gmail.com","threadId":"28295","inReplyTo":"201109042043.01159.trast@student.ethz.ch","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2011-09-04T19:11:26Z","receivedAt":"2011-09-04T19:11:26Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast wrote:\n> Tor Arntsen wrote:\n>> On Sun, Sep 4, 2011 at 4:30 PM, knittl wrote:\n>> >\n>> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban wrote:\n>> > > With my first use of git(1) I  created a small project with about 200\n>> > > \"commits\".  When this was complete, I needed to label each commit with\n>> > > information pointing it to a section of a document. I used tags for this.\n>> >\n>> > Use git notes[1] to attach additional info to existing commits. Git\n>> > notes will by default be copied when using git rebase or git commit\n>> > --amend (cf. notes.rewrite. config)\n>>\n>> Is that true? I've always lost the notes when rebasing. I just tried\n>> that again now (1.7.5.4), and after a rebase the notes attached to any\n>> commit that was rebased just disappeared. I've always had to hunt down\n>> and re-create the notes. It would indeed be much more convenient if\n>> the notes would tag along.\n>\n> Yes, that support has been present since 1.7.1, but it's not enabled\n> by default: you need to configure notes.rewriteRef.\n\nThanks. Got it working. So it's not by default, as was suggested by\nknittl, it has to be enabled. BTW, it's not at all obvious from the\nmanpage what it should be set to, there's no actual example. Found it\nby trial&error plus finding a diff for a test.\n\n-Tor\n"},{"id":"174829","messageId":"E8AFFECA8E294A55B0E2918B205113A6@urbanjsPC","threadId":"28295","inReplyTo":"CABNEGjy8M-pFTOs504Q1+G_DtocJwvzDyOAsJp9cn4BOSkv1TQ@mail.gmail.com","subject":"Re: Lost association between TAGS and COMMITs when rebased a git(1) repository","fromName":"John S. Urban","fromEmail":"urbanjost@comcast.net","sentAt":"2011-09-04T20:18:30Z","receivedAt":"2011-09-04T20:18:30Z","isPatch":false,"sender":{"key":"urbanjost@comcast.net","avatar":null},"body":"Thanks for catching how this is not the default, and that it needs set. But \nexactly what is the value that works?\n----- Original Message ----- \nFrom: \"Tor Arntsen\" \nTo: \"Thomas Rast\" \nCc: \"knittl\" ; \"John S. Urban\" \n; \nSent: Sunday, September 04, 2011 3:11 PM\nSubject: Re: Lost association between TAGS and COMMITs when rebased a git(1) \nrepository\n\n\nOn Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast wrote:\n> Tor Arntsen wrote:\n>> On Sun, Sep 4, 2011 at 4:30 PM, knittl wrote:\n>> >\n>> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban \n>> > wrote:\n>> > > With my first use of git(1) I created a small project with about 200\n>> > > \"commits\". When this was complete, I needed to label each commit with\n>> > > information pointing it to a section of a document. I used tags for \n>> > > this.\n>> >\n>> > Use git notes[1] to attach additional info to existing commits. Git\n>> > notes will by default be copied when using git rebase or git commit\n>> > --amend (cf. notes.rewrite. config)\n>>\n>> Is that true? I've always lost the notes when rebasing. I just tried\n>> that again now (1.7.5.4), and after a rebase the notes attached to any\n>> commit that was rebased just disappeared. I've always had to hunt down\n>> and re-create the notes. It would indeed be much more convenient if\n>> the notes would tag along.\n>\n> Yes, that support has been present since 1.7.1, but it's not enabled\n> by default: you need to configure notes.rewriteRef.\n\nThanks. Got it working. So it's not by default, as was suggested by\nknittl, it has to be enabled. BTW, it's not at all obvious from the\nmanpage what it should be set to, there's no actual example. Found it\nby trial&error plus finding a diff for a test.\n\n-Tor\n"},{"id":"174830","messageId":"f415402994735a60664e1f9f85be490a68b25ed3.1315167848.git.trast@student.ethz.ch","threadId":"28295","inReplyTo":"CABNEGjy8M-pFTOs504Q1+G_DtocJwvzDyOAsJp9cn4BOSkv1TQ@mail.gmail.com","subject":"[PATCH] Documentation: \"on for all\" configuration of notes.rewriteRef","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-09-04T20:28:57Z","receivedAt":"2011-09-04T20:28:57Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Users had problems finding a working setting for notes.rewriteRef.\nDocument how to enable rewriting for all notes.\n\nSigned-off-by: Thomas Rast \n---\n[Sorry for the spam; the first one lacks my reply blurb and the\nin-reply-to. :-( ]\n\nTor Arntsen wrote:\n> Thanks. Got it working. So it's not by default, as was suggested by\n> knittl, it has to be enabled. BTW, it's not at all obvious from the\n> manpage what it should be set to, there's no actual example. Found it\n> by trial&error plus finding a diff for a test.\n\nLet's document it then. This still won't help you find out about the\noption/feature in the first place, though. Maybe we should flip the\ndefault to enabled?\n\n Documentation/config.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 0ecef9d..302b2d0 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1464,7 +1464,8 @@ notes.rewriteRef::\n \tYou may also specify this configuration several times.\n +\n Does not have a default value; you must configure this variable to\n-enable note rewriting.\n+enable note rewriting. Set it to `refs/notes/*` to enable rewriting\n+for all notes.\n +\n This setting can be overridden with the `GIT_NOTES_REWRITE_REF`\n environment variable, which must be a colon separated list of refs or\n-- \n1.7.7.rc0.420.g468b7\n"},{"id":"174831","messageId":"4E63E2FF.2070603@spacetec.no","threadId":"28295","inReplyTo":"f415402994735a60664e1f9f85be490a68b25ed3.1315167848.git.trast@student.ethz.ch","subject":"Re: [PATCH] Documentation: \"on for all\" configuration of notes.rewriteRef","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2011-09-04T20:43:43Z","receivedAt":"2011-09-04T20:43:43Z","isPatch":true,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"\nOn 04/09/2011 22:28, Thomas Rast wrote:\n> \n> Users had problems finding a working setting for notes.rewriteRef.\n> Document how to enable rewriting for all notes.\n> \n> Signed-off-by: Thomas Rast \n> ---\n> [Sorry for the spam; the first one lacks my reply blurb and the\n> in-reply-to. :-( ]\n> \n> Tor Arntsen wrote:\n>> Thanks. Got it working. So it's not by default, as was suggested by\n>> knittl, it has to be enabled. BTW, it's not at all obvious from the\n>> manpage what it should be set to, there's no actual example. Found it\n>> by trial&error plus finding a diff for a test.\n> \n> Let's document it then. This still won't help you find out about the\n> option/feature in the first place, though. Maybe we should flip the\n> default to enabled?\n> \n> Documentation/config.txt | 3 ++-\n> 1 files changed, 2 insertions(+), 1 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 0ecef9d..302b2d0 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1464,7 +1464,8 @@ notes.rewriteRef::\n> \tYou may also specify this configuration several times.\n> +\n> Does not have a default value; you must configure this variable to\n> -enable note rewriting.\n> +enable note rewriting. Set it to `refs/notes/*` to enable rewriting\n> +for all notes.\n> +\n> This setting can be overridden with the `GIT_NOTES_REWRITE_REF`\n> environment variable, which must be a colon separated list of refs or\n\nLooks good to me, it would have been sufficient for me to find it \nright away. But, as you say, it requires you to know or be told about \nthe feature in the first place.. \nAs far as I'm concerned it would be perfect if it was set to refs/notes/*\nby default, but people are using notes for all kinds of things. Maybe there\nare issues with using that default that I don't know about.\n\n-Tor\n"},{"id":"175039","messageId":"20110907212310.GH13364@sigill.intra.peff.net","threadId":"28295","inReplyTo":"f415402994735a60664e1f9f85be490a68b25ed3.1315167848.git.trast@student.ethz.ch","subject":"Re: [PATCH] Documentation: \"on for all\" configuration of notes.rewriteRef","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-07T21:23:10Z","receivedAt":"2011-09-07T21:23:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:\n\n> Users had problems finding a working setting for notes.rewriteRef.\n> Document how to enable rewriting for all notes.\n\nHmm. Is this a safe thing to recommend?\n\nI think the idea of storing something like generation numbers in\ngit-notes is dead at this point, but it would be quite disastrous to\nhave generation numbers copied to rebased commits. Ditto for something\nlike a patch-id cache. Should these sorts of immutable cache notes, if\nand when they do come about, go into a separate hierarchy?\n\n-Peff\n"},{"id":"175040","messageId":"201109072329.18338.trast@student.ethz.ch","threadId":"28295","inReplyTo":"20110907212310.GH13364@sigill.intra.peff.net","subject":"Re: [PATCH] Documentation: \"on for all\" configuration of notes.rewriteRef","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-09-07T21:29:17Z","receivedAt":"2011-09-07T21:29:17Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> On Sun, Sep 04, 2011 at 10:27:04PM +0200, Thomas Rast wrote:\n> \n> > Users had problems finding a working setting for notes.rewriteRef.\n> > Document how to enable rewriting for all notes.\n> \n> Hmm. Is this a safe thing to recommend?\n> \n> I think the idea of storing something like generation numbers in\n> git-notes is dead at this point, but it would be quite disastrous to\n> have generation numbers copied to rebased commits. Ditto for something\n> like a patch-id cache. Should these sorts of immutable cache notes, if\n> and when they do come about, go into a separate hierarchy?\n\nAdmittedly I never considered the problem of supposedly-immutable\nnotes here. The whole point was to help users who had no idea that\nthe string put there should probably start with refs/notes/.\n\nSo maybe the patch should instead say something along the lines of, to\nenable rewriting for the notes ref called foo, put refs/notes/foo --\nwhich to a core gitter of course sounds extremely redundant.\n\nBut what about the general issue of users who *have* put refs/notes/*,\nand then some software comes along that does not expect them to be\nrewritten? Do we declare the software broken, or discourage from such\nblanket rewriting?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"175041","messageId":"20110907213542.GA26388@sigill.intra.peff.net","threadId":"28295","inReplyTo":"201109072329.18338.trast@student.ethz.ch","subject":"Re: [PATCH] Documentation: \"on for all\" configuration of notes.rewriteRef","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-07T21:35:42Z","receivedAt":"2011-09-07T21:35:42Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 07, 2011 at 11:29:17PM +0200, Thomas Rast wrote:\n\n> Admittedly I never considered the problem of supposedly-immutable\n> notes here. The whole point was to help users who had no idea that\n> the string put there should probably start with refs/notes/.\n> \n> So maybe the patch should instead say something along the lines of, to\n> enable rewriting for the notes ref called foo, put refs/notes/foo --\n> which to a core gitter of course sounds extremely redundant.\n> \n> But what about the general issue of users who *have* put refs/notes/*,\n> and then some software comes along that does not expect them to be\n> rewritten? Do we declare the software broken, or discourage from such\n> blanket rewriting?\n\nI think putting \"refs/notes/*\" is a perfectly reasonable thing from the\nuser's perspective, and I'd hate to take away that convenience (and\nespecially, I think in the long run, we'd like to have a hierarchy of\nnotes that have rewriting turned on by default).\n\nThe cache code is probably what should be changed, then. It can move to\n\"refs/cache\", I guess, though I'm not too happy with that. The notes\ncode assumes refs/notes in several places, and it's nice to be able to\nlook at the cache trees with \"--notes=cache/foo\".\n\nMaybe some way of saying \"every notes tree gets rewriting, except ones\nin refs/notes/cache\"?\n\nRight now it's not a big problem. The only such immutable cache in a\nreleased version of git is the textconv cache, and it only contains\nblobs. Which, AFAIK, cannot be subject to rewriting. So we could put it\noff until another such cache comes along.\n\n-Peff\n"}]}