Re: when is a merge a conflict, two named branches with or without heads
> Point 3 is not true. When you have two branches but only 1 topological > head, you can only merge the topological head into the other branch. > Trying to merge the other direction will fail because the other branch > is already an ancestor. Ah, thanks for the clarification > Merging... > + Feature into master: No conflict merge, feature is a direct line > descendant of master. Well yes, but still there might be two cases: 1. For the simplicity, there is one file and it gets modified. So there is a «sort of conflict» 2. In feature branch the file test is not changed but a new file is added. As in , | hg init 2-namedB-1head-two-files | cd 2-namedB-1head-two-files | hg branch master | echo 1 > test | hg add test | hg commit -m "First commit in master" | echo 1.1 > test | hg addremove | hg commit -m "Second commit in master" | hg branch feature | echo 1.2 > test2 | hg addremove | hg commit -m "First commit in feature" | echo 1.2.1 > test2 | hg commit -m "Second commit in feature" | hg checkout master ` But I presume you will argue by the graph: «a descendant is a descendant is a descendant. I don't care whether you modify a file or add a new one. So the difference between 1 and 2 is artificial» However the graph in the case of merging feature into master does not look linear anymore. (Not sure what git does, maybe just a fast-forward). Anyhow I think the graph should be nonlinear I just wished there were a message indicating the change in a file. But that is most likely just me. > + Master into feature: abort: merging with a working directory > ancestor has no effect > Mischa > > This e-mail message, including any attachments, is for the sole use of > the intended recipient(s) and may contain information that is > confidential and protected by law from unauthorized disclosure. Any > unauthorized review, use, disclosure or distribution is prohibited. If > you are not the intended recipient, please contact the sender by reply > e-mail and destroy all copies of the original message. > ___ > Mercurial mailing list > Mercurial@lists.mercurial-scm.org > https://lists.mercurial-scm.org/mailman/listinfo/mercurial -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature ___ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
RE: when is a merge a conflict, two named branches with or without heads
> -Original Message- > From: Uwe Brauer > Sent: Friday, July 21, 2023 8:25 AM > > What is a bit confusing, is: > > 1. Merging is allowed in both cases. If I had used bookmarks (or >even topics, at least in the standard setting) then hg would have >refused the merge, nothing to merge since there is only one head. > > 2. In the case with two heads, hg does the expected thing. > > 3. But in the case with one head I find the merging well a bit >surprising. I presume there is a fundamental conceptual issue >here. Merging is allowed even if the graph has one head, and it >is important what is merged into what. If I merge feature into >master, the «content» of test file of «feature» is taken, if I >had done it vice versa then the content of the «master» branch >would have prevailed. Point 3 is not true. When you have two branches but only 1 topological head, you can only merge the topological head into the other branch. Trying to merge the other direction will fail because the other branch is already an ancestor. Merging... + Feature into master: No conflict merge, feature is a direct line descendant of master. + Master into feature: abort: merging with a working directory ancestor has no effect Mischa This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
Re: when is a merge a conflict, two named branches with or without heads
>>> "RW" == Rainer Woitok writes: Rainer, > Uwe, > On Friday, 2023-07-21 14:38:03 +0200, you wrote: >> ... >> What do I miss here? What I find confusing that hg diff displays in both >> cases a conflicting difference but hg merge *ignores* in the first >> example that conflict. > Just run "hg log -G" on both your repositories :-) I always do this almost every 2 sec. And I know one graph is only one head the other has two heads. I did this on purpose What is a bit confusing, is: 1. Merging is allowed in both cases. If I had used bookmarks (or even topics, at least in the standard setting) then hg would have refused the merge, nothing to merge since there is only one head. 2. In the case with two heads, hg does the expected thing. 3. But in the case with one head I find the merging well a bit surprising. I presume there is a fundamental conceptual issue here. Merging is allowed even if the graph has one head, and it is important what is merged into what. If I merge feature into master, the «content» of test file of «feature» is taken, if I had done it vice versa then the content of the «master» branch would have prevailed. Anyhow merging with just one head is a bit of corner case, still I wished some message would pop telling me what is going to happen. > Sincerely, > Rainer -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature ___ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
Re: when is a merge a conflict, two named branches with or without heads
Uwe, On Friday, 2023-07-21 14:38:03 +0200, you wrote: > ... > What do I miss here? What I find confusing that hg diff displays in both > cases a conflicting difference but hg merge *ignores* in the first > example that conflict. Just run "hg log -G" on both your repositories :-) Sincerely, Rainer ___ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
when is a merge a conflict, two named branches with or without heads
Hi I run into a problem I don't fully understand. Consider the following example hg init hg-merge cd hg-merge hg branch master echo 1 > test hg add test hg commit -m "First commit in master" echo 1.1 > test hg add . hg commit -m "Second commit in master" hg branch feature echo 1.2 > test hg add . hg commit -m "First commit in feature" echo 1.2.1 > test hg add . hg commit -m "Second commit in feature" hg checkout master now when I run hg diff -r feature hg diff -r feature diff --git a/test b/test --- a/test +++ b/test @@ -1,1 +1,1 @@ -1.2.1 +1.1 So there is clearly a conflict the file only contains a line. However hg merge feature Does not report back any merging conflict If on the other hand create a head, by hg init hg-merge-conflict cd hg-merge-conflict hg branch master echo 1 > test hg add test hg commit -m "First commit in master" echo 1.1 > test hg add . hg commit -m "Second commit in master" hg up 0 hg branch feature echo 1.2 > test hg add . hg commit -m "First commit in feature" echo 1.2.1 > test hg add . hg commit -m "Second commit in feature" hg checkout master And hg diff -r feature diff --git a/test b/test --- a/test +++ b/test @@ -1,1 +1,1 @@ -1.2.1 +1.1 And now hg merge reports a conflict as it should. What do I miss here? What I find confusing that hg diff displays in both cases a conflicting difference but hg merge *ignores* in the first example that conflict. (I presume the reason is: example 1 has no topological head) Regards Uwe Brauer -- Warning: Content may be disturbing to some audiences I strongly condemn Putin's war of aggression against the Ukraine. I support to deliver weapons to Ukraine's military. I support the NATO membership of the Ukraine. I support the EU membership of the Ukraine. https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/ smime.p7s Description: S/MIME cryptographic signature ___ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
Re: find pruned changesets
I don't think we have. We should get a `pruned()` revset On 7/21/23 10:52, Mitchell Elutovich wrote: I am struggling to put together a hg log [only] command to show me pruned changesets, is there a way to have a revset based on a textual string/regex of the obsolete description? My current solution is: hg --hidden log -r "obsolete()" | grep -B 6 -A 1 "using prune" ___ Evolve-testers mailing list evolve-test...@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-evolve-testers -- Pierre-Yves David ___ Evolve-testers mailing list evolve-test...@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-evolve-testers
find pruned changesets
I am struggling to put together a hg log [only] command to show me pruned changesets, is there a way to have a revset based on a textual string/regex of the obsolete description? My current solution is: hg --hidden log -r "obsolete()" | grep -B 6 -A 1 "using prune" ___ Evolve-testers mailing list evolve-test...@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-evolve-testers
