committing some lines
Steve Fink
sphink at gmail.com
Wed Sep 27 17:19:05 UTC 2023
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?
Mercurial doesn't have a staging area / index / cache, and I don't miss it.
It feels to me like an architectural wart that multiplies the number of
operations you have to be aware of, for no particularly good reason other
than to paper over some unfortunate choices for defaults that git made. One
of them is that in git, if you commit then by default you get nothing.
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. Hg is
the opposite: the default is to take everything, or at least everything
that has been identified as belonging in the repository. (`hg add` and `git
add` have subtly different base semantics: in hg, it means "add this file
to the set of files tracked and maintained by the repository, permanently".
In git, it means "add this to the set of currently pending changes", a
fundamentally temporary property.)
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.
That's a long-winded way of justifying that if you *are* building up a more
permanent set of changes from the work you're doing, that in hg it's
considered fine to make a temporary, partial commit and repeatedly amend it
as you continue on. Or perhaps even have a stack of independent changes,
and absorbing relevant changes into any or all of the different commits in
the stack. At least for me, it's common to use `hg commit -i` to produce
several updates to the deeper commits in the stack, then `hg histedit` to
reorder and amend them into their appropriate "main" commits.
But I don't know exactly what that means for monky. If you just want to
support the git-style workflow of a staging area, then my vote is that it's
fine to have a top commit with a temporary message like "<monky staged
changes>" that you repeatedly amend by adding new hunks in. (And sometimes
I work that way too. If there are multiple primary commits in my stack,
then at some point I'll `hg split` the "staging" commit into pieces that I
`hg histedit` into place. Or I might `hg uncommit -a` and try my luck with
`hg absorb` to do what can be done automatically, and if there's anything
left over, handle it manually.)
On Wed, Sep 27, 2023 at 6:15 AM Mitchell Elutovich <melutovich at gmail.com>
wrote:
> https://github.com/ananthakumaran/monky/issues/104#issuecomment-1054503171
>
> Someone mentioned to me recently that they come from git, magit, and emacs
> background and would be interested in having this feature in monky work,
> how well does mercurial support it; any existing extensions that would help?
> _______________________________________________
> Mercurial mailing list
> Mercurial at lists.mercurial-scm.org
> https://lists.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20230927/c673c137/attachment.html>
More information about the Mercurial
mailing list