Make git-commit cleverer - have it figure out whether it needs -a automatically
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for.
Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include", so they turn this behaviour off as well.
---
I've been using this today, and so far it's been quite friendly. git-commit is suddenly just doing the Right Thing.
It's so good that the only (small) hurdle, is remembering during an amend that you need to update the index first to get any code changes in to the amend - but that is the same as it ever was.
git-commit.sh | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)
git-commit.sh +7 -0
@@ -265,6 +265,13 @@ $1" done case "$edit_flag" in t) no_edit= ;; esac +# Clever commit - if this commit would do nothing, then make it an "all" +# commit +if [ -z "$(git-diff-index --cached --name-only HEAD)" \ + -a -z "$amend" -a -z "$only" -a -z "$also" ]; then + all=t +fi + ################################################################ # Sanity check options
Signature · 1 line
1.4.4.1.g3ece-dirty
Quoted 7 lines · Andy Parkins
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Quoted 6 lines
Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for.
Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include", so they turn this behaviour off as well.
Could we add suggestion by Andreas Ericsson to print in the "smart commit" case:
Nothing to commit but changes in working tree. Assuming 'git commit -a'
or something like that?
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Hi,
Quoted 6 lines · Jakub Narebski
Could we add suggestion by Andreas Ericsson to print in the "smart commit" case:
Nothing to commit but changes in working tree. Assuming 'git commit -a'
or something like that?
Only that you would not see it (or ignore it, as has been illustrated in another thread), because your editor pops up, hiding that message.
Ciao,
Dscho
PATCH 1/1 Make git-commit cleverer - have it figure out whether it needs -a automatically
In reply to Jakub NarebskiRaimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for.
Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include", so they turn this behaviour off as well.
I've also output a message as suggested by Andreas Ericsson.
--- git-commit.sh | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
git-commit.sh +8 -0
@@ -265,6 +265,14 @@ $1" done case "$edit_flag" in t) no_edit= ;; esac +# Clever commit - if this commit would do nothing, then make it an "all" +# commit +if [ -z "$(git-diff-index --cached --name-only HEAD)" \ + -a -z "$amend" -a -z "$only" -a -z "$also" ]; then + echo "Nothing to commit but changes in working tree. Assuming 'git commit -a'" + all=t +fi + ################################################################ # Sanity check options
Signature · 1 line
1.4.4.1.g3ece-dirty
git-commit.sh $1" · line 272
Quoted 13 lines
git-commit.sh +5
-0@@ -265,6 +265,14 @@ $1" done case "$edit_flag" in t) no_edit= ;; esac +# Clever commit - if this commit would do nothing, then make it an "all" +# commit +if [ -z "$(git-diff-index --cached --name-only HEAD)" \ + -a -z "$amend" -a -z "$only" -a -z "$also" ]; then + echo "Nothing to commit but changes in working tree. Assuming 'git commit -a'"
This is hardly seen as the editor will immediately pop up. Better pause a second or put it in commit template (I'd prefer the latter).
Quoted 8 lines
git-commit.sh +3
-1+ all=t +fi + ################################################################ # Sanity check options --1.4.4.1.g3ece-dirty
PATCH 1/1 Make git-commit cleverer - have it figure out whether it needs -a automatically
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for. Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include", so they turn this behaviour off as well.
Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this by adding an extra comment to the commit message.
--- git-commit.sh | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
git-commit.sh +10 -0
@@ -265,6 +265,16 @@ $1" done case "$edit_flag" in t) no_edit= ;; esac +# Clever commit - if this commit would do nothing, then make it an "all" +# commit +if [ -z "$(git-diff-index --cached --name-only HEAD)" \ + -a -z "$amend" -a -z "$only" -a -z "$also" ]; then + echo "# There was nothing to commit but changes were detected in the" > $GIT_DIR/SQUASH_MSG + echo "# working tree. 'git commit -a' mode activated." >> $GIT_DIR/SQUASH_MSG + echo "#" >> $GIT_DIR/SQUASH_MSG + all=t +fi + ################################################################ # Sanity check options
Signature · 1 line
1.4.4.1.g3ece-dirty
Quoted 6 lines · Andy Parkins
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Brilliant solution!
Quoted 7 lines · Andy Parkins
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
Quoted 7 lines
Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for. Additionally, it's probably not the right thing to do if any files are specified with "--only" or "--include", so they turn this behaviour off as well.
Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this by adding an extra comment to the commit message.
Insount on #git pointed out fragility of this solution with respect to adding/removing/moving files, which dirties index (which might not be understood by newbie user: "git commit" used to work, but doesn't work the same when I added some files).
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Quoted 4 lines · Jakub Narebski
Insount on #git pointed out fragility of this solution with respect to adding/removing/moving files, which dirties index (which might not be understood by newbie user: "git commit" used to work, but doesn't work the same when I added some files).
It does, provided they only added files and didn't change anything else. If they did then we're out of it for this patch anyway.
Anyway, this is only meant to help ease people into the index. As discussed elsewhere, hiding the index is a silly policy.
This patch isn't /just/ for the newbies by the way (who are already confused, so that hasn't changed), I know about the index, but I still like it. Remember, all it's really saying is "when commit would do nothing, do something". So it only takes away an option that you can't have been using anyway because it didn't do anything.
Andy
Signature · 1 line
Dr Andy Parkins, M Eng (hons), MIEE
Quoted 8 lines · Nguyen Thai Ngoc Duy
git-commit.sh $1" · line 272
Quoted 5 lines
git-commit.sh +5
-0+# Clever commit - if this commit would do nothing, then make it an "all" +# commit +if [ -z "$(git-diff-index --cached --name-only HEAD)" \ + -a -z "$amend" -a -z "$only" -a -z "$also" ]; then + echo "Nothing to commit but changes in working tree. Assuming 'git commit -a'"This is hardly seen as the editor will immediately pop up. Better pause a second or put it in commit template (I'd prefer the latter).
Well, if it is VISUAL editor, you would see this. But adding this to template is certainly good idea.
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
Quoted 4 lines · Andy Parkins
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?"
The is dangerous on filesystems which lie to the programs about file metadata. The "virtual filesystem" of cygwin is one of this kind: exec-bit of the files depend
on its contents. Just calling git-commit -a will commit executability at this particular
moment. For whatever reason, disabling handling of the exec-mode in gits config does not work.
If you about to change the behaviour, provide at least a config option to go back
Quoted 7 lines · Alex Riesen
The is dangerous on filesystems which lie to the programs about file metadata. The "virtual filesystem" of cygwin is one of this kind: exec-bit of the files depend
on its contents. Just calling git-commit -a will commit executability at this particular
moment. For whatever reason, disabling handling of the exec-mode in gits config does not work.
Surely this is a separate fault?
Quoted 3 lines
If you about to change the behaviour, provide at least a config option to go back
to the old git-commit, which didn't do any magic.
Wasn't the whole point of this to avoid needing another config option?
Andy
Signature · 1 line
Dr Andy Parkins, M Eng (hons), MIEE
Quoted 11 lines · Andy Parkins
Quoted 8 lines
The is dangerous on filesystems which lie to the programs about file metadata. The "virtual filesystem" of cygwin is one of this kind: exec-bit of the files depend
on its contents. Just calling git-commit -a will commit executability at this particular
moment. For whatever reason, disabling handling of the exec-mode in gits config does not work.Surely this is a separate fault?
Of course it is. It's just that the problem is not solved yet, and if -a becomes git-commit's default a simple git-commit will be a real annoying thing.
Quoted 6 lines
Quoted 3 lines
If you about to change the behavior, provide at least a config option to go back
to the old git-commit, which didn't do any magic.Wasn't the whole point of this to avoid needing another config option?
Quoted 3 lines · Alex Riesen
Of course it is. It's just that the problem is not solved yet, and if -a becomes git-commit's default a simple git-commit will be a real annoying thing.
There was talk of making git-commit -a; bear in mind that this patch was to completely sidestep making that default. This patch has no effect on existing behaviour save for one special case: when commit would otherwise have done nothing, it now does "git-commit -a".
If you have a problem with git-commit -a, then presumably you are already using git-update-index for all your commit needs; in which case this patch has zero impact on you.
Quoted 3 lines
Quoted 1 line
Wasn't the whole point of this to avoid needing another config option?
was it it the point of breaking existing setups?
Of course it isn't; I have no intention of breaking yours or anybody else's setup. However, as your complaint is that this patch highlights another bug, I would think the solution is fix the other bug, instead of botch around it in this patch.
Perhaps I was a little terse; what I should have said was - I don't really want to solve this executable bit problem with a config option; as that's papering over the cracks. If executable bits are a problem, well why not detect when that's the case automatically. I don't have a cygwin environment so I have no way to test what you ask for.
Andy
Signature · 1 line
Dr Andy Parkins, M Eng (hons), MIEE