hg inc - single branch view by default

[Arne Babenhauserheide]

Am Dienstag, 16. Dezember 2014, 19:31:05 schrieb anatoly techtonik:
> > [alias]
> > # focus incoming on the current branch
> > inb = incoming --focus-branch .
> 
> Also need to isolate changes in one branch for logging and pulling.

So same for log and pull?

pub = pull --branch .
lob = log --branch .

> So, you don't use "hg pull" + "hg log", because log command to select
> all changes from the current revision to the tip is complicated? Or is there
> other reason?

I use incoming instead of pull+log, because it gives me what I want:
See whether there’s something new (and what).

> > Something like the child of the greatest common ancestor?
> >
> > Or do you mean the greatest common ancestor itself?
> >
> >     hg log -r "ancestor(revs, ...)"
> 
> The first one - "child of the greatest common ancestor", but spelled in
> modern urban slang so that it could be used on IRC conveniently.

The threadstarter ☺

(thread is already used a lot for email)

First diverging change?

> Yes, from my own point of view. I admit that Mercurial is more simple for
> non-branched workflow, but once you start collaborating and need to
> adjust your changes after review, it is a nightmare.
> 
> The best we can get is documented here:
> http://scons.org/wiki/SconsMercurialWorkflows#TL.3BDR
> 
> And I believe the only way to strip the former changesets after rebase is
> through the admin interface of Bitbucket. Can't test it right now.

Adjusting published changes after review is not so nice, that’s
true. I think the most important thing for that is to stop fearing
closed heads: Just push a new head and close the old one.

> > Git is actually more convenient for some parts of usecases, but I
> > never found a usecase where it did more good than damage. So we should
> > be careful whether by going down the git path we wouldn’t give up more
> > than we gain.
> 
> People don't want to think and waste time on routines, and finding
> balance is hard. Evolve extension has a good chance to fix that though
> - preserve history without loosing flexibility.

I agree - I actually want to use evolve on published but not yet
accepted changesets: Make only the canonical repository publishing
(finalizing?).

Best wishes,
Arne
--
Celebrate with ye beauty and gather yer friends for a Pirate Party!
    → http://1w6.org/english/flyerbook-rules#pirate-party ←

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 299 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20141216/a11e1ea3/attachment.asc>