Commited to wrong branch

Commited to wrong branch

[Howard Miller]

Hi,

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.

I was advised to do a 'git reflog --branchname--' (I don't
know/understand what this command does) but it doesn't work. I just
get 'usage: git reflog (expire | ...)'

So basically I am no further forward. Just to reiterate I need to...

* remove the commit from my current branch (it tracks a remote so I
would prefer there to be no evidence to confuse other people after I
push)
* add the changes to the (other) branch they should have been added to.
* not loose or break anything.

Any (more) help appreciated.

Re: Commited to wrong branch

[Martin Langhoff]

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

Re: Commited to wrong branch

[Howard Miller]

Hi Martin,

I'm pretty shocked how difficult this is... still...

I'm finding git logs and reflogs pretty difficult to read and
interpret (head melting) - in particular telling what happened on what
branch - but looking at the reflog (which I assume is showing me the
actions on the current branch, but I'm not sure) 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.

I cannot currently change branches - it only complains about one file.
I'm a bit worried about that - I would like to understand why this is
a problem but I don't.

So I am now a little hazy on how to deal with previous TWO commits.

Sorry for misery.... I've lost the plot a bit here :-)

Howard



2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> 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
>

Re: Commited to wrong branch

[Martin Langhoff]

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

Re: Commited to wrong branch

[Björn Steinbrink]

On 2009.09.15 12:55:58 +0200, Martin Langhoff wrote:
> 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.

Not "as if", they are.

> (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.

Well, then you could use "git checkout -m Y", to have git try a
three-way merge (which might of course leave conflicts).

> 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.

But a lot worse than the usual 3-way merge stuff, like "checkout -m" or
"stash apply". The advantage of "stash" + "stash apply" is that, in case
of conflicts, you can easily retry to fix them over and over again,
while with "checkout -m", you can't easily start over AFAIK.

> There is a more git-style approach that is to use git-stash -- it uses
> git-apply and may not do what you want.

Only "stash apply --index" uses "git apply", and only to re-apply the
staged changes. The changes for the working tree are applied using a
3way merge.

Björn

Re: Commited to wrong branch

[Howard Miller]

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.

Howard

2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> 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
>

Re: Commited to wrong branch

[Martin Langhoff]

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

Re: Commited to wrong branch

[Howard Miller]

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
>

Re: Commited to wrong branch

[Björn Steinbrink]

[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

Re: Commited to wrong branch

[Howard Miller]

Please stop what?

Ok... thanks for all your help guys but I'm giving up. A silly mistake
has wasted a day. It shouldn't be like that. I appreciate that it's me
that doesn't know enough about the way git works but I don't want to
know. I don't have time - I have actual work to do. It'll be quicker
to recreate the code I have lost.

Git encourages one to be experimental and create branches and stuff
all the time which is great but doesn't do enough to stop one getting
completely confused. That's how it feels to me anyway. Yes I am in a
sulk - sorry :-)

Howard

2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> [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
>

Re: Commited to wrong branch

[Howard Miller]

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
>>
>

Re: Commited to wrong branch

[Howard Miller]

Martin et al.

Thanks for your help and sorry for ranting (also to Daniele Segato who
replied off-list).... these things always happen when you have the
least amount of time to deal with them!!

Problem solved.... well bodged actually (just copied files which were
all in one directory over to the correct branch).... but it will do. I
shall be MUCH more careful in future :-)

Howard

(PS. I now even know what 'top-posting' is - but not why it's bad.)

2009/9/15 Howard Miller <howard@e-learndesign.co.uk>:
> 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
>>>
>>
>

Re: Commited to wrong branch

[Martin Langhoff]

On Tue, Sep 15, 2009 at 3:27 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> 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?)

Absolutely perfect plan. In fact, there's a way to "sync" your local
branch to the remote one:

 git checkout X
 git reset  origin/X

(assuming that the remote branch is 'origin/X')

> * 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?)

correct (git reset --hard OTOH will discard your changes)

> * 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

Oh... well if there were other changes to the same files in the other
branch you could be carrying "other" changes. git diff to make sure
you're committing what you want.

> Seems too easy :-)

It is :-)


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

Re: Commited to wrong branch

[Martin Langhoff]

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

Re: Commited to wrong branch

[Johannes Sixt]

Howard Miller schrieb:
> (PS. I now even know what 'top-posting' is - but not why it's bad.)

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Commited to wrong branch

[Howard Miller]

2009/9/15 Martin Langhoff <martin.langhoff@gmail.com>:
> 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
>

...and I still don't understand cvs either  :-)

(NB. I have put my reply at the bottom where nobody will see it - this
is why forums are better than mailing lists.... >ducks<)

Re: Commited to wrong branch

[Björn Steinbrink]

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

Re: Commited to wrong branch

[Howard Miller]

I don't imagine having a problem with conflict markers although I've
never had any in a git related project (yet!). I'm in the happy
position of working by myself at the moment which, in the end, is how
I got out of my problem because I knew where all the changes where.
Interestingly, the whole .rej file thing IS new to me. I've been using
patch files for years and have never had that happen before. Hmmm...

Never used emacs either - I'm a Vim-kid :-)

Martin's point about simply copying the repo so you have a backup is
at the same time dead simple and brilliant. It's almost an undo. I
have an idea that I could now fumble my way through a problem like
this. The bother is that git has too many commands and too little
(idiot proof) help which is a shame. Not everybody is a power user -
but we are just the sort of people who mess up. I'm trying to put a
positive spin on things - we need a git tips wiki or something.
Version control to me is a dull necessity - I don't want to have to
think about it!

Howard

2009/9/15 Björn Steinbrink <B.Steinbrink@gmx.de>:
> 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
>

Re: Commited to wrong branch

[Martin Langhoff]

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.

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

Re: Commited to wrong branch

[Björn Steinbrink]

On 2009.09.15 23:53:03 +0200, Martin Langhoff wrote:
> 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.

That's not git getting confused trying to use the ancestry, but git
being unable to make use of the history. It has to use a fake common
ancestor, as using the true common ancestor would obviously mean that
you do a real merge, not a cherry-pick. Under some circumstances that
can lead to quite "interesting" conflicts, yeah, but IMHO still better
to deal with than those .rej files, especially when you switch to diff3
conflict marker mode (git checkout --conflict=diff3 -- file), which also
contains the version of the code that the "common ancestor" has.

> > 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.

No, you didn't understand what I said. I said that _you_ shouldn't be
using git-apply. That "git am" internally uses "git apply" is a totally
different story. And with --3way, it doesn't even run just "git apply <
patch", but uses "git apply" just to build a fake common ancestor and
does a 3-way merge with git-merge-recursive.

Björn