Graham Hay <grahamr...@gmail.com> 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

Reply via email to