* Commited to wrong branch @ 2009-09-15 10:31 Howard Miller 2009-09-15 10:55 ` Martin Langhoff 0 siblings, 1 reply; 20+ messages in thread From: Howard Miller @ 2009-09-15 10:31 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 10:31 Commited to wrong branch Howard Miller @ 2009-09-15 10:55 ` Martin Langhoff 2009-09-15 11:05 ` Howard Miller 2009-09-15 11:19 ` Björn Steinbrink 0 siblings, 2 replies; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 10:55 UTC (permalink / raw) To: Howard Miller; +Cc: git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 10:55 ` Martin Langhoff @ 2009-09-15 11:05 ` Howard Miller 2009-09-15 11:16 ` Martin Langhoff 2009-09-15 11:19 ` Björn Steinbrink 1 sibling, 1 reply; 20+ messages in thread From: Howard Miller @ 2009-09-15 11:05 UTC (permalink / raw) To: Martin Langhoff; +Cc: git 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 11:05 ` Howard Miller @ 2009-09-15 11:16 ` Martin Langhoff 2009-09-15 12:10 ` Howard Miller 0 siblings, 1 reply; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 11:16 UTC (permalink / raw) To: Howard Miller; +Cc: git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 11:16 ` Martin Langhoff @ 2009-09-15 12:10 ` Howard Miller 2009-09-15 12:46 ` Martin Langhoff 0 siblings, 1 reply; 20+ messages in thread From: Howard Miller @ 2009-09-15 12:10 UTC (permalink / raw) To: Martin Langhoff; +Cc: git 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 12:10 ` Howard Miller @ 2009-09-15 12:46 ` Martin Langhoff 2009-09-15 12:58 ` Howard Miller 0 siblings, 1 reply; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 12:46 UTC (permalink / raw) To: Howard Miller; +Cc: git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 12:46 ` Martin Langhoff @ 2009-09-15 12:58 ` Howard Miller 2009-09-15 13:06 ` Björn Steinbrink 2009-09-15 13:27 ` Howard Miller 0 siblings, 2 replies; 20+ messages in thread From: Howard Miller @ 2009-09-15 12:58 UTC (permalink / raw) To: Martin Langhoff; +Cc: git 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 12:58 ` Howard Miller @ 2009-09-15 13:06 ` Björn Steinbrink 2009-09-15 13:12 ` Howard Miller 2009-09-15 13:54 ` Martin Langhoff 2009-09-15 13:27 ` Howard Miller 1 sibling, 2 replies; 20+ messages in thread From: Björn Steinbrink @ 2009-09-15 13:06 UTC (permalink / raw) To: Howard Miller; +Cc: Martin Langhoff, git [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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:06 ` Björn Steinbrink @ 2009-09-15 13:12 ` Howard Miller 2009-09-15 13:54 ` Martin Langhoff 1 sibling, 0 replies; 20+ messages in thread From: Howard Miller @ 2009-09-15 13:12 UTC (permalink / raw) To: Björn Steinbrink; +Cc: Martin Langhoff, git 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:06 ` Björn Steinbrink 2009-09-15 13:12 ` Howard Miller @ 2009-09-15 13:54 ` Martin Langhoff 2009-09-15 14:11 ` Howard Miller 2009-09-15 20:39 ` Björn Steinbrink 1 sibling, 2 replies; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 13:54 UTC (permalink / raw) To: Björn Steinbrink; +Cc: Howard Miller, git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:54 ` Martin Langhoff @ 2009-09-15 14:11 ` Howard Miller 2009-09-15 20:39 ` Björn Steinbrink 1 sibling, 0 replies; 20+ messages in thread From: Howard Miller @ 2009-09-15 14:11 UTC (permalink / raw) To: Martin Langhoff; +Cc: Björn Steinbrink, git 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<) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:54 ` Martin Langhoff 2009-09-15 14:11 ` Howard Miller @ 2009-09-15 20:39 ` Björn Steinbrink 2009-09-15 20:52 ` Howard Miller 2009-09-15 21:53 ` Martin Langhoff 1 sibling, 2 replies; 20+ messages in thread From: Björn Steinbrink @ 2009-09-15 20:39 UTC (permalink / raw) To: Martin Langhoff; +Cc: Howard Miller, git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 20:39 ` Björn Steinbrink @ 2009-09-15 20:52 ` Howard Miller 2009-09-15 21:53 ` Martin Langhoff 1 sibling, 0 replies; 20+ messages in thread From: Howard Miller @ 2009-09-15 20:52 UTC (permalink / raw) To: Björn Steinbrink; +Cc: Martin Langhoff, git 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 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 20:39 ` Björn Steinbrink 2009-09-15 20:52 ` Howard Miller @ 2009-09-15 21:53 ` Martin Langhoff 2009-09-15 22:30 ` Björn Steinbrink 1 sibling, 1 reply; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 21:53 UTC (permalink / raw) To: Björn Steinbrink; +Cc: Howard Miller, git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 21:53 ` Martin Langhoff @ 2009-09-15 22:30 ` Björn Steinbrink 0 siblings, 0 replies; 20+ messages in thread From: Björn Steinbrink @ 2009-09-15 22:30 UTC (permalink / raw) To: Martin Langhoff; +Cc: Howard Miller, git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 12:58 ` Howard Miller 2009-09-15 13:06 ` Björn Steinbrink @ 2009-09-15 13:27 ` Howard Miller 2009-09-15 13:45 ` Howard Miller 2009-09-15 13:46 ` Martin Langhoff 1 sibling, 2 replies; 20+ messages in thread From: Howard Miller @ 2009-09-15 13:27 UTC (permalink / raw) To: Martin Langhoff; +Cc: git 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 >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:27 ` Howard Miller @ 2009-09-15 13:45 ` Howard Miller 2009-09-15 14:08 ` Johannes Sixt 2009-09-15 13:46 ` Martin Langhoff 1 sibling, 1 reply; 20+ messages in thread From: Howard Miller @ 2009-09-15 13:45 UTC (permalink / raw) To: Martin Langhoff; +Cc: git 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 >>> >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:45 ` Howard Miller @ 2009-09-15 14:08 ` Johannes Sixt 0 siblings, 0 replies; 20+ messages in thread From: Johannes Sixt @ 2009-09-15 14:08 UTC (permalink / raw) To: Howard Miller; +Cc: Martin Langhoff, git 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 13:27 ` Howard Miller 2009-09-15 13:45 ` Howard Miller @ 2009-09-15 13:46 ` Martin Langhoff 1 sibling, 0 replies; 20+ messages in thread From: Martin Langhoff @ 2009-09-15 13:46 UTC (permalink / raw) To: Howard Miller; +Cc: git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Commited to wrong branch 2009-09-15 10:55 ` Martin Langhoff 2009-09-15 11:05 ` Howard Miller @ 2009-09-15 11:19 ` Björn Steinbrink 1 sibling, 0 replies; 20+ messages in thread From: Björn Steinbrink @ 2009-09-15 11:19 UTC (permalink / raw) To: Martin Langhoff; +Cc: Howard Miller, git 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2009-09-15 22:30 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-15 10:31 Commited to wrong branch Howard Miller 2009-09-15 10:55 ` Martin Langhoff 2009-09-15 11:05 ` Howard Miller 2009-09-15 11:16 ` Martin Langhoff 2009-09-15 12:10 ` Howard Miller 2009-09-15 12:46 ` Martin Langhoff 2009-09-15 12:58 ` Howard Miller 2009-09-15 13:06 ` Björn Steinbrink 2009-09-15 13:12 ` Howard Miller 2009-09-15 13:54 ` Martin Langhoff 2009-09-15 14:11 ` Howard Miller 2009-09-15 20:39 ` Björn Steinbrink 2009-09-15 20:52 ` Howard Miller 2009-09-15 21:53 ` Martin Langhoff 2009-09-15 22:30 ` Björn Steinbrink 2009-09-15 13:27 ` Howard Miller 2009-09-15 13:45 ` Howard Miller 2009-09-15 14:08 ` Johannes Sixt 2009-09-15 13:46 ` Martin Langhoff 2009-09-15 11:19 ` Björn Steinbrink
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.