Re: Questions about branches in git

[Michael Witten <mfwitten@gmail.com>]

On Thu, Jan 28, 2010 at 12:44 PM, Mike Linck
<mgl@absolute-performance.com> wrote:
> ...
> It seems that after a topic or bug branch is merged back into its
> parent, especially if it was fast forwarded, it becomes hard to
> determine what changes were made in it, to resolve the problem that it
> was created to address.
> ...
> I understand that there are mechanism kind of available to address
> this problem.  If we (all developers in my company) remember always to
> rebase -i before they merge their topic branches back in, then it
> could be squashed making it easier to identify and cherry pick onto
> other branches...

For now, you should probably rely on graphical tools like gitk in
order to visualize the various branches. There's also `git log
--graph'. You could also just keep your branches around for reference
and use `git merge-base' as necessary.

However, I've been thinking for a while that it would be useful to
have übercommits (they don't exist) that are treated like single
commits but that actually encapsulate multiple continguous commits.

For your case, you could tell git to make merges by creating such
übercommits, which would then be easily identified, referenced, and
manipulated for your backporting purposes; such übercommits would
encapsulate the relevant commits.

These übercommits would also allow developers to make a string of
commits that by themselves break things but together formulate a
complete solution; because the übercommits encapsulate the breakage,
bisection would still be simple (no fear of dealing with broken
commits), but the small manageable commits would still be available
for references and manipulation.

Perhaps trees could be reappropriated for the implementation of übercommits.

Sincerely,
Michael Witten