[feature wishlist] add commit subcommand to git add -i

[feature wishlist] add commit subcommand to git add -i

[Jim Cromie]

when using git add -i, it would be handy to have a [c]ommit option.

This would save some typing:
q # to quit git add -i
$> commit ....
git add -i <file> # to resume incremental adds

*** Commands ***
  1: [s]tatus	  2: [u]pdate	  3: [r]evert	  4: [a]dd untracked
  5: [p]atch	  6: [d]iff	  7: [q]uit	  8: [h]elp
  9: [c]commit
What now>

[f]ragment would also be handy, which would break each chunk of a diff
into a separate commit, with the summary line provided automatically
<file> @@ -696,7 +692,7 @@ int foo ...

This would help a bit with random cleanups, since rebase -i could then
be used to
reorder and recombine the fragments, and edit the commit messages afterwards.


going further, if git rebase -i  had ability to  "back" a fixup patch
back to where it should have been, and adjust the intervening patches
where conflict would normally happen, that would be awesome.
Simplistically, this would just shift the patch 1 step back iteratively,
until it wouldnt apply properly, and then --abort, stopping at the last
clean rebase.

apologies if this is too hair-brained, or already done.

Re: [feature wishlist] add commit subcommand to git add -i

[Conrad Irwin]

On Sun, Aug 14, 2011 at 1:38 AM, Jim Cromie <jim.cromie@gmail.com> wrote:
> going further, if git rebase -i  had ability to  "back" a fixup patch
> back to where it should have been, and adjust the intervening patches
> where conflict would normally happen, that would be awesome.
> Simplistically, this would just shift the patch 1 step back iteratively,
> until it wouldnt apply properly, and then --abort, stopping at the last
> clean rebase.
>
> apologies if this is too hair-brained, or already done.

It sounds like you're looking for several git commit
(-p|--interactive) --fixup <commit>, followed by a git rebase -i
--autosquash. It's not quite as automatic as you describe, but I think
that automating it would be pretty hard to do correctly.

Conrad

Re: [feature wishlist] add commit subcommand to git add -i

[Jim Cromie]

On Sun, Aug 14, 2011 at 2:48 AM, Conrad Irwin <conrad.irwin@gmail.com> wrote:
> On Sun, Aug 14, 2011 at 1:38 AM, Jim Cromie <jim.cromie@gmail.com> wrote:
>> going further, if git rebase -i  had ability to  "back" a fixup patch
>> back to where it should have been, and adjust the intervening patches
>> where conflict would normally happen, that would be awesome.
>> Simplistically, this would just shift the patch 1 step back iteratively,
>> until it wouldnt apply properly, and then --abort, stopping at the last
>> clean rebase.
>>
>> apologies if this is too hair-brained, or already done.
>
> It sounds like you're looking for several git commit
> (-p|--interactive) --fixup <commit>, followed by a git rebase -i
> --autosquash. It's not quite as automatic as you describe, but I think
> that automating it would be pretty hard to do correctly.
>
> Conrad
>

it is indeed similar.  in the simple case, I know which patch needs the fixup,
and using editor to rearrange the todo-file is straightforward.
using --autosquash requires knowing the commit-log message to be fixed,
and using it to name the fixup commit, which is doable, but I havent trained
myself to do so.  I'll give it a try next time..

thanks
Jim

Re: [feature wishlist] add commit subcommand to git add -i

[Ramkumar Ramachandra]

Hi Jim,

Jim Cromie writes:
> when using git add -i, it would be handy to have a [c]ommit option.

I can't personally comment on this because I use Magit for staging/
unstaging and committing.  It's quite an awesome application- do check
it out if you use Emacs.

> going further, if git rebase -i  had ability to  "back" a fixup patch
> back to where it should have been, and adjust the intervening patches
> where conflict would normally happen, that would be awesome.
> Simplistically, this would just shift the patch 1 step back iteratively,
> until it wouldnt apply properly, and then --abort, stopping at the last
> clean rebase.

Hm, I'm not sure if I understand fully: is the idea about moving a
commit backwards iteratively so we have to resolve several simpler and
smaller conflicts?  I have to admit that I work around this problem by
running 'rebase -i' several times, moving the commit back in the
sequence little-by-little.

-- Ram

Re: [feature wishlist] add commit subcommand to git add -i

[Jim Cromie]

On Sun, Aug 14, 2011 at 2:56 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Hi Jim,
>
> Jim Cromie writes:
>> when using git add -i, it would be handy to have a [c]ommit option.
>
> I can't personally comment on this because I use Magit for staging/
> unstaging and committing.  It's quite an awesome application- do check
> it out if you use Emacs.
>

I;ll take a look, thanks.

>> going further, if git rebase -i  had ability to  "back" a fixup patch
>> back to where it should have been, and adjust the intervening patches
>> where conflict would normally happen, that would be awesome.
>> Simplistically, this would just shift the patch 1 step back iteratively,
>> until it wouldnt apply properly, and then --abort, stopping at the last
>> clean rebase.
>
> Hm, I'm not sure if I understand fully: is the idea about moving a
> commit backwards iteratively so we have to resolve several simpler and
> smaller conflicts?

yes - thats certainly part of it.
I added iteratively as a simplification.
I suspect there are more clever ways to do it.

the simplest case is to move a fixup patch backwards where no conflicts arise,
put the fixup right after the patch where the errant code was added.

the harder one is to recognize and resolve the interim conflicts.
To avoid handwaving, I reconstructed my particular case,
which is available on github:
https://github.com/jimc/linux-2.6/tree/rebase-back-usecase

1 - patches 1-11 on dynamic-debug, from Jason Baron, last Thurs.
     (these are the ones that gave git am heartburn, fixed in git-next)
2 - Suggestion by Joe Perches to use C-99
     I cut pasted his suggestion, made a commit.
     d61db7e joes suggestion C-99
3 - 53929c5 drop enabled, check flags&bitmask
4 - 57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG
5 - fixup, which needs to go back to just after 2.

specifically:
[jimc@groucho linux-2.6]$ git log --oneline -5
07d4a51 fixup C-99, move attribute before assignment
57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG
53929c5 drop enabled, check flags&bitmask
d61db7e joes suggestion C-99
f06abb5 dynamic_debug: use a single printk() to emit msgs

>  I have to admit that I work around this problem by
> running 'rebase -i' several times, moving the commit back in the
> sequence little-by-little.

when I did it manually,
there were a number of conficts to resolve.
pretty minor really, but tedious.

<<<<<<< HEAD
		.enabled = false,				       \
	} __used __aligned(8) __attribute__((section("__verbose")))
=======
	}
>>>>>>> 07d4a51... fixup C-99, move attribute before assignment

if I could say:

[jimc@groucho linux-2.6]$ git rebase -i HEAD~5
pick f06abb5 dynamic_debug: use a single printk() to emit msgs
pick d61db7e joes suggestion C-99
pick 53929c5 drop enabled, check flags&bitmask
pick 57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG
*back* 07d4a51 fixup C-99, move attribute before assignment

and get something like (but with diff commit-ids)

[jimc@groucho linux-2.6]$ git log --oneline -5
57a9be0 prefer CONFIG_DYNAMIC_DEBUG over DEBUG
53929c5 drop enabled, check flags&bitmask
07d4a51 fixup C-99, move attribute before assignment
d61db7e joes suggestion C-99
f06abb5 dynamic_debug: use a single printk() to emit msgs

that would be *slick*
I wonder if a 3-way merge is a partial answer to the conflicts that arise?

>
> -- Ram
>

thanks
Jim

Re: [feature wishlist] add commit subcommand to git add -i

[Thomas Rast]

Jim Cromie wrote:
> [f]ragment would also be handy, which would break each chunk of a diff
> into a separate commit, with the summary line provided automatically
> <file> @@ -696,7 +692,7 @@ int foo ...
> 
> This would help a bit with random cleanups, since rebase -i could then
> be used to
> reorder and recombine the fragments, and edit the commit messages afterwards.
> 
> going further, if git rebase -i  had ability to  "back" a fixup patch
> back to where it should have been

This little script may be of interest to you:

  http://article.gmane.org/gmane.comp.version-control.git/163621

-- 
Thomas Rast
trast@{inf,student}.ethz.ch