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. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
