The location alt_odb[j].name[0..] is filled with ??/?{38} to form a sha1
filename to try, but I was too lazy to allocate a copy, so while
fsck_object_dir() is running for the directory, the filenames ??/?{38}
are filled after NUL (usually and always the location should have '/'),
making them "not found".
This should fix it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We used to print the index of the object we unpacked, not how many we
had unpacked. Which caused slightly confusing progress reports like
100% (2/3) done
rather than the more obvious "3/3" for 100% ;)
Add write_sha1_to_fd(), which writes an object to a file descriptor. This
includes support for unpacking it and recompressing it.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This ends up being very calming for big "git clone"s, since otherwise
you just get very frustrated with a long silence, wondering whether it's
working at all.
Use "-q" to quiet it down.
Now if we could just do the same for the initial "figure out what to
pack" phase, which can also be quite slow if the other end is busy (or
not packed and not in cache)...
If it is fed a commit with more than one leading blank lines,
the sed scripts git-format-patch-script used looped forever.
Using git-stripspace upfront makes the sed script somewhat
simpler to work around this problem.
Also use git-rev-parse so that we can say
$ git-format-patch-script HEAD^^^^
to prepare the latest four patches for e-mail submission.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add notes on branches, merging, tagging, and update some of the usage to
the friendlier "git cmd" syntax.
It's still ridiculously lacking, but perhaps it's a _bit_ more useful.
Instead of having to cut-and-paste the result, write it to the tag
directory directly. Also, start an editor for the tag message, rather
than just reading it from stdin.
It used to do "Merge $3" as the message, but that ends up being
inconvenient, and much more easily done inside git-pull-script instead.
This makes the third argument to "git resolve" much easier to explain.
Change git-update-cache --refresh behaviour to use sha1's rather than
comparing byte by byte.
[JC demangled whitespace from the posted patch himself because he
liked it so much. Also adjusted to the index_fd() interface
slightly done differently from the original one.]
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add --info-only option to git-update-cache.
[JC demangled whitespace from the posted patch himself because he
liked it so much. Also adjusted to the index_fd() interface
slightly done differently from the original one.]
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch makes the first half of write_sha1_file() and
index_fd() externally visible, to allow callers to compute the
object ID without actually storing it in the object database.
[JC demangled the whitespaces himself because he liked the patch
so much, and reworked the interface to index_fd() slightly,
taking suggestion from Linus and of his own.]
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This silently adds the ".git" directory component if needed, so you
don't need to state it explicitly for the source. Also, it turns the
source into an absolute pathname when local, so that you can use
relative pathnames without losing sight of the source when we cd into
the destination.
The protocol always supported it, but send-pack didn't actually know how
to tell the other side about a new branch/tag.
NOTE! You'll have to name it explicitly on the command line: if you
don't name any branches, git-send-pack will default to the branches that
already exist.
It always uses a git-relative pathname, ie "refs/heads/master" instead of
".git/refs/heads/master" or whatever your GIT_DIR might be.
This way when we send refs back-and-forth between repositories, there's
never any question about GIT_DIR on either side.
This tries to be more lenient to the users and stricter to the
attackers by quoting the input properly for shell safety,
instead of forbidding certain characters from the input.
Things to note:
- We do not quote "prog" parameter (which comes from --exec).
The user should know what he is doing. --exec='echo foo'
will supply the first two parameters to the resulting
command, while --exec="'echo foo'" will give the first
parameter, a single string with a space inside.
- We do not care too much about leaking the sq_quote() output
just before running exec().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A useful shell safety helper sq_expand() was hidden as a static
function in diff.c. Extract it out and make it available as
sq_quote().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It sets up the normal git environment variables and a few helper
functions (currently just "die()"), and returns ok if it all looks like
a git archive. So use it something like
. git-sh-setup-script || die "Not a git archive"
to make the rest of the git scripts more careful and readable.
This is the script I use to prepare patches for e-mail submission.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I still worry about just quoting things when passing it off to "ssh" or
"sh -c", so I'm being anal. But _, ^ and , are certainly ok and while
both ~ and @ can have speacial meaning to shell/ssh they are benign.
The Makefile in the test suite directory considers any file
matching t[0-9][0-9][0-9][0-9]-*.sh as the top-level test script
to be executed. Unfortunately this was not documented, and the
common test library, t6000-lib.sh was named to match that
pattern. This caused t6000-lib.sh to be called from Makefile as
the top-level program, causing it to leave t/sed.script file
behind. Rename it to t6000lib.sh to prevent this, and document
the naming convention a bit more clearly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When we are cloning a repository on a local filesystem, it is
faster to just create a hard linkfarm of .git/object hierarchy
and copy the .git/refs files. By default, the script uses the
clone-pack method, but it can be told with the -l flag to do the
hard linkfarm (falling back on recursive file copy) to replicate
the .git/object hierarchy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
targets: git.spec, dist, and rpm. A simple 'make rpm' will build the rpm.
Also adds git.spec.in which is used to generate git.spec.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Replace (*f)() with f() where the former idiom was used in epoch.c
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This change ensures that git-rev-list --merge-order produces the same result
irrespective of what position the --merge-order argument appears in the argument
list.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When sed uses \n rather than ; as a separator (for BSD sed(1) compat),
it is cleaner to use a file directly, rather than an environment
variable containing \n characters.
This change changes t/t6000 write to sed.script directly and changes
the other tests to remove knowledge of sed.script.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It's cheaper to calculate, and doesn't give different results depending
on the order of the arguments passed in (and is thus more appropriate
for something like gitk that can validly take the unordered "--all" flag
to show all branches).
The previous dup fix seems to have fixed --topo-order. Holler if you
still see problems.
That's what we should have done in the first place, since it not only
avoids another unnecessary flag, it also protects the commits from
showing up as duplicates later when they show up as parents of another
commit (in the pop_most_recent_commit() path).
This will hopefully also fix --topo-sort.
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>
The function write_one_ref() is passed the list of refs received
from the other end, which was obtained by directory traversal
under $GIT_DIR/refs; this can contain paths other than what
git-init-db prepares and would fail to clone when there is
such.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch passes the test case introduced by the previous patch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This test case demonstrates a problem with --merge-order.
A
|
B
|\
C D
|/
E
|
F
git-rev-list --merge-order A B doesn't produce the expected output of
A
B
D
C
E
F
The problem is fixed by a subsequent patch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch implements a small tidy up of rev-list.c to reduce
(but not eliminate) the amount of ugliness associated
with the merge_order flag.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
