* Logical bug during MERGE or REBASE
@ 2021-07-02 16:25 skottkuk
2021-07-03 7:57 ` Atharva Raykar
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: skottkuk @ 2021-07-02 16:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Hello.
I got a strange result in the process of "merge" and/or "rebase".
I'm not a git professional, so maybe this is not a bug, but a feature.
But as for me, it would be logical to consider the construction inside {} as something whole, and not just put all the changes into one heap with notification what all OK, no conflicts.
All the details are inside the git-bugreport-2021-07-02-1737.txt.
I hope this log will be useful. Feel free to write me for extra details.
Best regards,
Skott
[-- Attachment #2: git-bugreport-2021-07-02-1737.txt --]
[-- Type: text/plain, Size: 1862 bytes --]
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
I did:
$git init
$git add Program.cs
Inside:
{
Console.Writeline("1");
Console.Readline();
}
$git commit -m "Init commit"
$git checkout -b dev
Did this changes in Program.cs:
{
Console.Writeline("1");
Console.Readline();
Console.Readline();
Console.Readline();
}
$git commit -a -m "dev commit"
$git checkout master
Did this changes in Program.cs:
{
Console.Writeline("1");
Console.Writeline("2");
Console.Readline();
Console.Readline();
}
$git commit -a -m "master commit"
And I get a logical bug inside Program.cs when I want merge or rebase:
1)git merge dev
OR
2)git rebase dev
What did you expect to happen? (Expected behavior)
I expected conflict in my Program.cs like:
{
Console.Writeline("1");
<<<<<<< HEAD
Console.Writeline("2");
=======
Console.Readline();
>>>>>>> dev
Console.Readline();
Console.Readline();
}
What happened instead? (Actual behavior)
Just sum of 2 commits without any conflicts:
{
Console.Writeline("1");
Console.Writeline("2");
Console.Readline();
Console.Readline();
Console.Readline();
Console.Readline();
}
What's different between what you expected and what actually happened?
Extra lines was added in "silent" mode without any notification.
Anything else you want to add:
Now necessary to revice all lines, even if there are no any conflicts :(
[System Info]
git version:
git version 2.32.0.windows.1
cpu: x86_64
built from commit: 4c204998d0e156d13d81abe1d1963051b1418fc0
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Windows 6.1 7601
compiler info: gnuc: 10.3
libc info: no libc information available
$SHELL (typically, interactive shell): <unset>
[Enabled Hooks]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Logical bug during MERGE or REBASE 2021-07-02 16:25 Logical bug during MERGE or REBASE skottkuk @ 2021-07-03 7:57 ` Atharva Raykar 2021-07-04 6:12 ` Bagas Sanjaya 2021-07-03 9:07 ` martin 2021-07-03 11:03 ` Ævar Arnfjörð Bjarmason 2 siblings, 1 reply; 6+ messages in thread From: Atharva Raykar @ 2021-07-03 7:57 UTC (permalink / raw) To: skottkuk; +Cc: git On 02-Jul-2021, at 21:55, skottkuk@wp.pl wrote: > > Hello. > > I got a strange result in the process of "merge" and/or "rebase". > > I'm not a git professional, so maybe this is not a bug, but a feature. > But as for me, it would be logical to consider the construction inside {} > as something whole, and not just put all the changes into one heap with > notification what all OK, no conflicts. > > All the details are inside the git-bugreport-2021-07-02-1737.txt. > I hope this log will be useful. Feel free to write me for extra details. > > Best regards, > Skott<git-bugreport-2021-07-02-1737.txt> Let's look at the diffs (I have annotated this with arrows): $ # common ancestor, ie, the first commit $ initial=$(git merge-base master dev) $ git diff $initial master diff --git a/program.cs b/program.cs index 8bc1a4d..93f872f 100644 --- a/program.cs +++ b/program.cs @@ -1,4 +1,6 @@ { Console.Writeline("1"); + Console.Writeline("2"); + Console.Readline(); Console.Readline(); <--- X } $ git diff $initial dev diff --git a/program.cs b/program.cs index 8bc1a4d..eb91c97 100644 --- a/program.cs +++ b/program.cs @@ -1,4 +1,6 @@ { Console.Writeline("1"); Console.Readline(); <--- X + Console.Readline(); + Console.Readline(); } As you can tell, on the master branch, Git sees the changes as "lines were added above the line labeled X", and on the dev branch, Git sees the changes as "lines were added below the line labeled X". Thus when a 3-way merge is performed, it sees no conflicting changes. Adding lines above X does not conflict with adding lines below X. I do agree the result does look surprising at first. If in the dev branch, git had assumed the "Readline()s" to be added in between, rather than at the bottom, you would have ended up with a conflict, but that did not happen. --- Atharva Raykar ಅಥರ್ವ ರಾಯ್ಕರ್ अथर्व रायकर ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: Logical bug during MERGE or REBASE 2021-07-03 7:57 ` Atharva Raykar @ 2021-07-04 6:12 ` Bagas Sanjaya 2021-07-04 6:30 ` Atharva Raykar 0 siblings, 1 reply; 6+ messages in thread From: Bagas Sanjaya @ 2021-07-04 6:12 UTC (permalink / raw) To: Atharva Raykar, skottkuk; +Cc: git On 03/07/21 14.57, Atharva Raykar wrote: > Let's look at the diffs (I have annotated this with arrows): > > $ # common ancestor, ie, the first commit > $ initial=$(git merge-base master dev) > > $ git diff $initial master > > diff --git a/program.cs b/program.cs > index 8bc1a4d..93f872f 100644 > --- a/program.cs > +++ b/program.cs > @@ -1,4 +1,6 @@ > { > Console.Writeline("1"); > + Console.Writeline("2"); > + Console.Readline(); > Console.Readline(); <--- X > } > > $ git diff $initial dev > > diff --git a/program.cs b/program.cs > index 8bc1a4d..eb91c97 100644 > --- a/program.cs > +++ b/program.cs > @@ -1,4 +1,6 @@ > { > Console.Writeline("1"); > Console.Readline(); <--- X > + Console.Readline(); > + Console.Readline(); > } > > As you can tell, on the master branch, Git sees the changes as > "lines were added above the line labeled X", > and on the dev branch, Git sees the changes as > "lines were added below the line labeled X". What's the purpose of "X-labeled line" above? -- An old man doll... just what I always wanted! - Clara ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Logical bug during MERGE or REBASE 2021-07-04 6:12 ` Bagas Sanjaya @ 2021-07-04 6:30 ` Atharva Raykar 0 siblings, 0 replies; 6+ messages in thread From: Atharva Raykar @ 2021-07-04 6:30 UTC (permalink / raw) To: Bagas Sanjaya; +Cc: skottkuk, Git List On 04-Jul-2021, at 11:42, Bagas Sanjaya <bagasdotme@gmail.com> wrote: > > On 03/07/21 14.57, Atharva Raykar wrote: >> Let's look at the diffs (I have annotated this with arrows): >> $ # common ancestor, ie, the first commit >> $ initial=$(git merge-base master dev) >> $ git diff $initial master >> diff --git a/program.cs b/program.cs >> index 8bc1a4d..93f872f 100644 >> --- a/program.cs >> +++ b/program.cs >> @@ -1,4 +1,6 @@ >> { >> Console.Writeline("1"); >> + Console.Writeline("2"); >> + Console.Readline(); >> Console.Readline(); <--- X >> } >> $ git diff $initial dev >> diff --git a/program.cs b/program.cs >> index 8bc1a4d..eb91c97 100644 >> --- a/program.cs >> +++ b/program.cs >> @@ -1,4 +1,6 @@ >> { >> Console.Writeline("1"); >> Console.Readline(); <--- X >> + Console.Readline(); >> + Console.Readline(); >> } >> As you can tell, on the master branch, Git sees the changes as >> "lines were added above the line labeled X", >> and on the dev branch, Git sees the changes as >> "lines were added below the line labeled X". > > What's the purpose of "X-labeled line" above? It was just something I manually annotated on the output to keep a track of which 'Console.Readline()' line I was referring to. It is less tedious for to say "line labeled X" than, "the second line in the code block in the initial commit". If it has made my explanation a little unclear, I don't mind having a second attempt at it :) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Logical bug during MERGE or REBASE 2021-07-02 16:25 Logical bug during MERGE or REBASE skottkuk 2021-07-03 7:57 ` Atharva Raykar @ 2021-07-03 9:07 ` martin 2021-07-03 11:03 ` Ævar Arnfjörð Bjarmason 2 siblings, 0 replies; 6+ messages in thread From: martin @ 2021-07-03 9:07 UTC (permalink / raw) To: skottkuk, git On 02/07/2021 18:25, skottkuk@wp.pl wrote: > But as for me, it would be logical to consider the construction inside {} as something whole, For git the {} are just text, like anything else in your file. Also, seeing the function as a whole, i.e. always give a conflict for any 2 changes within one function, is not wanted. There a plenty of cases where 2 or more changes within the same (bigger) function are merged together, and expected to be merged. For all else see the reply from Atharva Raykar. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Logical bug during MERGE or REBASE 2021-07-02 16:25 Logical bug during MERGE or REBASE skottkuk 2021-07-03 7:57 ` Atharva Raykar 2021-07-03 9:07 ` martin @ 2021-07-03 11:03 ` Ævar Arnfjörð Bjarmason 2 siblings, 0 replies; 6+ messages in thread From: Ævar Arnfjörð Bjarmason @ 2021-07-03 11:03 UTC (permalink / raw) To: skottkuk; +Cc: git, Atharva Raykar On Fri, Jul 02 2021, skottkuk@wp.pl wrote: > Hello. > > I got a strange result in the process of "merge" and/or "rebase". Atharva already replied to most of this, just adding on this point: > [...] > But as for me, it would be logical to consider the construction inside > {} as something whole, and not just put all the changes into one heap > with notification what all OK, no conflicts. Git in general is not aware that your programming language considers {} to be special, we don't try to do language detection, or to semantically parse the program. It's a general merge driver on text lines that works the same whether you have a language like C# that uses {} braces, or a language like Emacs Lisp which does not. There's particular common cases where this logic goes "wrong", I've run into it the most with repetitive declarations like: { { description => "some thingy", callback => function { foo }, strict => 1, warn => 1, }, [... lots of these omitted ... ] { description => "other thingy", callback => function { bar }, strict => 1, warn => 1, }, }, I didn't bother to check this specific example, but in cases *like that* the merge driver will often append "duplicates" when two branches added the same "other thingy", since the boilerplate at the end (or beginning, depending) is repetitive, so a duplication becomes indistinguishable from an addition for a naïve merge driver). You can define your own merge driver that's aware of your language, I think this is probably a too complex and Bad Idea in general. Custom merge drivers are very useful for e.g. the git-annex case, which ends up merging really simple "log" files. merges there are always equivalent to basically a "sort -u". I.e. keep all lines added, remove duplicates. But for a programming language a "smart merge" is, I'd like to submit, simply an impossible task. Even if you had perfect AI you couldn't do it, even if I had a clone of myself from yesterday we probably couldn't agree on how to solve all merges. That's because once you get past the simple cases a merge resolution is something that requires judgement calls from the programmer. E.g. I worked on a topic branch, and now I've got a conflict because someone changed the function signature. I can either do the bare minimum and use some compatibility interface today, or convert all my work to the "new API" and not have to convert from the legacy API in the future. Either one would be a valid resolution, which the perfect AI, or even my clone from yesterday might do differently. But most importantly having a textual conflict in a program when you merge/rebase is almost always the trivial case, having a semantic conflict is something you always need to check for. Git (or merge tools in general) can't help you with that, because your "conflict" is in a conflict between the expectations of your topic branch, and whether or not they hold given whatever's happened on an advancing upstream. So whether you have textual conflicts on merge/rebase from git or not, your workflow really should be to always assume that you have a semantic conflict, unless you're already completely familiar with the new code you're merging into your branch. I.e. after a merge/rebase look at your patches again to see if they make sense given what changed on the upstream, compile, run the tests you have etc. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-07-04 6:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-02 16:25 Logical bug during MERGE or REBASE skottkuk 2021-07-03 7:57 ` Atharva Raykar 2021-07-04 6:12 ` Bagas Sanjaya 2021-07-04 6:30 ` Atharva Raykar 2021-07-03 9:07 ` martin 2021-07-03 11:03 ` Ævar Arnfjörð Bjarmason
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).