committing some lines

[Steve Fink]

On Sun, Oct 1, 2023 at 11:55 PM Hartmut Goebel <h.goebel at crazy-compilers.com>
wrote:

> Am 27.09.23 um 19:19 schrieb Steve Fink:
>
> I can only really speak for myself, and I haven't used either magit or
> monky, but maybe my opinion will have some value in knowing what mercurial
> users tend to expect?
>
> So I strongly suggest you give magit a try to get a notion of its
> benefits. Mitchel already pointed to the following intro to magit video can
> easily be listened to in double speed and if so is ~7 minutes.
>
> https://www.youtube.com/watch?v=vQO7F2Q9DwA
>
> I will watch it, because I've heard such good things about magit, but to
be clear: I don't have much interest in using git any more than I have to.
I started with git and used it for some time before I ended up on a project
that uses mercurial, and I don't want to go back. I still use git here and
there, but even for github now I prefer using it via Facebook's sapling
fork of mercurial. So until magit gains support for hg, it's only of
academic interest to me.

Mercurial doesn't have a staging area / index / cache, and I don't miss it.
>
> I miss it a lot, since it makes it much harder to split the current state
> of the working directory into smaller pieces.
>
> Maybe a top-level commit which get amended (as you mention in your other
> post) can work like a staging area. Actually I don't care about how this is
> solved, as long a tooling is powerful — and this is what mercurial is
> lacking,
>
> "hg commit --interactive" works per-chunk only — which is not fine-grained
> enough for my needs. And the ncurses interface available for "hg commit
> --interactive" is, well, has potential for improvement.
>
Heh. I guess this is where we diverge. I love the ncurses interface of `hg
commit -i`, and it is plenty capable of sub-chunk (line) operation. I'm not
familiar with the non-ncurses interface, since when I accidentally end up
in it, I feel like I'm in some 90s throwback interface and exit immediately.

>  Which means you need to individually identify the files or chunks that
> you want to include, and anything you don't identify gets left behind.
>
> Is is wrong: You can just use "git commit -a" to commit all changes in one
> rush. Yes. you need to add a flag, but that's all.
>
I'm aware of that, but I believe the default is instructive of the mental
model git encourages. `git add filename` on a file that is already in the
repository is a normal, expected operation. `git commit -a` is a shortcut
for a bunch of adds.

I mean, git and hg are very very comparable in capability and power, so
anything missing in one that is really useful is going to tend to be added
to the other before long. Unless it goes against the grain of the other
tool.


> Hg is the opposite: the default is to take everything, or at least
> everything that has been identified as belonging in the repository.
>
> And this often leads to commits including unrealated changes.
>
I guess my 90% is your 10%, and vice versa. git's behavior often leads to
commits missing changes for me (since I don't use -a as a matter of course,
and perhaps I should).

>
> The other relevant default is that git treats commits as permanent and
> immutable. In hg, the revision hash does refer to a permanent and immutable
> thing, but your current commit stack can be updated and evolved and
> modified.
>
> Again, this is not true: In both mercurial and git commits are permanent
> and immutable. And the commit stack can be updated and modified in both —
> an in git this not even requires an extension, but is already build in.
>
Yes, primitive history modification is also built into hg (`hg commit
--amend`). I guess I was unclear: yes, both hg and git support history
rewriting. But mercurial expects it and manages it, with a rich set of
features like phases and evolve and obsolescence. git tolerates it. Or at
least, that's my impression—maybe it's more of a cultural thing, but at
least my understanding is that history rewriting is frowned upon other than
squashing and rebasing. Correct me if I'm wrong. (And I'm not talking about
public history rewriting. Both tools frown on that. I hear git has gotten
much better about not requiring `git push -f` for normal operation.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20231002/60a84516/attachment.html>