Graham Hay <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
