Greetings,
i was interested if you already considered this as feature, or if you may
consider this as good feature. I know that during merge every character need
be considered. And at the end it will be. I described my problem to another
developer and he named this feature as good noise merge reduction.
Issue:
Several times it happened that i added or removed condition in code but a lot
of code stayed. Only indention was changed. If there was also other change on
some line i had a conflict. And several times it happened that a lot of code
was appended instead of replaced (if some line was similar with same
indention). This made merging messed and confusing. If we would remove this
spaces noise from beginning and end, we could get more acquired merge. What do
you think? Of course this is only for looking for most matching lines. At the
end the code should keep all necessary spaces.
Thank you very much for your opinion.
--
Dušan Červenka | Software Developer
a: ACRIOS Systems s.r.o. | Razinova 2257/5 | Ostrava 700 30
e: cervenka@acrios.com | w: www.acrios.com
m: +421 918 715 117
On Wed, Aug 11, 2021 at 12:25:10AM +0200, Dušan Červenka | ACRIOS wrote:
Several times it happened that i added or removed condition in code but a lot
of code stayed. Only indention was changed. If there was also other change on
some line i had a conflict. And several times it happened that a lot of code
was appended instead of replaced (if some line was similar with same
indention). This made merging messed and confusing. If we would remove this
spaces noise from beginning and end, we could get more acquired merge. What do
you think? Of course this is only for looking for most matching lines. At the
end the code should keep all necessary spaces.
Have you looked at the whitespace options you can pass to the
merge-recursive strategy? E.g.:
git merge -Xignore-space-at-eol some-branch
It may not do quite what you want, though (it sounds like you are more
interested in matching context with whitespace changes than ignoring
spaces on modified lines).
-Peff
Hi, Thank you for your respond. Actually in my case we have code formatted
before pushing, so we shouldn't have issues with trailing spaces (i mentioned
them as i they are doing some noise in comparison too). The issue is more
about spaces on beginning of line. Changing indention of code may result in
prepending code if some line with old indention match some line with indented
block of code.
On štvrtok 12. augusta 2021 1:12:54 CEST Jeff King wrote:
On Wed, Aug 11, 2021 at 12:25:10AM +0200, Dušan Červenka | ACRIOS wrote:
quoted
Several times it happened that i added or removed condition in code but a
lot of code stayed. Only indention was changed. If there was also other
change on some line i had a conflict. And several times it happened that
a lot of code was appended instead of replaced (if some line was similar
with same indention). This made merging messed and confusing. If we would
remove this spaces noise from beginning and end, we could get more
acquired merge. What do you think? Of course this is only for looking for
most matching lines. At the end the code should keep all necessary
spaces.
Have you looked at the whitespace options you can pass to the
merge-recursive strategy? E.g.:
git merge -Xignore-space-at-eol some-branch
It may not do quite what you want, though (it sounds like you are more
interested in matching context with whitespace changes than ignoring
spaces on modified lines).
-Peff
--
Dušan Červenka | Software Developer
a: ACRIOS Systems s.r.o. | Razinova 2257/5 | Ostrava 700 30
e: cervenka@acrios.com | w: www.acrios.com
m: +421 918 715 117