Re: Please support add -p with a new file, to add only part of the file

Re: Please support add -p with a new file, to add only part of the file

[Jonathan Nieder]

(+cc: Wincent who brought us the "add -p" shortcut --- thanks!; Thomas,
 who expanded its scope to git checkout et al; and Jeff, who has done
 some hacking on it)
Hi Josh,

Josh Triplett wrote:

> I recently found myself with a new file that I needed to check in part
> of with several commits.  I wanted to use "git add -p newfile" and use
> 'e' to add and commit several times (along with corresponding bits in
> existing files).  However, "git add -p" does not work on a new file,
> only an existing file.

Yep.  A workaround is to use "git add -N newfile" before running
"git add -p newfile".

I imagine "git add -p '*.c'" should also offer to add hunks from
source files that git doesn't know about yet, too.

Here's a quick demo (untested) that might _almost_ do the right thing.
Unfortunately it leaves intent-to-add entries around even for files
the operator rejects.  Anyway, maybe it can be a good starting point
for playing around.

Hope that helps,
Jonathan

 git-add--interactive.perl |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 8f0839d2..6e99ff1b 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1619,6 +1619,10 @@ sub main_loop {
 process_args();
 refresh();
 if ($patch_mode) {
+	if ($patch_mode eq 'stage') {
+		# NEEDSWORK: should use "git update-index --intent-to-add"
+		system(qw(git add --intent-to-add --), @ARGV);
+	}
 	patch_update_cmd();
 }
 else {
-- 
1.7.8.2

Re: Please support add -p with a new file, to add only part of the file

[Thomas Rast]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Josh Triplett wrote:
>
>> I recently found myself with a new file that I needed to check in part
>> of with several commits.  I wanted to use "git add -p newfile" and use
>> 'e' to add and commit several times (along with corresponding bits in
>> existing files).  However, "git add -p" does not work on a new file,
>> only an existing file.
>
> Yep.  A workaround is to use "git add -N newfile" before running
> "git add -p newfile".
>
> I imagine "git add -p '*.c'" should also offer to add hunks from
> source files that git doesn't know about yet, too.
> 
> Here's a quick demo (untested) that might _almost_ do the right thing.
> Unfortunately it leaves intent-to-add entries around even for files
> the operator rejects.  Anyway, maybe it can be a good starting point
> for playing around.

I think a proper solution needs a way to generate a diff that includes
all of the named files (even untracked).  AFAICS there is no such
feature in the diff-* commands right now.

A not-so-proper solution might of course start by looking at which files
are untracked, and only run the 'git add -N' immediately before patch
application.

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

Re: Please support add -p with a new file, to add only part of the file

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> A not-so-proper solution might of course start by looking at which files
> are untracked, and only run the 'git add -N' immediately before patch
> application.

Isn't the real issue that we mistakenly gave an impression that "add -p"
is the primary interface to the users, and forgot to tell them about the
more general "add -i", which "add -p" is a small subset of?

Even if you start with "add -N", there won't be individual "hunks" you can
pick and choose from diffing emptiness and the whole new file, so you end
up using "edit hunk" interface.

Whatever you do, you should aim to make it easier to use than

	$ cp newfile.c newfile.c-saved
        $ edit newfile.c ;# delete all the things you do not want for now
        $ git add newfile.c
        $ mv newfile.c-saved newfile.c

Personally, I think it is a very tall order to tweak "add -p / edit"
interface to make it easier to use than the above four command sequence,
the second one among which is the most time and braincell consuming part
of the process, especially when "add -p / edit" gives you has to be
unnecessarily distracting by having '+' prefix.

Re: Please support add -p with a new file, to add only part of the file

[Jeff King]

On Tue, Jan 10, 2012 at 10:32:20AM -0800, Junio C Hamano wrote:

> Thomas Rast <trast@student.ethz.ch> writes:
> 
> > A not-so-proper solution might of course start by looking at which files
> > are untracked, and only run the 'git add -N' immediately before patch
> > application.
> 
> Isn't the real issue that we mistakenly gave an impression that "add -p"
> is the primary interface to the users, and forgot to tell them about the
> more general "add -i", which "add -p" is a small subset of?

Maybe it is just me, but I find "add -p" insanely useful, and the rest
of "add -i" to be worthless clutter. The "add -p" functionality is not
easily available anywhere else, but the rest of "add -i" can be easily
(and often more efficiently) mimicked using existing git commands.

> Even if you start with "add -N", there won't be individual "hunks" you can
> pick and choose from diffing emptiness and the whole new file, so you end
> up using "edit hunk" interface.

I don't think the main impetus for this is that people necessarily want
to pick and choose hunks from added files. I think it is simply a nice
workflow to do:

  $ hack hack hack
  $ git add -p ;# inspect and add changes
  $ git commit

which is very similar to the traditional git workflow:

  $ hack hack hack
  $ git diff ;# inspect changes
  $ git add foo ;# add changes
  $ git commit

I find myself using "add -p" almost exclusively these days, as it
combines the two middle steps (and even though I usually am just hitting
"y" after inspection, when I _do_ want to make a change, I am right
there in the hunk selection loop already).

-Peff

Re: Please support add -p with a new file, to add only part of the file

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> Even if you start with "add -N", there won't be individual "hunks" you can
>> pick and choose from diffing emptiness and the whole new file, so you end
>> up using "edit hunk" interface.
>
> I don't think the main impetus for this is that people necessarily want
> to pick and choose hunks from added files.

Well, read the subject of your e-mail and tell me what it says ;-)

And that is why I was contrasting an imaginary workflow to use the
existing "add -p" with requested "allow it to be used with new files" with
what somebody may "emulate" without help from "add -p" machinery, which
is:

	$ cp newfile.c newfile.c-saved
        $ edit newfile.c ;# delete all the things you do not want for now
        $ git add newfile.c
        $ mv newfile.c-saved newfile.c

I just had to point the above out, even though I agree with the use case
you shown below for final verification. They are quite different topic, as
"git diff" won't be very useful for 'inspect changes' step in the "new
file" case to begin with.

>   $ hack hack hack
>   $ git add -p ;# inspect and add changes
>   $ git commit
>
> which is very similar to the traditional git workflow:
>
>   $ hack hack hack
>   $ git diff ;# inspect changes
>   $ git add foo ;# add changes
>   $ git commit
>
> I find myself using "add -p" almost exclusively these days, as it
> combines the two middle steps (and even though I usually am just hitting
> "y" after inspection, when I _do_ want to make a change, I am right
> there in the hunk selection loop already).

Re: Please support add -p with a new file, to add only part of the file

[Jeff King]

On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >> Even if you start with "add -N", there won't be individual "hunks" you can
> >> pick and choose from diffing emptiness and the whole new file, so you end
> >> up using "edit hunk" interface.
> >
> > I don't think the main impetus for this is that people necessarily want
> > to pick and choose hunks from added files.
> 
> Well, read the subject of your e-mail and tell me what it says ;-)

Heh. Oops.

Yes, I agree that "add -p" is not especially useful for that case, and
the workflow I was describing is very different[1].

Sorry for the noise.

-Peff

[1] For the record, I _do_ find myself using "git add -N" so that new
    files can be part of my "git add -p" workflow. So that feature is
    working as intended. It would save me a little bit of effort,
    though, if I could tell git I also want to include untracked files
    during the "-p" session, and dispense with the earlier "add -N".

    I'd also find it useful to mark conflicts as resolved, but I think
    we discussed that once before and you brought up some ugly corner
    cases.

Re: Please support add -p with a new file, to add only part of the file

[Josh Triplett]

On Tue, Jan 10, 2012 at 02:38:57PM -0500, Jeff King wrote:
> On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:
> 
> > Jeff King <peff@peff.net> writes:
> > 
> > >> Even if you start with "add -N", there won't be individual "hunks" you can
> > >> pick and choose from diffing emptiness and the whole new file, so you end
> > >> up using "edit hunk" interface.
> > >
> > > I don't think the main impetus for this is that people necessarily want
> > > to pick and choose hunks from added files.
> > 
> > Well, read the subject of your e-mail and tell me what it says ;-)
> 
> Heh. Oops.
> 
> Yes, I agree that "add -p" is not especially useful for that case, and
> the workflow I was describing is very different[1].

I've gotten used to editing diffs directly, and when I just want to
include subsets of a file on a chunk-by-chunk basis (for instance, one
new function but not another new function), I'd find it a lot easier and
less error-prone to "git add -p newfile" and edit a diff than to copy
the file aside, edit the original to delete pieces I don't want, add,
commit, and copy the file back.

Most importantly, I want to use "git add -p" because I know it'll
*never* modify my working copy, only the index.  I find that a useful
safety property.

Apart from that, it also means I have less mental state to track
("remember to copy the original file back later").

- Josh Triplett