| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
IIRC our strategy was to let the users' umask take care of the
final mode bits. This patch fixes places that deviate from it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
| |
|
|
|
| |
Mainly making a lot of local functions and variables be marked "static",
but there was a "zero as NULL" warning in there too.
|
| |
|
|
|
| |
It needed to take the GIT_DIR information into account, something that
the original receive-pack usage just never cared about.
|
| |
|
|
| |
This turns it into a generic "do xyz for each ref" library function.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes the receiver always send a full list of valid refs, which
will allow us to do better packs, as well as handle creation of new
refs. Eventually. Right now we just moved the matching and enabled it.
So now you can do
git-send-pack host:path branch1 branch2
to only send branches "branch1" and "branch2".
|
| |
|
|
|
|
|
|
|
| |
A "old ref" of all zeroes is considered a "don't care" ref, and allows
us to say "write the new ref regardless of what the old ref contained
(or even if it existed at all)".
This allows (if git-send-pack were to do it) creating new refs, and
fixing up old ones.
|
| |
|
|
|
|
| |
After unpacking the object pack successfully, we go through the list of
refs, and verify that they still contain their expected values. Then we
replace them with the new ones.
|
| |
|
|
| |
We don't act on them yet, but we parse them.
|
| | |
|
| | |
|
|
|
It's not working yet, but it's at the point where I want to be able to
track my changes. The theory of operation is that this is the "remote"
side of a "git push". It can tell us what references the remote side
has, receives out reference update commands and a pack-file, and can
execute the unpacking command.
|
