Junio, on 3/25/07 you said:
I know Linus does not like applying patches with whitespace
fuzziness, but I personally think a merge that ignores
whitespace changes would be a useful thing to have, without
having to call an external specialized merge backend. In other
words, I do not think it is so special a thing to want to, but
it is rather an unfortunate norm. I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.
Whatever came of this? I tried giving git merge a --ignore-whitespace
argument and the error message that followed show no equivalent
argument.
It would sure come in handy right now. Is there some other way to do
it that I didn't find searching the mailing list?
Thanks.
Kevin
layer [off-list ref] writes:
Junio, on 3/25/07 you said:
I know Linus does not like applying patches with whitespace
fuzziness, but I personally think a merge that ignores
whitespace changes would be a useful thing to have, without
having to call an external specialized merge backend. In other
words, I do not think it is so special a thing to want to, but
it is rather an unfortunate norm. I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.
Whatever came of this?
I do not know. When I say "I am not opposed to", I mean just that.
I may consider it a bad mode of operation, and I may hesitate to encourage
people to use it as their default. But I do not feel strongly enough to
veto it---as long as it is a rope you need to explicitly ask for to hang
yourself with, I think it is Ok if we allowed such an option.
It is not my itch to scratch, and I do not keep track.
Did you submit a patch that implements the new feature cleanly?
Junio C Hamano [off-list ref] wrote:
quoted
layer [off-list ref] writes:
quoted
Junio, on 3/25/07 you said:
I know Linus does not like applying patches with whitespace
fuzziness, but I personally think a merge that ignores
whitespace changes would be a useful thing to have, without
having to call an external specialized merge backend. In other
words, I do not think it is so special a thing to want to, but
it is rather an unfortunate norm. I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.
Whatever came of this?
I do not know. When I say "I am not opposed to", I mean just that.
I may consider it a bad mode of operation, and I may hesitate to encourage
people to use it as their default. But I do not feel strongly enough to
veto it---as long as it is a rope you need to explicitly ask for to hang
yourself with, I think it is Ok if we allowed such an option.
It is not my itch to scratch, and I do not keep track.
Thanks for the summary.
quoted
Did you submit a patch that implements the new feature cleanly?
Nope. I'm just barely emerging from newbie status, so I'm probably a
ways away from implementing it.
Kevin
Hi,
On Thu, 5 Feb 2009, layer wrote:
Junio, on 3/25/07 you said:
I know Linus does not like applying patches with whitespace
fuzziness, but I personally think a merge that ignores
whitespace changes would be a useful thing to have, without
having to call an external specialized merge backend. In other
words, I do not think it is so special a thing to want to, but
it is rather an unfortunate norm. I am not opposed to give
git-merge-recursive a command line option to tell it to merge
ignoring the whitespace-only changes, when it does the 3-way
file-level merge internally.
Whatever came of this? I tried giving git merge a --ignore-whitespace
argument and the error message that followed show no equivalent
argument.
I can think of two issues:
- there was this -X patch by Junio, but I think it is a bad interface to
pass merge backend options, as it is not closely coupled with the
backend. Just imagine this:
git merge -X ignore-whitespace -s resolve,recursive
Does the "-X ignore-whitespace" impact resolve, recursive, or both? And
we'd need some way to specify the option to the backend. I thought that
git merge -s resolve,recursive/ignore-whitespace
would be a sane syntax, but at least _I_ did not have a need to pass
backend options yet.
- more fundamental, how should the merge ignoring whitespace work? Which
version would it take if the lines agree _except_ for whitespace
changes? This needs to be well designed, as we have not only merges
(where we have "ours" and "theirs"), but also rebases (where we have
"theirs" and _then_ "ours"), and of course recursive merges when there
is more than a single merge base (and there, it gets really nasty, so
you better have the semantics of the whitespace-ignoring merge put down
quite clearly).
It would sure come in handy right now. Is there some other way to do
it that I didn't find searching the mailing list?
Of course, you could try to "normalize" the whitespace, and perform the
merge after that.
Ciao,
Dscho