On Saturday, 6 December 2014 05:50:37 UTC-5, Philip Oakley wrote: > > > ---- Original Message ----- > > *From: Stephen Morton* > *To:* git-...@googlegroups.com <javascript:> > *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 > > Thanks Pilip, that's useful.
Your answers gave me enough information to do further web searches to discover that I can use a graft to split up my repo. (Sort of backwards sounding at first, but it works.) Then I can use filter-branch to remove the old code isolated by the graft, and a whole series of garbage collection after that to actually get the repo size down. Steve -- 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.
