From: Cory Fields <FOSS@AtlasTechnologiesInc.com>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org
Subject: Re: 'git replace' and pushing
Date: Fri, 26 Nov 2010 16:16:39 -0500 [thread overview]
Message-ID: <AANLkTimQ3fjPb+YVJ5i8EAgui+gd5rfnXMvdQPJPeUtA@mail.gmail.com> (raw)
In-Reply-To: <4CEE2060.4020507@drmicha.warpmail.net>
On Thu, Nov 25, 2010 at 3:37 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Cory Fields venit, vidit, dixit 24.11.2010 05:33:
>> I am having some trouble understanding how a replaced object (commit)
>> should behave when pushed to a remote repo. Here's my scenario:
>>
>> We are moving from svn to git. Our svn repo is huge, and most of the
>> history is useless. To save space, I would like to do a 50/50 split so
>> that when the repo is cloned, 50% is seen by default, and the
>> historical 50% can be seen by fetching the replacement history. I've
>> done this by creating a phony snapshot at 3 then using a 'replace' to
>> put the others on top. The history is purely linear.
>>
>> 1---2---3---4---5
>> \---4---5
>
> I assume the "other" 4 goes off 3 (you're not using a monospaced font,
> are you?).
>
I used a monospace font, but gmail decided not to use it. Sorry for that.
> Also, the other 4 should have no parent, otherwise you've not cut-off
> any history.
I created a "fake" 4 that consists of the full working tree at 4 with no parent.
As I mentioned, everything looks fine locally.
>
>>
>> When the replacement is in place, the repo is half size (commit-wise)
>> as expected. The problem is that 'git push' does not honor the
>> replace. So when I push, all objects go with it, which defeats the
>> purpose. The only way that seams to work is doing a filter-branch and
>> replacing the other way.
>>
>> Is this by design? I would really like a way to split the repo without
>> breaking hashes for the developers that have already begun using git
>> svn.
>
> It is by design since a replace creates a "fake history", and this
> should not be created behind a users back.
>
> The 5 is not rewritten, and it's ancestry contains the whole history. If
> that is the commit your developers have already and that you want to
> preserve then there's not much you can do.
>
> You could try to push or pull your replacement refs first (refs/replace)
> but I don't think this will change what objects the push of 5 will
> transfer. Just have a try.
I tried this to no avail.
I realize that allowing replacements to be pushed "behind users backs", so
I guess not respecting it makes sense.
But is there no way that I can pull this off without rewriting hashes?
Thanks,
Cory
next prev parent reply other threads:[~2010-11-26 21:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 4:33 'git replace' and pushing Cory Fields
2010-11-25 8:37 ` Michael J Gruber
2010-11-26 21:16 ` Cory Fields [this message]
2010-11-26 21:43 ` Jonathan Nieder
2010-11-26 23:18 ` Junio C Hamano
2010-11-27 1:58 ` Cory Fields
2010-11-26 20:29 ` Martin von Zweigbergk
2010-11-27 1:59 ` Cory Fields
2010-11-27 7:52 ` Jonathan Nieder
2010-11-27 17:54 ` Cory Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimQ3fjPb+YVJ5i8EAgui+gd5rfnXMvdQPJPeUtA@mail.gmail.com \
--to=foss@atlastechnologiesinc.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).