Re: [git-users] Bringing back botched history in a rebaseable state
On Mon, Aug 28, 2017 at 10:32:36AM -0700, Michael wrote: > You might try 'imerge'. > > Git-imerge basically can construct a rebase, and it actually looks at all the > commits along the way, rather than only the heads and merge-base. That one here? https://github.com/mhagger/git-imerge Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
On Tue, Aug 29, 2017 at 09:06:24PM +0100, Philip Oakley wrote: > The other aspect is that 'rebase' does not always play well with merges. It > (rebase) was designed to handle just a single feature branch, not one that > has merges within it. That is an important information, I was not aware that just a single merge breaks rebase for this branch permanently. This should be more clear in the docs. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
Marc, The other aspect is that 'rebase' does not always play well with merges. It (rebase) was designed to handle just a single feature branch, not one that has merges within it. Philip - Original Message - From: "Konstantin Khomoutov" To: Sent: Tuesday, August 29, 2017 9:14 AM Subject: Re: [git-users] Bringing back botched history in a rebaseable state On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote: > > But when I try to git rebase fan upon master, I get the same file > > that > > is even in the diff between msater and fan over and over again. I > > guess > > that git rebase goes back to commit 2357bcc where fan was branched > > off > > master and tries to reapply all changes one by one, most of which > > have > > been rolled back since then or have already been done in master. I > > have > > merged msater into fan multiple times in the hope that this would > > make > > rebasing possible again, but to no avail. [...] > One way would be to merge with --no-commit then manually fixing up the > results (by picking the correct contents for particular files using > `git checkout`) and then staging the changes and comitting. Only the issue is that I don't want to merge, I want to rebase. Sorry, I was in a hurry and misread your actual problem statement :-( For rebasing, one way to attack the problem is to "be explicit" about both the range of commits to rebase and the point to rebase them onto. You specify the range as usually -- by using the hash name of the immediate parent of the "bottom" commit in the range, and use the "--onto" command-line option to tell the rebase where you want to plant that range on. Another possibility is to identify which commit really make "fan" different from "master", reset "fan" to point to "master" and then cherry-pick those commits from the old state of "fan". Since you were about to rebase "fan" anyway, there's no problem with keeping the "fan" history untouched, I reckon. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
On Mon, Aug 28, 2017 at 12:28:57PM +0200, Marc Haber wrote: > > > But when I try to git rebase fan upon master, I get the same file that > > > is even in the diff between msater and fan over and over again. I guess > > > that git rebase goes back to commit 2357bcc where fan was branched off > > > master and tries to reapply all changes one by one, most of which have > > > been rolled back since then or have already been done in master. I have > > > merged msater into fan multiple times in the hope that this would make > > > rebasing possible again, but to no avail. [...] > > One way would be to merge with --no-commit then manually fixing up the > > results (by picking the correct contents for particular files using > > `git checkout`) and then staging the changes and comitting. > > Only the issue is that I don't want to merge, I want to rebase. Sorry, I was in a hurry and misread your actual problem statement :-( For rebasing, one way to attack the problem is to "be explicit" about both the range of commits to rebase and the point to rebase them onto. You specify the range as usually -- by using the hash name of the immediate parent of the "bottom" commit in the range, and use the "--onto" command-line option to tell the rebase where you want to plant that range on. Another possibility is to identify which commit really make "fan" different from "master", reset "fan" to point to "master" and then cherry-pick those commits from the old state of "fan". Since you were about to rebase "fan" anyway, there's no problem with keeping the "fan" history untouched, I reckon. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
You might try 'imerge'. Git-imerge basically can construct a rebase, and it actually looks at all the commits along the way, rather than only the heads and merge-base. On 2017-08-28, at 3:28 AM, Marc Haber wrote: > On Mon, Aug 28, 2017 at 11:26:06AM +0300, Konstantin Khomoutov wrote: >> On Sat, Aug 26, 2017 at 12:37:55PM +0200, Marc Haber wrote: >>> But when I try to git rebase fan upon master, I get the same file that >>> is even in the diff between msater and fan over and over again. I guess >>> that git rebase goes back to commit 2357bcc where fan was branched off >>> master and tries to reapply all changes one by one, most of which have >>> been rolled back since then or have already been done in master. I have >>> merged msater into fan multiple times in the hope that this would make >>> rebasing possible again, but to no avail. >> [...] >> >> Isn't this the case covered by this bit from the git-merge(1) manual >> page? >> >> | With the strategies that use 3-way merge (including the default, >> recursive), >> | if a change is made on both branches, but later reverted on one of the >> | branches, that change will be present in the merged result; some people >> | find this behavior confusing. It occurs because only the heads and the >> merge >> | base are considered when performing a merge, not the individual commits. >> | The merge algorithm therefore considers the reverted change >> | as no change at all, and substitutes the changed version instead. >> >> I don't have a clear idea of how to deal with this properly. > > I guess that this does not work nicely with rebase since rebase tries to > apply each commit single in turn, which causes merge conflicts over and > over again. > >> One way would be to merge with --no-commit then manually fixing up the >> results (by picking the correct contents for particular files using >> `git checkout`) and then staging the changes and comitting. > > Only the issue is that I don't want to merge, I want to rebase. > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 > Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
On Mon, Aug 28, 2017 at 11:26:06AM +0300, Konstantin Khomoutov wrote: > On Sat, Aug 26, 2017 at 12:37:55PM +0200, Marc Haber wrote: > > But when I try to git rebase fan upon master, I get the same file that > > is even in the diff between msater and fan over and over again. I guess > > that git rebase goes back to commit 2357bcc where fan was branched off > > master and tries to reapply all changes one by one, most of which have > > been rolled back since then or have already been done in master. I have > > merged msater into fan multiple times in the hope that this would make > > rebasing possible again, but to no avail. > [...] > > Isn't this the case covered by this bit from the git-merge(1) manual > page? > > | With the strategies that use 3-way merge (including the default, recursive), > | if a change is made on both branches, but later reverted on one of the > | branches, that change will be present in the merged result; some people > | find this behavior confusing. It occurs because only the heads and the merge > | base are considered when performing a merge, not the individual commits. > | The merge algorithm therefore considers the reverted change > | as no change at all, and substitutes the changed version instead. > > I don't have a clear idea of how to deal with this properly. I guess that this does not work nicely with rebase since rebase tries to apply each commit single in turn, which causes merge conflicts over and over again. > One way would be to merge with --no-commit then manually fixing up the > results (by picking the correct contents for particular files using > `git checkout`) and then staging the changes and comitting. Only the issue is that I don't want to merge, I want to rebase. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Bringing back botched history in a rebaseable state
On Sat, Aug 26, 2017 at 12:37:55PM +0200, Marc Haber wrote: > Hi, > > whenever I think that I have finally understood how merging and rebasing > in git works, something happens and I am confused as before. > > The git history (obtained with git log --graph --oneline --decorate > --all) pasted below shows a git repository containing my ssh > configuration, with a master branch that is shared between machines, and > a local branch, fan, containing changes that are needed to use ssh on > fan. Althouth both branches have diverged at the bottom of the history, > the entire diff is tiny. > > 128 [4/4984]mh@fan:~ $ git diff master..fan | diffstat > head/00_dist_defaults |1 + > mh/5_dist_swivel |2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > [5/4985]mh@fan:~ $ > > But when I try to git rebase fan upon master, I get the same file that > is even in the diff between msater and fan over and over again. I guess > that git rebase goes back to commit 2357bcc where fan was branched off > master and tries to reapply all changes one by one, most of which have > been rolled back since then or have already been done in master. I have > merged msater into fan multiple times in the hope that this would make > rebasing possible again, but to no avail. [...] Isn't this the case covered by this bit from the git-merge(1) manual page? | With the strategies that use 3-way merge (including the default, recursive), | if a change is made on both branches, but later reverted on one of the | branches, that change will be present in the merged result; some people | find this behavior confusing. It occurs because only the heads and the merge | base are considered when performing a merge, not the individual commits. | The merge algorithm therefore considers the reverted change | as no change at all, and substitutes the changed version instead. I don't have a clear idea of how to deal with this properly. One way would be to merge with --no-commit then manually fixing up the results (by picking the correct contents for particular files using `git checkout`) and then staging the changes and comitting. You could also try exploring whether "ours" or "theirs" modifiers to the merge strategy would do what yo're after, like with $ git merge -s recursive -X ours ... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
