# Git Notes - Track rebase/etc + reverse-lookup for bugs ideas 10 messages from 2008-11-10 to 2008-11-11. Participants: Thomas Harning, Jeff King, Johannes Schindelin, Johan Herland, Miklos Vajna. Thread: https://gitlist.dev/t/16251 ## Thomas Harning, 2008-11-10 17:37 Subject: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <6A0F154C-B9FE-4770-BF70-82A5BEBF907C@gmail.com> URL: https://gitlist.dev/e/6A0F154C-B9FE-4770-BF70-82A5BEBF907C%40gmail.com ``` Just wondering, has there been any looking into whether the git-notes concept can track rebases? Reading over what git-notes is leads me to think it could be a good mechanism for the distributed bug-tracking idea I had some time ago. The only gotcha I see is that there would have to be some reverse mapping / fast lookup to track the commit objects that given notes are attached to.... and to facilitate individual assignment... notes applied to notes. Example structure: Commits A B C D Notes BUG Notes nA nC == bug notes A <- nA |\ B C <- nC |/ D nA <- BUG nB <- BUG Operations for bug-tracking: 1) List all 'BUG'-type items that would refer to individual notes 2) List 'BUG' items reachable from a point Perhaps with criterion that a certain 'bug note' attribute is not set... or that a 'BUG_CLOSED' note is not attached to the given 'bug note' ... this seems to be somewhat of an extreme abuse of the notes system... but I could imagine it may have uses outside... ``` ## Jeff King, 2008-11-10 19:11 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <20081110191134.GA3329@sigill.intra.peff.net> URL: https://gitlist.dev/e/20081110191134.GA3329%40sigill.intra.peff.net In-Reply-To: <6A0F154C-B9FE-4770-BF70-82A5BEBF907C@gmail.com> ``` On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote: > Just wondering, has there been any looking into whether the git-notes > concept can track rebases? Not that I know of, but then again, I'm not sure exactly what you mean by "track rebases". > Reading over what git-notes is leads me to think it could be a good > mechanism for the distributed bug-tracking idea I had some time ago. > The only gotcha I see is that there would have to be some reverse mapping > / fast lookup to track the commit objects that given notes are attached > to.... and to facilitate individual assignment... notes applied to notes. You can really think of the notes facility as a way of mapping SHA1 -> SHA1. So the oft-discussed concept of "attach some text to this commit" would be a commit sha1 mapping to a blob that contains the text. You have the commit, and you want to look up the attached text. How fast you can do a reverse lookup depends on what you are given. If you are saying "I want to look through the list of all notes, and see which commits they are attached to" that is quick. You are iterating through the mapping, so you just look at the left hand side. But if you are given a SHA-1 (say, of a blob with some text) and ask "which commits map to this blob", then you will have to linearly search through the mapping. Which really _isn't_ that painful, if you are doing one such search per user request, but can be slow if you want to do it for 10,000 notes. And in the latter case, I would suggest simply building a reverse mapping. Which you _could_ make as a parallel notes namespace, but then you have to keep the two in sync. I would suggest instead simply building a hash table on the fly for the reverse mapping (which is basically what the forward-lookup does, anyway, since our tree lookup is necessarily linear). As far as attaching notes to notes, again it depends what you mean. If you mean "map a blob SHA-1 to another blob SHA-1", then that is simple. E.g., if you have some commit mapping to the text note "foo", then you can map another note "bar" onto "foo". But if you want to put a note onto the actual mapping, that is a bit different. Since notes are a commit history of trees, I would think you would simply make a new commit, and put your note into the commit message. And if you need to do so after the fact, then of course it is just putting a note onto the commit in the notes history. But bear in mind that the whole point of notes is annotating commits after the fact, since commits must remain immutable. So might it not be simpler to just update the note itself, with the new information, rather than creating a note of a note? > Operations for bug-tracking: > > 1) List all 'BUG'-type items that would refer to individual notes > 2) List 'BUG' items reachable from a point > Perhaps with criterion that a certain 'bug note' attribute is not > set... > or that a 'BUG_CLOSED' note is not attached to the given 'bug note' I'm not sure that doing bug tracking in this way makes sense with notes. If notes are a mapping of a commit sha-1 to a blob, then how do I have a commit with _two_ bugs? I think a bug database should be indexed by bug id, not by commit id which has the bug. -Peff ``` ## Jeff King, 2008-11-10 19:51 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <20081110195120.GA3688@sigill.intra.peff.net> URL: https://gitlist.dev/e/20081110195120.GA3688%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote: > > Not that I know of, but then again, I'm not sure exactly what you mean > > by "track rebases". > > I guess he means that you could have something like this > > rebased from > > in the notes for any given commit, so that _if_ you have the commit, e.g. > gitk could show that connection (maybe dashed in the graphical history > display, and as a "Rebased from:" link). You don't really need "notes" for that, though, since you can put that information into the commit message (or headers) if you choose. I guess it has the advantage of not polluting the commit for others. -Peff ``` ## Johannes Schindelin, 2008-11-10 19:51 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0811102049460.30769%40pacific.mpi-cbg.de In-Reply-To: <20081110191134.GA3329@sigill.intra.peff.net> ``` Hi, On Mon, 10 Nov 2008, Jeff King wrote: > On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote: > > > Just wondering, has there been any looking into whether the git-notes > > concept can track rebases? > > Not that I know of, but then again, I'm not sure exactly what you mean > by "track rebases". I guess he means that you could have something like this rebased from in the notes for any given commit, so that _if_ you have the commit, e.g. gitk could show that connection (maybe dashed in the graphical history display, and as a "Rebased from:" link). Ciao, Dscho ``` ## Johan Herland, 2008-11-10 20:01 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <200811102101.15285.johan@herland.net> URL: https://gitlist.dev/e/200811102101.15285.johan%40herland.net In-Reply-To: <20081110195120.GA3688@sigill.intra.peff.net> ``` On Monday 10 November 2008, Jeff King wrote: > On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote: > > > Not that I know of, but then again, I'm not sure exactly what you > > > mean by "track rebases". > > > > I guess he means that you could have something like this > > > > rebased from > > > > in the notes for any given commit, so that _if_ you have the commit, > > e.g. gitk could show that connection (maybe dashed in the graphical > > history display, and as a "Rebased from:" link). > > You don't really need "notes" for that, though, since you can put that > information into the commit message (or headers) if you choose. I guess > it has the advantage of not polluting the commit for others. Does it make sense to teach "git rebase" the -x option from "git cherry-pick"? As with "git cherry-pick -x" it only makes sense to use it if your rebasing from a public branch. Have fun! ...Johan -- Johan Herland, www.herland.net ``` ## Thomas Harning, 2008-11-10 20:26 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <74EBEC20-FC39-444E-8B96-31E5B36894B8@gmail.com> URL: https://gitlist.dev/e/74EBEC20-FC39-444E-8B96-31E5B36894B8%40gmail.com In-Reply-To: ``` On Nov 10, 2008, at 2:51 PM, Johannes Schindelin wrote: > Hi, > > On Mon, 10 Nov 2008, Jeff King wrote: > >> On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote: >> >>> Just wondering, has there been any looking into whether the git- >>> notes >>> concept can track rebases? >> >> Not that I know of, but then again, I'm not sure exactly what you >> mean >> by "track rebases". > > I guess he means that you could have something like this > > rebased from > > in the notes for any given commit, so that _if_ you have the commit, > e.g. > gitk could show that connection (maybe dashed in the graphical history > display, and as a "Rebased from:" link). What I intended is that if notes are attached to 'A', A` (after a rebase) will have the exact same note. ``` ## Miklos Vajna, 2008-11-10 20:34 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <20081110203437.GW24201@genesis.frugalware.org> URL: https://gitlist.dev/e/20081110203437.GW24201%40genesis.frugalware.org In-Reply-To: <200811102101.15285.johan@herland.net> ``` On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland wrote: > Does it make sense to teach "git rebase" the -x option from "git > cherry-pick"? As with "git cherry-pick -x" it only makes sense to use it if > your rebasing from a public branch. But rebasing a public branch is always something we try to prevent. So basically -x would be useful only in case the user does what we asked not to do. ;-) ``` ## Johannes Schindelin, 2008-11-10 20:48 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0811102147340.30769%40pacific.mpi-cbg.de In-Reply-To: <20081110195120.GA3688@sigill.intra.peff.net> ``` Hi, On Mon, 10 Nov 2008, Jeff King wrote: > On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote: > > > > Not that I know of, but then again, I'm not sure exactly what you > > > mean by "track rebases". > > > > I guess he means that you could have something like this > > > > rebased from > > > > in the notes for any given commit, so that _if_ you have the commit, > > e.g. gitk could show that connection (maybe dashed in the graphical > > history display, and as a "Rebased from:" link). > > You don't really need "notes" for that, though, since you can put that > information into the commit message (or headers) if you choose. I guess > it has the advantage of not polluting the commit for others. Exactly. And it would have the nice side effect that you could use a notes ref "rebases", and just not show it when you are not interested in looking at rebases. Ciao, Dscho ``` ## Johan Herland, 2008-11-10 21:51 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <200811102251.37044.johan@herland.net> URL: https://gitlist.dev/e/200811102251.37044.johan%40herland.net In-Reply-To: <20081110203437.GW24201@genesis.frugalware.org> ``` On Monday 10 November 2008, Miklos Vajna wrote: > On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland wrote: > > Does it make sense to teach "git rebase" the -x option from "git > > cherry-pick"? As with "git cherry-pick -x" it only makes sense to use > > it if your rebasing from a public branch. > > But rebasing a public branch is always something we try to prevent. So > basically -x would be useful only in case the user does what we asked > not to do. ;-) Sorry, I wasn't clear enough: I am talking about a copy-rebase, that is, the original public branch is unchanged, but you copy patches from it by making a local temporary branch that starts out in the same place and then rebasing it onto the other public branch where your want the patches to end up (followed by fast-forwarding the target branch and removing the temp branch). This is basically identical to cherry-picking a range of commits, but since "git cherry-pick" does not support cherry-picking a range of commits, this is the only alternative, AFAICS. However, it would probably be a better solution to make "git cherry-pick" work on a commit range... (cf. the ongoing "multiple-commit cherry-pick" thread) ...Johan -- Johan Herland, www.herland.net ``` ## Jeff King, 2008-11-11 00:31 Subject: Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas Message-ID: <20081111003136.GA26481@coredump.intra.peff.net> URL: https://gitlist.dev/e/20081111003136.GA26481%40coredump.intra.peff.net In-Reply-To: <74EBEC20-FC39-444E-8B96-31E5B36894B8@gmail.com> ``` On Mon, Nov 10, 2008 at 03:26:52PM -0500, Thomas Harning wrote: > What I intended is that if notes are attached to 'A', A` (after a > rebase) will have the exact same note. I think that may have been brought up at the GitTogether. It would be very easy, when rebasing A to A', to copy any notes for A to A' (retroactively applying notes for A' to A (or vice versa) is much harder, since we don't maintain any mapping between the two). _But_ that is not necessarily a good idea in all cases, because your notes may say certain things about A like "I tested this on system X". But you _haven't_ tested A', and it might not pass your test. Leaving aside editing the commits with "rebase -i", there might just be a bad interaction with the commit you rebased onto. So I think it would probably make sense to add a "--copy-notes" option to rebase for those times when the user knows it makes sense, but doing so by default is probably a mistake. -Peff ```