Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Thomas Harning]

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

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Jeff King]

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

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Jeff King]

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 <SHA-1>
> 
> 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

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Johannes Schindelin]

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 <SHA-1>

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

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Johan Herland]

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 <SHA-1>
> >
> > 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, <johan@herland.net>
www.herland.net

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Thomas Harning]

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 <SHA-1>
>
> 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.

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland <johan@herland.net> 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. ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Johannes Schindelin]

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 <SHA-1>
> > 
> > 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

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Johan Herland]

On Monday 10 November 2008, Miklos Vajna wrote:
> On Mon, Nov 10, 2008 at 09:01:15PM +0100, Johan Herland 
<johan@herland.net> 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, <johan@herland.net>
www.herland.net

Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas

[Jeff King]

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