tokkee.org

Rework pretty_print_commit to use strbufs instead of custom buffers.

  Also remove the "len" parameter, as:
  (1) it was used as a max boundary, and every caller used ~0u
  (2) we check for final NUL no matter what, so it doesn't help for speed.

  As a result most of the pp_* function takes 3 arguments less, and we need
a lot less local variables, this makes the code way more readable, and
easier to extend if needed.

  This patch also fixes some spacing and cosmetic issues.

  This patch also fixes (as a side effect) a memory leak intoruced in
builtin-archive.c at commit df4a394f (fmt was xmalloc'ed and not free'd)

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

Change semantics of interpolate to work like snprintf.

  Also fix many off-by-ones and a useless memset.

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

Strbuf API extensions and fixes.

  * Add strbuf_rtrim to remove trailing spaces.
  * Add strbuf_insert to insert data at a given position.
  * Off-by one fix in strbuf_addf: strbuf_avail() does not counts the final
    \0 so the overflow test for snprintf is the strict comparison. This is
    not critical as the growth mechanism chosen will always allocate _more_
    memory than asked, so the second test will not fail. It's some kind of
    miracle though.
  * Add size extension hints for strbuf_init and strbuf_read. If 0, default
    applies, else:
      + initial buffer has the given size for strbuf_init.
      + first growth checks it has at least this size rather than the
        default 8192.

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

Merge branch 'master' into ph/strbuf

* master:
  archive - leakfix for format_subst()
  Make --no-thin the default in git-push to save server resources
  fix doc for --compression argument to pack-objects
  git-tag -s must fail if gpg cannot sign the tag.
  git-svn: understand grafts when doing dcommit
  git-diff: don't squelch the new SHA1 in submodule diffs
  Define NO_MEMMEM on Darwin as it lacks the function
  git-svn: fix "Malformed network data" with svn:// servers
  (cvs|svn)import: Ask git-tag to overwrite old tags.
  git-rebase: fix -C option
  git-rebase: support --whitespace=<option>
  Documentation / grammer nit
  archive: rename attribute specfile to export-subst
  archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)
  add memmem()
  Remove unused function convert_sha1_file()
  archive: specfile support (--pretty=format: in archive files)
  Export format_commit_message()

Merge branch 'rs/archive'

* rs/archive:
  archive - leakfix for format_subst()
  Define NO_MEMMEM on Darwin as it lacks the function
  archive: rename attribute specfile to export-subst
  archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)
  add memmem()
  Remove unused function convert_sha1_file()
  archive: specfile support (--pretty=format: in archive files)
  Export format_commit_message()

archive - leakfix for format_subst()

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

Merge branch 'sp/maint-no-thin'

* sp/maint-no-thin:
  Make --no-thin the default in git-push to save server resources
  fix doc for --compression argument to pack-objects
  git-tag -s must fail if gpg cannot sign the tag.

Make --no-thin the default in git-push to save server resources

1) pushes happen less often than fetches, so the bandwidth saving is
   much less visible in that case overall.

2) thin packs have to be complemented with missing delta bases to be
   valid, so many received thin packs will take more disk space.

3) the bother of repacking should be distributed amongst "clients"
   i.e. fetchers and pushers as much as possible, and not the server
   being fetched or pushed, to keep disk and CPU usage low on the
   server.

This is why a fetch should get thin packs but a push should not.

Both Nico and I have been assuming that --no-thin was the default
behavior of git-push ever since Nico introduced --fix-thin into the
index-pack process, which allowed fetch and receive-pack to avoid
exploding packfiles received during transfer.  This patch finally
makes it so.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fix doc for --compression argument to pack-objects

Remove obsolete details (core.legacyheaders is always true now).

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-tag -s must fail if gpg cannot sign the tag.

Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.

If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.

Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status.  They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.

Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long.  This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.

However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.

With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.

Proposed-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  git-svn: understand grafts when doing dcommit
  git-diff: don't squelch the new SHA1 in submodule diffs
  git-svn: fix "Malformed network data" with svn:// servers
  (cvs|svn)import: Ask git-tag to overwrite old tags.
  Documentation / grammer nit

git-svn: understand grafts when doing dcommit

Use the rev-list --parents functionality to read the parents
of the commit.  cat-file only shows the raw object with the
original parents and doesn't take into account grafts; so
we'll rely on rev-list machinery for the smarts here.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-diff: don't squelch the new SHA1 in submodule diffs

The code to squelch empty diffs introduced by commit
fb13227e089f22dc31a3b1624559153821056848 would inadvertently
populate filespec "two" of a submodule change using the uninitialized
(null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output.

This change teaches diffcore_skip_stat_unmatch to handle
submodule changes correctly.

Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Define NO_MEMMEM on Darwin as it lacks the function

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix "Malformed network data" with svn:// servers

We have a workaround for the reparent function not working
correctly on the SVN native protocol servers.  This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.

Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common().  So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

(cvs|svn)import: Ask git-tag to overwrite old tags.

If the tag was moved in CVS or SVN history, it will be moved in the
imported history as well. Tag history is not tracked.

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

git-rebase: fix -C option

The extra shift here causes failure to parse any commandline including
the -C option.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rebase: support --whitespace=<option>

Pass --whitespace=<option> to git-apply.  Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation / grammer nit

If we're counting, a smaller number is 'fewer' not 'less'

Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Use strbuf API in cache-tree.c

  Should even be marginally faster.

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

Use strbuf API in buitin-rerere.c

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

Use strbuf API in apply, blame, commit-tree and diff

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

mktree: Simplify write_tree() using strbuf API

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

fast-import: Use strbuf API, and simplify cmd_data()

  This patch features the use of strbuf_detach, and prevent the programmer
to mess with allocation directly. The code is as efficent as before, just
more concise and more straightforward.

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

Simplify strbuf uses in archive-tar.c using strbuf API

  This is just cleaner way to deal with strbufs, using its API rather than
reinventing it in the module (e.g. strbuf_append_string is just the plain
strbuf_addstr function, and it was used to perform what strbuf_addch does
anyways).

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

Rework strbuf API and semantics.

  The gory details are explained in strbuf.h. The change of semantics this
patch enforces is that the embeded buffer has always a '\0' character after
its last byte, to always make it a C-string. The offs-by-one changes are all
related to that very change.

  A strbuf can be used to store byte arrays, or as an extended string
library. The `buf' member can be passed to any C legacy string function,
because strbuf operations always ensure there is a terminating \0 at the end
of the buffer, not accounted in the `len' field of the structure.

  A strbuf can be used to generate a string/buffer whose final size is not
really known, and then "strbuf_detach" can be used to get the built buffer,
and keep the wrapping "strbuf" structure usable for further work again.

  Other interesting feature: strbuf_grow(sb, size) ensure that there is
enough allocated space in `sb' to put `size' new octets of data in the
buffer. It helps avoiding reallocating data for nothing when the problem the
strbuf helps to solve has a known typical size.

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

archive: rename attribute specfile to export-subst

As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)

As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now.  This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add memmem()

memmem() is a nice GNU extension for searching a length limited string
in another one.

This compat version is based on the version found in glibc 2.2 (GPL 2);
I only removed the optimization of checking the first char by hand, and
generally tried to keep the code simple.  We can add it back if memcmp
shows up high in a profile, but for now I prefer to keep it (almost
trivially) simple.

Since I don't really know which platforms beside those with a glibc
have their own memmem(), I used a heuristic: if NO_STRCASESTR is set,
then NO_MEMMEM is set, too.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://repo.or.cz/git/git-p4

* 'master' of git://repo.or.cz/git/git-p4:
  git-p4: Added support for automatically importing newly appearing perforce branches.
  git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.
  git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.
  git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).
  git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.
  git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.
  git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.
  git-p4: Always call 'p4 sync ...' before submitting to Perforce.

Merge branch 'maint'

* maint:
  Include a git-push example for creating a remote branch
  Cleanup unnecessary file modifications in t1400-update-ref
  Makefile: Add cache-tree.h to the headers list
  Don't allow contrib/workdir/git-new-workdir to trash existing dirs
  git-apply: do not read past the end of buffer

Include a git-push example for creating a remote branch

Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.

This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Cleanup unnecessary file modifications in t1400-update-ref

Kristian Høgsberg pointed out that the two file modifications
we were doing during the 'creating initial files' step are not even
used within the test suite.  This was actually confusing as we do
not even need these changes for the tests to pass.  All that really
matters here is the specific commit dates are used so that these
appear in the branch's reflog, and that the dates are different so
that the branch will update when asked and the reflog entry is
also updated.  There is no need for the file modification.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: Add cache-tree.h to the headers list

The dependency was missing.

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Don't allow contrib/workdir/git-new-workdir to trash existing dirs

Recently I found that doing a sequence like the following:

  git-new-workdir a b
  ...
  git-new-workdir a b

by accident will cause a (and now also b) to have an infinite cycle
in its refs directory.  This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.

This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo".  Plenty of commands start
to see ambiguous ref names and others just take ages to compute.

git-clone has the same safety check, so git-new-workdir should
behave just like it.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-apply: do not read past the end of buffer

When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage.  This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space.  Not good.

The code that follows the part this patch touches tries to match
the fragment with line offsets.  Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.

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

Merge branch 'ds/sendmail'

* ds/sendmail:
  send-email: Add support for SSL and SMTP-AUTH

Function for updating refs.

A function intended to be called from builtins updating refs
by locking them before write, specially those that came from
scripts using "git update-ref".

[jc: with minor fixups]

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Remove unused function convert_sha1_file()

convert_sha1_file() became unused by the previous patch -- remove it.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

archive: specfile support (--pretty=format: in archive files)

Add support for a new attribute, specfile.  Files marked as being
specfiles are expanded by git-archive when they are written to an
archive.  It has no effect on worktree files.  The same placeholders
as those for the option --pretty=format: of git-log et al. can be
used.

The attribute is useful for creating auto-updating specfiles.  It is
limited by the underlying function format_commit_message(), though.
E.g. currently there is no placeholder for git-describe like output,
and expanded specfiles can't contain NUL bytes.  That can be fixed
in format_commit_message() later and will then benefit users of
git-log, too.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Export format_commit_message()

Drop the parameter "msg" of format_commit_message() (as it can be
inferred from the parameter "commit"), add a parameter "template"
in order to avoid accessing the static variable user_format
directly and export the result.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: Added support for automatically importing newly appearing perforce branches.

If a change in a p4 "branch" appears that hasn't seen any previous commit and
that has a known branch mapping we now try to import it properly. First we
find the p4 change of the source branch that the new p4 branch is based on. Then
we using git rev-list --bisect to locate the corresponding git commit to that change.
Finally we import all changes in the new p4 branch up to the current change and resume
with the regular import.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.

Signed-off-by: Simon Hausmann <simon@lst.de>

git-p4: Always call 'p4 sync ...' before submitting to Perforce.

Acked-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-by: Thiago Macieira <thiago@kde.org>

send-email: Add support for SSL and SMTP-AUTH

Allows username and password to be given using --smtp-user
and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
backed by corresponding defaults in the git configuration file.

This implements Junio's 'mail identity' suggestion in a slightly
more generalised manner. --identity=$identity, backed by
sendemail.identity indicates that the configuration subsection
[sendemail "$identity"] should take priority over the [sendemail]
section for all configuration values.

Signed-off-by: Douglas Stockwell <doug@11011.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start 1.5.4 cycle

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

GIT 1.5.3.1: obsolete git-p4 in RPM spec file.

HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.

David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.

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

Typofix: 1.5.3 release notes

GIT 1.5.3

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

Merge branch 'jp/send-email-cc'

* jp/send-email-cc:
  git-send-email --cc-cmd

Mention -m as an abbreviation for --merge

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update my contact address as the maintainer.

Documentation: minor AsciiDoc mark-up fixes.

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

URL: allow port specification in ssh:// URLs

Allow port specification in ssh:// URLs in the
usual notation:

ssh://[user@]host.domain[:<port>]/<path>

This allows git to be used over ssh-tunneling
networks.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Avoid one-or-more (\+) non BRE in sed scripts.

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

rebase -m: Fix incorrect short-logs of already applied commits.

When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:

    o--X--A--B--Y    <- master
     \
      A--B--Z        <- topic

then 'git rebase -m master' would report:

    Already applied: 0001 Y
    Already applied: 0002 Y

With this fix it reports the expected:

    Already applied: 0001 A
    Already applied: 0002 B

As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-diff: resurrect the traditional empty "diff --git" behaviour

The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea.  It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.

This commit reinstates the traditional behaviour, but with a twist.

By default, the empty "diff --git" output is totally squelched out
from "git diff" output.  At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user.  In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.

The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.

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

git-tag: Fix -l option to use better shell style globs.

This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring.  The same
thing now could be achieved doing "git tag -l '*foo*'".

This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.

Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.

Tests for "git tag" were also changed to reflect this.

Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix dcommit clobbering upstream when committing multiple changes

Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.

Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date.  git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.

--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit.  Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.

Thanks to David Watson for finding this and the original test.

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

git-svn: Protect against "diff.color = true".

If the configuration of the user has "diff.color = true", the
output from "log" we invoke internally added color codes, which
broke the parser.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>

filter-branch: introduce convenience function "skip_commit"

With this function, a commit filter can leave out unwanted commits
(such as temporary commits).  It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision.  IOW
no tree object is changed by this.

If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with

git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: provide the convenience functions also for commit filters

Move the convenience functions to the top of git-filter-branch.sh, and
return from the script when the environment variable SOURCE_FUNCTIONS is
set.

By sourcing git-filter-branch with that variable set automatically, all
commit filters may access the convenience functions like "map".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase -i: mention the option to split commits in the man page

The interactive mode of rebase can be used to split commits.  Tell the
interested parties about it, with a dedicated section in the man page.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: fix remnants of old syntax in documentation

Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time.  This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.

This updates the last leftovers in the documentation to reflect the
new behavior.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Teach bash about completing arguments for git-tag

Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`.  In both such cases being able to complete the names
of existing tags saves the fingers some typing effort.  We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.

When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.

If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Hopefully the final update to draft release notes for 1.5.3.

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

Make "git-log --" without paths behave the same as "git-log" without --

"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so.  It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
libifying revlist generation).

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

git-init: autodetect core.symlinks

We already autodetect if filemode is reliable on the filesystem
to deal with VFAT and friends.  Do the same for symbolic link
support.

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

Make git-archimport log entries more consistent

When appending the "git-archimport-id:" line to the end of log entries,
git-archimport would use two blank lines as a separator when there was no
body in the arch log (only a Summary: line), and zero blank lines when there
was a body (making it hard to see the break between the actual log message
and the git-archimport-id: line).

This patch makes git-archimport generate one blank line as a separator in all
cases.

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

fix same sized delta logic

The code favoring shallower deltas when size is equal was triggered
only when previous delta was also cached.  There should be no relation
between cached deltas and same sized deltas.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: make sure orig_namespace ends with a single slash.

Later in a loop any existing ref whose path begins with it is
removed.  It would be a disaster if you allowed it to say refs/head
for example.

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

git-filter-branch: document --original option

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-filter-branch: more detailed USAGE

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: do not allow gnu make to remove test-*.o files

It appears parallel build (-j) gets confused.

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

Temporary fix for stack smashing in mailinfo

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fixing comment in merge strategies

Comments in both these strategies refer to the wrong number
of remotes

Signed-off-by: Tom Clarke <tom@u2i.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-files --error-unmatch: do not barf if the same pattern is given twice.

This is most visible when you do "git commit Makefile Makefile"; it
may be a stupid request, but that is not a reason to fail the command.

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

Merge branch 'master' of git://git./gitk/gitk

* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Fix bug causing undefined variable error when cherry-picking

completion: also complete git-log's --left-right and --cherry-pick option

Both --left-right and --cherry-pick are particularly long to type, so
help the user there.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitk: Fix bug causing undefined variable error when cherry-picking

When "Show nearby tags" is turned off and the user did a cherry-pick,
we were trying to access variables relating to the descendent/ancestor
tag & head computations in addnewchild though they hadn't been set.
This makes sure we don't do that.  Reported by Johannes Sixt.

Signed-off-by: Paul Mackerras <paulus@samba.org>

git-daemon(1): assorted improvements.

Jari Aalto noticed a handful places in git-daemon documentation
that need to be improved.

 * --inetd makes --pid-file to be ignored, in addition to --user
   and --group

 * receive-pack service was not described at all.  We should, if
   only to warn about the security implications of it.

 * There was no example of per repository configuration.

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

GIT 1.5.3-rc7

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

git-svn.txt: fix an obvious misspelling.

Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git.el: Added colors for dark background

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

format-patch documentation: reword to hint "--root <one-commit>" more clearly

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

Merge branch 'jc/logsemantics'

* jc/logsemantics:
  "format-patch --root rev" is the way to show everything.
  Porcelain level "log" family should recurse when diffing.

Documentation/git-diff: A..B and A...B cannot take tree-ishes

As pointed out by Linus, these notations require the endpoints
given by the end user to be commits.  Clarify.

Also, three-dots in AsciiDoc are turned into ellipses unless
quoted with bq.  Be careful.

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

git-add: Make the filename globbing note a bit clearer

I think the trick with Git-side filename globbing is important and perhaps
not that well known.  Clarify a bit in git-add documentation what it means.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add: Make the "tried to add ignored file" error message less confusing

Currently the error message seems to imply (at least to me) that only
the listed files were withheld and the rest of the files was added to the
index, even though that's obviously not the case.

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: Fix escaping HTML of project owner in 'projects_list' and
'summary' views

This for example allows to put email address in the project owner
field in the projects index file (when $projects_list points to
a file, and not to a directory), in the form of:

path/to/repo.git Random+J+Developer+<random@developer.example.org>

Noticed-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"format-patch --root rev" is the way to show everything.

We used to trigger the special case "things not in origin"
semantics only when one and only one positive ref is given, and
no number (e.g. "git format-patch -4 origin") was specified, and
used the general revision range semantics for everything else.

This narrows the special case a bit more, by making:

git format-patch --root this_version

to show everything that leads to the named commit.

More importantly, document the two different semantics better.
The generic revision range semantics came later and bolted on
without being clearly documented.

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

Porcelain level "log" family should recurse when diffing.

Most notably, "git log --name-status" stopped at top level
directory changes without "-r" option.

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

git-merge: do up-to-date check also for all strategies

This clarifies the logic to omit fast-forward check and omit
trivial merge before running the specified strategy.

The "index_merge" variable started out as a flag to say "do not
do anything clever", but when recursive was changed to skip the
trivial merge, the semantics were changed and the variable alone
does not make sense anymore.

This splits the variable into two, allow_fast_forward (which is
almost always true, and avoids making a merge commit when the
other commit is a descendant of our branch, but is set to false
for ours and subtree) and allow_trivial_merge (which is false
for ours, recursive and subtree).

Unlike the earlier implementation, the "ours" strategy allows an
up-to-date condition.  When we are up-to-date, the result will
be our commit, and by definition, we will have our tree as the
result.

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

git --bare cmd: do not unconditionally nuke GIT_DIR

"GIT_DIR=some.where git --bare cmd" and worse yet
"git --git-dir=some.where --bare cmd" were very confusing.  They
both ignored git-dir specified, and instead made $cwd as GIT_DIR.

This changes --bare not to override existing GIT_DIR.

This has been like this for a long time.  Let's hope nobody sane
relied on this insane behaviour.

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

Fix initialization of a bare repository

Here is my attempt to fix this with a minimally intrusive patch.

 * As "git --bare init" cannot tell if it was called with --bare or
   just "GIT_DIR=. git init", I added an explicit assignment of
   is_bare_repository_cfg on the codepath for "git --bare".

 * GIT_WORK_TREE alone without GIT_DIR does not make any sense,
   nor GIT_WORK_TREE with an explicit "git --bare".  Catch that
   mistake.  It might make sense to move this check to "git.c"
   side as well, but I tried to shoot for the minimum change for
   now.

 * Some scripts, especially from the olden days, rely on
   traditional GIT_DIR behaviour in "git init".  Namely, these
   are some notable patterns:

   (create a bare repository)
   - mkdir some.git && cd some.git && GIT_DIR=. git init
   - mkdir some.git && cd some.git && git --bare init

   (create a non-bare repository)
   - mkdir .git && GIT_DIR=.git git init
   - mkdir .git && GIT_DIR=`pwd`/.git git init

This comes with a new test script and also passes the existing
test suite, but there may be cases that are still broken with
the current tip of master and this patch does not yet fix.  I'd
appreciate help in straightening this mess out.

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