Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

From: Jeff King <peff@peff.net>
Date: Oct 23, 2012, 21:22 UTC
Message-ID: <20121023212245.GA28828@sigill.intra.peff.net>
In-Reply-To: <CAHkRjk6x9ToVzY7jv1ZxPt57F6agcH7SfHZpZNpHC3QP3PZp3Q@mail.gmail.com>

On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote:

Show 16 quoted lines

> > It is spelled:
> >
> >   git notes add -m <comment> SHA1
> >
> > The resulting notes are stored in a separate revision-controlled branch
> > and can be pushed and pulled like regular refs. Note, though, that the
> > default refspecs do not yet include refs/notes, so you'd have to add
> > them manually. The workflows around notes are not very mature yet, so if
> > you start using them, feedback would be appreciated.
> 
> What would be nice is that notes are pushed/pulled automatically with
> standard git push/fetch/pull commands. Usually git walks the DAG
> starting with the pulled commit or tag and following the parents. With
> notes, the reference is reversed, the note pointing to the commit and
> not the other way around. So handling this automatically in Git would
> be really useful.

Right, that's what I meant about the refspecs. You can configure git to push or pull them automatically, but it is not the default. Something like:

  git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*'

would be a start, but you'd also want to "git notes merge" upstream's changes into your local notes (you _could_ just fetch straight into refs/notes/, but if you are making your own notes locally, you have to resolve it somehow). Exactly how to make this smooth is one of the workflow considerations; there's been discussion, but most people aren't using the feature, so we don't have a lot of data.

If you are asking whether we could "auto-follow" notes for commits that have been fetched like we do for tags, the answer is "not really". The notes tree is version-controlled as a whole, so you generally fetch the whole thing or not. And the remote does not advertise note information the same way we advertise peeled tag references, so a client does not know which notes are available for fetch. The intended strategy is to pull in the notes or not (though you can have multiple notes refs with different names, and fetch just a subset of them).

> The other feature I'd like is that notes are automatically folded in
> the log during git rebase (maybe similar to the squash option). If you
> rebase, you lose all the notes (though this depends on the workflow,
> it may not be needed with published branches).

Git-rebase can automatically copy notes from one commit to another during a rebase, but you need to set notes.rewriteRef to do so (see "git help config" for details). The reason for this conservative default is that some notes may not be appropriate for automatic copying (e.g., a notes tree containing QA approval should probably be invalidated during a rebase, whereas one with commentary probably should).

Squashing the notes into the commit message during rebase would be a useful feature (at least for some type of notes), but that feature does not currently exist (and as far as I recall, this is the first it has been proposed).

Again, I think a lot of this comes down to the fact that not many people are really using notes for their daily workflow, so these itches are not coming up and getting scratched.

-Peff