Hi Yury, > In monotone a branch is a subgraph that consist of vertices with > "branch" label (cert in mtn terminology) attached. So you know the > set of branches given commit belongs to.
I'm not sure what your point is. Are you saying that Git cannot determine the set of branch heads that are reachable from any given commit? It is true that the Monotone store format is more explicit than Git's in that regard. Monotone emphasizes branches a lot, and Git doesn't. Both approaches have their pros and cons. However, you (or Michael) cannot reasonably say that "Git throws away history" because of that choice. That is a baseless exaggeration. >> Simply run "git cherry -v stdenv master"; that will give you the >> desired information with fairly high accuracy. > > This shows the commits that are *currently* in one branch but not in > the other. This doesn't let you known whether given commit (which is > already merged both into master and stdenv-updates) first appeared in > stdenv, or in master. I am sorry, I have misunderstand what you were trying to achieve. You are right, "git cherry" doesn't show you that information. "git log" does. >> git rebase master stdenv >> >> Then you'll have a stdenv branch that consists of exactly those patches >> that are unique to stdenv. > > Never ever rebase a published branch. Frankly, if I had an interest in snappy one-liners, I'd be watching an Arnold Schwarzenegger movie instead of discussing software engineering. Take care, Peter _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
