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

[Yury G. Kudryashov]

Peter Simons wrote:

> Hi Yury,
> 
>  >> I'm not sure what you mean. On what occasion does Git throw away
>  >> history?
>  >
>  > Michael means that git has no "branch" concept, only "branch head"
>  > concept.
> 
> I'm not sure whether I follow. Given a branch head, the corresponding
> "branch" is the sequence of ancestors from that head. Where is the
> problem? And how is Git supposed to be different in that regard from
> other DCVS, like monotone?
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.
> 
>  > Suppose that you have two branches, "master" and "stdenv". As usual,
>  > you merge master->stdenv every day or two and you merge
>  > stdenv->master every month or two. Then it is not possible to search
>  > for commits that first appeared in stdenv.
> 
> Actually, that is no problem at all. I use that exact setup every day to
> maintain the various ~/dot.something files for my home directories on
> different machines. There are plenty of ways to accomplish what you
> describe. 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.

> An alternative and arguably superior solution is to run:
> 
>   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.