Use the comment in the code to document the --exclude-existing
function to git-show-ref.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unlike 'patch --fuzz=NUM', which specifies the number of lines allowed
to mismatch, 'git-apply -CNUM' requests the match of NUM lines of
context. Omitting -C requests full context match, and that's what
should be used for cvsexportcommit -p.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This bug has been around since the the conversion to use the
Git.pm library back in October or November. Eventually I'd like
"git rev-list/log" to have the option to not truncate overly
long messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When patches are merged from another git-svn managed branch,
they will have the git-svn-id: metadata line in them (generated
by git-format-patch).
When doing rebase or dcommit via git-svn, this would cause
git-svn to find the wrong upstream branch. We now verify
that the commit is consistent with the value in the .rev_db
file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a typo: s/Not/Note/
Some formating fixes: Use ` ` syntax for all filenames and
' ' syntax for all commandline switches.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Every time _any_ documentation page changed, cmds-*.txt files
were regenerated, which caused git.{html,txt} to be remade. Try
not to update cmds-*.txt files if their new contents match the
old ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The libiconv on Darwin uses the old iconv() interface (2nd argument is a
const char **, instead of a char **). Add OLD_ICONV to the Darwin
variable definitions to handle this.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the test 'compare delta flavors', /usr/bin/stat is used to get file size.
This isn't portable. There already is a dependency on Perl, use its '-s'
operator to get the file size.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the knowledge about .git/config usage out of refs.c and into
builtin-branch.c instead, which allows git-branch to update HEAD to point
at the moved branch before attempting to update the config file. It also
allows git-branch to exit with an error code if updating the config file
should fail.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git_config_rename_section() fails, rename_ref() used to return 1, which
left HEAD pointing to an absent refs/heads file (since the actual renaming
had already occurred).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The renaming without config test changed a branch from q to Q, which
fails on non-case sensitive file systems. Change the test to use q
and q2.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The number of characters in a line MUST be no more than 998 characters,
and SHOULD be no more than 78 characters (RFC2822).
It is much safer to fold the header by ourselves.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use ' ' syntax for all commandline options mentioned in text.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current order the options are documented in makes no sense
at all to me. Reorder them so that similar options are grouped
together and also order them somehwhat by importance.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Actually tell the user what he did wrong in case of usage errors
instead of only printing the general usage information.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document the fact that git-cvsimport tries to find out CVSROOT from
CVS/Root and $ENV{CVSROOT} and CVS_module from CVS/Repository.
Also use ` ` syntax for all filenames for consistency.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sync both the usage lines in the code and the asciidoc
documentation with the real list of options. While
all options seems to be documented in the asciidoc
document, not all of them were listed in the usage line.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user is trying to apply a Git generated diff file and they
have specified a -p<n> option, where <n> is not 1, the user probably
has a good reason for doing this. Such as they are me, trying to
apply a patch generated in git.git for the git-gui subdirectory to
the git-gui.git repository, where there is no git-gui subdirectory
present.
Users shouldn't supply -p2 unless they mean it. But if they are
supplying it, they probably have thought about how to make this
patch apply to their working directory, and want to risk whatever
results may come from that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git_config_rename_section return success if no config file
exists. Otherwise, renaming a branch would abort, leaving the
repository in an inconsistent state.
[jc: test]
Signed-off-by: Geert Bosch <bosch@gnat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git_patchset_body needs patch generated with --full-index option to
detect split patches, meaning two patches which corresponds to single
difftree (raw diff) entry. An example of such situation is changing
type (mode) of a file, e.g. from plain file to symbolic link.
Add, in git_blobdiff, --full-index option to patch generating git diff
invocation, for the 'html' format output ("blobdiff" view).
"blobdiff_plain" still uses shortened sha1 in the extended git diff
header "index <hash>..<hash>[ <mode>]" line.
Noticed-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 64edf4b2 cleaned up the initialization of git-archive,
at the cost of 'git-archive --list' now requiring a git repo.
This patch reverts the cleanup and documents the requirement
for this particular dirtyness in a test.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier code does not swap hunks when the beginning of the
first side is identical to the whole of the second side. In
such a case, the first one should sort later.
Signed-off-by: Junio C Hamano <junkio@cox.net>
On OS X, wc outputs 6 spaces before the number of lines, so the test
expecting the string "10" failed. Do not quote $cmd to strip away
the problematic whitespace as other tests do.
Also fix the grammar of the test name while making changes to it.
There's only one preimage, so it's "has", not "have".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that this release really matters, as we will be doing
1.5.1 tomorrow. This commit is to tie the loose ends and
merge all of "maint" branch into "master" in preparation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mainly consistent usage of "git command" and not "git-command" syntax
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a file has more then one conflicting hunks, it repeated the
contents of previous hunks in output for later ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-cvsserver documentation claims that the server will set
-k modes if appropriate which is not really the case. On the other
hand the available gitcvs.allbinary variable is not documented at
all. Fix both these issues by rewording the related paragraph.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we're on an invalid HEAD, we should detect this and avoid
attempting to continue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch leaves the base name in the resulting intermediate tree, to
propagate the conflict from intermediate merges up to the top-level merge.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a simple script to create a working directory that uses symlinks
to point at an exisiting repository. This allows having different
branches in different working directories but all from the same
repository.
Based on a description from Junio of how he creates multiple working
directories[1]. With the following caveat:
"This risks confusion for an uninitiated if you update a ref that
is checked out in another working tree, but modulo that caveat
it works reasonably well."
[1] http://article.gmane.org/gmane.comp.version-control.git/41513/
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The update hook is no longer the correct place to generate emails; there
is now the hooks/post-receive script which is run automatically after a
ref has been updated.
This patch is to make use of that new location, and to address some
faults in the old update hook.
The primary problem in the conversion was that in the update hook, the
ref has not actually been changed, but is about to be. In the
post-receive hook the ref has already been updated. That meant that
where we previously had lines like:
git rev-list --not --all
would now give the wrong list because "--all" in the post-receive hook
includes the ref that we are making the email for. This made it more
difficult to show only the new revisions added by this update.
The solution is not pretty; however it does work and doesn't need any
changes to git-rev-list itself. It also fixes (more accurately: reduces
the likelihood of) a nasty race when another update occurs while this
script is running. The solution, in short, looks like this (see the
source code for a longer explanation)
git rev-parse --not --all | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $oldrev..$newrev
This uses git-rev-parse followed by grep to filter out the revision of
the ref in question before it gets to rev-list and inhibits the output
of itself. By using $(git rev-parse $revname) rather than $newrev as the
filter, it also takes care of the situation where another update to the
same ref has been made since $refname was $newrev.
The second problem that is addressed is that of tags inhibiting the
correct output of an update email. Consider this, with somebranch and
sometag pointing at the same revision:
git push origin somebranch
git push origin sometag
That would work fine; the push of the branch would generate an email
containing all the new commits introduced by the update, then the push
of the tag would generate the shortlog formatted tag email. Now
consider:
git push origin sometag
git push origin somebranch
When some branch comes to run its "--not --all" line, it will find
sometag, and filter those commits from the email - leaving nothing.
That meant that those commits would not show (in full) on any email.
The fix is to not use "--all", and instead use "--branches" in the
git-rev-parse command.
Other changes
* Lose the monstrous one-giant-script layout and put things in easy to
digest functions. This makes it much easier to find the place you
need to change if you wanted to customise the output. I've also
tried to write more verbose comments for the same reason. The hook
script is big, mainly because of all the different cases that it has
to handle, so being easy to navigate is important.
* All uses of "git-command" changed to "git command", to cope better
if a user decided not to install all the hard links to git;
* Cleaned up some of the English in the email
* The fact that the receive hook makes the ref available also allows me
to use Shawn Pearce's fantastic suggestion that an annotated tag can
be parsed with git-for-each-ref. This removes the potentially
non-portable use of "<<<" heredocs and the nasty messing around with
"date" to convert numbers of seconds UTC to a real date
* Deletions are now caught and notified (briefly)
* To help with debugging, I've retained the command line mode from the
update hook; but made it so that the output is not emailed, it's just
printed to the screen. This could then be redirected if the user
wanted
* Removed the "Hello" from the beginning of the email - it's just
noise, and no one seriously has their day made happier by "friendly"
programs
* The fact that it doesn't rely on repository state as an indicator any
more means that it's far more stable in its output; hopefully the
same arguments will always generate the same email - even if the
repository changes in the future. This means you can easily recreate
an email should you want to.
* Included Jim Meyering's envelope sender option for the sendmail call
* The hook is now so big that it was inappropriate to copy it
to every repository by keeping it in the templates directory.
Instead, I've put a comment saying to look in contrib/hooks, and
given an example of calling the script from that template hook. The
advantage of calling the script residing at some fixed location is
that if a future package of git included a bug fixed version of the
script, that would be picked up automatically, and the user would not
have to notice and manually copy the new hook to every repository
that uses it.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We ignore errors if the path we're tracking did not exist for
a particular revision range, but we still print out warnings
telling the user about that.
As pointed out by Seth Falcon, this amounts to a lot of warnings
that could confuse and worry users. I'm not entirely comfortable
completely silencing the warnings, but showing one warning per
path that we track should be reasonable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes a problem reported by Randal Schwartz:
>I finally tracked down all the (albeit inconsequential) errors I was getting
>on both OpenBSD and OSX. It's the warn() function in usage.c. There's
>warn(3) in BSD-style distros. It'd take a "great rename" to change it, but if
>someone with better C skills than I have could do that, my linker and I would
>appreciate it.
It was annoying to me, too, when I was doing some mergetool testing on
Mac OS X, so here's a fix.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't translate the patch to UTF-8, instead preserve the data as
is. This also reverts a test case that was included in the
original patch series.
Also allow overwriting the authorship and title information we
gather from RFC2822 mail headers with additional in-body
headers, which was pointed out by Linus.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix the bug that caused "blobdiff" view called with new style URI
for a rename with change diff to be show as new (added) file diff.
New style URI for "blobdiff" for rename means with $hash_base ('hb') and
$hash_parent_base ('hpb') paramaters denoting tree-ish (usually commit)
of a blobs being compared, together with both $file_name ('f') and
$file_parent ('fp') parameters.
It is done by adding $file_parent ('fp') to the path limiter, meaning
that diff command becomes:
git diff-tree [options] hpb hb -- fp f
Other option would be finding hash of a blob using git_get_hash_by_path
subroutine and comparing blobs using git-diff, or using extended SHA-1
syntax and compare blobs using git-diff:
git diff [options] hpb:fp hp:f
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
