On Thu, Oct 14, 2021 at 02:00:48PM +0200, Uwe Brauer wrote:
> If you're talking about
> hg commit --interactive
> which was previously available as an extension called "record", then yes,
> it appears to be roughly the same thing.
Right.
> The difference appears in that Git "exposes" that area which holds the state
> of the commit being prepared.
There is only one confusion left (I will use HTML in this mail, in order
to display better the following table).
I'd say the Google Group interface (or your Emacs mail client) had managed to
produce a fully-readable ASCII representation of this table ;-)
| HG | Git | comment |
|----------+-----------------------+----------------------------------------|
| hg ci | git ci -a | commit all changes at once |
|----------+-----------------------+----------------------------------------|
| hg ci -i | git ci (?) | commit interactive some-or-all-changes |
| | or git add -i git ci | |
| | or git -i | |
While the first row is clear, the second is not clear to me.
And I think this is why users are from time to time confused. Once
understood maybe it is best to have an alias
1. for the interactive commit
2. and one for the commit all changes
I'm not sure I quite follow your logic here; let me explain.
If I'm absolutely positive about what I want to commit - say I did a
reasonably trivial change which did not involve adding new files or removing
existing - I just do
git commit -a
and call it a day.
If, on the other hand, I'm about to _craft_ a synthetic commit out of the
changes currently present in the work three, I "switch" into a much more
rigorous mode of operation. I usually start with
git add -up
which means "add changes in the files which were updated (-u, --update), on a
hunk-by-hunk basis (-p, --patch)", then manually select which hunks to stage
(sometimes I split the hunks as I go (Git allows to do that) and edit the
hunks about to be applied). Then I _always_ inspect what the staged changes
look like - by running `git diff --staged`, - inspect the changes which a
still in the work tree (`git diff`, `git status`).
Quite often I also verify whether the currently staged changes are "good to
the machine" and not to my naked eye; to do that I run
git stash --keep-index
which saves away the changes in the work tree which are not in the index and
then removes them from the work tree (so the work tree matches the state in
the staging area) and then build the project / run source code linters and
tests etc. If all is well, I commit and then "pop" the stashed state back.
IOW, I consider the case of crafting a commit as requiring an approach with
which you cannot cut corners: you should make sure your commit is sensible on
all accounts, and this means even if Git were to have something like
`hg ci -i`, I am not sure I would use it: I need to examine the state I made
before I commit it.
On the other hand, since Git has interactive rebasing (history editing), it's
OK to follow another path: create a string of commits which look OK - or may
be even commits with known deficiences - and then rebase the resulting series
with additional editing of the known-not-so-good commits.
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/20211016161411.xt6umon5vphlk27v%40carbon.
