Otherwise we would end up getting values from Gecos which is often not
what people would want.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This converts receive-pack to use the standard ref locking code
instead of its own.  As a side effect, it automatically records
the "push" event to ref-log if enabled.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This updates the use of git-update-ref in git-branch, git-tag
and git-commit to make them safer in a few corner cases as
demonstration.

 - git-tag makes sure that the named tag does not exist, allows
   you to edit tag message and then creates the tag.  If a tag
   with the same name was created by somebody else in the
   meantime, it used to happily overwrote it.  Now it notices
   the situation.

 - git-branch -d and git-commit (for the initial commit) had the
   same issue but with smaller race window, which is plugged
   with this.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds -d flag to update-ref to allow safe deletion of ref.
Before deleting it, the command checks if the given <oldvalue>
still matches the value the caller thought the ref contained.

Similarly, it also accepts 0{40} or an empty string as <oldvalue>
to allow safe creation of a new ref.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This drops "mustexist" parameter lock_ref_sha1() and lock_any_ref_forupdate()
functions take.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/lt-ref2-with-lt-refs:
  Fix show-ref usage for --dereference.
  Document git-show-ref [-s|--hash] option.
  Add man page for git-show-ref
  gitignore: git-show-ref is a generated file.
  Use Linus' show ref in "git-branch.sh".
  Add [-s|--hash] option to Linus' show-ref.
  Teach "git checkout" to use git-show-ref
  Add "git show-ref" builtin command

* jc/for-each-ref-with-lt-refs:
  Add git-for-each-ref: helper for language bindings

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

There is a format string vulnerability introduced with the packed refs
file format.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This was lost in the packed-ref updates. The original test was a bit
dubious, so I cleaned that up, too. It fixes the case when the current HEAD
is refs/heads/bla/master: the original test was true for both bla/master
_and_ master.

However, it shares a hard-to-fix bug with the original test: if the current
HEAD is refs/heads/master, and there is a branch refs/heads/heads/master,
then both are marked active.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It called read_ref(git_path(..)..), where read_ref does the git_path()
stuff itself.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* lt/refs: (58 commits)
  git-pack-refs --prune
  pack-refs: do not pack symbolic refs.
  Tell between packed, unpacked and symbolic refs.
  Add callback data to for_each_ref() family.
  symbolit-ref: fix resolve_ref conversion.
  Fix broken sha1 locking
  fsck-objects: adjust to resolve_ref() clean-up.
  gitignore: git-pack-refs is a generated file.
  wt-status: use simplified resolve_ref to find current branch
  Fix t1400-update-ref test minimally
  Enable the packed refs file format
  Make ref resolution saner
  Add support for negative refs
  Start handling references internally as a sorted in-memory list
  gitweb fix validating pg (page) parameter
  git-repack(1): document --window and --depth
  git-apply(1): document --unidiff-zero
  gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export
  upload-archive: monitor child communication even more carefully.
  gitweb: export options
  ...

* lt/refs: (58 commits)
  git-pack-refs --prune
  pack-refs: do not pack symbolic refs.
  Tell between packed, unpacked and symbolic refs.
  Add callback data to for_each_ref() family.
  symbolit-ref: fix resolve_ref conversion.
  Fix broken sha1 locking
  fsck-objects: adjust to resolve_ref() clean-up.
  gitignore: git-pack-refs is a generated file.
  wt-status: use simplified resolve_ref to find current branch
  Fix t1400-update-ref test minimally
  Enable the packed refs file format
  Make ref resolution saner
  Add support for negative refs
  Start handling references internally as a sorted in-memory list
  gitweb fix validating pg (page) parameter
  git-repack(1): document --window and --depth
  git-apply(1): document --unidiff-zero
  gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export
  upload-archive: monitor child communication even more carefully.
  gitweb: export options
  ...

"git pack-refs --prune", after successfully packing the existing
refs, removes the loose ref files.  It tries to protect against
race by doing the usual lock_ref_sha1() which makes sure the
contents of the ref has not changed since we last looked at.

Also we do not bother trying to prune what was already packed, and
we do not try pruning symbolic refs.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now we can tell which one is symbolic and which one is not, it
is easy to do so.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This adds a "int *flag" parameter to resolve_ref() and makes
for_each_ref() family to call callback function with an extra
"int flag" parameter.  They are used to give two bits of
information (REF_ISSYMREF and REF_ISPACKED) about the ref.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is a long overdue fix to the API for for_each_ref() family
of functions.  It allows the callers to specify a callback data
pointer, so that the caller does not have to use static
variables to communicate with the callback funciton.

The updated for_each_ref() family takes a function of type

	int (*fn)(const char *, const unsigned char *, void *)

and a void pointer as parameters, and calls the function with
the name of the ref and its SHA-1 with the caller-supplied void
pointer as parameters.

The commit updates two callers, builtin-name-rev.c and
builtin-pack-refs.c as an example.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

An earlier conversion accidentally hardcoded "HEAD" to be passed to
resolve_ref(), thereby causing git-symbolic-ref command to always
report where the HEAD points at, ignoring the command line parameter.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Current git#next is totally broken wrt. cloning over HTTP, generating refs
at random directories. Of course it's caused by the static get_pathname()
buffer. lock_ref_sha1() stores return value of mkpath()'s get_pathname()
call, then calls lock_ref_sha1_basic() which calls git_path(ref) which
calls get_pathname() at that point returning pointer to the same buffer.
So now you are sprintf()ing a format string into itself, wow! The resulting
pathnames are really cute. (If you've been paying attention, yes, the
mere fact that a format string _could_ write over itself is very wrong
and probably exploitable here. See the other mail I've just sent.)

I've never liked how we use return values of those functions so liberally,
the "allow some random number of get_pathname() return values to work
concurrently" is absolutely horrible pit and we've already fallen in this
before IIRC. I consider it an awful coding practice, you add a call
somewhere and at some other point some distant caller of that breaks since
it reuses the same return values. Not to mention this takes quite some time
to debug.

My gut feeling tells me that there might be more of this.  I don't have
time to review the rest of the users of the refs.c functions though.
Signed-off-by: NPetr Baudis <pasky@suse.cz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

It depended on specific error messages to detect failure but the
implementation changed and broke the test.  This fixes the breakage
minimally.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This actually "turns on" the packed ref file format, now that the
infrastructure to do so sanely exists (ie notably the change to make the
reference reading logic take refnames rather than pathnames to the loose
objects that no longer necessarily even exist).

In particular, when the ref lookup hits a refname that has no loose file
associated with it, it falls back on the packed-ref information. Also, the
ref-locking code, while still using a loose file for the locking itself
(and _creating_ a loose file for the new ref) no longer requires that the
old ref be in such an unpacked state.

Finally, this does a minimal hack to git-checkout.sh to rather than check
the ref-file directly, do a "git-rev-parse" on the "heads/$refname".
That's not really wonderful - we should rather really have a special
routine to verify the names as proper branch head names, but it is a
workable solution for now.

With this, I can literally do something like

	git pack-refs
	find .git/refs -type f -print0 | xargs -0 rm -f --

and the end result is a largely working repository (ie I've done two
commits - which creates _one_ unpacked ref file - done things like run
"gitk" and "git log" etc, and it all looks ok).

There are probably things missing, but I'm hoping that the missing things
are now of the "small and obvious" kind, and that somebody else might want
to start looking at this too. Hint hint ;)
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The old code used to totally mix up the notion of a ref-name and the path
that that ref was associated with.  That was not only horribly ugly (a
number of users got the path, and then wanted to try to turn it back into
a ref-name again), but it fundamnetally doesn't work at all once we do any
setup where a ref doesn't have a 1:1 relationship with a particular
pathname.

This fixes things up so that we use the ref-name throughout, and only
turn it into a pathname once we actually look it up in the filesystem.
That makes a lot of things much clearer and more straightforward.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

You can remove a ref that is packed two different ways: either simply
repack all the refs without that one, or create a loose ref that has the
magic all-zero SHA1.

This also adds back the test that a ref actually has the object it
points to.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This also adds some very rudimentary support for the notion of packed
refs.  HOWEVER! At this point it isn't used to actually look up a ref
yet, only for listing them (ie "for_each_ref()" and friends see the
packed refs, but none of the other single-ref lookup routines).

Note how we keep two separate lists: one for the loose refs, and one for
the packed refs we read. That's so that we can easily keep the two apart,
and read only one set or the other (and still always make sure that the
loose refs take precedence).

[ From this, it's not actually obvious why we'd keep the two separate
  lists, but it's important to have the packed refs on their own list
  later on, when I add support for looking up a single loose one.

  For that case, we will want to read _just_ the packed refs in case the
  single-ref lookup fails, yet we may end up needing the other list at
  some point in the future, so keeping them separated is important ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* sk/ftp:
  Add ftp:// protocol support for git-http-fetch
  http-fetch.c: consolidate code to detect missing fetch target

* jc/pack:
  pack-objects: document --revs, --unpacked and --all.
  pack-objects --unpacked=<existing pack> option.
  pack-objects: further work on internal rev-list logic.
  pack-objects: run rev-list equivalent internally.
  Separate object listing routines out of rev-list

* jc/am:
  Fix git-am safety checks

* jk/diff:
  wt-status: remove extraneous newline from 'deleted:' output
  git-status: document colorization config options
  Teach runstatus about --untracked
  git-commit.sh: convert run_status to a C builtin
  Move color option parsing out of diff.c and into color.[ch]
  diff: support custom callbacks for output

Currently it is possible to give any string ending with a number as
page.  -1 for example is quite bad (error log shows probably 100
warnings).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Copy and pasted from git-pack-objects(1).
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>