Re: More builtin git-am issues..

On Sat, Sep 5, 2015 at 9:39 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> To salvage "interpret-trailers" needs a lot more, as we are >> realizing that the definition that led to its external design does >> not match the way users use footers in

Re: More builtin git-am issues..

On Sat, Sep 05, 2015 at 09:30:27AM +0200, Johannes Sixt wrote: > >How about a bit looser rule like this? > > > > A block of text at the end of the message, each and every > > line in which must match "^[^: ]+:[ ]" (that is, > > a "keyword" that does not contain a whitespace nor

Re: More builtin git-am issues..

Am 05.09.2015 um 02:54 schrieb Junio C Hamano: Linus Torvalds writes: So I think that logic should basically be extended to saying - if any line in the last chunk has a "Signed-off-by:", set a flag. - at the end of the loop, if that flag wasn't set, return

Re: More builtin git-am issues..

Junio C Hamano writes: > To salvage "interpret-trailers" needs a lot more, as we are > realizing that the definition that led to its external design does > not match the way users use footers in the real world. This affects > the internal data representation and the whole

Re: More builtin git-am issues..

Junio C Hamano writes: > Johannes Sixt writes: > >> Why do we need a new rule? The old git-am had a logic that pleased >> everyone, and it must have been implemented somewhere. Shouldn't it be >> sufficient to just re-implement or re-use that logic? > ... >

Re: More builtin git-am issues..

Junio C Hamano writes: > But for the purpose of 2.6-rc period, I think we should start from > doing a separate implementation inside builtin/am.c without touching > append_signoff(). > ... > Here is a quick attempt to do the "just fix am regression without > changing anything

Re: More builtin git-am issues..

Junio C Hamano writes: > And a quick attempt without even compilation testing has flaws as > expected X-<. > > Second attempt. ... and I forget the de-dup logic. The third attempt. builtin/am.c | 32 ++-- 1 file changed, 30 insertions(+), 2

Re: More builtin git-am issues..

Linus Torvalds writes: > That said, the original "git am" rules actually seem to be rather > straightforward: it's never an issue about "last block of text", and > it's simply an issue of "is there a sign-ff _anywhere_ in the text". > > That simplicity has a

Re: More builtin git-am issues..

Johannes Sixt writes: > Why do we need a new rule? The old git-am had a logic that pleased > everyone, and it must have been implemented somewhere. Shouldn't it be > sufficient to just re-implement or re-use that logic? If you look at the helper the rewritten "am" calls, you will

Re: More builtin git-am issues..

Jeff King writes: > [1] I think part of the reason people are interested in "fancy" here is > that this topic extends beyond "git am". There's "commit -s", of > course, but there's also the generic "interpret-trailers" command, > which is supposed to be a

More builtin git-am issues..

Ok, this may not be new either, but I'm trying to be careful when using "git am" these days, because I know it got rewritten. And I _think_ the whitespace handling for adding sign-offs got scrogged. I just applied the usual patch-bomb from Andrew, and several of the commits (but not all) end up

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 4:47 PM, Linus Torvalds wrote: > > I *think* it's this part: > > if (!(found_rfc2822 || > is_cherry_picked_from_line(buf + i, k - i - 1))) > return 0; > > which basically returns 0

Re: More builtin git-am issues..

On Fri, Sep 04, 2015 at 04:52:42PM -0700, Linus Torvalds wrote: > On Fri, Sep 4, 2015 at 4:47 PM, Linus Torvalds > wrote: > > > > I *think* it's this part: > > > > if (!(found_rfc2822 || > > is_cherry_picked_from_line(buf + i,

Re: More builtin git-am issues..

Linus Torvalds writes: > So I think that logic should basically be extended to saying > > - if any line in the last chunk has a "Signed-off-by:", set a flag. > > - at the end of the loop, if that flag wasn't set, return 0. I am reluctant to special case S-o-b:

Re: More builtin git-am issues..

Linus Torvalds writes: > but the failing cases have a comment by Andrew: > > [a...@linux-foundation.org: coding-style fixes] > Signed-off-by: Tang Chen > Cc: Xishi Qiu > Cc: Yasuaki Ishimatsu

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 6:06 PM, Junio C Hamano wrote: > > that rule would still not think this is a signature block, but at > that point, do we really want to consider such a block of text a > signature block? So exactly why are you arguing for these rules that are known to

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 6:23 PM, Junio C Hamano wrote: > > OK, I didn't know that was acceptable in the kernel community > to have random comments like that inside the block. Can these > comments span multiple paragraphs? What I am wondering is what > you want to see in a case

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 5:07 PM, Jeff King wrote: > > Do we want to make Signed-off-by a special token here? What about "Cc:", > and other project-specific trailers? You wouldn't want to end up with: > > [some comment] > Cc: somebody > > Signed-off-by: somebody else > > It's

Re: More builtin git-am issues..

On Fri, Sep 4, 2015 at 5:54 PM, Junio C Hamano wrote: > > How about a bit looser rule like this? > > A block of text at the end of the message, each and every > line in which must match "^[^: ]+:[ ]" (that is, > a "keyword" that does not contain a

Re: More builtin git-am issues..

Linus Torvalds writes: > On Fri, Sep 4, 2015 at 6:06 PM, Junio C Hamano wrote: >> >> that rule would still not think this is a signature block, but at >> that point, do we really want to consider such a block of text a >> signature block? > > So

Re: More builtin git-am issues..

Linus Torvalds writes: > The thing is, and that was what the report was all about, not every > line _is_ of that format. We have commetns from the sign-off people. > Things like this: > > Signed-off-by: Noam Camus > Acked-by: Vineet Gupta