Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-cvsserver has been moved from libexecdir to bindir.
Signed-off-by: NQuy Tonthat <qtonthat@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* cb/maint-update-ref-fix:
  push: fix local refs update if already up-to-date
  do not force write of packed refs

* cj/maint-gitpm-fix-maybe-self:
  Git.pm: do not break inheritance

* ar/maint-mksnpath:
  Use git_pathdup instead of xstrdup(git_path(...))
  git_pathdup: returns xstrdup-ed copy of the formatted path
  Fix potentially dangerous use of git_path in ref.c
  Add git_snpath: a .git path formatting routine with output buffer
  Fix potentially dangerous uses of mkpath and git_path
  Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
  Add mksnpath which allows you to specify the output buffer

Conflicts:
	builtin-revert.c
	rerere.c

* mv/maint-branch-m-symref:
  update-ref --no-deref -d: handle the case when the pointed ref is packed
  git branch -m: forbid renaming of a symref
  Fix git update-ref --no-deref -d.
  rename_ref(): handle the case when the reflog of a ref does not exist
  Fix git branch -m for symrefs.

git push normally updates local refs only after a successful push. If the
remote already has the updates -- pushed indirectly through another repository,
for example -- we forget to update local tracking refs.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We force writing a ref if it does not exist. Originally, we only had to look
for the ref file to check if it existed. Now we have to look for a packed ref
as well. Luckily, resolve_ref already does all the work for us.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Even long timers seem to have missed that "format-patch -1 $commit" is a
much simpler and more obvious way to say "format-patch $commit^..$commit"
from the current documentation (and an example "format-patch -3 $commit"
to get three patches).  Add an explicit instruction in a much earlier part
of the documentation to make it easier to find.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Also fix error in diff_filepair::status documentation, and point to
the in-code reference as well as the doc.
Signed-off-by: NYann Dirson <ydirson@altern.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMikael Magnusson <mikachu@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* js/maint-fetch-update-head:
  pull: allow "git pull origin $something:$current_branch" into an unborn branch
  Fix fetch/pull when run without --update-head-ok

* jk/maint-ls-files-other:
  refactor handling of "other" files in ls-files and status

* jc/maint-reset-remove-unmerged-new:
  reset --hard/read-tree --reset -u: remove unmerged new paths

* jc/maint-co-track:
  Enhance hold_lock_file_for_{update,append}() API
  demonstrate breakage of detached checkout with symbolic link HEAD
  Fix "checkout --track -b newbranch" on detached HEAD

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Gmail is one of the most popular email providers in the world. Now that Gmail
supports IMAP, sending properly formatted patches via `git imap-send` is
trivial. This section in SubmittingPatches explains how to do so.
Signed-off-by: NTom Preston-Werner <tom@github.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This makes attributes easier to find; before this patch some
attributes had individual subsections, and some didn't.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPierre Habouzit <madcoder@debian.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since no version of receive-pack accepts these "funny refs", we should
mirror the check when considering the list of refs to send. IOW, don't
even make them eligible for matching or mirroring.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The comments for normalize_absolute_path explicitly claim
that the source and destination buffers may be the same
(though they may not otherwise overlap). Thus the call to
memcpy may involve copying overlapping data, and memmove
should be used instead.

This fixes a valgrind error in t1504.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In the main loop of find_deltas, we do:

  struct object_entry *entry = *list++;
  ...
  if (!*list_size)
	  ...
	  break

Because we look at and increment *list _before_ the check of
list_size, in the very last iteration of the loop we will
look at uninitialized data, and increment the pointer beyond
one past the end of the allocated space. Since we don't
actually do anything with the data until after the check,
this is not a problem in practice.

But since it technically violates the C standard, and
because it provokes a spurious valgrind warning, let's just
move the initialization of entry to a safe place.

This fixes valgrind errors in t5300, t5301, t5302, t303, and
t9400.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Most cache_entry structs are allocated by using the
cache_entry_size macro, which rounds the size of the struct
up to the nearest multiple of 8 bytes (presumably to avoid
memory fragmentation).

There is one exception: the special "conflict entry" is
allocated with an empty name, and so is explicitly given
just one extra byte to hold the NUL.

However, later code doesn't realize that this particular
struct has been allocated differently, and happily tries
reading and copying it based on the ce_size macro, which
assumes the 8-byte alignment.

This can lead to reading uninitalized data, though since
that data is simply padding, there shouldn't be any problem
as a result. Still, it makes sense to hold the padding
assumption so as not to surprise later maintainers.

This fixes valgrind errors in t1005, t3030, t4002, and
t4114.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Help identify aspell version on Windows too

In this case we did nothing in the past, but we should delete the
reference in fact.

The problem was that when the symref is not packed but the referenced
ref is packed, then we assumed that the symref is packed as well, but
symrefs are never packed.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NDeskin Miller <deskinm@umich.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The documentation spoke of the attribute being set "to" a path; this can
mistakenly be interpreted as "the attribute needs to have its value set to
some kind of path". This clarifies things.
Signed-off-by: NJan Krüger <jk@jk.gs>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMarkus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.
Signed-off-by: NAlex Riesen <ariesen@harmanbecker.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This allows us replace perl when getting the mtime of a file because
of time zone conversions, though at the moment only one platform which
does this has been identified: Cygwin when used with ActiveState Perl
(as usual).

The output format is:

    <mtime1> TAB <filename1> <LF>
    <mtime2> TAB <filename2> <LF>
    ...

which, if only mtime is needed can be parsed with cut(1):

    test-chmtime -v +0 filename1 | cut -f 1

Also, the change adds a description of programs features, with examples.
Signed-off-by: NAlex Riesen <ariesen@harmanbecker.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Insert an empty <simpara> in manpages after code blocks to force and
empty line.

The problem can be seen on the manpage for the git tutorial, where an
example command and the following paragraph is printed with no empty
line between them:

     First, note that you can get documentation for a command such as git
     log --graph with:

         $ man git-log
     It is a good idea to introduce yourself to git [...]
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The function's purpose is to replace git_path where the buffer of
formatted path may not be reused by subsequent calls of the function
or will be copied anyway.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Probably happened when working around git_path's problem with returned
buffer being reused.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There may be cases where one would really want to rename the symbolic
ref without changing its value, but "git branch -m" is not such a
use-case.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we refuse to do rename detection due to having too many files
created or deleted, let the user know the numbers.  That way there is a
reasonable starting point for setting the diff.renamelimit option.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is one of the server side programs and needs to be found on usual $PATH.
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>