Equivalent to Mercurial's 'fetch'

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Finney wrote:
| Aaron Bentley <aaron at aaronbentley.com> writes:
|
|> Merge is good.  It's for situations where you have diverged.
|>
|> Pull is good.  It's for situations where you are updating a mirror.
|
| You're suggesting that pull should *not* be used for branches that
| aren't mirrors?
|
| For a given project, I often have a single "integration" branch and
| numerous "feature" branches. Development is mostly done in the feature
| branches, with changes being pulled back and forth between them, and
| merges being done into the integration branch to apply feature branch
| changes.

"changes being pulled back and forth" sounds like a use case for merge, not pull.

At least, if I had 2 feature branches, and I was combining them, I would always
use merge. As I'm integrating feature A into feature B. That way the mainline of
A stays the implementation of feature A.

|
| However, sometimes a feature branch has diverged from the branch I
| want to update from, so a pull isn't possible and I do a merge
| instead; this is more troublesome than a pull, so I prefer to avoid
| it.

It doesn't sound like a mirror (IMO).

|
| 'bzr merge --pull' (of which I only became aware yesterday) sounds
| ideally suited to this, hence my interest in why you think it's wrong.
|
| It seems as though you're saying that my workflow is not recommended,
| and that instead all those updates to feature branches should be done
| with a merge every time.
|

That is how *I* would do it. There are certainly different schools of thought.
For example, this case:

~ A C B   (A == feature A, C == common ancestry, B == feature B)

~   :
~   |
~   a
~   |\
~   b c
~  / \|
~ d   e
~ |\  |
~ | \ f
~ |  \|
~ |   g
~ ?

So you did some development in feature B and feature A, and you merged feature
A's changes into B.

At this point, doing log on feature B will show:

revno: 8
~  Merged in feature A

~    revno: 4.2.1
~      commit d (for feature A)

revno: 7
~  Other stuff (commit f)

revno: 6
~  Merge in trunk changes

~    revno: 4.1.1
~      change b in trunk

revno: 5
~  Change c for feature B

revno: 4
~  Change a

Now, what do you want to do in Feature A? If you 'pull' in Feature A, then 'bzr
log' will show you exactly what you see in Feature B.

If you merge in Feature B, then you would see something like:

revno: 7
~  Merged feature B

~    revno: 4.1.4
~      change g
~    revno: 4.1.3
~      change f
~    revno: 4.1.2
~      change e
~    revno: 4.1.1
~      change d

revno: 6
~  commit d (for feature A)
revno: 5
~  Change b

revno: 4
~  Change a

I tend to use 'bzr log --short --forward -r -10..-1' (with an alias) so I would see:

revno: 4
~  Change a

revno: 5
~  Change b

revno: 6
~  commit d (for feature A)

revno: 7 [merge]
~  Merged feature B


Certainly there is room for disagreement. But generally the Bazaar project
distinguishes changes made on the current branch (commit), from changes made
that you integrate (merge + commit).

And you can view just the changes on this branch with 'bzr log --short'. *I*
find it a very nice way to get an overview of what has been going on.

For example 'bzr log --short -r -10..-1' on bzr.dev takes up ~ 1 page worth of
real-estate. (34 lines). 'bzr log --long -r -10..-1' prints out lots of stuff,
including all the details for each feature, and takes 289 lines.
Now, you can do 'bzr log --long --limit 10' which is 70 lines long, and gives
you the details of the last feature that was merged, but doesn't give you an
actual overview of what has been going on in the branch.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhG+ggACgkQJdeBCYSNAAN0HgCePox/DTWq4qlKnn43+THf3q4Y
Dw8AoIzmQyOeRiVJaan2w7QuSyysQI57
=N75R
-----END PGP SIGNATURE-----