It does not seem to need it either and gives an error on FC5 I use
at kernel.org to cut documentation tarballs, so remove it in the
meantime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is in the hope of giving JBF's user-manual wider exposure.
I am not very happy with trailing whitespaces in the new
document, but let's not worry too much about the formatting
issues for now, but concentrate more on the structure and the
contents.
The last test in t9200 wants to see if executable bit is
retained, which has no chance of succeeding on a filesystem that
does not handle executable bit correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For the purpose of this test we do not really care if the paths
are in latin-1, but people on Cygwin seem to be having problem
on foreign-looking pathnames that do not play well with their
locale.
Let's try to re-code them in UTF-8 and see who screams,
thanks, or reports no-improvements.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the index wasn't clean, git-rebase would simply show the output from
git-diff-index with no further comment to the user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, it fixes the following (typical for cygwin) problem:
$ git-update-index --chmod=-x ../wrapper/Jamfile
fatal: git-update-index: cannot chmod -x '../wrapper/Jamfile'
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recent commit ae1dffcb28 by Junio
changed the way --upload-pack was passed around between clone,
fetch and ls-remote and modified the handling of the command
line parameter parsing.
Unfortunately FreeBSD 6.1 insists that the expression
expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)'
is illegal, as the --upload-pack option is not supported by their
implementation of expr.
Elsewhere in Git we use z as a leading prefix of both arguments,
ensuring the -- isn't seen by expr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently if we are unable to parse an object update-server-info
coredumps, as it doesn't bother to check the return value of its
call to parse_object.
Instead of coredumping, skip the ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is not meant to frighten people or even to suggest they might be
doing something wrong, but rather to notify them of a state change and
provide a likely option in the case this state was entered by mistake.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... which I broke when we introduced user.signingkey configuration.
There was no reason to add a new variable keyid to the script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd like complete gitweb setup instructions some day, but for now just
refer to the gitweb README.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Fix blameview to use git-cat-file to read the file content.
This make sure we show the right content when we have modified
file in the working directory which is not committed.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... with:
$ git fetch ${remote} HEAD
Also
$ git fetch ${remote} :${localref}
worked, but
$ git fetch ${remote} HEAD:{localref}
didn't. Now both are equivalent.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rfc2047 unquoter spitted out an annoying "- unquoted" which was
added during debugging but I forgot to remove.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change df391b192 to rename fsck-objects to fsck broke
fsck-objects. This should fix it again.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to use lock_any_ref_for_update() because the command
needs to also update HEAD (which is not under refs/, so
lock_ref_sha1() cannot be used). The function however did not
check for refs with illegal characters in them.
Use check_ref_format() to catch malformed refs. For this check,
we specifically do not want to say having less than two levels
in the name is illegal to allow HEAD (and perhaps other special
refs in the future).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document Junio's show-branch trick for finding out which tags are
descendents of a given comit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I still really want a section on interoperability with CVS, subversion,
etc., but I'm not getting around to it very fast, so just add this to
the TODO section for now. And a few other minor todo updates.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief discussion of reflogs. Also recovery of dangling commits
seems to fit in here, so move some of the discussion out of Linus's
email to here.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Direct editing of config files may be more natural for users than using
the git-config commandline; but we should still reference the
git-config man page when we describe such editing, so people know where
to go for details on the config file syntax and meanings of the
variables.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Looks like we're going to allow git-config as the preferred alias to
git-repo-config, so let's document that instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial import of fsck and dangling objects discussion, mostly lifted from
an email from Linus.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I know it's only an example, but having this might save someone else the
trouble of writing an enhanced version for themselves.
It basically does the same job as the old update hook, but with these
differences:
* The recipients list is read from the repository config file from
hooks.mailinglist
* Updating unannotated tags can be allowed by setting
hooks.allowunannotated
* Announcement emails (via annotated tag creation) can be sent to a
different mailing list by setting hooks.announcelist
* Output email is more verbose and generates specific content depending
on whether the ref is a tag, an annotated tag, a branch, or a
tracking branch
* The email is easier to filter; the subject line is prefixed with
[SCM] and a project description pulled from the "description" file
* It catches (and displays differently) branch updates that are
performed with a --force
Obviously, it's nothing that clever - it's the update hook I use on my
repositories but I've tried to keep it general, and tried to make the
output always relevant to the type of update.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I got bitten because in the UK (where one would expect 1970-01-01 00:00
to be UTC 0) some politicians decided to mess around with daylight
savings time from 1968 to 1971; it was permanently BST (+0100). That
means that on my computer the following is true:
$ date --date="1970-01-01 00:00" +"%F %T %z (%Z)"
1970-01-01 00:00:00 +0100 (BST)
This of course means that the --date argument to date is specified in
local time, not UTC. So when the hooks--update script does this:
date=$(date --date="1970-01-01 00:00:00 $ts seconds")
It's actually saying (in my timezone) "1970-01-01 01:00:00 UTC" + $ts.
Clearly this is wrong. The UNIX epoch started at midnight UTC not 1am
UTC.
This leads to the tagged time in hooks--update being shown as one hour
earlier than the true tagged time (in my timezone). The problem would
be worse for other timezones. For a +1300 timezone on 1970-01-01, the
tagged time would be 13 hours earlier. Oops.
The solution is to force the reference time to UTC, which is what this
patch does. In my timezone:
$ date --date="1970-01-01 00:00 +0000" +"%F %T %z (%Z)"
1970-01-01 01:00:00 +0100 (BST)
Much better.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Love it or hate it, some people actually still program in Tcl. Some
of those programs are meant for interfacing with Git. Programs such as
gitk and git-gui. It may be useful to have Tcl-safe output available
from for-each-ref, just like shell, Perl and Python already enjoy.
Thanks to Sergey Vlasov for pointing out the horrible flaws in the
first and second version of this patch, and steering me in the right
direction for Tcl value quoting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows pushing over the git:// protocol, and while it's not
authenticated, it could make sense from within a firewalled
setup where nobody but trusted internal people can reach the git
port. git-daemon is possibly easier and faster to set up in the
kind of situation where you set up git instead of CVS inside a
company.
"git-receive-pack" is disabled by default, so you need to enable it
explicitly by starting git-daemon with the "--enable=receive-pack"
command line argument, or by having your config enable it automatically.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* The description of valid colour specifications was rather
incomplete, so fix it so that it actually describes colour specs as
accepted by color_parse().
* The list of colour items allowed in color.diff.BLAH was missing the
`commit' and `whitespace' entries.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Starting a pager defeats the purpose of the incremental output
mode. This changes git-blame to only paginate if --incremental
was not given.
git -p blame --incremental still starts the pager, though.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My prior change to git-describe attempts to print the distance
between the input commit and the best matching tag, but this distance
was usually only an estimate as we always aborted revision walking
as soon as we overflowed the configured limit on the number of
possible tags (as set by --candidates).
Displaying an estimated distance is not very useful and can just be
downright confusing. Most users (heck, most Git developers) don't
immediately understand why this distance differs from the output
of common tools such as `git rev-list | wc -l`. Even worse, the
estimated distance could change in the future (including decreasing
despite no rebase occuring) if we find more possible tags earlier
on during traversal. (This could happen if more tags are merged
into the branch between queries.) These factors basically make an
estimated distance useless.
Fortunately we are usually most of the way through an accurate
distance computation by the time we abort (due to reaching the
current --candidates limit). This means we can simply finish
counting out the revisions still in our commit queue to present
the accurate distance at the end. The number of commits remaining
in the commit queue is probably less than the number of commits
already traversed, so finishing out the count is not likely to take
very long. This final distance will then always match the output of
`git rev-list | wc -l`.
We can easily reduce the total number of commits that need to be
walked at the end by stopping as soon as all of the commits in the
commit queue are flagged as being merged into the already selected
best possible tag. If that's true then there are no remaining
unseen commits which can contribute to our best possible tag's
depth counter, so further traversal is useless.
Basic testing on my Mac OS X system shows there is no noticable
performance difference between this accurate distance counting
version of git-describe and the prior version of git-describe,
at least when run on git.git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you get two different describes at different
times from a non-rewinding branch and they both come up with the same
tag name, you can tell which is the 'newer' one by distance. This is
rather common in practice, so its incredibly useful.
[jc: still needs documentation and fixups when traversal gives up
early.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
