git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Herland <johan@herland.net>
To: Joey Hess <joey@kitenet.net>
Cc: git@vger.kernel.org
Subject: Re: git notes: notes
Date: Wed, 20 Jan 2010 11:48:11 +0100	[thread overview]
Message-ID: <201001201148.11701.johan@herland.net> (raw)
In-Reply-To: <20100120050343.GA12860@gnu.kitenet.net>

On Wednesday 20 January 2010, Joey Hess wrote:
> Just a quick note that the new notes feature can break things that parse
> git log. For example a parser that assumes it can split the log on blank
> lines to separate the header and commit message, can easily become
> confused by the new blank line before "Notes:".

As Thomas already stated, git log is porcelain, and its output format is not 
set in stone. If you need a stable, script-friendly format, you should 
probably use the --format option, or use plumbing instead (such as e.g. git 
rev-list, which also has a --format option).

> Might be worth documenting in release notes, maybe too late now though.
> But really, it's all good, notes are a great feature.
> 
> PS, Has anyone thought about using notes to warn bisect away from
> commits that are known to be unbuildable or otherwise cause bisection
> trouble?

No, I haven't thought of that specific use case. Great idea! :)

BTW, since I started talking about git notes, people on this list have found 
more and more interesting use cases for them:

- Free-form text extension to the commit message

- Help in bug tracking with header-like lines such as:
    - Causes-Bug: #12345
    - Fixes-Bug: #54321

- Store after-the-fact "Acked-By", "Reviewed-By", etc. annotations

- In a repo converted from a merge-unfriendly VCS (such as CVS), use notes
  to identify merges without having to rewrite Git history (note that you
  can also use grafts, or "git replace" to accomplish this).

- Refer to related commits elsewhere in the repo (i.e. relationships that
  are not already apparent from the commit graph)

- When cherry-picking, add a reverse link from the source commit to the
  cherry-picked commit (since it may be of interest to people reviewing the
  source commit

- Rebasing public branches is forbidden, but if you wanted to change that,
  you could potentially help solve it by using notes to add reverse links
  from source commits to rebased commits, so that downstream people could
  more easily traverse your history when rebasing/merging their own
  branches.

- Initially, there were some discussion whether it could also be used to
  guide git blame to make better decisions, although I don't currently see
  how that would be done in practice.

In any case, it seems the notes idea may have the potential to become one of 
the more useful features in Git.


Have fun! :)

...Johan


[1]: ...almost 3 years ago (wow, time flies...):
     http://article.gmane.org/gmane.comp.version-control.git/46883

-- 
Johan Herland, <johan@herland.net>
www.herland.net

  parent reply	other threads:[~2010-01-20 10:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20  5:03 git notes: notes Joey Hess
2010-01-20  9:48 ` Thomas Rast
2010-01-20 18:14   ` Joey Hess
2010-01-20 10:48 ` Johan Herland [this message]
2010-01-20 18:24   ` Joey Hess
2010-01-20 19:30     ` Junio C Hamano
2010-01-20 19:56       ` Joey Hess
2010-01-20 20:10         ` Junio C Hamano
2010-01-20 20:36           ` Joey Hess
2010-01-20 20:54             ` Jeff King
2010-01-20 20:59               ` Junio C Hamano
2010-01-20 21:31                 ` Jeff King
2010-01-20 21:41                   ` Jeff King
2010-01-20 22:07                     ` Junio C Hamano
2010-01-20 22:21                       ` Jeff King
2010-01-20 21:02           ` Michael J Gruber
2010-01-20 21:08             ` Junio C Hamano
2010-01-20 21:36               ` Jeff King
2010-01-20 21:59               ` Junio C Hamano
2010-01-20 22:25                 ` Jeff King
2010-01-20 22:33                   ` Junio C Hamano
2010-01-20 22:58                 ` Johannes Schindelin
2010-01-20 23:06                   ` Jeff King
2010-01-20 23:14                   ` Junio C Hamano
2010-01-21  2:54                     ` Johan Herland
2010-01-21  3:03                       ` Junio C Hamano
2010-01-21  3:37                     ` Junio C Hamano
2010-01-21  8:45               ` Michael J Gruber
2010-01-24 14:20               ` Matthieu Moy
2010-01-24 14:27                 ` Sverre Rabbelier
2010-01-21  2:05     ` Johan Herland
2010-01-21  3:59       ` Johannes Schindelin
2010-01-21  4:05         ` Joey Hess
2010-01-27 11:55           ` Johan Herland
2010-01-25 18:08       ` John Koleszar
2010-01-27 20:01         ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201001201148.11701.johan@herland.net \
    --to=johan@herland.net \
    --cc=git@vger.kernel.org \
    --cc=joey@kitenet.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).