My company does not maintain the repository with git
(we effectively use CVS), but I keep a repo locally for my own sanity. In the past, I\'ve wanted to bring up c
Git doesn't track this information by design.
http://markmail.org/message/yfb5ihwddjmrstz6
So don't think of it as "git throws away branch identity" as much as
"git never cared about branch identity in the first place, and doesn't
think it's relevant."
Your branch name is just that, your branch name. It can be literally anything you want. Or you can not use a branch name, and be in detached head state. Long term, only commit reachability is stored.
If you have information you want to track (like a Defect Number), then you need to include it in the commit message.
If you are using a central server you can setup a receive hook which logs the remote branch name information somehow (git notes
for instance). My company uses this. I find it only quasi-useful (mainly if you want to yell at a program manager instead of the guy who wrote or pushed the code).
merges-introducing() {
# merges-introducing $introducing [$descendant]
local introducing;
if introducing=`git rev-parse $1`; then
shift
git rev-list --ancestry-path --parents --reverse ^$introducing ${@-HEAD} \
| awk '{seen[$1]=1} NR>1 && !seen[$2] {print $1}' \
| xargs -r git show --oneline --no-patch
fi
}
Finds the merges incorporating a commit from a merged history.
git rev-list
's --ancestry-path
lists only the commits on the line of descent from the bottom commit (^$introducing
here) to the top (default HEAD
, your current checkout), --parents
gives the parents for each of them, --reverse
lists the commits oldest-first (so $introducing
comes first), and the post-processing, the awk|xargs
, prints only merges whose first parent isn't on that ancestry path.
Unless someone's gone in and hand-edited the merge messages the subject lines for those commits will say the branch name and any source url of the relevant (and non-fastforward) merges, oldest first.