{"thread":{"id":"28652","subject":"[RFC] teach --edit to git rebase","startedAt":"2011-10-11T21:21:53Z","lastAt":"2011-10-12T13:57:11Z","messageCount":4,"participants":["Jean Privat","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"177399","messageId":"CAMQw0oOBEjW3yS2+wcktXDuEuUiHKjfbK2qDzKvBOiwxo7Zkow@mail.gmail.com","threadId":"28652","inReplyTo":null,"subject":"[RFC] teach --edit to git rebase","fromName":"Jean Privat","fromEmail":"jean.privat@gmail.com","sentAt":"2011-10-11T21:21:53Z","receivedAt":"2011-10-11T21:21:53Z","isPatch":false,"sender":{"key":"jean.privat@gmail.com","avatar":"https://gravatar.com/avatar/96a32df5131ffa7083a5d5338990fa18d9ecc0f2da1598abf8235213e3d00661?d=mp&s=160"},"body":"The idea of this patch is to allow a simple edition of a buggy commit\nin the history.\n\n## Motivation\n\nThe motivation behind the option is that sometime I have to do a\nsimple fixup of a previous commit.\nUsually the way to do it is just to commit the fix on the top of the\nbranch (git commit --fixup) then doing a 'git rebase  --autosquash'.\nHowever, the way is often not optimal if the context of commit on the\ntop of the branch is different from the context of the buggy commit,\nthus the rebase with a fixup will lead to a conflict when git will\napply the fixup patch to the buggy commit (and a second conflict\nlater).\n\nAn other way is to do a 'git rebase --interactive' with an edit in the\ntodo list (instead of a pick). This is what I propose to simplify.\n\n## Proposal\n\nMy idea is to add a --edit option to 'git rebase' in order to\nautomatize the 'git rebase --interactive' workflow.\n\nCurrently:\n\n    $ git rebase -i commit-to-fix^\n    # replace the first 'pick' with 'edit' then save and quit\n    $ hack hack hack...\n    $ git commit --amend  # or whatever you want to do like split commit\n    $ git rebase --continue  # and resolve possible conflicts\n\nWith the --edit option:\n\n    $ git rebase --edit commit_to_fix # note: no caret, no editor ! yeah !\n    $ hack hack hack...\n    $ git commit --amend  # or what ever like split commit\n    $ git rebase --continue  # and resolve possible conflicts\n\nNote that for a more complex history modification, a standard git\nrebase with reordering, squashing and stuff the way to go is a good\nold git rebase --interactive.\n\n## Implementation proposal\n\nYes I know \"show me the code\" but because I am lazy I prefer ask 1-if\nthe proposal makes sense, and 2-if the following way of doing it makes\nsense.\n\nThe idea is to extend git-rebase and git-rebase-interactive.\n\n* detect and check the option --edit in git-rebase\n* automatically prepare the todolist in git-rebase-interactive without\nlaunching the editor.\n\n## Alternative proposals\n\nA weak point of the proposal it that it is a new option to a\noverloaded git command (git rebase). In fact is is even a new synopsis\nto git rebase since the --edit option will be incompatible with\n--interactive (it is an automatic interactive) and with --onto (since\nthere is no real point to ``move'' the base if you want to fixup a\nsingle commit).\nA counter proposal could be to not extend the command 'git rebase' but\nadd a new git command (for instance 'git edit buggy_commit') but since\nthe edit may[1] lead to conflicts the user has to do some 'git edit\n--continue' to finish the editing (or 'git edit --abort' if bored). It\nwill also require to adapt a lot of tinny things because hint\nmessages, error messages, and prompts will talk about 'rebase' and not\n'edit'.\n\n[1] In fact, it is probable that the *may* is in fact a *will* since\nif no conflict arise, it is likable that a simple 'commit --fixup'\n(followed by a later 'git rebase --autosquash') will just work and be\nsimpler.\n\nAn other alternative is to use a simple git alias for myself (and do\nnot bother the git community) but I do not know how to automatize the\ncommand 'git rebase --interactive' I suppose I need more complex\ninfrastructure in the existing 'git rebase' (Maybe I did not look\nenough and there is a way to do it with a git alias).\n\nA last alternative is do do nothing. What I propose is just a way to\n1-do not need a caret ('git rebase --edit commit' instead of 'git\nrebase --interactive commit^') and 2-avoid launching the editor.\nTherefore, maybe the itch do not really need a patch.\n\n-- Jean Privat\n"},{"id":"177405","messageId":"CAMQw0oO+eGxOX=347G0vZPe1uf-SyGGnT1Ku7cykgv4PQK1ZVQ@mail.gmail.com","threadId":"28652","inReplyTo":"CAMQw0oOBEjW3yS2+wcktXDuEuUiHKjfbK2qDzKvBOiwxo7Zkow@mail.gmail.com","subject":"Re: [RFC] teach --edit to git rebase","fromName":"Jean Privat","fromEmail":"jean.privat@gmail.com","sentAt":"2011-10-11T22:36:45Z","receivedAt":"2011-10-11T22:36:45Z","isPatch":false,"sender":{"key":"jean.privat@gmail.com","avatar":"https://gravatar.com/avatar/96a32df5131ffa7083a5d5338990fa18d9ecc0f2da1598abf8235213e3d00661?d=mp&s=160"},"body":"> An other alternative is to use a simple git alias for myself (and do\n> not bother the git community) but I do not know how to automatize the\n> command 'git rebase --interactive' I suppose I need more complex\n> infrastructure in the existing 'git rebase' (Maybe I did not look\n> enough and there is a way to do it with a git alias).\n\nHum. I just found that I can do something like :\n\n[alias]\n        edit=!GIT_EDITOR='sed -i -e 1s/pick/edit/ --' git rebase -i\n-no-autosquash $1^\n\nThe main thing that bothers me is that after the rebase, the head is\ndetached (why?)\n\nThe other thing is that the error messages for invalid usages are far\nfor perfect\n\n$ git edit toto\nfatal: Needed a single revision\ninvalid upstream toto^\n\n$ git edit --root toto\nerror: unknown option `root^'\nusage: git rebase [-i] [options] [--onto <newbase>] [<upstream>] [<branch>]\n[...]\n\n-Jean\n"},{"id":"177424","messageId":"7vvcrubyz1.fsf@alter.siamese.dyndns.org","threadId":"28652","inReplyTo":"CAMQw0oOBEjW3yS2+wcktXDuEuUiHKjfbK2qDzKvBOiwxo7Zkow@mail.gmail.com","subject":"Re: [RFC] teach --edit to git rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-12T04:44:34Z","receivedAt":"2011-10-12T04:44:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean Privat <jean.privat@gmail.com> writes:\n\n> Yes I know \"show me the code\" but because I am lazy I prefer ask 1-if\n> the proposal makes sense, and 2-if the following way of doing it makes\n> sense.\n\nNo, no, and no we do not necessarily hate talking to lazy people but only\nas long as what they propose makes some sense.\n\nThe only thing you can do with this new option is \"update one commit\nburied in the history, and rebase everything that build on top of it\", as\nfar as I can tell. It feels a shame to waste the generic word \"--edit\" for\nsuch a narrow option.\n\nAt the UI level, \"git commit --amend HEAD~4\" might be a more natural way\nto invoke such an operation, I would think.\n"},{"id":"177438","messageId":"CAMQw0oOKsVv82c5yaHR0LQu+B-OaBAE8OBXQH-ksiQc2KEBnjA@mail.gmail.com","threadId":"28652","inReplyTo":"7vvcrubyz1.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] teach --edit to git rebase","fromName":"Jean Privat","fromEmail":"jean.privat@gmail.com","sentAt":"2011-10-12T13:57:11Z","receivedAt":"2011-10-12T13:57:11Z","isPatch":false,"sender":{"key":"jean.privat@gmail.com","avatar":"https://gravatar.com/avatar/96a32df5131ffa7083a5d5338990fa18d9ecc0f2da1598abf8235213e3d00661?d=mp&s=160"},"body":"> The only thing you can do with this new option is \"update one commit\n> buried in the history, and rebase everything that build on top of it\",\n\nIt is a good summary indeed.\n\n> as\n> far as I can tell. It feels a shame to waste the generic word \"--edit\" for\n> such a narrow option.\n\nI'm bad at bikesheeding. The 'edit' come from the 'edit' command in\nrebase interactive. I am open to other names. Note that in the\nfollowing I keep the --edit name, not because I am suborn but because\nI do not have better to propose yet.\n\n> At the UI level, \"git commit --amend HEAD~4\" might be a more natural way\n> to invoke such an operation, I would think.\n\nAs I say in the original email the point of the 'rebase --edit\nsome-commit' is to temporally checkout some-commit so that edits are\ndone in the context of the commit and not in the context of the head\nof the branch.\nOne has to do a rebase --edit prior to modification (although we can\nimagine a possibility to bring back the index or the content of the\nworking directory with us either automatically as with a branch\ncheckout or manually with the help of stash).\n\nUnless I misinterpret the 'git commit --amend HEAD~4' you suggest, it\nmeans that you have to prepare the commit in the head of the branch.\nIt may be difficult if what was in HEAD~4 is altered by HEAD~2.\nMy argument is that if preparing a patch to HEAD~4 in HEAD is easy, a\ngit commit --fixup will do the tick.\nIf the preparation is difficult because I have to work on (or more\ninsidious, near) change that occurs between HEAD~4 and HEAD, I need\nsomething like my proposal. For example I added a line in HEAD~2 but I\nprefer now to have this line to appears in HEAD~4.\n\nThe workflow I propose is :\n\n$ # we are on master\n$ git rebase --edit HEAD~4 # workdir is a detached master~4 like with a\n                           # git checkout master~4\n$ hack hack hack; git add files\n$ git commit --amend\n$ git rebase --continue # conflict is detected with master~2, resolve it\n                        # manually\n$ git rebase --continue # workdir is now a rebased master\n\nI do no see what is the workflow with an extend git commit --amend\nDo you mean something like the following ?\n\n$ git checkout HEAD~4 -- . # bring back the content of master~4 but\n                           # HEAD still points master\n$ hack hack hack; git add files # And try to now be disturbed by the fact\n                                # that diff and status are polluted\n                                # with things related to master\n$ git commit --amend HEAD~4 # conflict is detected with master~2, resolve it\n$ git rebase --continue # Do we really want using \"git rebase\"?\n\nThis last workflow seems so awkward to me that I might miss something.\n\n-- Jean Privat\n"}]}