committing some lines

[Steve Fink]

I should mention that it's rare that I have a specific "staging" patch on
top of my stack. In practice, usually the top commit is what I'm actively
working on, and I'll `hg amend -i` repeatedly to build it up. Leftover
stuff accumulates in my working directory, and at some point I'll keep the
pieces I want by making new commits for them, and discarding the stuff I no
longer need. But I'm not averse to the git-style staging area approach,
which in my mind maps most naturally to a topmost staging commit.


On Wed, Sep 27, 2023 at 10:19 AM Steve Fink <sphink at gmail.com> wrote:

> 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/55f8dd3d/attachment.html>