{"thread":{"id":"24202","subject":"git-rebase --abort eats files","startedAt":"2010-06-26T12:53:11Z","lastAt":"2013-08-31T15:26:06Z","messageCount":6,"participants":["Madhu","Johannes Sixt","Ramkumar Ramachandra","Pete Harlan"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"144300","messageId":"20100626125924.160F11F212@leonis4.robolove.meer.net","threadId":"24202","inReplyTo":null,"subject":"git-rebase --abort eats files","fromName":"Madhu","fromEmail":"enometh@meer.net","sentAt":"2010-06-26T12:53:11Z","receivedAt":"2010-06-26T12:53:11Z","isPatch":false,"sender":{"key":"enometh@meer.net","avatar":null},"body":"Don't know if this has been resolved-by-debate here before, But adding\na file via git-add in the middle of an interactive rebase and aborting\nthe rebase deletes the hitherto untracked file.  It should not. \n\nrm -rfv /tmp/t1 ; mkdir -pv /tmp/t1\ncd /tmp/t1 && git-init-db\ncd /tmp/t1 && touch file1 file2 file3\ncd /tmp/t1 && git-add file1\ncd /tmp/t1 && git-commit -m \"Explet1\" file1\ncd /tmp/t1 && git-add file2\ncd /tmp/t1 && git-commit -m \"Explet2\" file2\ncd /tmp/t1 && git-rebase --abort\ncd /tmp/t1 && EDITOR=\"sed -i -e 's/^pick/edit/'\" git rebase -i 'HEAD^'\ncd /tmp/t1 && git-add file3\ncd /tmp/t1 && git-status\ncd /tmp/t1 && git-rebase --abort\ntest -e /tmp/t1/file3 || echo bwaaah\n\nMaybe something like this to fix it?\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 436b7f5..2702536 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -749,6 +749,7 @@ first and then run 'git rebase --continue' again.\"\n                        git symbolic-ref HEAD $HEADNAME\n                        ;;\n                esac &&\n+               git-reset &&\n                output git reset --hard $HEAD &&\n                rm -rf \"$DOTEST\"\n                exit\n\n--\nMadhu\n"},{"id":"144325","messageId":"201006262009.30380.j6t@kdbg.org","threadId":"24202","inReplyTo":"20100626125924.160F11F212@leonis4.robolove.meer.net","subject":"Re: git-rebase --abort eats files","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-06-26T18:09:30Z","receivedAt":"2010-06-26T18:09:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Samstag, 26. Juni 2010, Madhu wrote:\n> Don't know if this has been resolved-by-debate here before, But adding\n> a file via git-add in the middle of an interactive rebase and aborting\n> the rebase deletes the hitherto untracked file.  It should not.\n>\n> Maybe something like this to fix it?\n>\n> +++ b/git-rebase--interactive.sh\n> @@ -749,6 +749,7 @@ first and then run 'git rebase --continue' again.\"\n>                         git symbolic-ref HEAD $HEADNAME\n>                         ;;\n>                 esac &&\n> +               git-reset &&\n>                 output git reset --hard $HEAD &&\n>                 rm -rf \"$DOTEST\"\n>                 exit\n\nNo, it can't be that simple. If rebase stopped due to a conflict on a commit \nthat added new files, then your version of rebase --abort will leave these \nnew files behind as untracked.\n\n-- Hannes\n"},{"id":"144379","messageId":"20100628090517.GA8091@debian","threadId":"24202","inReplyTo":"201006262009.30380.j6t@kdbg.org","subject":"Re: git-rebase --abort eats files","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-06-28T09:05:17Z","receivedAt":"2010-06-28T09:05:17Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Madhu,\n\nJohannes Sixt wrote:\n> On Samstag, 26. Juni 2010, Madhu wrote:\n> > +++ b/git-rebase--interactive.sh\n> > @@ -749,6 +749,7 @@ first and then run 'git rebase --continue' again.\"\n> >                         git symbolic-ref HEAD $HEADNAME\n> >                         ;;\n> >                 esac &&\n> > +               git-reset &&\n> >                 output git reset --hard $HEAD &&\n> >                 rm -rf \"$DOTEST\"\n> >                 exit\n> \n> No, it can't be that simple. If rebase stopped due to a conflict on a commit \n> that added new files, then your version of rebase --abort will leave these \n> new files behind as untracked.\n\nRight. The interactive rebase has to be able to differentiate between\nfiles that you added to resolve a conflict and files that you added to\nretain at the end of the rebase -- and the interactive rebase has no\ninformation about this. Hence, this problem can't be fixed without\nexplicitly finding out the intent of the user. In my opinion, you\nshould simply stash your changes before aborting the rebase instead of\nadding files and figuring out some complex way of expressing intent.\n\n-- Ram\n"},{"id":"144437","messageId":"20100629012412.7FDBD1F212@leonis4.robolove.meer.net","threadId":"24202","inReplyTo":"20100628090517.GA8091@debian","subject":"Re: git-rebase --abort eats files","fromName":"Madhu","fromEmail":"enometh@meer.net","sentAt":"2010-06-29T01:23:53Z","receivedAt":"2010-06-29T01:23:53Z","isPatch":false,"sender":{"key":"enometh@meer.net","avatar":null},"body":"  |Date: Mon, 28 Jun 2010 11:05:17 +0200\n  |From: Ramkumar Ramachandra <artagnon@gmail.com>\n  |Cc: Madhu <enometh@meer.net>, git@vger.kernel.org\n  |Content-Type: text/plain; charset=us-ascii\n  |Content-Disposition: inline\n  |\n  |> No, it can't be that simple. If rebase stopped due to a conflict\n  |> on a commit that added new files, then your version of rebase\n  |> --abort will leave these new files behind as untracked.\n  |\n  |Right. The interactive rebase has to be able to differentiate\n  |between files that you added to resolve a conflict and files that\n  |you added to retain at the end of the rebase -- and the interactive\n  |rebase has no information about this. Hence, this problem can't be\n  |fixed without explicitly finding out the intent of the user.\n\nWrong.  Rebase has to be able to differentaiate between two cases\n\n1. when there is a conflict, and the user is prompted to fix it, and\n then continue with a git-add, git-commit, and git-rebase --continue\n\nand \n\n2. when the user is given a commit, which he is asked to git-commit\n  --amend, and then git-rebase --continue\n\nRebase is already aware of when each situation occurs.\n\n  |In my opinion, you should simply stash your changes before aborting\n  |the rebase instead of adding files and figuring out some complex\n  |way of expressing intent.\n\nThis does not make sense.\n\n--\nMadhu\n"},{"id":"144444","messageId":"4C2996FE.3010206@pcharlan.com","threadId":"24202","inReplyTo":"20100629012412.7FDBD1F212@leonis4.robolove.meer.net","subject":"Re: git-rebase --abort eats files","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2010-06-29T06:47:26Z","receivedAt":"2010-06-29T06:47:26Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"On 06/28/2010 06:23 PM, Madhu wrote:\n>   |Date: Mon, 28 Jun 2010 11:05:17 +0200\n>   |From: Ramkumar Ramachandra <artagnon@gmail.com>\n>   |Cc: Madhu <enometh@meer.net>, git@vger.kernel.org\n>   |\n>   |> No, it can't be that simple. If rebase stopped due to a conflict\n>   |> on a commit that added new files, then your version of rebase\n>   |> --abort will leave these new files behind as untracked.\n>   |\n>   |Right. The interactive rebase has to be able to differentiate\n>   |between files that you added to resolve a conflict and files that\n>   |you added to retain at the end of the rebase -- and the interactive\n>   |rebase has no information about this. Hence, this problem can't be\n>   |fixed without explicitly finding out the intent of the user.\n> \n> Wrong.  Rebase has to be able to differentaiate between two cases\n> \n> 1. when there is a conflict, and the user is prompted to fix it, and\n>  then continue with a git-add, git-commit, and git-rebase --continue\n> \n> and \n> \n> 2. when the user is given a commit, which he is asked to git-commit\n>   --amend, and then git-rebase --continue\n> \n> Rebase is already aware of when each situation occurs.\n\nIf I read your original question correctly, the problem is: if you\nhave an untracked file in your directory before you start a rebase,\nand then you add that file during the rebase, and then abort the\nrebase, Git will delete your file from the working directory instead\nof just returning it to its untracked state.\n\nSo aborting a rebase doesn't simply roll back time: it can be\ndestructive in a way the user may not expect.\n\nThe followups to the original question seem to me to be clouding the\nissue with the question of what to do with any new material added\nduring a rebase, not just files that were originally present but\nuntracked.\n\nMaybe it's not easy to solve the original problem, or maybe it's not\nworth doing; maybe it's worth documenting.  (And documenting how to\nrecover the files, since they're in the object database for a while.)\nI'd guess that to solve it rebase would have to do a \"git status\" when\nit started, to see which files it should leave behind in the working\ndirectory.  I'm not a Git hacker so that's just speculation.\n\nBut I think it's worth discussing this behavior on its own, separately\nfrom the question about other material added during a rebase.\n\n[As to what to do with other material added during a rebase, I'd like\nit nuked.  When I abort a rebase it's because I've gummed things up\nand want to start over.]\n\n--Pete\n\n> \n>   |In my opinion, you should simply stash your changes before aborting\n>   |the rebase instead of adding files and figuring out some complex\n>   |way of expressing intent.\n> \n> This does not make sense.\n> \n> --\n> Madhu\n"},{"id":"226419","messageId":"20130831.205606.373615550.enometh@meer.net","threadId":"24202","inReplyTo":"20100626125924.160F11F212@leonis4.robolove.meer.net","subject":"git-rebase --continue eats commits","fromName":"Madhu","fromEmail":"enometh@meer.net","sentAt":"2013-08-31T15:26:06Z","receivedAt":"2013-08-31T15:26:06Z","isPatch":false,"sender":{"key":"enometh@meer.net","avatar":null},"body":"\nDon't know if this has been resolved-by-debate here before, But if\n`git-rebase' finds a hitherto untracked file in the worktree, which it\nwants to create, it then aborts asking you to remove the file.  So if\nyou remove it and ask git to continue with `git-rebase --continue', it\nthen deletes the commit that was being applied from the branch. ---Madhu\n\n\n(setenv \"TDIR\" \"/dev/shm/foo/\")\n\nmkdir -pv $TDIR && cd $TDIR && git-init\n(cd $TDIR && echo a > a && git add a && git commit -m \"a\")\n(cd $TDIR && echo b > b && git add b && git commit -m \"b\")\n(cd $TDIR && echo c > c && git add c && git commit -m \"c\")\n(cd $TDIR && EDITOR=\"sed -i -e 's/^pick/edit/'\" git rebase -i 'HEAD^^')\n(cd $TDIR && echo fubar > c)\n(cd $TDIR && git-rebase --continue)\n\n    Rebasing (2/2)\nerror: The following untracked working tree files would be overwritten by merge:\n\tc\n    Please move or remove them before you can merge.\n    Aborting\n    Could not apply ddd6f51...\n\n(cd $TDIR && rm -fv c)\n(cd $TDIR && git-rebase --continue)\n\n    Rebasing (2/2)\nSuccessfully rebased and updated refs/heads/master.\n\n(cd $TDIR && git log)\n\n;; commit `c' is gone\n"}]}