---- Original Message ----- 
  From: Stephen Morton 
  To: git-users@googlegroups.com 
  Sent: Friday, December 05, 2014 7:11 PM
  Subject: [git-users] Behavior of 'git clone --depth <d> --no-single-branch' ? 
It's not doing at all what I expect.

  I'm trying to make a slice of a very large repo, discarding old history.

  I'm doing this which I figure should take me back enough time.

  git clone --depth 9320 --no-single-branch ssh://URL

  But then the resulting repo has the entire history. Neither the whole 
history, nor the master branch history have been truncated to 9,320 changesets. 
It's as if the --depth parameter is being ignored.

   $ > git log --oneline --all | wc -l
   $> git log master --oneline | wc -l

   $ > git --version
  git version 2.1.3

  Am I doing something wrong, or misunderstanding something?

Most likely misunderstanding something ;-)
That something is probably that the depth is around each leg of the DAG, so 
merges can create shortcuts which suck in a lot of other commits you hadn't 
expected (at least that's my understanding). This includes old redundant 
branches which are way back in history!
The other option, which is a bit of a guess, is that you are getting the depth 
from the various tags as well.

As a follow-up question, what I really want to do is to split a repo up, with 
the newer history in one part and the older history in the other. Ideally, I 
would pick a changeset and it and all its descendants would be in the newer 
part and its ancestors (and their descendants) would be in the other part. This 
strikes me as a better, more branch-aware way of splitting up a repo. 
Try using 'git filter-branch' for creating new repos. Filter the branches based 
on say commit date, or some measure of depth (to cover clock errors between 
committer machines). Obviously, you'l need to run it twice, once to create the 
older segment, and once for the new segment.

Don't forget that all the 'new repo' commits will get new sha1 values because 
their history 'changed' (amputation below date X), so you will need a change 
over date when your developers check everything in, you do the remaining split, 
and then they checkout against the new repo sha1s.

Alternatively, just clone the repo and hard delete the old unwanted branches 
followed by a garbage collect. This leaves you with just your master (trunk) 
branch and a few current ones, hopefully spliced high up the commit tree. 
(assumes a DAG shape that is ammenable to such pruning ;-) [because you have a 
clone of your old you will have sha1 continuity across and between the many 
distributed partial copies]

As yet there is no way of doing a --timedepth=<time_t val> fetch, which would 
be ideal. (As they say, contributions welcome!)

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to