That all seems quite reasonable, and is what I would expect to happen.
However at the moment, if I create a branch from master and edit one
line in one file,
with no other changes on the remote, it takes me over an hour to push
the new branch.
On 19 March 2015 at 18:36, Junio C Hamano wrote:
> Graham Hay writes:
>
>> We have a fairly large repo (~2.4GB), mainly due to binary resources
>> (for an ios app). I know this can generally be a problem, but I have a
>> specific question.
>>
>> If I cut a branch, and edit a few (non-binary) files, and push, what
>> should be uploaded? I assumed it was just the diff (I know whole
>> compressed files are used, I mean the differences between my branch
>> and where I cut it from). Is that correct?
>
> If you start from this state:
>
> (the 'origin')(you)
> ---Z---A clone ->---Z---A
>
> and edit a few files, say, a/b, a/c and d/e/f, and committed to make
> the history look like this:
>
> (the 'origin')(you)
> ---Z---A ---Z---A---B
>
> i.e. "git diff --name-only A B" would show these three files, then
> the next push from you to the origin, i.e.
>
> (the 'origin')(you)
> ---Z---A---B<- push ---Z---A---B
>
> would involve transferring from you to the origin of the following:
>
> * The commit object that holds the message, authorship, etc. for B
> * The top-level tree object of commit B (as that is different from
>that of A)
> * The tree object for 'a', 'd', 'd/e' and the blob object for
>'a/b', 'a/c', and 'd/e/f'.
>
> However, that assumes that nothing is happening on the 'origin'
> side.
>
> If the 'origin', for example, rewound its head to Z before you
> attempt to push your B, then you may end up sending objects that do
> not exist in Z that are reachable from B. Just like the above
> bullet points enumerated what is different between A and B, you
> can enumerate what is different between Z and A and add that to the
> above set. That would be what will be sent.
>
> If the 'origin' updated its tip to a commit you do not even know
> about, normally you will be prevented from pushing B because we
> would not want you to lose somebody else's work. If you forced such
> push, then you may end up sending a lot more.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
