[Nix-dev] Re: DVCS - what we care about?

Yury G. Kudryashov urkud+nix at ya.ru
Fri Aug 13 14:39:30 CEST 2010


Peter Simons wrote:

> 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?
The point *is* that concept of "branch head" differs from (say, svn) concept 
of branch. More details below.
> 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.
I don't say "git throws away history" but let me give you example of loosed 
information.

<initial commit>
git co -b stdenv
git ci <-- commit A
git co master
git ci <-- commit B
git co stdenv; git merge master <-- commit C
git co master; git merge stdenv <-- (fast-forward) commit C

Now "master" and "stdenv" point to the same vertex, and you can't easily 
search for commits made in "stdenv" (i.e. A) versus commits made in "master" 
(i.e. B).

>  >> 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.
How does git log help? AFAICS, it is not possible to answer this question 
with git (OK, you can read commit messages yourself, but AFAIK there is no 
meta-info for this).
> 
>  >>   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.
man git-rebase
/RECOVERING FROM UPSTREAM REBASE
(second match)




More information about the nix-dev mailing list