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.
What's the use case for committing both the freshly created file and it's exclusion in .gitignore?
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: Troubles with picking an editor during Git update
Git guidelines states that I should leave cc intact. I have altered it, as I wanted to reply to both of you. I hope that my approach can be considered acceptable. Johannes, I see the following line in the piece of code you quoted: EditorAvailable[GE_NotepadPlusPlus]:=RegQueryStringValue(HKEY_LOCAL_MACHINE,'SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\notepad++.exe','',NotepadPlusPlusPath); It mentions the following registry key, which was missing from my registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\notepad++.exe I reinstalled Notepad++ 6.6.9, which added the key and made the installer acknowledge that Notepad++ is installed on my system. Thanks for encouraging me to further investigate the issue. I have dig deeper into the file that you linked for me. As far as my comprehension goes, an EditorSelectionChanged procedure (line 1084) is responsible for toggling the "next" button. I noticed that it gets invoked in at least 2 situations: - when an user picks a text editor (an OnChange event, line 1119) - once the custom page for configuring the default Git editor is initialized (the InitializeWizard procedure, line 1199) My reasoning tells me that it would be applicable in the NextButtonClick procedure as well. I'd add the following piece of code to it: if (EditorPage<>NIL) and (CurPageID=EditorPage.ID) then begin EditorSelectionChanged(NIL); end; I'd also remove the line 1199, as I think the change that I proposed would render it redundant. Philip, I feel that composing a pull request is beyond me. I came to a conclusion that it would drain me of too much resources. Thanks for the suggestion, as it would be my first pull request ever. I didn't manage to achieve it, although I believe that I would be capable of doing this, which already fills me with utter joy. I am willing to post my report to Git for Windows issue tracker. Thanks for the suggestion!
Troubles with picking an editor during Git update
Hi there! I had an issue with Git installer for Windows while trying to update my instance of the software. My previous version was "git version 2.15.1.windows.2", while my operating system prompted me to upgrade to "2.17.0". The installer asked me to "choose the default editor for Git". One of these options was Notepad++ - my editor of choice. Vim was selected by default and I've picked Notepad++ from a drop-down list. As soon as I did it, a "next" button greyed out. When I moved back to the previous step and then forward to the editor choice, the "Notepad++" option was still highlighted, and the "next" button wasn't greyed out anymore - it was active and I was able to press it and continue installation. Steps to reproduce: 1. Have Notepad++ 6.6.9 installed on Windows 10 64-bit 10.0.17134 Build 17134. 2. Use an installer for version 2.17.0 to upgrade from version 2.15.1. 3. On an editor selection screen, choose Notepad++ instead of Vim. You should be unable to continue installation because of the "next" button being disabled. 4. Press "prev". 5. Press "next". Notepad++ should be still highlighted, and the "next" button should be active, allowing to continue installation. I find it to be a crafty trick to make me use Vim. I have considered it for a good moment.
