{"thread":{"id":"44635","subject":"git add -p with new file","startedAt":"2016-12-07T01:24:14Z","lastAt":"2016-12-13T19:59:40Z","messageCount":17,"participants":["Ariel","Duy Nguyen","Jeff King","Junio C Hamano","Stephan Beyer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"307094","messageId":"alpine.DEB.2.11.1612062012540.13185@cherryberry.dsgml.com","threadId":"44635","inReplyTo":null,"subject":"git add -p with new file","fromName":"Ariel","fromEmail":"asgit@dsgml.com","sentAt":"2016-12-07T01:18:59Z","receivedAt":"2016-12-07T01:24:14Z","isPatch":false,"sender":{"key":"asgit@dsgml.com","avatar":null},"body":"\nIf you do git add -p new_file it says:\n\nNo changes.\n\nWhich is a rather confusing message. I would expect it to show me the \ncontent of the file in patch form, in the normal way that -p works, let me \nedit it, etc.\n\n(Note: I am aware I can do -N first, but when I specifically enter the \nname of a new file I feel it should figure out what I mean.)\n\n \t-Ariel\n"},{"id":"307097","messageId":"CACsJy8A_YMyEUgX--1tEfJC4aaYfDbFFL8WEs6CHp4a4=mHRjw@mail.gmail.com","threadId":"44635","inReplyTo":"alpine.DEB.2.11.1612062012540.13185@cherryberry.dsgml.com","subject":"Re: git add -p with new file","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-12-07T09:22:36Z","receivedAt":"2016-12-07T09:23:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Dec 7, 2016 at 8:18 AM, Ariel <asgit@dsgml.com> wrote:\n>\n> If you do git add -p new_file it says:\n>\n> No changes.\n>\n> Which is a rather confusing message. I would expect it to show me the\n> content of the file in patch form, in the normal way that -p works, let me\n> edit it, etc.\n\nWe could improve it a bit, suggesting the user to do git add -N. But\nis there a point of using -p on a new file? It will be one big chunk,\nyou can't split anything. Perhaps maybe you want to use 'e' to edit\nwhat's added?\n\n> (Note: I am aware I can do -N first, but when I specifically enter the name\n> of a new file I feel it should figure out what I mean.)\n-- \nDuy\n"},{"id":"307355","messageId":"20161209141129.r53b4rbtgd76fn2a@sigill.intra.peff.net","threadId":"44635","inReplyTo":"alpine.DEB.2.11.1612062012540.13185@cherryberry.dsgml.com","subject":"Re: git add -p with new file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-09T14:11:30Z","receivedAt":"2016-12-09T14:11:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 06, 2016 at 08:18:59PM -0500, Ariel wrote:\n\n> If you do git add -p new_file it says:\n> \n> No changes.\n> \n> Which is a rather confusing message. I would expect it to show me the\n> content of the file in patch form, in the normal way that -p works, let me\n> edit it, etc.\n> \n> (Note: I am aware I can do -N first, but when I specifically enter the name\n> of a new file I feel it should figure out what I mean.)\n\nKeep in mind that the argument to \"git add -p\" is not a filename, but a\n\"pathspec\" that can match many files. What should:\n\n  git init\n  mkdir subdir\n  for i in one two; do echo $i >subdir/$i; done\n  git add -p subdir\n\ndo?  Or for that matter, \"git add -p .\"? It's contrary to the rest of\ngit-add for specifying pathspecs to actually make things _more_\ninclusive rather than less.\n\nSo I don't think triggering the change of behavior based on the presence\nof a pathspec makes sense.\n\nHistorically \"add -p\" has been more like \"add -u\" in updating tracked\nfiles. We have \"-A\" for \"update everything _and_ new files\". It doesn't\nseem unreasonable to me to have a variant of \"-p\" that is similar.\n\nI don't think that variant should just be \"add -N everything, and then\nrun add -p\". As Duy points out, the patch for a new file is just one big\nblock. But the decision of \"do I want to start tracking this untracked\nfile\" is potentially an interesting one.\n\n-Peff\n"},{"id":"307374","messageId":"alpine.DEB.2.11.1612091322290.13185@cherryberry.dsgml.com","threadId":"44635","inReplyTo":"CACsJy8A_YMyEUgX--1tEfJC4aaYfDbFFL8WEs6CHp4a4=mHRjw@mail.gmail.com","subject":"Re: git add -p with new file","fromName":"Ariel","fromEmail":"asgit@dsgml.com","sentAt":"2016-12-09T18:26:58Z","receivedAt":"2016-12-09T18:27:16Z","isPatch":false,"sender":{"key":"asgit@dsgml.com","avatar":null},"body":"\nOn Wed, 7 Dec 2016, Duy Nguyen wrote:\n\n> On Wed, Dec 7, 2016 at 8:18 AM, Ariel <asgit@dsgml.com> wrote:\n\n>> If you do git add -p new_file it says:\n\n>> No changes.\n\n>> Which is a rather confusing message. I would expect it to show me the\n>> content of the file in patch form, in the normal way that -p works, let me\n>> edit it, etc.\n\n> We could improve it a bit, suggesting the user to do git add -N. But\n> is there a point of using -p on a new file?\n\nI got into the habit of always using -p as a way of checking my diffs \nbefore committing, so I ran it out of habit on a new file as well and got \nthat confusing message.\n\nIt's even worse if you run it on multiple files, some changed, some added \n- the added ones are ignored completely, without any message at all.\n\n> It will be one big chunk, you can't split anything.\n\nThat's fine, that's what I would expect.\n\n> Perhaps maybe you want to use 'e' to edit what's added?\n\nI might, but mainly it would show me what it was adding.\n\n \t-Ariel\n"},{"id":"307376","messageId":"alpine.DEB.2.11.1612091331170.13185@cherryberry.dsgml.com","threadId":"44635","inReplyTo":"20161209141129.r53b4rbtgd76fn2a@sigill.intra.peff.net","subject":"Re: git add -p with new file","fromName":"Ariel","fromEmail":"asgit@dsgml.com","sentAt":"2016-12-09T18:43:24Z","receivedAt":"2016-12-09T18:43:31Z","isPatch":false,"sender":{"key":"asgit@dsgml.com","avatar":null},"body":"\nOn Fri, 9 Dec 2016, Jeff King wrote:\n\n> On Tue, Dec 06, 2016 at 08:18:59PM -0500, Ariel wrote:\n\n>> If you do git add -p new_file it says:\n\n>> No changes.\n\n>> Which is a rather confusing message. I would expect it to show me the\n>> content of the file in patch form, in the normal way that -p works, let me\n>> edit it, etc.\n\n> What should:\n[git add directory with two new files]\n> do?\n\nIt should do the exact same thing that git add without -p does: Add the \ndirectory and both files, but because of the -p also show the diff on the \nscreen and ask.\n\n> It's contrary to the rest of git-add for specifying pathspecs to \n> actually make things _more_ inclusive rather than less.\n\nIs it? Because git add without -p is happy to add new files.\n\n> Historically \"add -p\" has been more like \"add -u\" in updating tracked\n> files.\n\nBut it doesn't have to be that way. You could make add -p identical to add \nwithout options, except the -p prompts to review diffs first.\n\n> We have \"-A\" for \"update everything _and_ new files\". It doesn't\n> seem unreasonable to me to have a variant of \"-p\" that is similar.\n\nThat seems unnecessarily complex because -p asks about each file, so you \nwill never find new files added without realizing it.\n\n> I don't think that variant should just be \"add -N everything, and then\n> run add -p\". As Duy points out, the patch for a new file is just one big\n> block. But the decision of \"do I want to start tracking this untracked\n> file\" is potentially an interesting one.\n\nWhat makes sense to me is a two part question: First ask 'Add new path', \nand then if yes, ask to stage the hunk (where the hunk is the entire \nfile).\n\nThis makes -p useful on new files, without hurting prior expectations of \nhow it works.\n\n \t-Ariel\n"},{"id":"307421","messageId":"20161210085556.nwg3pbay367jqin5@sigill.intra.peff.net","threadId":"44635","inReplyTo":"alpine.DEB.2.11.1612091331170.13185@cherryberry.dsgml.com","subject":"Re: git add -p with new file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T08:55:56Z","receivedAt":"2016-12-10T08:56:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:\n\n> > It's contrary to the rest of git-add for specifying pathspecs to\n> > actually make things _more_ inclusive rather than less.\n> \n> Is it? Because git add without -p is happy to add new files.\n\nI was just speaking there of whether the presence of the file on the\ncommand-line was relevant. In other words, \"git add -u untracked-file\"\ndoes not countermand the \"-u\" to say \"also add this file\".\n\n> > Historically \"add -p\" has been more like \"add -u\" in updating tracked\n> > files.\n> \n> But it doesn't have to be that way. You could make add -p identical to add\n> without options, except the -p prompts to review diffs first.\n\nThe question is whether you would annoy people using \"-p\" if you started\nincluding untracked files by default. I agree because it's inherently an\ninteractive process that we can be looser with backwards compatibility.\n\nPerhaps a config option would be the best path forward (even if we were\nto switch the default to \"true\", it leaves an escape hatch for people\nwho do not like the new behavior).\n\n> > We have \"-A\" for \"update everything _and_ new files\". It doesn't\n> > seem unreasonable to me to have a variant of \"-p\" that is similar.\n> \n> That seems unnecessarily complex because -p asks about each file, so you\n> will never find new files added without realizing it.\n\nIf you care about adding new files, wouldn't you just always use \"-P\"\ninstead of \"-p\"?\n\n-Peff\n"},{"id":"307455","messageId":"xmqq37hvphji.fsf@gitster.mtv.corp.google.com","threadId":"44635","inReplyTo":"20161210085556.nwg3pbay367jqin5@sigill.intra.peff.net","subject":"Re: git add -p with new file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-10T22:04:33Z","receivedAt":"2016-12-10T22:04:43Z","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> On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:\n> ...\n>> But it doesn't have to be that way. You could make add -p identical to add\n>> without options, except the -p prompts to review diffs first.\n>\n> The question is whether you would annoy people using \"-p\" if you started\n> including untracked files by default. I agree because it's inherently an\n> interactive process that we can be looser with backwards compatibility.\n\nIt might be interactive, but it will be irritating that we suddenly\nhave to see hundreds of lines in an untracked file before we are\nasked to say \"no I do not want to add this file\" and have to do so\nfor all the untracked files that happen to match the given pathspec.\n\nIt might make it less irritating if one of the interactive choices\noffered in the first prompt were N that tells the command: \"No,\nignore all the untracked paths\", though.  I dunno.\n\nAlso, because \"git add -p\" (no pathspec) is NOT a no-op, the\nsimilarity Ariel sees with \"git add\" (no other options) does not\nhold.  As you kept explaining (but perhaps not successfully being\nunderstood yet), \"add -p\" works like \"add -u\", and it will make the\ncommand incoherent if we allowed \"git add -p <path>\" to add new\npaths, exactly because \"git add -u <path>\" does not do so.  Of\ncourse that can be fixed by allowing \"git add -u\" to also add new\npaths that match pathspec.\n\nOf course, Ariel can vote for making \"add -p\" more like \"add\" (with\nno options) than \"add -u\".  I _think_ it is a better way to solve\nthe incoherence than making \"add -u\" to add new paths.  But what it\nmeans is that \"add -p <paths>\" works on both tracked and untracked\npaths that match the given pathspec <paths>, and also \"add -p\" (no\npathspec) must become a no-op (because \"add\" without option and\npathspec is).\n\n"},{"id":"307465","messageId":"20161211130034.ygj5l2gbx33uknlk@sigill.intra.peff.net","threadId":"44635","inReplyTo":"xmqq37hvphji.fsf@gitster.mtv.corp.google.com","subject":"Re: git add -p with new file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-11T13:00:34Z","receivedAt":"2016-12-11T13:00:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 10, 2016 at 02:04:33PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:\n> > ...\n> >> But it doesn't have to be that way. You could make add -p identical to add\n> >> without options, except the -p prompts to review diffs first.\n> >\n> > The question is whether you would annoy people using \"-p\" if you started\n> > including untracked files by default. I agree because it's inherently an\n> > interactive process that we can be looser with backwards compatibility.\n> \n> It might be interactive, but it will be irritating that we suddenly\n> have to see hundreds of lines in an untracked file before we are\n> asked to say \"no I do not want to add this file\" and have to do so\n> for all the untracked files that happen to match the given pathspec.\n> \n> It might make it less irritating if one of the interactive choices\n> offered in the first prompt were N that tells the command: \"No,\n> ignore all the untracked paths\", though.  I dunno.\n\nYeah, I agree dumping the contents automatically is annoying. Ariel\nsuggested asking twice about each path, which sounds clunky to me. I'd\nprobably give a simple question, with an option to dump the contents.\nLike:\n\n  $ echo foo >untracked\n  $ git add -p\n  New file: untracked\n  Stage this file [y,n,v,q,a,d,/,e,?]? v     <-- user types 'v' for \"view\"\n\n  diff --git a/untracked b/untracked\n  index e69de29..257cc56 100644\n  --- a/untracked\n  +++ b/untracked\n  @@ -0,0 +1 @@\n  +foo\n  Stage this file [y,n,v,q,a,d,/,e?]? y\n\nAlternatively, \"v\" could just run \"$GIT_PAGER <file>\". The point is to\nrefresh your memory on what is in it before making a decision.\n\nI'd also probably add interactive.showUntracked to make the whole thing\noptional (but I think it would be OK to default it to on).\n\nSome thought would have to be given handling binary files, as we\nwouldn't want to dump their contents (but maybe showing them in a pager\nwould be OK).. We skip them entirely right now. So a related feature may\nbe asking \"Stage this file\" for binary files, with an option to somehow\nview the contents.\n\nI don't have plans to work on any of this myself. Just dumping thoughts\non what I'd expect an implementation to deal with.\n\n-Peff\n"},{"id":"307541","messageId":"e60f6324-421f-3445-b2a9-02c2dd0c2688@gmx.net","threadId":"44635","inReplyTo":"alpine.DEB.2.11.1612091322290.13185@cherryberry.dsgml.com","subject":"Re: git add -p with new file","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2016-12-12T20:24:29Z","receivedAt":"2016-12-12T20:25:04Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi Ariel,\n\nOn 12/09/2016 07:26 PM, Ariel wrote:\n> On Wed, 7 Dec 2016, Duy Nguyen wrote:\n>> We could improve it a bit, suggesting the user to do git add -N. But\n>> is there a point of using -p on a new file?\n> \n> I got into the habit of always using -p as a way of checking my diffs\n> before committing,\n\nNot commenting on the main issue here, but if you want to check your new\nfiles with a \"git add -p\"-like tool, you can do\n\n\tgit add <untracked files>\n\tgit reset -p\n\n(this is unstaging, but it's still useful)\n\nBest\n  Stephan\n"},{"id":"307542","messageId":"dc698b79-6311-a2a3-c564-a43ef071e62b@gmx.net","threadId":"44635","inReplyTo":"20161211130034.ygj5l2gbx33uknlk@sigill.intra.peff.net","subject":"Re: git add -p with new file","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2016-12-12T20:31:03Z","receivedAt":"2016-12-12T20:31:40Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nOn 12/11/2016 02:00 PM, Jeff King wrote:\n> On Sat, Dec 10, 2016 at 02:04:33PM -0800, Junio C Hamano wrote:\n>> Jeff King <peff@peff.net> writes:\n>>> On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:\n>>> ...\n>>>> But it doesn't have to be that way. You could make add -p identical to add\n>>>> without options, except the -p prompts to review diffs first.\n>>>\n>>> The question is whether you would annoy people using \"-p\" if you started\n>>> including untracked files by default. I agree because it's inherently an\n>>> interactive process that we can be looser with backwards compatibility.\n>>\n>> It might be interactive, but it will be irritating that we suddenly\n>> have to see hundreds of lines in an untracked file before we are\n>> asked to say \"no I do not want to add this file\" and have to do so\n>> for all the untracked files that happen to match the given pathspec.\n>>\n>> It might make it less irritating if one of the interactive choices\n>> offered in the first prompt were N that tells the command: \"No,\n>> ignore all the untracked paths\", though.  I dunno.\n> \n> Yeah, I agree dumping the contents automatically is annoying. Ariel\n> suggested asking twice about each path, which sounds clunky to me. I'd\n> probably give a simple question, with an option to dump the contents.\n> Like:\n> \n>   $ echo foo >untracked\n>   $ git add -p\n>   New file: untracked\n>   Stage this file [y,n,v,q,a,d,/,e,?]? v     <-- user types 'v' for \"view\"\n\nI am also a \"git add -p\"-only user (except for new files and merges).\nHowever, I usually keep a lot of untracked files in my repositories.\nFiles that I do not (git)ignore because I want to see them when I type\n\"git status\".\n\nHence, the imagination only that \"git add -p\" starts to ask me for each\nuntracked file feels like a lot of annoying \"n\" presses. I could imagine\nthat it is okay-ish when it asks about the untracked files *after* all\ntracked paths have been processed (I guess this has been proposed\nbefore), so that I can safely quit.\n\nI am also not really sure what problem this feature is trying to solve.\nIf the \"problem\"(?) is that it should act more like \"git add\" instead of\n\"git add -u\", for whatever reason, this may be fine (but the\nconfiguration option is a must-have then).\n\nFor me, I often had the problem that I simply forgot to add new\nfiles...¹ Still I doubt that one would benefit from such a feature\nbecause either:\n\n- you do not have many untracked files (unlike me). You will see the\nuntracked file (that should be tracked) in the \"git status\" output when\nyou edit the commit message², then you abort-add-commit or\ncommit-add-amend and everything is fine.\n\nOr:\n\n- you have a lot of untracked files (like me). You won't see the\nuntracked file (that should be tracked) in the \"git status\" output (you\nignore it because the list is so long) and you won't see it in the \"git\nadd -p\" run because you quit before seeing that file.\n\nSo I have mixed feelings...\n\n> I'd also probably add interactive.showUntracked to make the whole thing\n> optional (but I think it would be OK to default it to on).\nHm, \"interactive.showUntracked\" is a confusing name because \"git add -i\"\n(interactive) already handles untracked files.\n\nBest\n  Stephan\n\n¹ I do not have that problem any more because I got used to add new\nfiles right after saving, in a very early state, and then I simply use\n\"git add -p\"...\n\n² Unless you use git commit -m ... But using \"git commit -m\" without\n\"git status\" before is user-issue anyway.\n\n"},{"id":"307639","messageId":"20161213173341.wemlunlixdp6277h@sigill.intra.peff.net","threadId":"44635","inReplyTo":"dc698b79-6311-a2a3-c564-a43ef071e62b@gmx.net","subject":"Re: git add -p with new file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T17:33:41Z","receivedAt":"2016-12-13T17:35:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 12, 2016 at 09:31:03PM +0100, Stephan Beyer wrote:\n\n> I am also a \"git add -p\"-only user (except for new files and merges).\n> However, I usually keep a lot of untracked files in my repositories.\n> Files that I do not (git)ignore because I want to see them when I type\n> \"git status\".\n> \n> Hence, the imagination only that \"git add -p\" starts to ask me for each\n> untracked file feels like a lot of annoying \"n\" presses. I could imagine\n> that it is okay-ish when it asks about the untracked files *after* all\n> tracked paths have been processed (I guess this has been proposed\n> before), so that I can safely quit.\n\nYeah, this is the \"some people might be annoyed\" that I mentioned\noriginally. If your workflow leaves a lot of untracked files that you\ndon't care about it, then I think you'd want this feature disabled\nentirely via a config option (or vice versa, that it would only be\nenabled by config option).\n\n> I am also not really sure what problem this feature is trying to solve.\n> If the \"problem\"(?) is that it should act more like \"git add\" instead of\n> \"git add -u\", for whatever reason, this may be fine (but the\n> configuration option is a must-have then).\n\nI think the problem is just that \"add -p\" does not give the whole story\nof what you might want to do before making a commit.\n\n> > I'd also probably add interactive.showUntracked to make the whole thing\n> > optional (but I think it would be OK to default it to on).\n> Hm, \"interactive.showUntracked\" is a confusing name because \"git add -i\"\n> (interactive) already handles untracked files.\n\nSure, that was just meant for illustration. I agree there's probably a\nbetter name.\n\n-Peff\n"},{"id":"307653","messageId":"xmqq7f734qe0.fsf@gitster.mtv.corp.google.com","threadId":"44635","inReplyTo":"20161213173341.wemlunlixdp6277h@sigill.intra.peff.net","subject":"Re: git add -p with new file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:48:07Z","receivedAt":"2016-12-13T18:48:15Z","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>> I am also not really sure what problem this feature is trying to solve.\n>> If the \"problem\"(?) is that it should act more like \"git add\" instead of\n>> \"git add -u\", for whatever reason, this may be fine (but the\n>> configuration option is a must-have then).\n>\n> I think the problem is just that \"add -p\" does not give the whole story\n> of what you might want to do before making a commit.\n\nThe same is shared by \"git diff [HEAD]\", by the way.  It is beyond\nme why people use \"add -p\", not \"git diff [HEAD]\", for the final\nsanity check before committing.  \n\nPerhaps the latter is not advertised well enough?  \"add -p\" does not\neven page so it is not very useful way to check what is being added\nif you are adding a new file (unless you are doing a toy example to\nadd a 7-line file).\n\n>> > I'd also probably add interactive.showUntracked to make the whole thing\n>> > optional (but I think it would be OK to default it to on).\n>> Hm, \"interactive.showUntracked\" is a confusing name because \"git add -i\"\n>> (interactive) already handles untracked files.\n>\n> Sure, that was just meant for illustration. I agree there's probably a\n> better name.\n\n\"interactive.*\" is not a sensible hierarchy to use, because things\nother than \"add\" can go interactive.\n\naddPatch.showUntracked?\n"},{"id":"307655","messageId":"20161213185653.ys3ig377zhmblncl@sigill.intra.peff.net","threadId":"44635","inReplyTo":"xmqq7f734qe0.fsf@gitster.mtv.corp.google.com","subject":"Re: git add -p with new file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T18:56:53Z","receivedAt":"2016-12-13T18:57:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 10:48:07AM -0800, Junio C Hamano wrote:\n\n> > I think the problem is just that \"add -p\" does not give the whole story\n> > of what you might want to do before making a commit.\n> \n> The same is shared by \"git diff [HEAD]\", by the way.  It is beyond\n> me why people use \"add -p\", not \"git diff [HEAD]\", for the final\n> sanity check before committing.  \n> \n> Perhaps the latter is not advertised well enough?  \"add -p\" does not\n> even page so it is not very useful way to check what is being added\n> if you are adding a new file (unless you are doing a toy example to\n> add a 7-line file).\n\nI use \"add -p\" routinely for my final add-and-sanity-check, and it is\ncertainly not because I don't know about \"git diff\". I think it's just\nnice to break it into bite-size chunks and sort them into \"yes, OK\" or\n\"no, not yet\" bins. The lack of paging isn't usually a problem, because\nthis \"add -p\" is useful precisely when you have a lot of little changes\nspread across the code base.\n\nI'd probably also run \"git diff\" if I wanted to look at something\nbigger. And I routinely use \"git status\", too, to see the full state of\nmy tree.\n\nTo me they are all tools in the toolbox, and I can pick the one that\nworks best in any given situation, or that I just feel like using that\nday.\n\n> >> Hm, \"interactive.showUntracked\" is a confusing name because \"git add -i\"\n> >> (interactive) already handles untracked files.\n> >\n> > Sure, that was just meant for illustration. I agree there's probably a\n> > better name.\n> \n> \"interactive.*\" is not a sensible hierarchy to use, because things\n> other than \"add\" can go interactive.\n> \n> addPatch.showUntracked?\n\nHmm, I wonder if interactive.diffFilter was mis-named then. The\ndescription is written in such a way as to cover other possible\ninteractive commands showing a diff.\n\nIt might be possible to do the same here: come up with a general option\nthat _could_ cover new situations, but right now just applies here. Or\nmaybe it would be too confusing.\n\nTBH, I wasn't all that concerned with the name yet. Whoever writes the\npatch can figure it out, and _then_ we can all bikeshed it. :)\n\n-Peff\n"},{"id":"307661","messageId":"xmqqpokv3aor.fsf@gitster.mtv.corp.google.com","threadId":"44635","inReplyTo":"20161213185653.ys3ig377zhmblncl@sigill.intra.peff.net","subject":"Re: git add -p with new file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T19:12:36Z","receivedAt":"2016-12-13T19:12:45Z","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>> Perhaps the latter is not advertised well enough?  \"add -p\" does not\n>> even page so it is not very useful way to check what is being added\n>> if you are adding a new file (unless you are doing a toy example to\n>> add a 7-line file).\n>\n> I use \"add -p\" routinely for my final add-and-sanity-check,...\n> ... To me they are all tools in the toolbox, and I can pick the one that\n> works best in any given situation, or that I just feel like using that\n> day.\n\nOh, there is no question about that.  I was just pointing out that\n\"add -p\" is not the \"one that works best\" when dealing with a path\nthat is not yet even in the index.\n"},{"id":"307666","messageId":"98817141-fa57-7687-09c4-dc96419d8a35@gmx.net","threadId":"44635","inReplyTo":"alpine.DEB.2.11.1612062012540.13185@cherryberry.dsgml.com","subject":"git add -p with unmerged files (was: git add -p with new file)","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2016-12-13T19:21:59Z","receivedAt":"2016-12-13T19:33:45Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nWhile we're on the topic that \"git add -p\" should behave like the\n\"normal\" \"git add\" (not \"git add -u\"): what about unmerged changes?\n\nWhen I have merge conflicts, I almost always use my aliases\n\"edit-unmerged\" and \"add-unmerged\":\n\n$ git config --global --list | grep unmerged\nalias.list-unmerged=diff --name-only --diff-filter=U\nalias.edit-unmerged=!vim `git list-unmerged`\nalias.add-unmerged=!git add `git list-unmerged`\nalias.reset-unmerged=!uf=`git list-unmerged`; git reset HEAD $uf; git\ncheckout -- $uf\n\nThe \"add-unmerged\" alias is always a little scary because I'd rather\nlike to check the changes with the \"git add -p\" workflow I am used to.\n\nOpinions?\n\nBest\n  Stephan\n"},{"id":"307671","messageId":"20161213194859.eoztbojnp4veaozc@sigill.intra.peff.net","threadId":"44635","inReplyTo":"98817141-fa57-7687-09c4-dc96419d8a35@gmx.net","subject":"Re: git add -p with unmerged files (was: git add -p with new file)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T19:49:00Z","receivedAt":"2016-12-13T19:51:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 08:21:59PM +0100, Stephan Beyer wrote:\n\n> While we're on the topic that \"git add -p\" should behave like the\n> \"normal\" \"git add\" (not \"git add -u\"): what about unmerged changes?\n\nI agree that's a related part of the workflow, though the implementation\nis a bit harder.\n\n> When I have merge conflicts, I almost always use my aliases\n> \"edit-unmerged\" and \"add-unmerged\":\n> \n> $ git config --global --list | grep unmerged\n> alias.list-unmerged=diff --name-only --diff-filter=U\n> alias.edit-unmerged=!vim `git list-unmerged`\n\nYou might like contrib/git-jump for that, which makes it easier to go to\nthe specific spots within files.\n\nWhen \"git jump merge\" produces no hits, I know I've dealt with all of\nthe conflicts (textual ones, anyway). I do often want to run \"git add\n-p\" then to review the changes before staging.\n\nI think what is most helpful there is probably \"git diff HEAD\" to see\nwhat the merge is bringing in (or the cherry-pick, or \"am\", or\nwhatever). If I wanted \"add -p\" to do anything, I think it would be to\nact as if stage 2 (\"ours\", which should be the same as what is in HEAD)\nwas already in the index. I.e., show the diff against that, apply any\nhunks we select, and store the whole thing as stage 0, losing the\nunmerged bit.\n\nWhen you select all hunks, this is equivalent to \"git add unmerge-file\".\nIf you choose only a subset of hunks, it leaves the unselected ones for\nyou to examine later via \"git diff\". And if you choose none, it should\nprobably leave unmerged.\n\nThat's just a scheme I thought up, though. I've never actually tried it\nin practice.\n\n-Peff\n"},{"id":"307673","messageId":"xmqqwpf31tya.fsf@gitster.mtv.corp.google.com","threadId":"44635","inReplyTo":"98817141-fa57-7687-09c4-dc96419d8a35@gmx.net","subject":"Re: git add -p with unmerged files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T19:59:25Z","receivedAt":"2016-12-13T19:59:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer <s-beyer@gmx.net> writes:\n\n> While we're on the topic that \"git add -p\" should behave like the\n> \"normal\" \"git add\" (not \"git add -u\"): what about unmerged changes?\n>\n>\n> When I have merge conflicts, I almost always use my aliases\n> \"edit-unmerged\" and \"add-unmerged\":\n>\n> $ git config --global --list | grep unmerged\n> alias.list-unmerged=diff --name-only --diff-filter=U\n> alias.edit-unmerged=!vim `git list-unmerged`\n> alias.add-unmerged=!git add `git list-unmerged`\n> alias.reset-unmerged=!uf=`git list-unmerged`; git reset HEAD $uf; git\n> checkout -- $uf\n>\n> The \"add-unmerged\" alias is always a little scary because I'd rather\n> like to check the changes with the \"git add -p\" workflow I am used to.\n>\n> Opinions?\n\nFor this, you would NEVER want to use \"add -p\" to pick and choose.\nBy definition, while you are in conflicted merge, the path that had\nconflicts before you started the merge-y operation (be it \"pull\",\n\"am -3\", or \"cherry-pick\") did not have any change since HEAD, and\n\"pick this hunk, drop that hunk\" cannot be correct for the conflict\nresolution.\n\n\"git diff\" while conflicted will highlight what conflicted by\nshowing the three-way diff (similar to \"diff --cc\" on a merge\nresult) and after conflict is resolved you can view \"diff HEAD\"\non the path to see what the merge brought in.\n"}]}