two branches, cherrypicking when merging.

[Steve Fink]

It sounds like this does not match your preferred workflow, but just as a
comparison point, I would use a bookmark for Uwe instead of a named branch,
then:

- record -i -m WIP # select the work in progress
- commit -m 'mainline bugfix'
- rebase -d default -s <mainline bugfix rev>

Then I'd push the bugfix, update to the work in progress, and probably just
make my additional changes in the working directory and amend them in,
eventually doing a chistedit to smush the changes together, or split to
break them apart. Or more likely, amend a bunch of things into one big
blob, uncommit -a, amend -i -m ..., record -i -m ..., record -i -m ..., etc.

I'm sure named branches are great for some people, for something. For me, I
want to be able to just start changing stuff, and decide later which
topological head each part of my changes belongs to. If a nondefault named
branch gets recorded when I commit something, it's just as likely as not to
be a lie. So I'd rather stick to telling truths: I am modifying whatever it
is that I have checked out, I'm recording independent pieces, then I'm
moving them to the appropriate topological head and removing them (if
necessary) from whatever I have checked out. No lies, just accurate
recordings of intermediate state.

Though it really isn't semantically different when using named branches.
They just make me feel like I'm promising too much when I use them.


On Wed, Nov 2, 2016 at 4:42 PM, Becker, Mischa J <mischa.becker at kroger.com>
wrote:

> >  > Assuming that the experimental changes don't immediately need the fix,
> >  > I tend to do it the other way around. i.e. Shelve the fix and commit
> >  > the experimental changes first. Then update to default before
> >  > unshelving and committing the fix.
> >
> > Oh wait, can I unshelve *after* I switch the branch?
> >
> > That is: I shelve in Uwe, then update to default then unshelve would go
> into default?
> > But if so the graph would be less clear at least for me than the one I
> obtain if I
> > merged it from the Uwe branch. (That is why I don't like much rebase,
> also I agree
> > it might be useful in large projects and when one has to send patches).
>
> Oh right, whether or not you can unshelve the fix on a different branch
> depends on how different the affected file is between branches.  In my
> case, the bug is likely to be in a file my experimental branch hasn't
> touched so there is no difference and I can unshelve without problem.  I'm
> also using tortoise hg and it's version of shelve. (http://tortoisehg.
> readthedocs.io/en/latest/shelve.html)  I'm not doing anything directly
> from the command line and there might be some slight differences from that.
>
> I occasionally cherry pick parts of a change committed to experimental
> back to default or graft a whole commit over but generally, for bug fixes,
> I find the graph easier to read when I commit the fix to the correct named
> branch in the first place and merge the fix back into the other branch.
>
> >  > Aside from that, I generally find it extremely helpful to have a
> >  > separate copy of my repo for each major branch I'm working on. (And an
> >  > extra one for everything else.) That way when I spot a bug or other
> >  > issue, I can leave project1-experiment as is while dealing with the
> >  > other issue in project1-default. Once I've committed my changes I just
> >  > push the new commit(s) over to project1-experimental. If I made the
> >  > fix in project1-experimental and don't feel like doing a shelve, I'll
> >  > do a folder comparison with my diff program to easily copy the fix
> >  > over to project1-default for committing.
> >
> > Yes I start to realize the same need, but I thought that is what
> branches are for,
> > but it seems that a clone of the repo is easier to deal with than a
> overcomplex
> > branching system.
>
> I use separate clones to keep my work-in-progress separate and named
> branches to keep my commits separate in the repo history.  If you are only
> keeping things separate via clones and everything is committed to the
> default branch, then as soon as you push\pull changes between the two
> clones you've lost all that separation.  I find that confusing.
>
> Mischa
>
> ________________________________
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain information that is confidential and
> protected by law from unauthorized disclosure. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message.
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20161106/2640e82c/attachment-0002.html>