Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote: > Hi there! > > I hope that the subject of my message (i.e. the question) is > exhaustive enough, so I'll just stick to reproducing my issue. > > Steps to reproduce: > > 1. Create a new file. > 2. Stage the file. > 3. Add the file to .gitignore. > 4. Stage the .gitignore. > 5. Commit changes. > > I imagined that the file would now be removed from the stage (because > it's ignored now and not yet committed) but it isn't. Where this > behavior would be desirable? I know that a 'git add' command can be > invoked with an '-f' flag, which would yield the same result, but I > can't come up with an explanation where can it be applied. As far as I know, that is not an intentionally supported workflow. It is merely the result that .gitignore is only considered when adding new files to the index, not when committing nor when updating the entry for an existing file. If you are asking as a more general case: why do we not complain about .gitignore for files the index already knows about, then I think that is useful. It lets you override the .gitignore _once_ when adding the file initially, and then you don't have to deal with it again (and keep in mind that the pattern excluding it may be broad, like "*.o", or even just "*", so simply deleting it from the .gitignore is not an option). You could probably accomplish this these days by using a negative pattern in your .gitignore file. But I think the behavior in question may predate negative patterns (but I didn't dig). It's also a bit simpler to use in practice, IMHO. -Peff
Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?
Hi, Jeff King wrote: > Bartosz Konikiewicz wrote: >> Steps to reproduce: >> >> 1. Create a new file. >> 2. Stage the file. >> 3. Add the file to .gitignore. >> 4. Stage the .gitignore. >> 5. Commit changes. [...] > As far as I know, that is not an intentionally supported workflow. It is > merely the result that .gitignore is only considered when adding new > files to the index, not when committing nor when updating the entry for > an existing file. I am not sure I agree with "not intentionally supported". It's a little closer to "logical consequence of some intentionally features", because: > If you are asking as a more general case: why do we not complain about > .gitignore for files the index already knows about, then I think that is > useful. It lets you override the .gitignore _once_ when adding the file > initially, and then you don't have to deal with it again (and keep in > mind that the pattern excluding it may be broad, like "*.o", or even > just "*", so simply deleting it from the .gitignore is not an option). This workflow is very common. > You could probably accomplish this these days by using a negative > pattern in your .gitignore file. But I think the behavior in question > may predate negative patterns (but I didn't dig). It's also a bit > simpler to use in practice, IMHO. Agreed about simpler, even though it's not part of any of my own habits. In retrospect, despite the precedent of cvsignore, calling the file .gitignore may not have been a great idea. Some other name that conveys .git-prevent-me-from-accidentally-adding-these-files would make the behavior less surprising to new users. "git help gitignore" has some notes about this. If you have ideas about moments in interactive use where we could print some messages to make the behavior less surprising, that would be very welcome. Thanks, Jonathan
Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?
On 9 August 2018 at 21:58, Jeff King wrote: > If you are asking as a more general case: why do we not complain about > .gitignore for files the index already knows about, then I think that is > useful. It lets you override the .gitignore _once_ when adding the file > initially, and then you don't have to deal with it again (and keep in > mind that the pattern excluding it may be broad, like "*.o", or even > just "*", so simply deleting it from the .gitignore is not an option). This totally makes sense to me. Thanks for your explaination! On 10 August 2018 at 03:12, Jonathan Nieder wrote: > "git help gitignore" has some notes about this. Thanks! I wasn't aware of this. For some peculiar reason it didn't strike me that the most appropriate place to look for .gitignore-related stuff is - lo and behold - .gitignore manual page. I was looking for clarification on 'git add' page, which I didn't find informative enough in that aspect. > If you have ideas > about moments in interactive use where we could print some messages to > make the behavior less surprising, that would be very welcome. Sure I do! I have came up with two ideas which I believe that can be combined: 1. >staged unstaged path > 1:unchanged+1/-0 .gitignore ! > 2:+0/-0 nothing excluded.txt > > ! Not ignoring yet untracked files. > > *** Commands *** > 1: status 2: update 3: revert 4: add untracked > 5: patch6: diff 7: quit 8: help > What now> Here I propose to add an exclamation mark next to a .gitignore file and reference it below. I am also thinking about marking files that .gitignore affects. I think that any special character would be appropriate. If I may only suggest, I wouldn't choose an asterisk (*) because it's already used when a '2: update' option is chosen. 2. >staged unstaged path > 1:unchanged+1/-0 .gitignore > 2:+0/-0 nothing excluded.txt > > *** Commands *** > 1: status 2: update 3: revert 4: add untracked > 5: patch6: diff 7: quit 8: help > What now> q > You are about to add new files that are excluded in .gitignore. Confirm y/n? > What now>y > Bye. Here I ask the user to confirm that he is about to stage yet untracked files. Then I cheer him up with Git built-in courtesy.
Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote: > Steps to reproduce: > > 1. Create a new file. > 2. Stage the file. > 3. Add the file to .gitignore. > 4. Stage the .gitignore. > 5. Commit changes. > > I imagined that the file would now be removed from the stage (because > it's ignored now and not yet committed) but it isn't. Where this > behavior would be desirable? I know that a 'git add' command can be > invoked with an '-f' flag, which would yield the same result, but I > can't come up with an explanation where can it be applied. Let me give you one. If you use pristine-tar to check in the contents of an upstream tarball, upstream may have included both a .gitignore file and one or more ignored files in their tarball (say, something autoconf generated). Both of those files will be required in order to reproduce the tarball, so git add -f or multiple stages of add will need to be used. If we unstaged the files from the index when the .gitignore was added, this workflow wouldn't be possible. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
