What's the use case for committing both the freshly created file and it's exclusion in .gitignore?

What's the use case for committing both the freshly created file and it's exclusion in .gitignore?

[Bartosz Konikiewicz]

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.

Re: What's the use case for committing both the freshly created file and it's exclusion in .gitignore?

[Jeff King]

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?

[Jonathan Nieder]

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?

[Bartosz Konikiewicz]

On 9 August 2018 at 21:58, Jeff King <peff@peff.net> 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 <jrnieder@gmail.com> 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: patch        6: 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: patch        6: 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?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]