From: Junio C Hamano <hidden> Date: 2016-10-20 16:30:17
Jeff King [off-list ref] writes:
quoted
I still think it's worth while to add a check for git-commit which
does something like check when we say "git commit <files>" and if the
index already has those files marked as being changed, compare them
with the current contents of the file as in the checkout and quick
saying "please don't do that" so as to avoid the problem in the first
place.
...
I suspect both of those would complain about legitimate workflows.
I dunno. I do not ever use "git commit <file>" myself.
Users are different. I do use this all the time, and it is not
unusual at all to have changed contents on paths other than <file>
already added to the index when I do so, i.e. an unrelated small
typofix in <file> jumping ahead of the real changes I am working on
in other parts of the tree.
"Please don't do that" would break. Jacob says "avoid the problem",
but I do not see a problem in allowing it (it could be that the
problem Jacob has is in other parts of his workflow, but I do not
know what it is offhand).
From: Jacob Keller <hidden> Date: 2016-10-20 17:28:25
On Thu, Oct 20, 2016 at 9:30 AM, Junio C Hamano [off-list ref] wrote:
Jeff King [off-list ref] writes:
quoted
quoted
I still think it's worth while to add a check for git-commit which
does something like check when we say "git commit <files>" and if the
index already has those files marked as being changed, compare them
with the current contents of the file as in the checkout and quick
saying "please don't do that" so as to avoid the problem in the first
place.
...
I suspect both of those would complain about legitimate workflows.
I dunno. I do not ever use "git commit <file>" myself.
Users are different. I do use this all the time, and it is not
unusual at all to have changed contents on paths other than <file>
already added to the index when I do so, i.e. an unrelated small
typofix in <file> jumping ahead of the real changes I am working on
in other parts of the tree.
"Please don't do that" would break. Jacob says "avoid the problem",
but I do not see a problem in allowing it (it could be that the
problem Jacob has is in other parts of his workflow, but I do not
know what it is offhand).
I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:
I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.
Then, I (accidentally) run "git commit <file>"
I want git commit to complain here that the index <file> and acutal
<file> being requested are different and it thinks there's an issue.
I do *NOT* want it to complain if I do "git add -p" and put parts of
<other-file> into the index, and then run
git commit <file>
Does that make sense?
Basically if the index and "git commit <file>" both say "add <file>"
but they conflict in what version of <file> I want it to go "hey..
uhhh.. that's a bad idea"
Thanks,
Jake
On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
[...]
I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:
I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.
Then, I (accidentally) run "git commit <file>"
[...]
This reminded me of something that bothered me for a while. It's not
100% on-topic but still quite related so I thought I'd bring it up.
When working on a feature, I usually try to make atomic changes from the
beginning and use `git commit -a` to commit them one after another. This
works fine most of the time. Sometimes I notice only after making some
changes that it might be better to split the working tree changes into
several commits.
In that case, I git-add the relevant hunks and then, unfortunately, I
often run `git commit -a` instead of `git commit` (muscle memory bites
me), so I need to do all the splitting work again.
It's not much of an issue but would it be worthwhile to add an optional
feature (configurable) that warns you when using --all with staged
changes (which are not new files)? Are there others having the same
issue? Do you think this should be implemented as part of an alias
instead?
Regards,
Lukas
From: Jacob Keller <hidden> Date: 2016-10-23 01:07:42
On Sat, Oct 22, 2016 at 2:19 AM, Lukas Fleischer [off-list ref] wrote:
On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
quoted
[...]
I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:
I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.
Then, I (accidentally) run "git commit <file>"
[...]
This reminded me of something that bothered me for a while. It's not
100% on-topic but still quite related so I thought I'd bring it up.
When working on a feature, I usually try to make atomic changes from the
beginning and use `git commit -a` to commit them one after another. This
works fine most of the time. Sometimes I notice only after making some
changes that it might be better to split the working tree changes into
several commits.
In that case, I git-add the relevant hunks and then, unfortunately, I
often run `git commit -a` instead of `git commit` (muscle memory bites
me), so I need to do all the splitting work again.
It's not much of an issue but would it be worthwhile to add an optional
feature (configurable) that warns you when using --all with staged
changes (which are not new files)? Are there others having the same
issue? Do you think this should be implemented as part of an alias
instead?
Regards,
Lukas
This is (essentially) what I am asking for above. It's the same
overall problem of "muscle memory bites me" and I want the tool to
change to help avoiding because I don't think I can win the fight
against muscle memory every time. Being configurable would ensure that
only those that want the behavior opt in.
Thanks,
Jake
On Sat, Oct 22, 2016 at 4:19 PM, Lukas Fleischer [off-list ref] wrote:
On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
quoted
[...]
I still think we're misunderstanding. I want git commit to complain
*only* under the following circumstance:
I run "git add -p" and put a partial change into the index in <file>.
There are still other parts which were not added to the index yet.
Thus, the index version of the file and the actual file differ.
Then, I (accidentally) run "git commit <file>"
[...]
This reminded me of something that bothered me for a while. It's not
100% on-topic but still quite related so I thought I'd bring it up.
When working on a feature, I usually try to make atomic changes from the
beginning and use `git commit -a` to commit them one after another. This
works fine most of the time. Sometimes I notice only after making some
changes that it might be better to split the working tree changes into
several commits.
In that case, I git-add the relevant hunks and then, unfortunately, I
often run `git commit -a` instead of `git commit` (muscle memory bites
me), so I need to do all the splitting work again.
It's not much of an issue but would it be worthwhile to add an optional
feature (configurable) that warns you when using --all with staged
changes (which are not new files)? Are there others having the same
issue? Do you think this should be implemented as part of an alias
instead?
I hit the same problem sometimes, but in my case sometimes I
accidentally do "git add" after "git add -p" and a configuration in
"git commit -a" won't help me. I'd prefer we could undo changes in
index instead. Something like reflog but for index.
--
Duy
From: Jeff King <hidden> Date: 2016-10-23 01:38:56
On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:
I hit the same problem sometimes, but in my case sometimes I
accidentally do "git add" after "git add -p" and a configuration in
"git commit -a" won't help me. I'd prefer we could undo changes in
index instead. Something like reflog but for index.
An index write always writes the whole file from scratch, so you really
just need to save a copy of the old file. Perhaps something like:
rm -f $GIT_DIR/index.old
ln $GIT_DIR/index.old $GIT_DIR/index
... and then open $GIT_DIR/index.tmp ...
... and then rename(index.tmp, index) ...
could do it cheaply. It's a little more complicated if you want to save
a sequence of versions, and eventually would take a lot of space, but
presumably a handful of saved indexes would be sufficient.
Another option would be an index format that journals, and you could
potentially walk back the journal to a point. That seems like a much
bigger change (and has weird layering, because deciding when to fold in
the journal is usually a performance thing, but obviously this would
have user-visible impact about how far back you could undo).
-Peff
On Sun, Oct 23, 2016 at 8:38 AM, Jeff King [off-list ref] wrote:
On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:
quoted
I hit the same problem sometimes, but in my case sometimes I
accidentally do "git add" after "git add -p" and a configuration in
"git commit -a" won't help me. I'd prefer we could undo changes in
index instead. Something like reflog but for index.
An index write always writes the whole file from scratch, so you really
just need to save a copy of the old file. Perhaps something like:
rm -f $GIT_DIR/index.old
ln $GIT_DIR/index.old $GIT_DIR/index
... and then open $GIT_DIR/index.tmp ...
... and then rename(index.tmp, index) ...
could do it cheaply. It's a little more complicated if you want to save
a sequence of versions, and eventually would take a lot of space, but
presumably a handful of saved indexes would be sufficient.
Yeah. I had something [1] like that but never sorted out the UI for it :(
Another option would be an index format that journals, and you could
potentially walk back the journal to a point. That seems like a much
bigger change (and has weird layering, because deciding when to fold in
the journal is usually a performance thing, but obviously this would
have user-visible impact about how far back you could undo).