---- Original Message ----- From: Stephen Morton To: [email protected] 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 61380 $> git log master --oneline | wc -l 262792 $ > 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!) -- Philip -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
