Commited to wrong branch

> I am resurrecting a discussion from a week or two back (been on
> holiday).  As follows...
>
> I had made some changes to some files and then done a commit. Only
> then did I realise that I had the wrong branch checked out. To make
> matters worse I then did a 'git reset HEAD^' which means that I can
> now no longer switch branches. I am stuck. I had some advice (thanks!)
> but it was not complete. I'd appreciate some more help.

> On Tue, Sep 15, 2009 at 12:31 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> I am resurrecting a discussion from a week or two back (been on
>> holiday).  As follows...
>>
>> I had made some changes to some files and then done a commit. Only
>> then did I realise that I had the wrong branch checked out. To make
>> matters worse I then did a 'git reset HEAD^' which means that I can
>> now no longer switch branches. I am stuck. I had some advice (thanks!)
>> but it was not complete. I'd appreciate some more help.
>
> Hi Howard,
>
> just to make sure I understand your issue
>
>  1 - you were on branch X, thinking your were on branch Y
>  2 - edit, diff, commit, realised the mistake
>  3 - git reset HEAD^
>
> so if you now run `git status` and `git diff` it will show your
> changes as if they were uncommitted and unstaged.
>
> (Before you start with various attempts to recover below, a great
> trick is to make an instant-backup in case things go wrong: cd .. / ;
> cp -pr moodle.git moodle-backup.git ; cd moodle.git )
>
> You can now try do do
>
>  4 - git checkout Y
>
> and if the changes are on files that don't change between X and Y,
> then git will change the branches and keep your changes there. If the
> files are different between X and Y, it won't work.
>
> What I can recommend is to save your patch, as follows
>
>  5 - git diff > tempchanges.patch
>  6 - git reset --hard # this will discard your changes, careful
>  7 - git checkout Y
>  8 - patch -p1 < tempchanges.patch
>
> The patch may not apply cleanly :-) -- note that patch is more
> tolerant of iffy merges than git's internal implementation ("git
> apply") -- so it will succeed more often... but the results need
> review.
>
> There is a more git-style approach that is to use git-stash -- it uses
> git-apply and may not do what you want. The steps are
>
>  5a - git stash # will save your changed files into a "stashed commit"
> and clear out the changes from your working copy
>  6a - git checkout Y
>  7a - git stash apply
>
> hth,
>
>
>
> m
> --
>  martin.langhoff@gmail.com
>  martin@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>

> On Tue, Sep 15, 2009 at 1:05 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> I'm pretty shocked how difficult this is... still...
>
> No prob. It's only hard at the beginning :-)
>
>> I'm finding git logs and reflogs pretty difficult to read and
>> interpret (head melting) - in particular telling what happened on what
>> branch -
>
> I found gitk enormously helpful to visualise things. Try
>
>  gitk # will show you the current branch
>
>  gitk X Y # will show you both branches
>
> gitk is a ton easier to visualise. git log is pretty good but won't
> show merges, so it's limited.
>
> git reflog is confusing, but it's mostly a tool to help when there's
> been a mess and you want to diagnose WTH happened...
>
>>but looking at the reflog (which I assume is showing me the
>> actions on the current branch, but I'm not sure)
>
> Don't worry about the reflog...
>
>>  I think I must have
>> made two commits on the wrong branch so the reset has only 'popped'
>> the top one. Other than that your interpretation is correct.
>
> Ok, so looking at gitk, there would still be one "wrong" commit. Can
> you confirm?
>
>> I cannot currently change branches - it only complains about one file.
>
> If you did follow my previous instructions (specially doing 'git reset
> --hard'), then this should not happen. Except...
>
> Except when you have a file that git is not tracking, and it exists in
> the "other" branch. The commit you undid earlier probably added that
> file. So just rm that file, and change branches.
>
>> I'm a bit worried about that - I would like to understand why this is
>> a problem but I don't.
>
> About the file? It was "new" in the commit you un-committed. So when
> you do git reset --hard, git makes sure all the files it is
> _currently_ tracking are "unchanged". If that file was new, it ignores
> it. Just rm it and be happy.
>
>> So I am now a little hazy on how to deal with previous TWO commits.
>
> Just review gitk and confirm if there are more commits to unstich --
> and we'll  work from there
>
>
> m
> --
>  martin.langhoff@gmail.com
>  martin@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>

> Martin,
>
> Looked at gitk - yes there is definitely one more commit still on the
> current (wrong) branch.
>
> I deleted the offending file and have now successfully switched to the
> other (correct) branch.

> On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
>> Martin,
>>
>> Looked at gitk - yes there is definitely one more commit still on the
>> current (wrong) branch.
>>
>> I deleted the offending file and have now successfully switched to the
>> other (correct) branch.
>
> ok!
>
> so you have
>
> A - The commit you undid, and have in the temp patch. Note that this
> patch file is missing the file you've rm'd.
>
> B - A commit you haven't "undone" on the "wrong" branch X.
>
>  and you are on branch Y
>
> so now...
>
> 1 - git format-patch Y^..Y  # will export that patch B into a file for you.
> 2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
>    this may need conflict resolution - read the notes it prints! If
> it refuses to apply the patch, do "git am --skip" to indicate you
> won't use git-am no more for this, and try applying it with the patch
> utility.
> 3 - patch -p1 < your-patch-A.patch
> 4 - find and readd the file you rm'd earlier -- if you don't have
> another copy, we can get it from git reflog but that'll take extra
> steps :-)
> 5 - git commit # you're committing your patch A here
>
> Now, review with gitk to see that you have what you want to have
> there. If it's all ok...
>
>  6 - git checkout X
>  7 - git reset --hard # unstich that last stray commit
>   --
>
> hope the above helps. Git pros will see that the process could be much
> shorter :-) I chose this specific path because in exporting your
> patches and applying them again you can see each step.
>
> If we were to start again, and the branches are reasonably close to
> eachother (not 19_STABLE vs cvshead :-) ) then you can say
>
>  - X has 2 bad commits that belong to Y, then
>  1 - gitk X & # open gitk to visualise the commits, send it to the background
>  2 - git checkout Y
>  3 - git cherry-pick X^ # takes the next-to-last commit from X and
> tries to apply it here - conflict resolution may be needed
>  4 - git cherry-pick X # same with the very last commit on X
>  5 - gitk # check that is all as you want it
>  6 - git checkout X
>  7 - git reset --hard X^^ # "rewind 2 commits"
>
> hth,
>
>
>
> m
> --
>  martin.langhoff@gmail.com
>  martin@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

> Got as far as applying the temporary patch and I now get a load of...
> 
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file
> theme/onepointnine/local.css.rej
> The next patch would create the file theme/onepointnine/local.css,

> [Please stop top-posting...]
>
> On 2009.09.15 13:58:32 +0100, Howard Miller wrote:
>> Got as far as applying the temporary patch and I now get a load of...
>>
>> Reversed (or previously applied) patch detected!  Assume -R? [n]
>> Apply anyway? [n]
>> Skipping patch.
>> 1 out of 1 hunk ignored -- saving rejects to file
>> theme/onepointnine/local.css.rej
>> The next patch would create the file theme/onepointnine/local.css,
>
> Just don't use patch(1), there's no sane reason to do that, you're
> sacrificing all of what git can offer there.
>
> cherry-pick or format-patch + am -3 are simply much better. (Or
> "checkout -m" or stash + stash apply, if you're dealing with uncommitted
> changes).
>
> Björn
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

> 2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> [Please stop top-posting...]
>
> Not everyone is deep in mailing-list lore :-) -- we can help anyway.
>
> Howard, I see you're wondering about it: http://www.idallen.com/topposting.html
>
>> Just don't use patch(1), there's no sane reason to do that, you're
>> sacrificing all of what git can offer there.
>
> Oh, yes there is, specially for newcomers used to patch, and how it
> handles conflicts.
>
> In this case, I happen to know that Howard is a refugee from CVS land
> (the moodle project in this case), and he is familiar with the output
> of patch if things go wrong.
>
> It's not what I'd recommend to someone that is deep in git-land. But
> even myself (with a bit of code in git) sometimes use patch when
> git-apply tries to be too clever and I just want a damn .rej file to
> review and edit with emacs.
>
> cheers,
>
>
> m
> --
>  martin.langhoff@gmail.com
>  martin@laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>

> 2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > Just don't use patch(1), there's no sane reason to do that, you're
> > sacrificing all of what git can offer there.
> 
> Oh, yes there is, specially for newcomers used to patch, and how it
> handles conflicts.

> On 2009.09.15 15:54:58 +0200, Martin Langhoff wrote:
>> 2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> > Just don't use patch(1), there's no sane reason to do that, you're
>> > sacrificing all of what git can offer there.
>>
>> Oh, yes there is, specially for newcomers used to patch, and how it
>> handles conflicts.
>
> Sooner or later you'll hit a merge conflict anyway, and conflict markers
> aren't that hard to understand, and IMHO are easier to handle than .rej
> files, as you get to edit everything in-place.
>
>> In this case, I happen to know that Howard is a refugee from CVS land
>> (the moodle project in this case), and he is familiar with the output
>> of patch if things go wrong.
>
> Uhm, CVS uses the same conflict markers that git uses.
>
>> It's not what I'd recommend to someone that is deep in git-land. But
>> even myself (with a bit of code in git) sometimes use patch when
>> git-apply tries to be too clever and I just want a damn .rej file to
>> review and edit with emacs.
>
> Well, you likely shouldn't be using git-apply, which is plumbing, and
> can't easily make use of the "index" information in git patches to do a
> three-way merge instead of a "stupid" patch application. Instead use
> git-am --3way to make git perform a three-way merge, leading to
> conflicts instead of plain patch rejection.
>
> And in a case like Howard's, in which nothing is coming from outside the
> repo, there's not even any reason to use am. It's already all in there,
> so "checkout -m", "stash/stash apply" (uncommitted changes) and
> "cherry-pick", "rebase [-i]" are way better than manually dealing with
> format-patch + am or even apply.
>
> Björn
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

> Well, you likely shouldn't be using git-apply, which is plumbing, and
> can't easily make use of the "index" information in git patches to do a
> three-way merge instead of a "stupid" patch application. Instead use
> git-am --3way to make git perform a three-way merge, leading to
> conflicts instead of plain patch rejection.

> 2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > Sooner or later you'll hit a merge conflict anyway, and conflict markers
> > aren't that hard to understand, and IMHO are easier to handle than .rej
> > files, as you get to edit everything in-place.
> 
> When git's diff3 gets confused trying to use ancestry, the conflict
> markers bring completely unrelated things that belong to the history
> of the file and not to the patch at hand.
> 
> It's not about the conflict markers but somewhat nonsensical proposed
> "sides" to the resolution.

> > Well, you likely shouldn't be using git-apply, which is plumbing, and
> > can't easily make use of the "index" information in git patches to do a
> > three-way merge instead of a "stupid" patch application. Instead use
> > git-am --3way to make git perform a three-way merge, leading to
> > conflicts instead of plain patch rejection.
> 
> Um, you got your internals wrong. git-apply is what git-am uses.

> Martin,
>
> Got as far as applying the temporary patch and I now get a load of...
>
> Reversed (or previously applied) patch detected!  Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 1 out of 1 hunk ignored -- saving rejects to file
> theme/onepointnine/local.css.rej
> The next patch would create the file theme/onepointnine/local.css,
>
> funnily I didn't think that file had anything to do with it, but when
> I changed branched I got
>
> T       theme/onepointnine/local.css
>
> Not sure what the T means :-(
>
> H.
>
> 2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
>> On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
>> <howard@e-learndesign.co.uk> wrote:
>>> Martin,
>>>
>>> Looked at gitk - yes there is definitely one more commit still on the
>>> current (wrong) branch.
>>>
>>> I deleted the offending file and have now successfully switched to the
>>> other (correct) branch.
>>
>> ok!
>>
>> so you have
>>
>> A - The commit you undid, and have in the temp patch. Note that this
>> patch file is missing the file you've rm'd.
>>
>> B - A commit you haven't "undone" on the "wrong" branch X.
>>
>>  and you are on branch Y
>>
>> so now...
>>
>> 1 - git format-patch Y^..Y  # will export that patch B into a file for you.
>> 2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
>>    this may need conflict resolution - read the notes it prints! If
>> it refuses to apply the patch, do "git am --skip" to indicate you
>> won't use git-am no more for this, and try applying it with the patch
>> utility.
>> 3 - patch -p1 < your-patch-A.patch
>> 4 - find and readd the file you rm'd earlier -- if you don't have
>> another copy, we can get it from git reflog but that'll take extra
>> steps :-)
>> 5 - git commit # you're committing your patch A here
>>
>> Now, review with gitk to see that you have what you want to have
>> there. If it's all ok...
>>
>>  6 - git checkout X
>>  7 - git reset --hard # unstich that last stray commit
>>   --
>>
>> hope the above helps. Git pros will see that the process could be much
>> shorter :-) I chose this specific path because in exporting your
>> patches and applying them again you can see each step.
>>
>> If we were to start again, and the branches are reasonably close to
>> eachother (not 19_STABLE vs cvshead :-) ) then you can say
>>
>>  - X has 2 bad commits that belong to Y, then
>>  1 - gitk X & # open gitk to visualise the commits, send it to the background
>>  2 - git checkout Y
>>  3 - git cherry-pick X^ # takes the next-to-last commit from X and
>> tries to apply it here - conflict resolution may be needed
>>  4 - git cherry-pick X # same with the very last commit on X
>>  5 - gitk # check that is all as you want it
>>  6 - git checkout X
>>  7 - git reset --hard X^^ # "rewind 2 commits"
>>
>> hth,
>>
>>
>>
>> m
>> --
>>  martin.langhoff@gmail.com
>>  martin@laptop.org -- School Server Architect
>>  - ask interesting questions
>>  - don't get distracted with shiny stuff  - working code first
>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

> What's to stop me.........
>
> * The "wrong" branch just tracks a remote so I can just dump it once I
> have this fixed - (delete it and recreate it?)
> * after my 'reset' the files I have in my working copy (still the
> wrong branch) should be the latest version ('git reset' does not
> change the working copy I think?)
> * So can I grab these files (they are mostly new), checkout the
> correct version, and just overwrite the existing files? I'll loose
> some history but not much and I don't care
>
> Seems too easy :-)
>
> 2009/9/15 Howard Miller <howard@e-learndesign.co.uk>:
>> Martin,
>>
>> Got as far as applying the temporary patch and I now get a load of...
>>
>> Reversed (or previously applied) patch detected!  Assume -R? [n]
>> Apply anyway? [n]
>> Skipping patch.
>> 1 out of 1 hunk ignored -- saving rejects to file
>> theme/onepointnine/local.css.rej
>> The next patch would create the file theme/onepointnine/local.css,
>>
>> funnily I didn't think that file had anything to do with it, but when
>> I changed branched I got
>>
>> T       theme/onepointnine/local.css
>>
>> Not sure what the T means :-(
>>
>> H.
>>
>> 2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
>>> On Tue, Sep 15, 2009 at 2:10 PM, Howard Miller
>>> <howard@e-learndesign.co.uk> wrote:
>>>> Martin,
>>>>
>>>> Looked at gitk - yes there is definitely one more commit still on the
>>>> current (wrong) branch.
>>>>
>>>> I deleted the offending file and have now successfully switched to the
>>>> other (correct) branch.
>>>
>>> ok!
>>>
>>> so you have
>>>
>>> A - The commit you undid, and have in the temp patch. Note that this
>>> patch file is missing the file you've rm'd.
>>>
>>> B - A commit you haven't "undone" on the "wrong" branch X.
>>>
>>>  and you are on branch Y
>>>
>>> so now...
>>>
>>> 1 - git format-patch Y^..Y  # will export that patch B into a file for you.
>>> 2 - git am 0001-whatever-the-name-of-the-file.txt # patch B
>>>    this may need conflict resolution - read the notes it prints! If
>>> it refuses to apply the patch, do "git am --skip" to indicate you
>>> won't use git-am no more for this, and try applying it with the patch
>>> utility.
>>> 3 - patch -p1 < your-patch-A.patch
>>> 4 - find and readd the file you rm'd earlier -- if you don't have
>>> another copy, we can get it from git reflog but that'll take extra
>>> steps :-)
>>> 5 - git commit # you're committing your patch A here
>>>
>>> Now, review with gitk to see that you have what you want to have
>>> there. If it's all ok...
>>>
>>>  6 - git checkout X
>>>  7 - git reset --hard # unstich that last stray commit
>>>   --
>>>
>>> hope the above helps. Git pros will see that the process could be much
>>> shorter :-) I chose this specific path because in exporting your
>>> patches and applying them again you can see each step.
>>>
>>> If we were to start again, and the branches are reasonably close to
>>> eachother (not 19_STABLE vs cvshead :-) ) then you can say
>>>
>>>  - X has 2 bad commits that belong to Y, then
>>>  1 - gitk X & # open gitk to visualise the commits, send it to the background
>>>  2 - git checkout Y
>>>  3 - git cherry-pick X^ # takes the next-to-last commit from X and
>>> tries to apply it here - conflict resolution may be needed
>>>  4 - git cherry-pick X # same with the very last commit on X
>>>  5 - gitk # check that is all as you want it
>>>  6 - git checkout X
>>>  7 - git reset --hard X^^ # "rewind 2 commits"
>>>
>>> hth,
>>>
>>>
>>>
>>> m
>>> --
>>>  martin.langhoff@gmail.com
>>>  martin@laptop.org -- School Server Architect
>>>  - ask interesting questions
>>>  - don't get distracted with shiny stuff  - working code first
>>>  - http://wiki.laptop.org/go/User:Martinlanghoff
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>

> On Tue, Sep 15, 2009 at 12:31 PM, Howard Miller
> <howard@e-learndesign.co.uk> wrote:
> > I am resurrecting a discussion from a week or two back (been on
> > holiday).  As follows...
> >
> > I had made some changes to some files and then done a commit. Only
> > then did I realise that I had the wrong branch checked out. To make
> > matters worse I then did a 'git reset HEAD^' which means that I can
> > now no longer switch branches. I am stuck. I had some advice (thanks!)
> > but it was not complete. I'd appreciate some more help.
> 
> Hi Howard,
> 
> just to make sure I understand your issue
> 
>   1 - you were on branch X, thinking your were on branch Y
>   2 - edit, diff, commit, realised the mistake
>   3 - git reset HEAD^
> 
> so if you now run `git status` and `git diff` it will show your
> changes as if they were uncommitted and unstaged.

> (Before you start with various attempts to recover below, a great
> trick is to make an instant-backup in case things go wrong: cd .. / ;
> cp -pr moodle.git moodle-backup.git ; cd moodle.git )
> 
> You can now try do do
> 
>   4 - git checkout Y
> 
> and if the changes are on files that don't change between X and Y,
> then git will change the branches and keep your changes there. If the
> files are different between X and Y, it won't work.

> What I can recommend is to save your patch, as follows
> 
>   5 - git diff > tempchanges.patch
>   6 - git reset --hard # this will discard your changes, careful
>   7 - git checkout Y
>   8 - patch -p1 < tempchanges.patch
> 
> The patch may not apply cleanly :-) -- note that patch is more
> tolerant of iffy merges than git's internal implementation ("git
> apply") -- so it will succeed more often... but the results need
> review.