Hi Jakub,
Jakub Narebski wrote:
> Gelonida <gelonida@xxxxxxxxx> writes:
>
>> We have a git repository, whose size we want to reduce drastically due
>> to frequent clone operations and a slow network connection.
>
> Why frequent *clone* operations, instead of using "git fetch" or
> equivalent ("git pull" which is fetch+merge, or "git remote update")?
The clone is part of the deployment process and would IIRC be equivalent
to a 'svn export'
Almost certainly one can also improve this, but this should probably
discussed in another thread.
The sequence on some remote hosts is.
- git clone tag dirname
- rm -rf dirname/.git
- tar cvfz dirname.tgz dirname
>
> If network is slow, you can do what others did in similar situations:
> use hook to allow only not to large fetches (to prevent cloning)
> directly on server, and provide bundle (see git-bundle(1)) to "seed"
> the clone; it can be on dumb server (served resumably), and can be
> also served by BitTorrent or equivalent.
The server NW is fast, but the clients' network connection not therefore
no need to offload the server.
>
>> The idea is following:
>>
>> * archive the git repository just in case we really have to go back in
>> history.
>>
>>
>> create a new git repository, which shall only contain last month's activity.
>>
>> all changes before should be squashed together.
>> It would be no problem if the very first commit remains unmodified.
>
> If you want to simply _remove_ history before specified commit,
> instead of squashing it, the best solution would be to use grafts to
> cauterize (cut) history, check using [graphical] history viewer that
> you cut it correctly, and then then use git-filter-branch to make this
> cut permanent.
This sounds exactly as what I'd like to do.
I used "git gui" => "Visualize All Branch History" y to choose a nice
single cutoff point.
I just didn't know how to apply the cut.
So the command to look for is git-filter-branch, right ?
I'll read the doc.
>
> You can later use grafts or refs/replaces/ mechanism to join "current"
> history with historical repository.
Probably we wont need this, but this sounds rather interesting and is
good to know.
Thanks a lot
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html