{"thread":{"id":"31924","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","startedAt":"2012-10-23T20:47:28Z","lastAt":"2012-10-24T11:18:02Z","messageCount":14,"participants":["Thomas Gleixner","Jeff King","Catalin Marinas","Linus Torvalds","Al Viro","Marc Gauthier","Ingo Molnar","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"201752","messageId":"alpine.LFD.2.02.1210232232070.2756@ionos","threadId":"31924","inReplyTo":"20121023184122.GZ2616@ZenIV.linux.org.uk","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2012-10-23T20:47:28Z","receivedAt":"2012-10-23T20:47:28Z","isPatch":true,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Tue, 23 Oct 2012, Al Viro wrote:\n> On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:\n> \n> > I fetched the series from your arch-tile branch and built it, and it works\n> > fine. It looks good from my inspection:\n> > \n> > Acked-by: Chris Metcalf \n> \n> Thanks; Acked-by applied, branch pushed and put into no-rebase mode.\n> \n> BTW, something like detached Acked-by objects might be a good idea - i.e.\n> commit-like git object with amendment to commit message of a given ancestor.\n> The situation when ACKs come only after the commit has been pushed is quite\n> common. Linus, what do you think about usefulness of such thing? Ability\n> to append ACKed-by/Tested-by of an earlier commit to a branch instead of\n> git commit --amend + possibly some cherry-picks + force-push, that is.\n\nI agree that this is a common issue. Acked-by/Reviewed-by mails come\nin after the fact that the patch has been committed to an immutable\n(i.e no-rebase mode) branch or if the change in question already hit\nLinus tree.\n\nStill it would be nice to have a recording of that in the git tree\nitself.\n\nSomething like: \"git --attach SHA1 \" would be appreciated!\n\nThanks,\n\n\ttglx\n"},{"id":"201753","messageId":"20121023205119.GA27729@sigill.intra.peff.net","threadId":"31924","inReplyTo":"alpine.LFD.2.02.1210232232070.2756@ionos","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-23T20:51:19Z","receivedAt":"2012-10-23T20:51:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote:\n\n> I agree that this is a common issue. Acked-by/Reviewed-by mails come\n> in after the fact that the patch has been committed to an immutable\n> (i.e no-rebase mode) branch or if the change in question already hit\n> Linus tree.\n> \n> Still it would be nice to have a recording of that in the git tree\n> itself.\n> \n> Something like: \"git --attach SHA1 \" would be appreciated!\n\nIt is spelled:\n\n git notes add -m SHA1\n\nThe resulting notes are stored in a separate revision-controlled branch\nand can be pushed and pulled like regular refs. Note, though, that the\ndefault refspecs do not yet include refs/notes, so you'd have to add\nthem manually. The workflows around notes are not very mature yet, so if\nyou start using them, feedback would be appreciated.\n\n-Peff\n"},{"id":"201756","messageId":"CAHkRjk6x9ToVzY7jv1ZxPt57F6agcH7SfHZpZNpHC3QP3PZp3Q@mail.gmail.com","threadId":"31924","inReplyTo":"20121023205119.GA27729@sigill.intra.peff.net","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2012-10-23T21:09:46Z","receivedAt":"2012-10-23T21:09:46Z","isPatch":true,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"On 23 October 2012 21:51, Jeff King wrote:\n> On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote:\n>\n>> I agree that this is a common issue. Acked-by/Reviewed-by mails come\n>> in after the fact that the patch has been committed to an immutable\n>> (i.e no-rebase mode) branch or if the change in question already hit\n>> Linus tree.\n>>\n>> Still it would be nice to have a recording of that in the git tree\n>> itself.\n>>\n>> Something like: \"git --attach SHA1 \" would be appreciated!\n>\n> It is spelled:\n>\n> git notes add -m SHA1\n>\n> The resulting notes are stored in a separate revision-controlled branch\n> and can be pushed and pulled like regular refs. Note, though, that the\n> default refspecs do not yet include refs/notes, so you'd have to add\n> them manually. The workflows around notes are not very mature yet, so if\n> you start using them, feedback would be appreciated.\n\nWhat would be nice is that notes are pushed/pulled automatically with\nstandard git push/fetch/pull commands. Usually git walks the DAG\nstarting with the pulled commit or tag and following the parents. With\nnotes, the reference is reversed, the note pointing to the commit and\nnot the other way around. So handling this automatically in Git would\nbe really useful.\n\nThe other feature I'd like is that notes are automatically folded in\nthe log during git rebase (maybe similar to the squash option). If you\nrebase, you lose all the notes (though this depends on the workflow,\nit may not be needed with published branches).\n\n-- \nCatalin\n"},{"id":"201757","messageId":"20121023212245.GA28828@sigill.intra.peff.net","threadId":"31924","inReplyTo":"CAHkRjk6x9ToVzY7jv1ZxPt57F6agcH7SfHZpZNpHC3QP3PZp3Q@mail.gmail.com","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-23T21:22:45Z","receivedAt":"2012-10-23T21:22:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote:\n\n> > It is spelled:\n> >\n> > git notes add -m SHA1\n> >\n> > The resulting notes are stored in a separate revision-controlled branch\n> > and can be pushed and pulled like regular refs. Note, though, that the\n> > default refspecs do not yet include refs/notes, so you'd have to add\n> > them manually. The workflows around notes are not very mature yet, so if\n> > you start using them, feedback would be appreciated.\n> \n> What would be nice is that notes are pushed/pulled automatically with\n> standard git push/fetch/pull commands. Usually git walks the DAG\n> starting with the pulled commit or tag and following the parents. With\n> notes, the reference is reversed, the note pointing to the commit and\n> not the other way around. So handling this automatically in Git would\n> be really useful.\n\nRight, that's what I meant about the refspecs. You can configure git to\npush or pull them automatically, but it is not the default. Something\nlike:\n\n git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*'\n\nwould be a start, but you'd also want to \"git notes merge\" upstream's\nchanges into your local notes (you _could_ just fetch straight into\nrefs/notes/, but if you are making your own notes locally, you have to\nresolve it somehow). Exactly how to make this smooth is one of the workflow\nconsiderations; there's been discussion, but most people aren't using\nthe feature, so we don't have a lot of data.\n\nIf you are asking whether we could \"auto-follow\" notes for commits that\nhave been fetched like we do for tags, the answer is \"not really\". The\nnotes tree is version-controlled as a whole, so you generally fetch the\nwhole thing or not. And the remote does not advertise note information\nthe same way we advertise peeled tag references, so a client does not\nknow which notes are available for fetch. The intended strategy is to\npull in the notes or not (though you can have multiple notes refs with\ndifferent names, and fetch just a subset of them).\n\n> The other feature I'd like is that notes are automatically folded in\n> the log during git rebase (maybe similar to the squash option). If you\n> rebase, you lose all the notes (though this depends on the workflow,\n> it may not be needed with published branches).\n\nGit-rebase can automatically copy notes from one commit to another\nduring a rebase, but you need to set notes.rewriteRef to do so (see \"git\nhelp config\" for details). The reason for this conservative default is\nthat some notes may not be appropriate for automatic copying (e.g., a\nnotes tree containing QA approval should probably be invalidated during\na rebase, whereas one with commentary probably should).\n\nSquashing the notes into the commit message during rebase would be a\nuseful feature (at least for some type of notes), but that feature does\nnot currently exist (and as far as I recall, this is the first it has\nbeen proposed).\n\nAgain, I think a lot of this comes down to the fact that not many people\nare really using notes for their daily workflow, so these itches are not\ncoming up and getting scratched.\n\n-Peff\n"},{"id":"201758","messageId":"alpine.LFD.2.02.1210232307480.2756@ionos","threadId":"31924","inReplyTo":"20121023205119.GA27729@sigill.intra.peff.net","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Thomas Gleixner","fromEmail":"tglx@linutronix.de","sentAt":"2012-10-23T21:25:06Z","receivedAt":"2012-10-23T21:25:06Z","isPatch":true,"sender":{"key":"tglx@linutronix.de","avatar":null},"body":"On Tue, 23 Oct 2012, Jeff King wrote:\n\n> On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote:\n> \n> > I agree that this is a common issue. Acked-by/Reviewed-by mails come\n> > in after the fact that the patch has been committed to an immutable\n> > (i.e no-rebase mode) branch or if the change in question already hit\n> > Linus tree.\n> > \n> > Still it would be nice to have a recording of that in the git tree\n> > itself.\n> > \n> > Something like: \"git --attach SHA1 \" would be appreciated!\n> \n> It is spelled:\n> \n> git notes add -m SHA1\n\nCool!\n\n> The resulting notes are stored in a separate revision-controlled branch\n\nWhich branch(es) is/are that ? What are the semantics of that?\n\nAssume I commit something to branch \"foo\"\n\nNow I get that late Ack/Reviewed-by and want to associate that to that\ncommit in branch \"foo\". Does that go into \"notes/foo\" ?\n\nIf yes, good. (Any other sensible prefix is good as well). If no,\nwhere does it go to?\n\nLater when I send a pull request to my upstream maintainer for branch\n\"foo\" does he get \"notes/foo\" automagically or do I have to request to\npull him that separately?\n\nEither way is fine for me, though something which lets me \"automate\"\nthat would be appreciated. I can work around that easily as my pull\nrequests are generated via scripts, so I can add the secondary one for\nthe dependent \"notes\" branch if necessary. Though it would be nice to\navoid that. Avoiding that, i.e having a straight connection (maybe\nconfigurable) between \"foo\" and \"notes/foo\" and the commits which have\nnot yet hit my upstream maintainer would make my life easier. I.e. I\njust have to check \"foo\" for stuff which is not upstream yet instead\nof checking both, but that might just be my laziness.\n\nThoughts?\n\n\ttglx\n"},{"id":"201761","messageId":"20121023214717.GA29306@sigill.intra.peff.net","threadId":"31924","inReplyTo":"alpine.LFD.2.02.1210232307480.2756@ionos","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-23T21:47:17Z","receivedAt":"2012-10-23T21:47:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote:\n\n> > The resulting notes are stored in a separate revision-controlled branch\n> \n> Which branch(es) is/are that ? What are the semantics of that?\n\nThey are stored in refs/notes/commits by default, but you can have\nmultiple notes refs if you want to store logically distinct sets of\nnotes.\n\nA notes ref's tree is just a tree whose entries are sha1s, and the file\ncontents contain the notes themselves (the sha1s are broken down into\nsubdirectories for performance, but \"git notes\" handles this behind the\nscenes). Technically you could check it out as a branch, edit, and\ncommit, but \"git checkout\" is not happy to have a HEAD outside of\nrefs/heads/, so you are stuck with plumbing like:\n\n $ git checkout `git rev-parse refs/notes/commits`\n $ edit edit edit\n $ git commit ...\n $ git update-ref refs/notes/commits HEAD\n\nIt's probably not good for much beyond exploring how notes are\nimplemented. See \"git help notes\" for more discussion.\n\n> Assume I commit something to branch \"foo\"\n> \n> Now I get that late Ack/Reviewed-by and want to associate that to that\n> commit in branch \"foo\". Does that go into \"notes/foo\" ?\n\nNo. It would go into refs/notes/commits, or you could ask it to go to\nrefs/notes/acks if you wanted to keep them separate from your default\nnotes. It is indexed by commit object, not by branch (so if that branch\nlater goes away, the notes are always still attached to the commit\nobjects, assuming they got merged in).\n\n> Later when I send a pull request to my upstream maintainer for branch\n> \"foo\" does he get \"notes/foo\" automagically or do I have to request to\n> pull him that separately?\n\nNo, he would have to pull your notes separately. Most of the discussion\naround sharing has been configuring the default refspec configuration to\nfetch notes. But in the kernel you guys use a lot of one-off pulls\nwithout configured remotes. I'm not sure what the right workflow would\nbe. It might simply be to ask git to always pull particular notes\ncommits at the same time (so you might push your notes to\nrefs/notes/for-linus, and then git would automatically grab the notes\nwhen somebody pulls refs/heads/for-linus).\n\n> Either way is fine for me, though something which lets me \"automate\"\n> that would be appreciated. I can work around that easily as my pull\n> requests are generated via scripts, so I can add the secondary one for\n> the dependent \"notes\" branch if necessary. Though it would be nice to\n> avoid that. Avoiding that, i.e having a straight connection (maybe\n> configurable) between \"foo\" and \"notes/foo\" and the commits which have\n> not yet hit my upstream maintainer would make my life easier. I.e. I\n> just have to check \"foo\" for stuff which is not upstream yet instead\n> of checking both, but that might just be my laziness.\n> \n> Thoughts?\n\nThat all makes sense. Putting extra work on the puller is not a good\nlong-term solution. So while sending them an extra \"also pull these\nnotes\" line, even if it ends up being a cut-and-pastable single-liner,\nis not great (even if it is the most flexible thing). Using a convention\nbased on name-equivalence seems like a sensible compromise.\n\n-Peff\n"},{"id":"201785","messageId":"522C1DF17AF50042AD8AE87F7887BD3D0B60880C30@exch.hq.tensilica.com","threadId":"31924","inReplyTo":"20121023214717.GA29306@sigill.intra.peff.net","subject":"RE: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Marc Gauthier","fromEmail":"marc@tensilica.com","sentAt":"2012-10-23T22:06:59Z","receivedAt":"2012-10-23T22:06:59Z","isPatch":true,"sender":{"key":"marc@tensilica.com","avatar":null},"body":"Jeff King wrote:\n> On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote:\n> > > The resulting notes are stored in a separate\n> > > revision-controlled branch\n> >\n> > Which branch(es) is/are that ? What are the semantics of that?\n[...]\n\n\nNice feature.\n\nCan a later commit be eventually be made to reference some set\nof notes added so far, so they become part of the whole history\nsigned by the HEAD SHA1? hence pulled/pushed automatically as\nwell. Otherwise do you not end up with a forever growing separate\ntree of notes that loses some of the properties of being behind\nthe head SHA1 (and perhaps less scalable in manageability)?\nAlso that way notes are separate only temporarily.\n\nAs for automating the inclusion of notes in the flow, can that\nbe conditional on some pattern in the note, so that e.g. the\nAcked-by's get included and folded in automatically, whereas\nothers do not, according to settings?\n\n-Marc\n"},{"id":"201765","messageId":"20121023222318.GA3055@sigill.intra.peff.net","threadId":"31924","inReplyTo":"522C1DF17AF50042AD8AE87F7887BD3D0B60880C30@exch.hq.tensilica.com","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-23T22:23:18Z","receivedAt":"2012-10-23T22:23:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote:\n\n> Can a later commit be eventually be made to reference some set\n> of notes added so far, so they become part of the whole history\n> signed by the HEAD SHA1? hence pulled/pushed automatically as\n> well. Otherwise do you not end up with a forever growing separate\n> tree of notes that loses some of the properties of being behind\n> the head SHA1 (and perhaps less scalable in manageability)?\n> Also that way notes are separate only temporarily.\n\nInteresting idea. It would be tough to do with existing objects. There\nare really only two ways for a commit to reference objects:\n\n 1. Via a parent header. But we would not want to include the notes\n tree as a separate parent. The semantics are all wrong, and would\n make your commit look like a nonsense merge.\n\n 2. As an entry in a tree. But we do not enforce connectivity of\n commits referenced in trees, because that is the way that\n submodules are implemented.\n\nSo I think we would have to add a new header that says \"also, here are\nsome notes for my history\". That has two problems:\n\n 1. It's not backwards compatible. People with the new version of git\n will expect to have objects referenced by the new header, but older\n servers may not provide those objects (and vice versa). We can add\n a protocol extension to communicate this, but fundamentally you are\n going to lose the object connection any time it passes through a\n repo running an older git.\n\n 2. It's impure from the perspective of git's data model. Adding in the\n notes reference is not really a property of the commit. It's more\n like saying \"Oh, these other things happened to _past_ commits, and\n I'm just now mentioning them\". So you pick an arbitrary commit to\n attach it to. What are the semantics with relation to that commit's\n position in the history graph? If I have a commit that is identical\n but without the notes reference, it will have a different sha1. But\n is it the same commit?\n\nSo it's a bit ugly. I think I'd rather build out the transfer\ninfrastructure to pass the notes references around more gracefully\nwithout trying to shoehorn them into the commit graph.\n\n> As for automating the inclusion of notes in the flow, can that\n> be conditional on some pattern in the note, so that e.g. the\n> Acked-by's get included and folded in automatically, whereas\n> others do not, according to settings?\n\nYeah. You can store arbitrary data in notes (e.g., one of the existing\nuses of notes is to record metadata on the patch emails that led to a\ncommit). Right now you typically separate it out by data type into\nseparate refs, and then you ask git log to show you particular ones (so\nwe see refs/notes/commits with \"--notes\", but you can do \"--notes=foo\"\nto see refs/notes/foo, or even show multiple refs).\n\nFor the fold-on-rebase idea, I'd think you would want something similar,\nlike setting rebase.foldNotes to \"foo\" to say \"refs/notes/foo contains\npseudo-headers that should be folded in like a signed-off-by\".\n\n-Peff\n"},{"id":"201783","messageId":"CA+55aFyYD2jvD3+TSe=GhBgg5UQt2RNFdYf6HGiKRX-xWzFmdw@mail.gmail.com","threadId":"31924","inReplyTo":"alpine.LFD.2.02.1210232307480.2756@ionos","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2012-10-24T01:02:49Z","receivedAt":"2012-10-24T01:02:49Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote:\n>>\n>> It is spelled:\n>>\n>> git notes add -m SHA1\n>\n> Cool!\n\nDon't use them for anything global.\n\nUse them for local codeflow, but don't expect them to be distributed.\nIt's a separate \"flow\", and while it *can* be distributed, it's not\ngoing to be for the kernel, for example. So no, don't start using this\nto ack things, because the acks *will* get lost.\n\n Linus\n"},{"id":"201784","messageId":"20121024015613.GB2616@ZenIV.linux.org.uk","threadId":"31924","inReplyTo":"CA+55aFyYD2jvD3+TSe=GhBgg5UQt2RNFdYf6HGiKRX-xWzFmdw@mail.gmail.com","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Al Viro","fromEmail":"viro@zeniv.linux.org.uk","sentAt":"2012-10-24T01:56:13Z","receivedAt":"2012-10-24T01:56:13Z","isPatch":true,"sender":{"key":"viro@zeniv.linux.org.uk","avatar":null},"body":"On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote:\n> On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote:\n> >>\n> >> It is spelled:\n> >>\n> >> git notes add -m SHA1\n> >\n> > Cool!\n> \n> Don't use them for anything global.\n> \n> Use them for local codeflow, but don't expect them to be distributed.\n> It's a separate \"flow\", and while it *can* be distributed, it's not\n> going to be for the kernel, for example. So no, don't start using this\n> to ack things, because the acks *will* get lost.\n\nHow about git commit --allow-empty, with\n\"belated ACK for \n\nAcked-by: <...>\n\" as commit message? I mean, that ought to work and propagate sanely,\nbut I'm really not sure if that's something in a good taste and should\nbe allowed as a common practice...\n"},{"id":"201786","messageId":"CA+55aFzg6cNFCCucwgFnJpgokwM=wkkXPMtd2XbtQB5m9UHOSA@mail.gmail.com","threadId":"31924","inReplyTo":"20121024015613.GB2616@ZenIV.linux.org.uk","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2012-10-24T02:14:07Z","receivedAt":"2012-10-24T02:14:07Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Oct 24, 2012 at 4:56 AM, Al Viro wrote:\n>\n> How about git commit --allow-empty, with\n> \"belated ACK for \n\nDon't bother. It's not that important, and it's just distracting.\n\nIt's not like this is vital information. If you pushed it out without\nthe ack, it's out without the ack. Big deal.\n\n Linus\n"},{"id":"201789","messageId":"20121024060222.GA20007@gmail.com","threadId":"31924","inReplyTo":"CA+55aFyYD2jvD3+TSe=GhBgg5UQt2RNFdYf6HGiKRX-xWzFmdw@mail.gmail.com","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Ingo Molnar","fromEmail":"mingo@kernel.org","sentAt":"2012-10-24T06:02:22Z","receivedAt":"2012-10-24T06:02:22Z","isPatch":true,"sender":{"key":"mingo@kernel.org","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote:\n> >>\n> >> It is spelled:\n> >>\n> >> git notes add -m SHA1\n> >\n> > Cool!\n> \n> Don't use them for anything global.\n> \n> Use them for local codeflow, but don't expect them to be \n> distributed. It's a separate \"flow\", and while it *can* be \n> distributed, it's not going to be for the kernel, for example. \n> So no, don't start using this to ack things, because the acks \n> *will* get lost.\n\nI'd also add a small meta argument: that it would be actively \nwrong to *allow* 'belated' acks to be added. In practice acks \nare most useful *before* a commit gets created and they often \nhave a mostly buerocratic role afterwards.\n\nSo we should encourage timely acks (which actually help \ndevelopment), and accept ack-less patches as long as they are \ncorrect and create no problems. More utility, less buerocracy. \nIncorrect, ack-less patches causing problems will get all the \nflames they deserve.\n\nThanks,\n\n\tIngo\n"},{"id":"201790","messageId":"5087848D.7060400@viscovery.net","threadId":"31924","inReplyTo":"20121023222318.GA3055@sigill.intra.peff.net","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2012-10-24T06:02:53Z","receivedAt":"2012-10-24T06:02:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/24/2012 0:23, schrieb Jeff King:\n> For the fold-on-rebase idea, I'd think you would want something similar,\n> like setting rebase.foldNotes to \"foo\" to say \"refs/notes/foo contains\n> pseudo-headers that should be folded in like a signed-off-by\".\n\nIf you are rebasing anyway, you can already use interactive rebase's\n--autosquash option:\n\n# a late ACK came in:\ngit commit --allow-empty -m'squash! tile: support GENERIC_\n\nAcked-by: A U Thor '\n\ngit rebase -i --keep-empty --autosquash $forkpoint\n\nRequires git 1.7.11 for --keep-empty and requires to edit out the\n'squash!...' headers when the editor appears during the rebase.\n\n-- Hannes\n"},{"id":"201806","messageId":"20121024111802.GB2006@arm.com","threadId":"31924","inReplyTo":"20121023212245.GA28828@sigill.intra.peff.net","subject":"Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2012-10-24T11:18:02Z","receivedAt":"2012-10-24T11:18:02Z","isPatch":true,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote:\n> On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote:\n> > > It is spelled:\n> > >\n> > > git notes add -m SHA1\n> > >\n> > > The resulting notes are stored in a separate revision-controlled branch\n> > > and can be pushed and pulled like regular refs. Note, though, that the\n> > > default refspecs do not yet include refs/notes, so you'd have to add\n> > > them manually. The workflows around notes are not very mature yet, so if\n> > > you start using them, feedback would be appreciated.\n> > \n> > What would be nice is that notes are pushed/pulled automatically with\n> > standard git push/fetch/pull commands. Usually git walks the DAG\n> > starting with the pulled commit or tag and following the parents. With\n> > notes, the reference is reversed, the note pointing to the commit and\n> > not the other way around. So handling this automatically in Git would\n> > be really useful.\n> \n> Right, that's what I meant about the refspecs. You can configure git to\n> push or pull them automatically, but it is not the default. Something\n> like:\n> \n> git config --add remote.origin.fetch '+refs/notes/*:refs/notes/origin/*'\n\nYes, but that's a bit more complicated than a simple pull. Anyway, Linus\nseems to not be in favour of annotating commits later for adding acks,\nso no need for such feature.\n\n> > The other feature I'd like is that notes are automatically folded in\n> > the log during git rebase (maybe similar to the squash option). If you\n> > rebase, you lose all the notes (though this depends on the workflow,\n> > it may not be needed with published branches).\n> \n> Git-rebase can automatically copy notes from one commit to another\n> during a rebase, but you need to set notes.rewriteRef to do so (see \"git\n> help config\" for details). The reason for this conservative default is\n> that some notes may not be appropriate for automatic copying (e.g., a\n> notes tree containing QA approval should probably be invalidated during\n> a rebase, whereas one with commentary probably should).\n\nThanks, I wasn't aware of this.\n\n> Squashing the notes into the commit message during rebase would be a\n> useful feature (at least for some type of notes), but that feature does\n> not currently exist (and as far as I recall, this is the first it has\n> been proposed).\n\nFor some workflow - I post patches to the list, people reply with their\nacks, I could just add those to notes and later fold them into the\nexisting commits before pushing the branch upstream. I guess it may be\njust a matter of changing git format-patch to include the notes. I can\nlater reword he commits and drop the \"Notes:\" line.\n\n-- \nCatalin\n"}]}