{"thread":{"id":"28093","subject":"[feature wishlist] add commit subcommand to git add -i","startedAt":"2011-08-14T08:38:36Z","lastAt":"2011-08-15T12:54:29Z","messageCount":6,"participants":["Jim Cromie","Conrad Irwin","Ramkumar Ramachandra","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"173482","messageId":"CAJfuBxwW8Dyp8FTS13uPOBKZGL9JOEqaSOhGN+zBJ_8BHpJE3g@mail.gmail.com","threadId":"28093","inReplyTo":null,"subject":"[feature wishlist] add commit subcommand to git add -i","fromName":"Jim Cromie","fromEmail":"jim.cromie@gmail.com","sentAt":"2011-08-14T08:38:36Z","receivedAt":"2011-08-14T08:38:36Z","isPatch":false,"sender":{"key":"jim.cromie@gmail.com","avatar":null},"body":"when using git add -i, it would be handy to have a [c]ommit option.\n\nThis would save some typing:\nq # to quit git add -i\n$> commit ....\ngit add -i # to resume incremental adds\n\n*** Commands ***\n 1: [s]tatus\t 2: [u]pdate\t 3: [r]evert\t 4: [a]dd untracked\n 5: [p]atch\t 6: [d]iff\t 7: [q]uit\t 8: [h]elp\n 9: [c]commit\nWhat now>\n\n[f]ragment would also be handy, which would break each chunk of a diff\ninto a separate commit, with the summary line provided automatically\n @@ -696,7 +692,7 @@ int foo ...\n\nThis would help a bit with random cleanups, since rebase -i could then\nbe used to\nreorder and recombine the fragments, and edit the commit messages afterwards.\n\n\ngoing further, if git rebase -i had ability to \"back\" a fixup patch\nback to where it should have been, and adjust the intervening patches\nwhere conflict would normally happen, that would be awesome.\nSimplistically, this would just shift the patch 1 step back iteratively,\nuntil it wouldnt apply properly, and then --abort, stopping at the last\nclean rebase.\n\napologies if this is too hair-brained, or already done.\n"},{"id":"173484","messageId":"CAOTq_pvMv6JN_jpQvDsmQTwmMgQK9JzuwXr+VF1T6X4=qf3GsQ@mail.gmail.com","threadId":"28093","inReplyTo":"CAJfuBxwW8Dyp8FTS13uPOBKZGL9JOEqaSOhGN+zBJ_8BHpJE3g@mail.gmail.com","subject":"Re: [feature wishlist] add commit subcommand to git add -i","fromName":"Conrad Irwin","fromEmail":"conrad.irwin@gmail.com","sentAt":"2011-08-14T08:48:49Z","receivedAt":"2011-08-14T08:48:49Z","isPatch":false,"sender":{"key":"conrad.irwin@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94272?v=4"},"body":"On Sun, Aug 14, 2011 at 1:38 AM, Jim Cromie wrote:\n> going further, if git rebase -i  had ability to  \"back\" a fixup patch\n> back to where it should have been, and adjust the intervening patches\n> where conflict would normally happen, that would be awesome.\n> Simplistically, this would just shift the patch 1 step back iteratively,\n> until it wouldnt apply properly, and then --abort, stopping at the last\n> clean rebase.\n>\n> apologies if this is too hair-brained, or already done.\n\nIt sounds like you're looking for several git commit\n(-p|--interactive) --fixup , followed by a git rebase -i\n--autosquash. It's not quite as automatic as you describe, but I think\nthat automating it would be pretty hard to do correctly.\n\nConrad\n"},{"id":"173485","messageId":"CALkWK0=9sT6wDwoa3vDF1bt1e8AiubwW42-o=c++MpzV47LhQg@mail.gmail.com","threadId":"28093","inReplyTo":"CAJfuBxwW8Dyp8FTS13uPOBKZGL9JOEqaSOhGN+zBJ_8BHpJE3g@mail.gmail.com","subject":"Re: [feature wishlist] add commit subcommand to git add -i","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-08-14T08:56:38Z","receivedAt":"2011-08-14T08:56:38Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Jim,\n\nJim Cromie writes:\n> when using git add -i, it would be handy to have a [c]ommit option.\n\nI can't personally comment on this because I use Magit for staging/\nunstaging and committing. It's quite an awesome application- do check\nit out if you use Emacs.\n\n> going further, if git rebase -i  had ability to  \"back\" a fixup patch\n> back to where it should have been, and adjust the intervening patches\n> where conflict would normally happen, that would be awesome.\n> Simplistically, this would just shift the patch 1 step back iteratively,\n> until it wouldnt apply properly, and then --abort, stopping at the last\n> clean rebase.\n\nHm, I'm not sure if I understand fully: is the idea about moving a\ncommit backwards iteratively so we have to resolve several simpler and\nsmaller conflicts? I have to admit that I work around this problem by\nrunning 'rebase -i' several times, moving the commit back in the\nsequence little-by-little.\n\n-- Ram\n"},{"id":"173523","messageId":"CAJfuBxzseEtSLSupmragyoVbZBS9Cmmd9cabLzpdT+9xiQRbQg@mail.gmail.com","threadId":"28093","inReplyTo":"CAOTq_pvMv6JN_jpQvDsmQTwmMgQK9JzuwXr+VF1T6X4=qf3GsQ@mail.gmail.com","subject":"Re: [feature wishlist] add commit subcommand to git add -i","fromName":"Jim Cromie","fromEmail":"jim.cromie@gmail.com","sentAt":"2011-08-15T00:43:27Z","receivedAt":"2011-08-15T00:43:27Z","isPatch":false,"sender":{"key":"jim.cromie@gmail.com","avatar":null},"body":"On Sun, Aug 14, 2011 at 2:48 AM, Conrad Irwin wrote:\n> On Sun, Aug 14, 2011 at 1:38 AM, Jim Cromie wrote:\n>> going further, if git rebase -i  had ability to  \"back\" a fixup patch\n>> back to where it should have been, and adjust the intervening patches\n>> where conflict would normally happen, that would be awesome.\n>> Simplistically, this would just shift the patch 1 step back iteratively,\n>> until it wouldnt apply properly, and then --abort, stopping at the last\n>> clean rebase.\n>>\n>> apologies if this is too hair-brained, or already done.\n>\n> It sounds like you're looking for several git commit\n> (-p|--interactive) --fixup , followed by a git rebase -i\n> --autosquash. It's not quite as automatic as you describe, but I think\n> that automating it would be pretty hard to do correctly.\n>\n> Conrad\n>\n\nit is indeed similar. in the simple case, I know which patch needs the fixup,\nand using editor to rearrange the todo-file is straightforward.\nusing --autosquash requires knowing the commit-log message to be fixed,\nand using it to name the fixup commit, which is doable, but I havent trained\nmyself to do so. I'll give it a try next time..\n\nthanks\nJim\n"},{"id":"173524","messageId":"CAJfuBxwiMZnghKQg9vzNVTKET9P6ryT_836mecP3a-q_EcFf7Q@mail.gmail.com","threadId":"28093","inReplyTo":"CALkWK0=9sT6wDwoa3vDF1bt1e8AiubwW42-o=c++MpzV47LhQg@mail.gmail.com","subject":"Re: [feature wishlist] add commit subcommand to git add -i","fromName":"Jim Cromie","fromEmail":"jim.cromie@gmail.com","sentAt":"2011-08-15T00:44:33Z","receivedAt":"2011-08-15T00:44:33Z","isPatch":false,"sender":{"key":"jim.cromie@gmail.com","avatar":null},"body":"On Sun, Aug 14, 2011 at 2:56 AM, Ramkumar Ramachandra\n wrote:\n> Hi Jim,\n>\n> Jim Cromie writes:\n>> when using git add -i, it would be handy to have a [c]ommit option.\n>\n> I can't personally comment on this because I use Magit for staging/\n> unstaging and committing.  It's quite an awesome application- do check\n> it out if you use Emacs.\n>\n\nI;ll take a look, thanks.\n\n>> going further, if git rebase -i  had ability to  \"back\" a fixup patch\n>> back to where it should have been, and adjust the intervening patches\n>> where conflict would normally happen, that would be awesome.\n>> Simplistically, this would just shift the patch 1 step back iteratively,\n>> until it wouldnt apply properly, and then --abort, stopping at the last\n>> clean rebase.\n>\n> Hm, I'm not sure if I understand fully: is the idea about moving a\n> commit backwards iteratively so we have to resolve several simpler and\n> smaller conflicts?\n\nyes - thats certainly part of it.\nI added iteratively as a simplification.\nI suspect there are more clever ways to do it.\n\nthe simplest case is to move a fixup patch backwards where no conflicts arise,\nput the fixup right after the patch where the errant code was added.\n\nthe harder one is to recognize and resolve the interim conflicts.\nTo avoid handwaving, I reconstructed my particular case,\nwhich is available on github:\nhttps://github.com/jimc/linux-2.6/tree/rebase-back-usecase\n\n1 - patches 1-11 on dynamic-debug, from Jason Baron, last Thurs.\n (these are the ones that gave git am heartburn, fixed in git-next)\n2 - Suggestion by Joe Perches to use C-99\n I cut pasted his suggestion, made a commit.\n d61db7e joes suggestion C-99\n3 - 53929c5 drop enabled, check flags&bitmask\n4 - 57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG\n5 - fixup, which needs to go back to just after 2.\n\nspecifically:\n[jimc@groucho linux-2.6]$ git log --oneline -5\n07d4a51 fixup C-99, move attribute before assignment\n57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG\n53929c5 drop enabled, check flags&bitmask\nd61db7e joes suggestion C-99\nf06abb5 dynamic_debug: use a single printk() to emit msgs\n\n>  I have to admit that I work around this problem by\n> running 'rebase -i' several times, moving the commit back in the\n> sequence little-by-little.\n\nwhen I did it manually,\nthere were a number of conficts to resolve.\npretty minor really, but tedious.\n\n<<<<<<< HEAD\n\t\t.enabled = false,\t\t\t\t \\\n\t} __used __aligned(8) __attribute__((section(\"__verbose\")))\n=======\n\t}\n>>>>>>> 07d4a51... fixup C-99, move attribute before assignment\n\nif I could say:\n\n[jimc@groucho linux-2.6]$ git rebase -i HEAD~5\npick f06abb5 dynamic_debug: use a single printk() to emit msgs\npick d61db7e joes suggestion C-99\npick 53929c5 drop enabled, check flags&bitmask\npick 57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG\n*back* 07d4a51 fixup C-99, move attribute before assignment\n\nand get something like (but with diff commit-ids)\n\n[jimc@groucho linux-2.6]$ git log --oneline -5\n57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG\n53929c5 drop enabled, check flags&bitmask\n07d4a51 fixup C-99, move attribute before assignment\nd61db7e joes suggestion C-99\nf06abb5 dynamic_debug: use a single printk() to emit msgs\n\nthat would be *slick*\nI wonder if a 3-way merge is a partial answer to the conflicts that arise?\n\n>\n> -- Ram\n>\n\nthanks\nJim\n"},{"id":"173531","messageId":"201108151454.29912.trast@student.ethz.ch","threadId":"28093","inReplyTo":"CAJfuBxwW8Dyp8FTS13uPOBKZGL9JOEqaSOhGN+zBJ_8BHpJE3g@mail.gmail.com","subject":"Re: [feature wishlist] add commit subcommand to git add -i","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2011-08-15T12:54:29Z","receivedAt":"2011-08-15T12:54:29Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jim Cromie wrote:\n> [f]ragment would also be handy, which would break each chunk of a diff\n> into a separate commit, with the summary line provided automatically\n> @@ -696,7 +692,7 @@ int foo ...\n> \n> This would help a bit with random cleanups, since rebase -i could then\n> be used to\n> reorder and recombine the fragments, and edit the commit messages afterwards.\n> \n> going further, if git rebase -i had ability to \"back\" a fixup patch\n> back to where it should have been\n\nThis little script may be of interest to you:\n\n http://article.gmane.org/gmane.comp.version-control.git/163621\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}