Re: Merging submodules - best merge-base
On Sat, Mar 09, 2013 at 06:45:56PM +0100, Jens Lehmann wrote: Am 07.03.2013 19:59, schrieb Heiko Voigt: On Thu, Mar 07, 2013 at 10:49:09AM +0100, Daniel Bratell wrote: Den 2013-03-06 19:12:05 skrev Heiko Voigt hvo...@hvoigt.net: So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Maybe both could be legal even. The current code can't be all wrong, and this case also seems to be straightforward. Ok I have thought about it further and I did not come up with a simple (and stable) enough strategy that would allow your use case to merge cleanly without user interaction. The problem is that your are actually doing a rewind from base to both tips. The fact that a rewind is there makes git suspicious and we simply give up. IMO, thats the right thing to do in such a situation. What should a merge strategy do? It infers from two changes what the final intention might be. For submodules we can do that when the changes on both sides point forward. Since thats the typical progress of development. If not there is some reason for it we do not know about. So the merge gives up. Please see this post about why we need to forbid rewinds from the initial design discussion: http://article.gmane.org/gmane.comp.version-control.git/149003 I agree that rewinds are a very good reason not merge two branches using a fast-forward strategy, but I believe Daniel's use case is a (and maybe the only) valid exception to that rule: both branches contain *exactly* the same rewind. In that case I don't see any problem to just do a fast forward to S21, as both agree on the commits to rewind. That is different than using the merge base of the two commits needing merge. I agree that rewinding to exactly the same commits is probably a valid exception. Will have a look into extending the submodule merge strategy to include this case. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging submodules - best merge-base
Am 07.03.2013 19:59, schrieb Heiko Voigt: On Thu, Mar 07, 2013 at 10:49:09AM +0100, Daniel Bratell wrote: Den 2013-03-06 19:12:05 skrev Heiko Voigt hvo...@hvoigt.net: On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Maybe both could be legal even. The current code can't be all wrong, and this case also seems to be straightforward. Ok I have thought about it further and I did not come up with a simple (and stable) enough strategy that would allow your use case to merge cleanly without user interaction. The problem is that your are actually doing a rewind from base to both tips. The fact that a rewind is there makes git suspicious and we simply give up. IMO, thats the right thing to do in such a situation. What should a merge strategy do? It infers from two changes what the final intention might be. For submodules we can do that when the changes on both sides point forward. Since thats the typical progress of development. If not there is some reason for it we do not know about. So the merge gives up. Please see this post about why we need to forbid rewinds from the initial design discussion: http://article.gmane.org/gmane.comp.version-control.git/149003 I agree that rewinds are a very good reason not merge two branches using a fast-forward strategy, but I believe Daniel's use case is a (and maybe the only) valid exception to that rule: both branches contain *exactly* the same rewind. In that case I don't see any problem to just do a fast forward to S21, as both agree on the commits to rewind. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging submodules - best merge-base
Den 2013-03-06 19:12:05 skrev Heiko Voigt hvo...@hvoigt.net: On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote: I can phrase this in two ways and I'll start with the short way: Why does a merge of a git submodule use as merge-base the commit that was active in the merge-base of the parent repo, rather than the merge-base of the two commits that are being merged? The long question is: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Maybe both could be legal even. The current code can't be all wrong, and this case also seems to be straightforward. /Daniel -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging submodules - best merge-base
On Thu, Mar 07, 2013 at 10:49:09AM +0100, Daniel Bratell wrote: Den 2013-03-06 19:12:05 skrev Heiko Voigt hvo...@hvoigt.net: On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Maybe both could be legal even. The current code can't be all wrong, and this case also seems to be straightforward. Ok I have thought about it further and I did not come up with a simple (and stable) enough strategy that would allow your use case to merge cleanly without user interaction. The problem is that your are actually doing a rewind from base to both tips. The fact that a rewind is there makes git suspicious and we simply give up. IMO, thats the right thing to do in such a situation. What should a merge strategy do? It infers from two changes what the final intention might be. For submodules we can do that when the changes on both sides point forward. Since thats the typical progress of development. If not there is some reason for it we do not know about. So the merge gives up. Please see this post about why we need to forbid rewinds from the initial design discussion: http://article.gmane.org/gmane.comp.version-control.git/149003 I am not saying that the current behavior is perfect but I think a merge containing a rewind needs user support. We could give the user a hint and say: Hey I gave up but the two sides are contained in each other and this is the commit containing both. Then the user can choose to use that suggested solution. We already do the same for the merge commit search. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merging submodules - best merge-base
On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote: I can phrase this in two ways and I'll start with the short way: Why does a merge of a git submodule use as merge-base the commit that was active in the merge-base of the parent repo, rather than the merge-base of the two commits that are being merged? The long question is: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Merging submodules - best merge-base
I can phrase this in two ways and I'll start with the short way: Why does a merge of a git submodule use as merge-base the commit that was active in the merge-base of the parent repo, rather than the merge-base of the two commits that are being merged? The long question is: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. /Daniel -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
