Re: [PATCH] git-add--interactive: manual hunk editing mode

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

 



Johannes Schindelin wrote:
> Hi,
> 
> On Thu, 29 May 2008, Thomas Rast wrote:
> 
> > You wrote:
> 
> Who "You"?  You did not say a name.
> 
> > > Adds a new option 'e' to the 'add -p' command loop that lets you 
> > > discard or keep one hunk line at a time.  This is useful if there are 
> > > no unchanged lines in the middle of the hunk, so 's' will not work, 
> > > but you would still like to split it.
> > 
> 
> The splitting (even without common lines at the borders) is something I 
> needed myself, but the concept got rebuked in
> 
> http://thread.gmane.org/gmane.comp.version-control.git/67854/focus=68108

Aha, thanks for the pointer.  I'm not sure I'm in a position to
restart that discussion, but let's try anyway:

Note that what Junio said in

http://thread.gmane.org/gmane.comp.version-control.git/67854/focus=68108
> That is, , if you want to do finer grained hunk splitting than what "git
> add -p" lets you do, you do _not_ let user specify "I want to split the
> hunk into two, before this point and after this point".  Instead, let
> the user pick zero or more '-' line and zero or more '+' line, and
> adjust the context around it.  An unpicked '-' line becomes the common
> context, and an unpicked '+' line disappears.  After that, you recount
> the diff.  That way, you do not have to do any "unidiff zero" cop-out.

is precisely what my patch implements.  I did not implement the
stashing he recommends in the same message, but I believe the fact
that 'add -p' stages the end result should be enough (and works at
least for my use case).

Johannes Sixt replied:

http://thread.gmane.org/gmane.comp.version-control.git/67854/focus=68108
> In this case I would expect two adjacent hunks: one that covers the selected
> changes, another one with the remaining changes, but each against the original:

I didn't do this because there is no way to ensure that the "other
half" can be applied cleanly to the unpatched state, thus requiring
extra tracking of "hunk dependencies", so to speak.  It could be done
of course, if anyone really needs it.

You also mention

http://thread.gmane.org/gmane.comp.version-control.git/67854/focus=68108
> I thought about [the line-wise picking], but the UI is not trivial.

The y/n loop with count prefix works well for me.  It would be nice to
have it in an actual GUI of course, but I don't know enough Tcl/Tk to
implement that.

- Thomas

-- 
Thomas Rast
trast@xxxxxxxxxxxxxxx

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

  Powered by Linux