On Sat, Sep 18, 2010 at 11:58, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: [..] > 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. [..] However, you can see it explictly if you add --log when merging, i.e. git merge --no-ff --log topic (you'll get a list of one-line commit messages from those commits merged into master from topic). It doesn't identify the commits, only the commit messages. Therefore I add problem report IDs into my oneline-messages, and I get a shortlist of exactly what was fixed by a given merge. This is sufficient support for me, I too don't care where a commit _originally_ came from, before it arrived into the branch that I at some point merge to the delivery branch. -Tor -- 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