Junio C Hamano wrote:
Liu Yubao <yubao.liu@xxxxxxxxx> writes:
Snip many great detailed description, thank you very much, I have
a question about the way git treats fast forwarding but that will
be another topic.
What's mainline is _not_ important, and which parent is first is
even less so. It solely depends on what you are looking for
which branch matters more. Putting too much weight on the
difference between HEAD^1 vs HEAD^2 statically does not make any
sense.
Reflecting this view of history, git log and other history
traversal commands treat merge parents more or less equally, and
_how_ you ask your question affects what branches are primarily
followed. For example, if somebody is interested in your device
driver work, this command:
git log -- drivers/liu-s-device/
would follow your side branch. On the other hand,
git log -- fs/
would follow Linus's development track while you were forked, if
you did not do any fs/ work while on that side branch and
Linus's development track had works in that area, _despite_ the
merge you gave Linus has your development track as its first
parent.
This is perfect and enough for two branches that work on different
files, but if two branches modify same files, "git log" can't separate
commits clearly. For example, I want to know what happened in your
git's "next" branch, I hope to get logs like this:
Merge branch 'jc/pickaxe' into next
Merge branch 'master' into next
Merge branch 'js/modfix' into next
...
some good work
...
Merge branch ....
I just want to *outline* what happened in "next" branch, if I am interested
in what have been merged from 'jc/pickaxe' I can follow the merge point again
or use something like "git log --follow-all-parents".
Instead, "git log" interlaces logs from many branches, I find it's a little
confused: why does "git log" of current branch contain many logs from other
branches? (This is not a real question, I know the reason)
I indeed understand that HEAD^1 is not always the commit that my work
bases on before a merge (thanks for your detailed description again:-),
it doesn't make sense to show HEAD~1, HEAD~2, HEAD~3 and so on, that's
to say 'git log' will never meet my requirement.
Maybe reflog is what I need, I want to know which commits "next" have pointed
to, but reflog is only for local purpose, it's not downloaded by 'git clone'
or 'git pull', so, is it a good idea to publish reflogs?
-
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