This special treatment influences or directly causes many of the
things in bzr that we've been discussing:
[...]
I've been arguing that all of these impacts are dubious. But I can
understand that a bzr user hearing arguments against them might fear
that they would lose the ability to be able to see a view of commits
that "belong" to a particular branch.
Dead center.
The mainline..featureA syntax literally just means:
the set of commits that are reachable by featureA
and excluding the set of commits reachable by mainline
From what I can gather from this, though, that means that when I merge
stuff from featureA into mainline (and keep on with other stuff in
featureA), I'll no longer be able to see those older commits from this
command. And I'll see merged revisions from branches other than
mainline (until they themselves get merged into mainline), correct?
It sounds more like a 'bzr missing --mine-only' than looking down a
mainline in log...
one thing you are missing 'mainline' in this git command is not saying
'everything that's in the 'main' published branch'. it's saying 'everything
reachable by the tag 'mainline'
so when you branched off for your feature development you could set a tag that
says 'branchpoint' and no matter what gets merged in mainline after that you can
always do branchpoint..featureA and find what you've done.
that being said, mainline..featureA is also extremely useful, it tells you what
development stuff you have done that have not yet been merged into mainline
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html