{"thread":{"id":"16383","subject":"Git commit won't add an untracked file given on the command line","startedAt":"2008-11-18T21:12:37Z","lastAt":"2008-11-20T10:18:46Z","messageCount":22,"participants":["Mark Burton","Francis Galiegue","Matthieu Moy","Johannes Schindelin","Miles Bader","Junio C Hamano","Daniel Barkalow","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96098","messageId":"20081118211237.234d8035@crow","threadId":"16383","inReplyTo":null,"subject":"Git commit won't add an untracked file given on the command line","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-11-18T21:12:37Z","receivedAt":"2008-11-18T21:12:37Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\nWhen I try: \n\ngit commit -m \"New file.\" .gitignore\n\nWhere .gitignore is not yet tracked, I get: \n\nerror: pathspec '.gitignore' did not match any file(s) known to git.\n\nIs that result by design, sloth or bug (or me being stupid)?\n\nThanks,\n\nMark\n"},{"id":"96100","messageId":"200811182227.20076.fge@one2team.com","threadId":"16383","inReplyTo":"20081118211237.234d8035@crow","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Francis Galiegue","fromEmail":"fge@one2team.com","sentAt":"2008-11-18T21:27:19Z","receivedAt":"2008-11-18T21:27:19Z","isPatch":false,"sender":{"key":"fge@one2team.com","avatar":null},"body":"Le Tuesday 18 November 2008 22:12:37 Mark Burton, vous avez écrit :\n> Hi,\n>\n> When I try:\n>\n> git commit -m \"New file.\" .gitignore\n>\n> Where .gitignore is not yet tracked, I get:\n>\n> error: pathspec '.gitignore' did not match any file(s) known to git.\n>\n> Is that result by design, sloth or bug (or me being stupid)?\n>\n\nYou must \"git add .gitignore\" first. And yes, this is by design.\n\nYou could also have done git commit -a -m \"themessage\".\n\n-- \nFrancis Galiegue\nONE2TEAM\nIngénieur système\nMob : +33 (0) 6 83 87 78 75\nTel : +33 (0) 1 78 94 55 52\nfge@one2team.com\n40 avenue Raymond Poincaré\n75116 Paris\n"},{"id":"96101","messageId":"20081118214730.005fc72d@crow","threadId":"16383","inReplyTo":"200811182227.20076.fge@one2team.com","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-11-18T21:47:30Z","receivedAt":"2008-11-18T21:47:30Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi Francis,\n\n> You must \"git add .gitignore\" first. And yes, this is by design.\n\nErr, that's a bit odd isn't it because \"git add\" stages the content into\nthe index but the whole point of specifying files on the command line\nto \"git commit\" is to commit the changes in the specified files while\nignoring what's currently in the index (so says the man page for commit).\n\nCheers,\n\nMark\n"},{"id":"96102","messageId":"vpq8wrg7k9k.fsf@bauges.imag.fr","threadId":"16383","inReplyTo":"200811182227.20076.fge@one2team.com","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-11-18T22:16:07Z","receivedAt":"2008-11-18T22:16:07Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Francis Galiegue writes:\n\n> Le Tuesday 18 November 2008 22:12:37 Mark Burton, vous avez écrit :\n>> Hi,\n>>\n>> When I try:\n>>\n>> git commit -m \"New file.\" .gitignore\n>>\n>> Where .gitignore is not yet tracked, I get:\n>>\n>> error: pathspec '.gitignore' did not match any file(s) known to git.\n>>\n>> Is that result by design, sloth or bug (or me being stupid)?\n>>\n>\n> You must \"git add .gitignore\" first. And yes, this is by design.\n\nIf it's by design, then it's a documentation bug:\n\n -o, --only\n Make a commit only from the paths specified on the\n command line, disregarding any contents that have been\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n staged so far. This is the default mode of operation of\n ^^^^^^^^^^^^^\n git-commit if any paths are given on the command line,\n\nWe have here a case where having staged content before doing commit -o\nactually changes its behavior.\n\nLooking at the code, this happens because the \"file\" list is actually\na pattern list (so that you can \"git commit '*.txt'\" or so), and the\npattern is looked for in the index (the error is raised in\n\"list_paths\").\n\n> You could also have done git commit -a -m \"themessage\".\n\nWell, he could have done that, but then the result would have been\ndifferent ;-).\n\n-- \nMatthieu\n"},{"id":"96108","messageId":"alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de","threadId":"16383","inReplyTo":"20081118214730.005fc72d@crow","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-19T01:07:41Z","receivedAt":"2008-11-19T01:07:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Nov 2008, Mark Burton wrote:\n\n> Hi Francis,\n> \n> > You must \"git add .gitignore\" first. And yes, this is by design.\n> \n> Err, that's a bit odd isn't it because \"git add\" stages the content into \n> the index but the whole point of specifying files on the command line to \n> \"git commit\" is to commit the changes in the specified files while \n> ignoring what's currently in the index (so says the man page for \n> commit).\n\nIt may be a traditional wart, but a helpful one. Remember, you can also \nsay:\n\n\tgit commit that/directory/\n\nI do _not_ want Git to add all untracked (and unignored) files in that \ndirectory automatically.\n\nCiao,\nDscho\n"},{"id":"96114","messageId":"87tza41pf4.fsf@catnip.gol.com","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-19T01:21:19Z","receivedAt":"2008-11-19T01:21:19Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n> It may be a traditional wart, but a helpful one. Remember, you can also \n> say:\n>\n> \tgit commit that/directory/\n>\n> I do _not_ want Git to add all untracked (and unignored) files in that \n> directory automatically.\n\nI agree, but it would kinda handy to have an exception for files\nexplicitly named on the command line.\n\n-Miles\n\n-- \nApologize, v. To lay the foundation for a future offense.\n"},{"id":"96112","messageId":"alpine.DEB.1.00.0811190238360.30769@pacific.mpi-cbg.de","threadId":"16383","inReplyTo":"87tza41pf4.fsf@catnip.gol.com","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-19T01:39:27Z","receivedAt":"2008-11-19T01:39:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Nov 2008, Miles Bader wrote:\n\n> Johannes Schindelin writes:\n> > It may be a traditional wart, but a helpful one. Remember, you can \n> > also say:\n> >\n> > \tgit commit that/directory/\n> >\n> > I do _not_ want Git to add all untracked (and unignored) files in that \n> > directory automatically.\n> \n> I agree, but it would kinda handy to have an exception for files \n> explicitly named on the command line.\n\nOnly if you do not have a clear picture of what the staging area is about, \nIMHO.\n\nCiao,\nDscho\n"},{"id":"96116","messageId":"7vtza4trdp.fsf@gitster.siamese.dyndns.org","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-19T01:51:30Z","receivedAt":"2008-11-19T01:51:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> It may be a traditional wart, but a helpful one. Remember, you can also \n> say:\n>\n> \tgit commit that/directory/\n>\n> I do _not_ want Git to add all untracked (and unignored) files in that \n> directory automatically.\n\nYes, very much so.\n\nAlthough it is conceivable that we may want to change that to behave more\nlike \"git add that/directory && git commit that/directory\", that is a\nrather large UI semantics change (even if it could be a useful one) that\nneeds to wait for a major version bump, perhaps in 1.7.0.\n\nI think Mark's update to the documentation is a good thing to have in any\ncase, so I've applied it.\n"},{"id":"96124","messageId":"buomyfwmldj.fsf@dhapc248.dev.necel.com","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811190238360.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-19T03:43:04Z","receivedAt":"2008-11-19T03:43:04Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n>> I agree, but it would kinda handy to have an exception for files \n>> explicitly named on the command line.\n>\n> Only if you do not have a clear picture of what the staging area is about, \n> IMHO.\n\nThat's such a vague statement, I've not sure how to take it.\n\nI use the staging area a lot, so I think I have a pretty clear idea of what\nit's \"about\", but I also often use \"commit FILE\" or \"commit -a\" for simple\ncases; even when splitting a change into multiple commits, it's often more\nconvenient to do \"commit FILE...\" instead of \"add FILE; commit\".\n\nI agree that having \"commit DIR\" add new files would likely be more\nannoying than helpful (it's not uncommon to have some temporary files\nlaying around), but given that \"commit FILE\" is _explicitly_ naming the new\nfile, it seems hard to imagine somebody would be surprised if it worked\neven when FILE was a new file...\n\n-Miles\n\n-- \n=====\n(^o^;\n(()))\n*This is the cute octopus virus, please copy it into your sig so it can spread.\n"},{"id":"96130","messageId":"alpine.DEB.1.00.0811191036340.30769@pacific.mpi-cbg.de","threadId":"16383","inReplyTo":"buomyfwmldj.fsf@dhapc248.dev.necel.com","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-19T09:41:44Z","receivedAt":"2008-11-19T09:41:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Nov 2008, Miles Bader wrote:\n\n> Johannes Schindelin writes:\n> >> I agree, but it would kinda handy to have an exception for files \n> >> explicitly named on the command line.\n> >\n> > Only if you do not have a clear picture of what the staging area is \n> > about, IMHO.\n> \n> That's such a vague statement, I've not sure how to take it.\n> \n> I use the staging area a lot, so I think I have a pretty clear idea of \n> what it's \"about\", but I also often use \"commit FILE\" or \"commit -a\" for \n> simple cases; even when splitting a change into multiple commits, it's \n> often more convenient to do \"commit FILE...\" instead of \"add FILE; \n> commit\".\n\nWhat I meant was this: the \"commit \" paradigm is not what you should \ndo most of the time. In order to work with the staging area efficiently, \nyou should make staging and committing two separate steps.\n\nI regularly encounter people who never call \"git diff --cached\" before \ncommitting, and guess who introduces all kinds of debug statements and \nother cruft into their commits? Exactly.\n\nSo my point is this: stage first, verify, then commit. That saves you a \nlot of embarrassment.\n\nCiao,\nDscho\n"},{"id":"96133","messageId":"20081119095452.3018d2de@crow","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811190206170.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-11-19T09:54:52Z","receivedAt":"2008-11-19T09:54:52Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\n> It may be a traditional wart, but a helpful one. Remember, you can also \n> say:\n> \n> \tgit commit that/directory/\n> \n> I do _not_ want Git to add all untracked (and unignored) files in that \n> directory automatically.\n\nYes, I can see the wisdom in not automatically adding the contents of a\ndirectory specified on the command line. So that's probably the answer\nto my original question.\n\nAs for \"knowing what the staging area is about\", I use the staging\narea almost all the time as I consider it one of git's major\nimprovements over \"traditional\" SCM systems. I especially like how I\ncan use tools like git gui to browse and select the changes to be\nstaged for the next commit.\n\nHaving said that, I still like the concept of being able to add named\nfiles without touching the index.\n\nFeature request for the git gui people:\n\n It would be nice if git gui was able to stage a highlighted region\n rather than either the whole hunk or just the line under the cursor\n as I believe it behaves now. I might be wrong but I don't think it\n can do that at the moment. I think that would be useful because\n although it's a step forward to be able to stage individual lines in\n a hunk, it can be laborious if you want to pick out more than just a\n couple of lines.\n\nCheers,\n\nMark\n"},{"id":"96137","messageId":"alpine.DEB.1.00.0811191226530.30769@pacific.mpi-cbg.de","threadId":"16383","inReplyTo":"20081119095452.3018d2de@crow","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-19T11:27:45Z","receivedAt":"2008-11-19T11:27:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 19 Nov 2008, Mark Burton wrote:\n\n> Having said that, I still like the concept of being able to add named \n> files without touching the index.\n\nThat's just impossible. You cannot create a tree object, let alone a \ncommit object, without touching the index (AKA staging area).\n\nCiao,\nDscho\n"},{"id":"96152","messageId":"7vd4grsveo.fsf@gitster.siamese.dyndns.org","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811191226530.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-19T13:22:07Z","receivedAt":"2008-11-19T13:22:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 19 Nov 2008, Mark Burton wrote:\n>\n>> Having said that, I still like the concept of being able to add named \n>> files without touching the index.\n>\n> That's just impossible. You cannot create a tree object, let alone a \n> commit object, without touching the index (AKA staging area).\n\nI do not think Mark really _means_ \"not in the index\".\n\nThe wish is more like \"I want to let git know that I am interested in this\npath, but I'm not ready to say what exact content I want for that path in\nthe next commit, not just yet\".\n\nI do not think that is an unreasonable wish. On the other hand, it is\nunreasonable for anybody to insist that we satisfy the wish without\ntouching the index. The index is the most natural place to do that.\n\nWe have a half (probably a quarter) of what we need for that implemented\nalready, by the way.\n"},{"id":"96160","messageId":"20081119144139.602f3334@crow","threadId":"16383","inReplyTo":"7vd4grsveo.fsf@gitster.siamese.dyndns.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-11-19T14:41:39Z","receivedAt":"2008-11-19T14:41:39Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\n> > That's just impossible. You cannot create a tree object, let alone a \n> > commit object, without touching the index (AKA staging area).\n> \n> I do not think Mark really _means_ \"not in the index\".\n> \n> The wish is more like \"I want to let git know that I am interested in this\n> path, but I'm not ready to say what exact content I want for that path in\n> the next commit, not just yet\".\n> \n> I do not think that is an unreasonable wish. On the other hand, it is\n> unreasonable for anybody to insist that we satisfy the wish without\n> touching the index. The index is the most natural place to do that.\n> \n> We have a half (probably a quarter) of what we need for that implemented\n> already, by the way.\n\nSorry, poor choice of words on my part - you have to remember my\nviewpoint is one of user more than developer.\n\nMy wish was really just based on the advertised behaviour that\nspecifying a file on the command line would commit the contents of that\nfile while leaving the index intact. Whether the index was temporarily\nused/altered during the execution of the commit didn't cross my mind.\n\nHey, it's not a big deal and with the accepted patch to the\ndocumentation it need not take any more of anyone's time.\n\nCheers,\n\nMark\n"},{"id":"96174","messageId":"alpine.LNX.1.00.0811191247560.19665@iabervon.org","threadId":"16383","inReplyTo":"7vd4grsveo.fsf@gitster.siamese.dyndns.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-19T18:01:04Z","receivedAt":"2008-11-19T18:01:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 19 Nov 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Wed, 19 Nov 2008, Mark Burton wrote:\n> >\n> >> Having said that, I still like the concept of being able to add named \n> >> files without touching the index.\n> >\n> > That's just impossible. You cannot create a tree object, let alone a \n> > commit object, without touching the index (AKA staging area).\n> \n> I do not think Mark really _means_ \"not in the index\".\n> \n> The wish is more like \"I want to let git know that I am interested in this\n> path, but I'm not ready to say what exact content I want for that path in\n> the next commit, not just yet\".\n> \n> I do not think that is an unreasonable wish. On the other hand, it is\n> unreasonable for anybody to insist that we satisfy the wish without\n> touching the index. The index is the most natural place to do that.\n\nI don't think that's what Mark wants, in this case. He's looking for the \nability to have \"git commit\" act on a temporary index created by adding to \nthe parent commit explicitly named files which aren't in the non-temporary \nindex. That is, Mark doesn't want to touch *the* index, which is fine; git \ncan commit with *an* index.\n\n> We have a half (probably a quarter) of what we need for that implemented\n> already, by the way.\n\nI've looked into what you're suggesting on occasion; the main issue is \ngetting the various index users to avoid getting confused. I was stumped \nby the diff code, which was confusing the \"intent to add something\" token \nwith its \"compare against the work tree\" token. I'd say, it's half \nimplemented, but testing is a major unstarted undertaking.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"96193","messageId":"7v7i6zs4ay.fsf@gitster.siamese.dyndns.org","threadId":"16383","inReplyTo":"alpine.LNX.1.00.0811191247560.19665@iabervon.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-19T23:07:33Z","receivedAt":"2008-11-19T23:07:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> I don't think that's what Mark wants, in this case. He's looking for the \n> ability to have \"git commit\" act on a temporary index created by adding to \n> the parent commit explicitly named files which aren't in the non-temporary \n> index.\n\nAh, I think that it would not be an entirely unreasonable thing to do\n(cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).\n\nYou can say \"git add that/directory\" and .gitignore mechanism protects you\nfrom crufts in that/directory, so fearing \"git commit that/directory\" to\nadd random junk to the next commit is not a reason to fear it.\n\nBut that is a huge behaviour change. For example, I have a handful test\nscripts in my t/ directory (all named following the usual t????-*.sh\nnaming convention) that I do not want to commit. Today, after making\nchanges to the tracked test scripts, I can rely on \"git commit t/\" not to\ninclude them in the commit, and I've _learned_ to trust that behaviour.\nI'd be surprised if others who have used git for more than a few months\nhaven't done so as well.\n\nAllowing what Mark wants without any explicit user customization will be a\ndisaster to the end user experience.\n"},{"id":"96194","messageId":"20081119233027.17687dd5@crow","threadId":"16383","inReplyTo":"7v7i6zs4ay.fsf@gitster.siamese.dyndns.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Mark Burton","fromEmail":"markb@ordern.com","sentAt":"2008-11-19T23:30:27Z","receivedAt":"2008-11-19T23:30:27Z","isPatch":false,"sender":{"key":"markb@ordern.com","avatar":null},"body":"\nHi,\n\n> Allowing what Mark wants without any explicit user customization will be a\n> disaster to the end user experience.\n\nIf the ability to commit a currently untracked file/tree whilst\npreserving the index is really worth having (and that's debatable, as\nthe git user community has survived until now without that capability)\nthen another option (say, -O) could be added to git-commit that does\nwhat -o does but allows untracked files/trees to be specified - that\nway, the current behaviour would remain unchanged and the above\nmentioned disaster averted.\n\nCheers,\n\nMark\n"},{"id":"96195","messageId":"7v1vx7s2a9.fsf@gitster.siamese.dyndns.org","threadId":"16383","inReplyTo":"20081119233027.17687dd5@crow","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-19T23:51:10Z","receivedAt":"2008-11-19T23:51:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Burton writes:\n\n>> Allowing what Mark wants without any explicit user customization will be a\n>> disaster to the end user experience.\n>\n> If the ability to commit a currently untracked file/tree whilst\n> preserving the index is really worth having (and that's debatable, as\n> the git user community has survived until now without that capability)\n> then another option (say, -O) could be added to git-commit that does\n> what -o does but allows untracked files/trees to be specified - that\n> way, the current behaviour would remain unchanged and the above\n> mentioned disaster averted.\n\nHeh, I apparently failed to convey what I wanted to say with \"without any\nexplicit user customization\" part of my message. IOW, I think you are\nsaying the same thing as what I wanted to say from the opposite angle.\n"},{"id":"96196","messageId":"alpine.LNX.1.00.0811191809430.19665@iabervon.org","threadId":"16383","inReplyTo":"7v7i6zs4ay.fsf@gitster.siamese.dyndns.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-19T23:52:36Z","receivedAt":"2008-11-19T23:52:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 19 Nov 2008, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > I don't think that's what Mark wants, in this case. He's looking for the \n> > ability to have \"git commit\" act on a temporary index created by adding to \n> > the parent commit explicitly named files which aren't in the non-temporary \n> > index.\n> \n> Ah, I think that it would not be an entirely unreasonable thing to do\n> (cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).\n> \n> You can say \"git add that/directory\" and .gitignore mechanism protects you\n> from crufts in that/directory, so fearing \"git commit that/directory\" to\n> add random junk to the next commit is not a reason to fear it.\n> \n> But that is a huge behaviour change. For example, I have a handful test\n> scripts in my t/ directory (all named following the usual t????-*.sh\n> naming convention) that I do not want to commit. Today, after making\n> changes to the tracked test scripts, I can rely on \"git commit t/\" not to\n> include them in the commit, and I've _learned_ to trust that behaviour.\n> I'd be surprised if others who have used git for more than a few months\n> haven't done so as well.\n> \n> Allowing what Mark wants without any explicit user customization will be a\n> disaster to the end user experience.\n\nThere are two possible limits that would preserve your case while handling \nMark's case: one is to only look at untracked files at all for names that \ndon't match any tracked files, and the other (independantly) is to treat \nnames as single filenames instead of patterns for untracked files.\n\nEither of these (or both) should keep the existing behavior for using a \npattern on the command line as a filter for which of the tracked files to \ncommit (since any pattern of tracked files won't be the name of an \nindividual untracked file).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"96197","messageId":"7vwsezqlm0.fsf@gitster.siamese.dyndns.org","threadId":"16383","inReplyTo":"alpine.LNX.1.00.0811191809430.19665@iabervon.org","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-20T00:36:39Z","receivedAt":"2008-11-20T00:36:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> There are two possible limits that would preserve your case while handling \n> Mark's case: one is to only look at untracked files at all for names that \n> don't match any tracked files, and the other (independantly) is to treat \n> names as single filenames instead of patterns for untracked files.\n>\n> Either of these (or both) should keep the existing behavior for using a \n> pattern on the command line as a filter for which of the tracked files to \n> commit (since any pattern of tracked files won't be the name of an \n> individual untracked file).\n\nPerhaps. I am starting to think that \"Did you forget to 'git add'?\" is\nactually the best behaviour we can have ;-)\n"},{"id":"96199","messageId":"buowsez56kv.fsf@dhapc248.dev.necel.com","threadId":"16383","inReplyTo":"alpine.DEB.1.00.0811191036340.30769@pacific.mpi-cbg.de","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2008-11-20T05:06:56Z","receivedAt":"2008-11-20T05:06:56Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n>> I use the staging area a lot, so I think I have a pretty clear idea of \n>> what it's \"about\", but I also often use \"commit FILE\" or \"commit -a\" for \n>> simple cases; even when splitting a change into multiple commits, it's \n>> often more convenient to do \"commit FILE...\" instead of \"add FILE; \n>> commit\".\n>\n> What I meant was this: the \"commit \" paradigm is not what you should \n> do most of the time. In order to work with the staging area efficiently, \n> you should make staging and committing two separate steps.\n>\n> So my point is this: stage first, verify, then commit. That saves you a \n> lot of embarrassment.\n\nYou seem to be saying that you think that using staging area explicitly\nis necessary or somehow \"more efficient\" for making good commits, but on\nthe face of it, that's simply not true.\n\nI'm extremely careful about committing clean changes, and do a lot of\ntesting and pre-commit diffing. For complex changes which need to be\nsplit, the staging area is indeed a very useful tool, and I'm very glad\ngit has it -- but it's hardly necessary for _all_ commits, and my\nexperience is that in practice, many commits are indeed the simple sort\nwhich for which it's superfluous. My goal is not to \"work with the\nstaging area efficiently\", it's to \"make good/clean/tested commits,\nefficiently\".\n\nObviously this depends on work style, and subject matter. Sometimes one\n_needs_ to make biggish changes and split them for commiting, and some\npeople like to use that work style even when it's not strictly\nnecessary. Other times, changes are more obviously independent, and can\nbe done, tested, and commited in a serial fashion without any splitting.\n\nPerhaps, given your work style or the type of work you, you use the\nstaging area 99% of the time. For your case, maybe any git features\nwhich bypass the staging area are simply unneeded complexity. However,\nmy own experience suggests that this is not universally true. I'd say I\nuse the staging area for maybe 50% of commits.\n\nOne of the nice thing about git is the way that it tries to cater to\nmultiple work styles, so it seems wrong to reject a useful feature\nsimply because you want to \"encourage\" people to use your preferred work\nstyle, when that work style is not obviously better. [Of course there\ncan be other good reasons to reject this feature -- maybe it's too\ndangerous or mucks up the code.]\n\n> I regularly encounter people who never call \"git diff --cached\" before \n> committing, and guess who introduces all kinds of debug statements and \n> other cruft into their commits? Exactly.\n\n[I'm not sure what the point of that was... for the record, no I'm not\none of \"those people\". When I use the staging area, I use \"git diff\n--cached\"; when I don't use the staging area, I \"git diff\" instead...]\n\n-Miles\n\n-- \nBacchus, n. A convenient deity invented by the ancients as an excuse for\ngetting drunk.\n"},{"id":"96212","messageId":"20081120101845.GA3291@gmail.com","threadId":"16383","inReplyTo":"20081119095452.3018d2de@crow","subject":"Re: Git commit won't add an untracked file given on the command line","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2008-11-20T10:18:46Z","receivedAt":"2008-11-20T10:18:46Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On 0, Mark Burton wrote:\n> \n> Hi,\n> \n> Feature request for the git gui people:\n> \n> It would be nice if git gui was able to stage a highlighted region\n> rather than either the whole hunk or just the line under the cursor\n> as I believe it behaves now. I might be wrong but I don't think it\n> can do that at the moment. I think that would be useful because\n> although it's a step forward to be able to stage individual lines in\n> a hunk, it can be laborious if you want to pick out more than just a\n> couple of lines.\n> \n> Cheers,\n> \n> Mark\n\n\ngit-cola can do that.\nhttp://cola.tuxfamily.org/\n\n\n-- \n\n\tDavid\n"}]}