{"thread":{"id":"29327","subject":"Re: Please support add -p with a new file, to add only part of the file","startedAt":"2012-01-09T20:47:21Z","lastAt":"2012-01-10T22:29:26Z","messageCount":7,"participants":["Jonathan Nieder","Thomas Rast","Junio C Hamano","Jeff King","Josh Triplett"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182180","messageId":"20120109204721.GC23825@burratino","threadId":"29327","inReplyTo":"20120109105134.1239.39047.reportbug@leaf","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-01-09T20:47:21Z","receivedAt":"2012-01-09T20:47:21Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: Wincent who brought us the \"add -p\" shortcut --- thanks!; Thomas,\n who expanded its scope to git checkout et al; and Jeff, who has done\n some hacking on it)\nHi Josh,\n\nJosh Triplett wrote:\n\n> I recently found myself with a new file that I needed to check in part\n> of with several commits.  I wanted to use \"git add -p newfile\" and use\n> 'e' to add and commit several times (along with corresponding bits in\n> existing files).  However, \"git add -p\" does not work on a new file,\n> only an existing file.\n\nYep.  A workaround is to use \"git add -N newfile\" before running\n\"git add -p newfile\".\n\nI imagine \"git add -p '*.c'\" should also offer to add hunks from\nsource files that git doesn't know about yet, too.\n\nHere's a quick demo (untested) that might _almost_ do the right thing.\nUnfortunately it leaves intent-to-add entries around even for files\nthe operator rejects.  Anyway, maybe it can be a good starting point\nfor playing around.\n\nHope that helps,\nJonathan\n\n git-add--interactive.perl |    4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/git-add--interactive.perl b/git-add--interactive.perl\nindex 8f0839d2..6e99ff1b 100755\n--- a/git-add--interactive.perl\n+++ b/git-add--interactive.perl\n@@ -1619,6 +1619,10 @@ sub main_loop {\n process_args();\n refresh();\n if ($patch_mode) {\n+\tif ($patch_mode eq 'stage') {\n+\t\t# NEEDSWORK: should use \"git update-index --intent-to-add\"\n+\t\tsystem(qw(git add --intent-to-add --), @ARGV);\n+\t}\n \tpatch_update_cmd();\n }\n else {\n-- \n1.7.8.2\n"},{"id":"182237","messageId":"87ty43fy7f.fsf@thomas.inf.ethz.ch","threadId":"29327","inReplyTo":"20120109204721.GC23825@burratino","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-10T14:07:16Z","receivedAt":"2012-01-10T14:07:16Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Josh Triplett wrote:\n>\n>> I recently found myself with a new file that I needed to check in part\n>> of with several commits.  I wanted to use \"git add -p newfile\" and use\n>> 'e' to add and commit several times (along with corresponding bits in\n>> existing files).  However, \"git add -p\" does not work on a new file,\n>> only an existing file.\n>\n> Yep.  A workaround is to use \"git add -N newfile\" before running\n> \"git add -p newfile\".\n>\n> I imagine \"git add -p '*.c'\" should also offer to add hunks from\n> source files that git doesn't know about yet, too.\n> \n> Here's a quick demo (untested) that might _almost_ do the right thing.\n> Unfortunately it leaves intent-to-add entries around even for files\n> the operator rejects.  Anyway, maybe it can be a good starting point\n> for playing around.\n\nI think a proper solution needs a way to generate a diff that includes\nall of the named files (even untracked).  AFAICS there is no such\nfeature in the diff-* commands right now.\n\nA not-so-proper solution might of course start by looking at which files\nare untracked, and only run the 'git add -N' immediately before patch\napplication.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182263","messageId":"7vpqer9znv.fsf@alter.siamese.dyndns.org","threadId":"29327","inReplyTo":"87ty43fy7f.fsf@thomas.inf.ethz.ch","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-10T18:32:20Z","receivedAt":"2012-01-10T18:32:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> A not-so-proper solution might of course start by looking at which files\n> are untracked, and only run the 'git add -N' immediately before patch\n> application.\n\nIsn't the real issue that we mistakenly gave an impression that \"add -p\"\nis the primary interface to the users, and forgot to tell them about the\nmore general \"add -i\", which \"add -p\" is a small subset of?\n\nEven if you start with \"add -N\", there won't be individual \"hunks\" you can\npick and choose from diffing emptiness and the whole new file, so you end\nup using \"edit hunk\" interface.\n\nWhatever you do, you should aim to make it easier to use than\n\n\t$ cp newfile.c newfile.c-saved\n        $ edit newfile.c ;# delete all the things you do not want for now\n        $ git add newfile.c\n        $ mv newfile.c-saved newfile.c\n\nPersonally, I think it is a very tall order to tweak \"add -p / edit\"\ninterface to make it easier to use than the above four command sequence,\nthe second one among which is the most time and braincell consuming part\nof the process, especially when \"add -p / edit\" gives you has to be\nunnecessarily distracting by having '+' prefix.\n"},{"id":"182265","messageId":"20120110183833.GA15787@sigill.intra.peff.net","threadId":"29327","inReplyTo":"7vpqer9znv.fsf@alter.siamese.dyndns.org","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-10T18:38:33Z","receivedAt":"2012-01-10T18:38:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 10, 2012 at 10:32:20AM -0800, Junio C Hamano wrote:\n\n> Thomas Rast <trast@student.ethz.ch> writes:\n> \n> > A not-so-proper solution might of course start by looking at which files\n> > are untracked, and only run the 'git add -N' immediately before patch\n> > application.\n> \n> Isn't the real issue that we mistakenly gave an impression that \"add -p\"\n> is the primary interface to the users, and forgot to tell them about the\n> more general \"add -i\", which \"add -p\" is a small subset of?\n\nMaybe it is just me, but I find \"add -p\" insanely useful, and the rest\nof \"add -i\" to be worthless clutter. The \"add -p\" functionality is not\neasily available anywhere else, but the rest of \"add -i\" can be easily\n(and often more efficiently) mimicked using existing git commands.\n\n> Even if you start with \"add -N\", there won't be individual \"hunks\" you can\n> pick and choose from diffing emptiness and the whole new file, so you end\n> up using \"edit hunk\" interface.\n\nI don't think the main impetus for this is that people necessarily want\nto pick and choose hunks from added files. I think it is simply a nice\nworkflow to do:\n\n  $ hack hack hack\n  $ git add -p ;# inspect and add changes\n  $ git commit\n\nwhich is very similar to the traditional git workflow:\n\n  $ hack hack hack\n  $ git diff ;# inspect changes\n  $ git add foo ;# add changes\n  $ git commit\n\nI find myself using \"add -p\" almost exclusively these days, as it\ncombines the two middle steps (and even though I usually am just hitting\n\"y\" after inspection, when I _do_ want to make a change, I am right\nthere in the hunk selection loop already).\n\n-Peff\n"},{"id":"182272","messageId":"7vd3ar9wto.fsf@alter.siamese.dyndns.org","threadId":"29327","inReplyTo":"20120110183833.GA15787@sigill.intra.peff.net","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-10T19:33:39Z","receivedAt":"2012-01-10T19:33:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> Even if you start with \"add -N\", there won't be individual \"hunks\" you can\n>> pick and choose from diffing emptiness and the whole new file, so you end\n>> up using \"edit hunk\" interface.\n>\n> I don't think the main impetus for this is that people necessarily want\n> to pick and choose hunks from added files.\n\nWell, read the subject of your e-mail and tell me what it says ;-)\n\nAnd that is why I was contrasting an imaginary workflow to use the\nexisting \"add -p\" with requested \"allow it to be used with new files\" with\nwhat somebody may \"emulate\" without help from \"add -p\" machinery, which\nis:\n\n\t$ cp newfile.c newfile.c-saved\n        $ edit newfile.c ;# delete all the things you do not want for now\n        $ git add newfile.c\n        $ mv newfile.c-saved newfile.c\n\nI just had to point the above out, even though I agree with the use case\nyou shown below for final verification. They are quite different topic, as\n\"git diff\" won't be very useful for 'inspect changes' step in the \"new\nfile\" case to begin with.\n\n>   $ hack hack hack\n>   $ git add -p ;# inspect and add changes\n>   $ git commit\n>\n> which is very similar to the traditional git workflow:\n>\n>   $ hack hack hack\n>   $ git diff ;# inspect changes\n>   $ git add foo ;# add changes\n>   $ git commit\n>\n> I find myself using \"add -p\" almost exclusively these days, as it\n> combines the two middle steps (and even though I usually am just hitting\n> \"y\" after inspection, when I _do_ want to make a change, I am right\n> there in the hunk selection loop already).\n"},{"id":"182273","messageId":"20120110193857.GA19665@sigill.intra.peff.net","threadId":"29327","inReplyTo":"7vd3ar9wto.fsf@alter.siamese.dyndns.org","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-01-10T19:38:57Z","receivedAt":"2012-01-10T19:38:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> >> Even if you start with \"add -N\", there won't be individual \"hunks\" you can\n> >> pick and choose from diffing emptiness and the whole new file, so you end\n> >> up using \"edit hunk\" interface.\n> >\n> > I don't think the main impetus for this is that people necessarily want\n> > to pick and choose hunks from added files.\n> \n> Well, read the subject of your e-mail and tell me what it says ;-)\n\nHeh. Oops.\n\nYes, I agree that \"add -p\" is not especially useful for that case, and\nthe workflow I was describing is very different[1].\n\nSorry for the noise.\n\n-Peff\n\n[1] For the record, I _do_ find myself using \"git add -N\" so that new\n    files can be part of my \"git add -p\" workflow. So that feature is\n    working as intended. It would save me a little bit of effort,\n    though, if I could tell git I also want to include untracked files\n    during the \"-p\" session, and dispense with the earlier \"add -N\".\n\n    I'd also find it useful to mark conflicts as resolved, but I think\n    we discussed that once before and you brought up some ugly corner\n    cases.\n"},{"id":"182284","messageId":"20120110222926.GB14895@leaf","threadId":"29327","inReplyTo":"20120110193857.GA19665@sigill.intra.peff.net","subject":"Re: Please support add -p with a new file, to add only part of the file","fromName":"Josh Triplett","fromEmail":"josh@joshtriplett.org","sentAt":"2012-01-10T22:29:26Z","receivedAt":"2012-01-10T22:29:26Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"On Tue, Jan 10, 2012 at 02:38:57PM -0500, Jeff King wrote:\n> On Tue, Jan 10, 2012 at 11:33:39AM -0800, Junio C Hamano wrote:\n> \n> > Jeff King <peff@peff.net> writes:\n> > \n> > >> Even if you start with \"add -N\", there won't be individual \"hunks\" you can\n> > >> pick and choose from diffing emptiness and the whole new file, so you end\n> > >> up using \"edit hunk\" interface.\n> > >\n> > > I don't think the main impetus for this is that people necessarily want\n> > > to pick and choose hunks from added files.\n> > \n> > Well, read the subject of your e-mail and tell me what it says ;-)\n> \n> Heh. Oops.\n> \n> Yes, I agree that \"add -p\" is not especially useful for that case, and\n> the workflow I was describing is very different[1].\n\nI've gotten used to editing diffs directly, and when I just want to\ninclude subsets of a file on a chunk-by-chunk basis (for instance, one\nnew function but not another new function), I'd find it a lot easier and\nless error-prone to \"git add -p newfile\" and edit a diff than to copy\nthe file aside, edit the original to delete pieces I don't want, add,\ncommit, and copy the file back.\n\nMost importantly, I want to use \"git add -p\" because I know it'll\n*never* modify my working copy, only the index.  I find that a useful\nsafety property.\n\nApart from that, it also means I have less mental state to track\n(\"remember to copy the original file back later\").\n\n- Josh Triplett\n"}]}