Re: Find out on which branch a commit was originally made

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 18, 2010, 09:58 UTC
Message-ID: <AANLkTiknoBS7x2za3qzghfS0TD6UUL83eoZz7LFBPUuc@mail.gmail.com>
In-Reply-To: <1jp0h7e.lgk0kp19qe5bbM%lists@haller-berlin.de>

On Sat, Sep 18, 2010 at 09:19, Stefan Haller <lists@haller-berlin.de> wrote:

Show 29 quoted lines

> I'm trying to pursuade my co-workers to switch from Subversion to Git;
> some of them prefer Mercurial.
>
> One concern that they are raising is that in Git there doesn't seem to
> be an easy way to find out on which branch a given commit was originally
> made, after the branch is merged back and deleted. They consider this a
> show-stopper.  In Mercurial, branch information is meta data attached to
> each commit, so you can easily get this information even after a branch
> is closed.
>
> Three questions:
>
> 1) Is this not something that Git users miss sometimes?  Why not?
>
> 2) Is there an easy way to get this information that I might have
> missed?  (Typical use-case: you blame a line of code with git gui blame,
> choose "Show history context" to show the changeset in gitk, and from
> there you want to go up to the next merge commit to see if the merge
> commit message mentions the name of the branch. I can't seem to figure
> out how to find this merge commit in gitk, and besides, "Show history
> context" shows me only 7 days of context by default, so the merge commit
> is likely not to be in my current list anyway.)
>
> 3) As a possible work-around, they suggest to require encoding the
> branch information in some format in the commit messages, maybe
> automatically with a commit-msg hook.  Does this sound like a feasible
> idea?  One drawback would be that it becomes awkward when you
> accidentally make a commit on the wrong branch, and want to rebase it
> onto the correct one.

    You want to do X, and you think Y is the best way of doing so.
Instead of asking about X, you ask about Y.
    — from Re: sequencial file naming by Abigail

Your Y is encoding the name of the current branch at commit-time, the you haven't told us. Why do your co-workers think this is essential to the point that they can't get by without it? What problem are they trying to solve?

But to answer your question then no, Git doesn't track this information. Because we think it's irrelevant.

As an example of how irrelevant it is consider my huge ab/i18n series (you may have spotted it on the list). It's currently composed of 140 patches.

If Git tracked the branch at commit time that series would contain a bunch of useless metadata. The series is currently composed of commits which were originally created on at least some of these branches:

    $ git branch -l |grep -e gettext -e i18n
    * ab/i18n
      ab/i18n-add-translations
      ab/i18n-all
      ab/i18n-all-continue
      ab/i18n-continue
      ab/i18n-continue-hi.po
      ab/i18n-continue-more
      ab/i18n-continue-with-hindi
      ab/i18n-for-junio
      ab/i18n-for-junio-with-docs
      ab/i18n-gettextize
      ab/i18n-v2
      debug-gettext-poison
      disable-gettext-by-default-in-releases
      gettext-remove-old-sanity-test
      gettextize-git-in-german
      gettextize-git-mainporcelain
      gettextize-git-mainporcelain-even-more
      gettextize-git-mainporcelain-more
      gettextize-git-mainporcelain-v2
      gettextize-git-mainporcelain-v3
      gettextize-git-mainporcelain-with-perl
      minor-gettext-infrastructure-fixes

But nobody will ever care what branch name I just happened to pick while I was hacking some patch, why should they? Why does it matter than I commited some commit on a Solaris box on a branch called `ab/i18n-oh-man-i-hate-solaris-will-this-just-bloddy-work-already' ?

What Git *does* track however when you do `git merge topic` is the name of the `topic` branch you're merging into some other branch, e.g. here (from git-merge(1)):

                     A---B---C topic
                    /         \
               D---E---F---G---H master

Even though A B and C might have been commited on branches called `blah`, `bluh` and `blarghl` you'll never know. You'll just know that someone put them all together on a branch called `topic` and that someone later merged that into master in the main repository. E.g.:

    Merge: A G
    Author: Some Guy <some-guy@example.com>
    Date:   <....>

        Merge branch 'topic'

From there you can *infer* that A-B-C came from the topic branch, because of that merge commit and that the DAG doesn't meet master until commit E.

But you can't ever get info about `blah`, `bluh` and `blarghl` back out of A-B and C again unless you track those branches down in someone's development repository.

Why? Because who cares about `blah`, `bluh` and `blarghl`, really?