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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 14, 2011 at 2:56 AM, Ramkumar Ramachandra
<artagnon@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]