On Aug 5, 2007, at 5:03 PM, David Kastrup wrote:

quoted text
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Aug 5, 2007, at 3:58 PM, Johannes Schindelin wrote:
>>
>>> Hi,
>>>
>>> On Sun, 5 Aug 2007, Steffen Prohaska wrote:
>>>
>>>> git gui is especially useful because it allows to select diff  
>>>> hunks.
>>>
>>> You should give a _big_ _fat_ _red_ warning there.
>>>
>>> If you selectively commit diff hunks, you _never_ tested what you
>>> committed.
>>>
>>> That is the reason we're not advertising git add -i more actively.
>>
>> Hmm... If you do 'git cherry-pick' or 'git rebase' you also did
>> not test what you committed. Should we advertise them less
>> actively as well?
>
> Selectively committing diff hunks also means that a subsequent rebase
> -i or git-cherry will have to reconsider the same commit as it has
> only been incompletely applied.
>
> So it can mean more work later.  Also one would in general have to
> edit the commit message (if it describes everything that has been
> done).
>
> There are simply consequences for the workflow if you do things
> right.  Whether they are worth a "big fat red warning" is one
> question, but mentioning them is probably not amiss.

I found it quite useful to be able to commit diff chunks selectively.
I started editing diffs as described in [1] but actually it turned
out to be easier for me to use git gui. I'm speaking unified diff
probably less fluently than Linus does.

My note about using git gui to select diff hunks is added to the
section 'Reordering or selecting from a patch series', which is in
my opinion the right section.

But apparently there's some dispute about usefulness of my comment on
cherry-picking. Maybe a separate section on rewriting changes would
be useful, which I do not have the time to start right now.

Junio, maybe you want to take only the first part of my patch?

	Steffen

[1] http://thread.gmane.org/gmane.comp.version-control.git/46733

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html