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

From: Jim Cromie <jim.cromie@gmail.com>
Date: Aug 15, 2011, 00:44 UTC
Message-ID: <CAJfuBxwiMZnghKQg9vzNVTKET9P6ryT_836mecP3a-q_EcFf7Q@mail.gmail.com>
In-Reply-To: <CALkWK0=9sT6wDwoa3vDF1bt1e8AiubwW42-o=c++MpzV47LhQg@mail.gmail.com>

On Sun, Aug 14, 2011 at 2:56 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

Show 9 quoted lines

> 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.

Show 10 quoted lines

>> 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