Always apply (and hide) some patches

[Danylo Hlynskyi]

> Why can’t you use secret commits?

I may use secret commits, but I think that explicitly hiding those commits
from log
will make commands like `hg commit -a` and `hg update` behave canonically.

For example, you have

(C1,public) --> (C2,draft) --> (C3, local) tip

When you do some changes and `hg commit -a`, those should be appended to C2
commit
which looks very strange if user can see C3 commit.

> If you have only a single commit, you can simply graft the local commit
> on top of the new one.

No, not always. Here are examples when this isn't that easy:
- your workdir is still dirty
- you have done your bug/feature commit on top of local, so you require two
grafts and
one strip when you want to push (my actual workflow)

Actually, there is one more way to achieve what I want (merge commits can
"forget" other commits),
but it creates non-linear history, which we try to avoid, and requires two
merges before push.

> Good luck and happy hacking!

Thanks!


2017-06-06 16:10 GMT+03:00 Arne Babenhauserheide <arne_bab at web.de>:

>
> Danylo Hlynskyi <abcz2.uprola at gmail.com> writes:
>
> > I can't base my work on top of hidden commit, because that would still
> > require rebasing.
> > And I can't base hidden commits on top of my changes, because they aren't
> > moving targets
> > and won't be autorebased after I commit.
>
> Why can’t you use secret commits? Do you mean that this cannot be
> implemented cleanly or that it is not the current behavior?
>
> >> That way you’d just need to run a single command to make your last
> commit
> > non-secret.
> >
> > Yes, that kind of workflow can be automated. What you've described is
> > basically auto-reordering using histedit
> …
> > $ hg to-local [BRANCH]
> > Marks 'tip' commit of a named BRANCH (or current branch, if nothing
> > specified) as local to this repo.
>
> Having this as a single command sounds good. The need to overwrite
> commands might make this harder than other methods.
>
> What I don’t understand is why you need a separate class of
> commits. Your description sounds like you just need secret phase (which
> is never exchanged with others) plus automatic grafting of new commits
> into the non-secret commits.
>
> > Most hg commands will ignore this commit, but the actual working
> directory
> > will behave
> > like this commit is applied.
> >
> > Internally, it is always rebased on top of latest updated commit in
> > selected named branch.
> >
> > Local commits are not mergeable. If your hg <command> hit the merge
> > conflict with local, you have to
> > make local commit normal using `hg from-local` and then convert back to
> > local after merge is done.
>
> If you have only a single commit, you can simply graft the local commit
> on top of the new one. With grafting you get rid of the need to have
> real merges.
>
> Good luck and happy hacking!
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170606/1314b16e/attachment-0002.html>