Thread (7 messages) flat view 7 messages, 3 authors, 2016-06-15

Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?

From: Stephan Beyer <hidden>
Date: 2016-06-15 22:44:54

Hi,

Jakub Narebski wrote:
quoted
It is taking the commit message from the commit in the "From <commit> .*"
line, does *not* change it in any way and then applies the changes using
threeway merge.
Not exactly.  "git am --rebasing" still tries to first just *apply*
the patch, then (I think) it falls back on blob-id based 3way merge.
That's of course totaly right and what I've meant, but unfortunately not
what I've written ;-)
quoted
Keeping that in mind what about dealing with --rebasing like that:
if --rebasing is given, git am simply generates
	pick <commit>
lines, instead of
	patch -3 -k <msg>
as it is now (and this is not enough, as it seems).
It is not.

Nevertheless it would be I think better for ordinary patch based rebase
to fall back not on git-am 3way merge, but on cherry-pick based merge
(i.e. on pick).
Hmm, if I get you right you _partly_ agree with me in choosing "pick" for
am --rebasing... But cherry-pick should only be chosen if a simple git-apply
failed first. Right?

I just got another idea which could easily be done and perhaps is the
right thing :)
Generating
	patch -C <commit> -3 <file>

This takes authorship and message from <commit> and does the usual
threeway-fallback behavior.

What do you think?
But I agree that it would be nice to simplify '--rebasing' logic, for
example using patch or 2way merge to generate tree, and commit message
taken directly from commit, not via 'format-patch | am' pipeline.
That's right, but that would require me to hack around in git-rebase
which I tried to avoid for now. :)

Regards,
  Stephan

-- 
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help