Does anyone use git-notes?

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

Thanks,
Scott

  ----- Original Message -----
From: Scott Chacon
Date: 8/25/2010 12:15 PM

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

I do.  I use them to automatically store a matching Perforce revision 
number for a given Git commit.  Only the server assigns them due to the 
merging issues.  I also change the ref, so they read as p4notes.

It irks me, though, that they show in the gitk --all view.  ARGH!

Josh

Scott Chacon wrote:

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

I run a cronjob that downloads mail from gmane and fetches git.git,
then attempts to correlate mail with commits.  The results are at

  git://repo.or.cz/git/trast.git notes/terse notes/full

I have previously posted about this at e.g.

  http://mid.gmane.org/200902091508.11460.trast@student.ethz.ch
  http://mid.gmane.org/201003042321.36240.trast@student.ethz.ch

though I should point out that it no longer tries to apply the patches
as outlined in the first post; this was simply way too expensive.


I also use it when heavily editing a patch series to tack little
reminders on my fixup patches.  I have

  $ git config alias.fixup
  !sh -c 'r=$1; git commit -m"fixup! $(git log -1 --pretty=%s $r)"' -

so I usually do

  # hack
  git add -p
  git fixup HEAD~3
  git notes add -m 'fix foo'

which combined with notes.rewriteRef=refs/notes/* (and
notes.rewriteMode left at the default of 'concatenate') means that I
end up having a little list of reminders what changed since the last
revisions.  I then simply clear them out before starting a new round.

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

On Wed, Aug 25, 2010 at 20:15, Scott Chacon [off-list ref] wrote:

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

I use Notes in a very simplistic way. For example, with an emulator
I'm writing I have two or three ways of using git-notes:
1: I commit fixes and changes with a commit message describing the
fix. Later I may find out that the fix made a couple more programs of
the set I have run in the emulator, so I add a note to the commit
saying 'This change makes X and Y work'.
2: I add test cases to the instruction validator I wrote for the
emulator, if the test currently fails I say so in the commit message.
At some later point I may commit a fix that lets the test pass, then I
go back to the original commit message (which said the test currently
failed) and add a note saying 'Fixed by [commit] nnnnnnn'.
3: Occasionally I just use notes as a reminder. If a commit adds a new
feature I may later (after using the feature) add a 'todo'-note about
what improvements I should add.

One use case I have thought of for the company case is to add notes to
a release commit with information that wasn't  or couldn't be added at
the time of the commit, e.g. a list of problem reports closed by the
release.  But I haven't actually figured out how I can get Notes
transferred over a pull yet.. although I haven't tried since 1.7.0.

-Tor

Scott Chacon venit, vidit, dixit 25.08.2010 20:15:

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

I use it to store the patch comments (the part that goes after the
"---", before the diff) along with my commits so that I have them in my
git.git tree, not only in my mbox. This makes it also easier to redo a
patch and keep the comment when regenerating the patch e-mail with
format-patch. (I don't have a good solution for the cover letter yet.)

Michael

On Thu, Aug 26, 2010 at 4:15 AM, Scott Chacon [off-list ref] wrote:

I would like to write a post on how to use them, but I'm a bit
confused as to how people actually use them on a day to day basis.  I
appears to me in trying to work out a flow for them that the lack of
an ability to merge them makes them very difficult to use for anything
practical.  Can someone share with me how they use them and what the
cycle is?

I use them to store test execution output.

By post-processing, then diffing such notes, I can work out what was
regressed or fixed between two commits.

jon.

On Thu, 2010-08-26 at 10:09 +0200, Michael J Gruber wrote:

I use it to store the patch comments (the part that goes after the
"---", before the diff) along with my commits so that I have them in my
git.git tree, not only in my mbox. This makes it also easier to redo a
patch and keep the comment when regenerating the patch e-mail with
format-patch. (I don't have a good solution for the cover letter yet.)

Michael

Not to stray off-topic, but I use tags for the cover letter eg:
refs/tags/patches/short-description/v[N]

I hadn't thought of using git-notes for the per-patch comments, here I
was with the opposite problem (A straighforward way to keep track of
cover-letters, but no good way to keep track of the per-patch comments)