Subject: Re: "git merge" merges too much!

From: "Greg A. Woods" <[email-masked]>
Date: Mon, 30 Nov 2009 13:12:31 -0500

Thank you very much for confirming my understanding of why "git merge"
was merging more changes than I had desired it to merge.

The way "git merge" works does concern me somewhat though as I try to
figure out how I might use "topic" branches to develop local features
and then merge them onto each supported release branch.  Some guides
I've read suggest this methodology, but I'm sure how well this will
work, even when the remote project uses release branches to manage
official releases.  Perhaps I really should look at StGit, but I'm not
sure about it either.

At Sun, 29 Nov 2009 00:14:27 -0500, Jeff King <[email-masked]> wrote:
Subject: Re: "git merge" merges too much!
> 
> On Sat, Nov 28, 2009 at 10:21:25PM -0500, Greg A. Woods wrote:
> > 
> > master branch to represent release points -- is there any way to get
> > "git log" to show which tags are associated with a given commit and/or
> 
> Try "git log --decorate".

Excellent!  That's exactly what I was looking for.

(From a first pass through the documentation I would never have guessed
that "tags" were also a form of "refs".  All these different names for
things in the Git vs.  many other VCS's, like "ref names" _really_
confusing to anyone like me with too much experience using those other
revision control systems.  Part of the problem is that Git documentation
seems to be two-or-more minded about several of its concepts and
features.  Even the gitglossary(7) is somewhat inconsistent on how it
uses "ref" and "refs".  Perhaps all that's needed is some firm editing
and clean-up of the manuals and documentation by a good strong technical
editor.)

> Yes, you must cherry-pick or use rebase (which is a more featureful
> version of the pipeline you mentioned).

"git rebase" will not work for me unless it grows a "copy" option ,
i.e. one which does not delete the original branch (i.e. avoids the
"reset" phase of its operation).  This option would likely only make
sense when used with the "--onto" option, I would guess.

"git rebase -i" would certainly give me all the control I could possibly
want when copying changes from branch to branch.

It likely wouldn't make sense to base this new "copy" feature directly
on "git rebase" though, especially in light of all the warnings about
how "git rebase" isn't friendly when applied to already published
branches.  I think in theory this "copy" feature won't cause problems
for already-published branches.

Perhaps it should be a whole new top-level command such as "git copy",
but then it's so much like "git merge" I'm not sure....  Ideally if "git
merge" could be taught how to work with just the changes from the base
of a branch then it would do what I'm looking for directly.

> The resulting commits will have different commit ids, but git generally
> does a good job at merging such things, because it looks only at the
> result state and not the intermediate commits.  If both sides have made
> an equivalent change, then there is no conflict.

> > Is there any way to get "git log --graph" (and/or gitk) to show me all
> > the branch heads, not just the current/specified one?
> 
> Try "--all" with either gitk or "git log". Or if you want a subset of
> heads, just name them.

Awsome!  Those options provide just what I wanted to see!

(git-log(1) is worse than ls(1) for having too many options, but worst
of all in the release I'm still using it doesn't respond sensibly nor
consistently with other commands when given the "-?" option.)

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <[email-masked]>
Planix, Inc. <[email-masked]>      Secrets of the Weird <[email-masked]>