On Sat, Sep 18, 2010 at 09:19, Stefan Haller <lists@xxxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxx>
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?
--
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