Re: [git-users] Bringing back botched history in a rebaseable state

[Marc Haber]

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

[Philip Oakley]

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" <kos...@bswap.ru>

To: <git-users@googlegroups.com>
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

[Konstantin Khomoutov]

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

[Michael]

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

[Marc Haber]

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

[Konstantin Khomoutov]

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.

[git-users] Bringing back botched history in a rebaseable state

[Marc Haber]

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.

* 193debd (HEAD -> master) customer Notebook is actually ln, not lv
| *   24929ae (fan) Merge branch 'master' into fan
| |\
| |/
|/|
* | a58930f (origin/master) add tipsy
* | f7e30b6 add fishtail
* | 8b05270 add aliases for testsystems
* | ac45ac3 testsid is no longer a ka51 host
| * 808f3bc add dosido slide woodpecker
| * 8e7e54a (origin/fan) fix wrong hostname lv/ln
| *   62d92a2 Merge remote-tracking branch 'origin/master' into fan
| |\
| |/
|/|
| * 72cb5ec public key for reinitialized yubikey
| * a1de811 add fleckerl
| * ce9d9cc test: add keys to agent
| * 6f8ec48 use swivel as swivel.ka51 to avoid RPF
| | * 76d5279 (origin/customer) move whip to its own file, add git.z.d
| | * 01efcb2 add ln00041
| | * df818d1 add swivel port forward for xrdp
| | * 00045df customer systems are directly reachable from a customer system
| |/
|/|
* | 21196ca access ldaptest1 via milonga
* | 7c2fe8f add oversway
* | 6aaa649 add mh-yubikey01
* | 366c9d5 move whip to its own file, add git.z.d
| | *   9949e2e (origin/atln) Merge branch 'master' into atln
| | |\
| |_|/
|/| |
* | | 32e85d7 add alemana
|/ /
* | 1010917 add temporary webvirt01
* | ca101af add gancho
* | 9445368 allow 3des for access to hp switches
| * 1bdaca1 add gancho
| * a321479 add swivel port forward for xrdp
| * 144fa67 customer systems are directly reachable from a customer system
|/
* 2357bcc add code for *.customer.net (needs branch on customer machines)
* 78f9a17 correctly bracket literal IPv6 address
* 2b1c71e use ssh -W instead of nc

How do I get back to a branch fan, that is clearly branched off master,
which can be cleanly rebased up on master when master changes?

Is there something easier than renaming fan to fan-old, branching a new
fan off master and applying the output of git diff master..fan-old to
the new fan?

What did I do wrong to cause this mess in this simple repository?

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.