Understanding mercurial.

[Erik Bågfors]

> > 1) Cherry-pick.
> > How do I cherry-pick changes from one branch to another? Is that even
> > possible? A quite common scenario for me is that we have a released
> > product, then keep developing that, then we find out a bug, want to
> > fix that, in the development tree, and backport it to the release
> > product tree (simply a patch release).
> 
> If you do it the other way round, make a change to the released tree
> and then merge it to the devel tree, you have what you want.

I think a tool shouldn't change the way you work. If I'm working with
a specific version, develoing it, etc, I expect to be able to change
it there first.

Cherry-picking is quite common in lot's of SCMs.
 
> > The only way I found was to export these changesets, which isn't very
> > convinient.
> 
> Hm, maybe a 'hg pick' command behaving similar to export/import, but
> on the SCM level, would be something good, what do the others think?

I think so.

> > 2) exporting more than one changeset
> > The only way I found is, hg export 100; hg export 101; hg export 102, etc.
> 
> With current tip version (don't know if this is possible in 0.6b) I
> have a script similar to:
> 
> #!/bin/sh
> hg export -vR "$HOME/hg/tah" -o "$HOME/patches/mercurial-tah%r.patch" -- "$@"
> 
> And call it as 'hg-export-tah 100:102' from anywhere.
> Short form would be:
> $ hg export -o ../%r.patch 100:102 105 106 tip
> to export revisions 100, 101, 102, 105, 106 and the current tip from
> the current repo to separate files in the directory above.

Sounds good.
 
> > 3) Importing changesets and keeping summary committer etc,
> > Right now it seems to set "# HG changeset patch" as summary always.
> > What's the rationality behind this?
> 
> Already available in tip, maybe 0.6b

Great... I'm at 0.6 btw, not 0.6b. That was what I could find as a
ubuntu package then. I read that 0.6b is available now. I will
upgrade.
 
> > 4) Merging sometimes creates two changesets with the same things in.
> > If I pull something that I need to merge with "update -m" I also need
> > to commit that change again and then I get two changesets with the
> > same information/change.  I find this very strange.  To understand
> > that i mean, this is what I did.
> 
> Merge changesets are somewhat boring, especially the diffs. As the
> diff is always against the first parent, you'll get these strange
> looking merge diffs. If there are conflicts, these diffs will be
> different!
> 
> For reasons why this is necessary, search the mailing list archive.

ok
 
> It is planned to hide these merge changesets in 'hg log' unless a
> flag is given.

ok...
  
> > I expect that when I
> > rename a file in one branch, then pull in changes from another branch
> > where the file isn't jet renamed, hg should be able to put those
> > changes into the renamed file.
> 
> Some say yes, some say no. Mercurial (or Matt) decided 'no', because
> of the flexibility of the copy command (see above). I'm not yet sure
> what is the better way, but if changes should be propagated to
> descendants, there has to be a way to turn this off, too, which
> makes it much more complicated for both, programmer and user.

Or you could add a "move" (or rename) command as well as a copy
command that renames the file and in that case is merged like I
want???

/Erik