---- Original Message -----
From: Stephen Morton
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
For more options, visit https://groups.google.com/d/optout.