Matthieu Moy [Mon, 19 Nov 2007 18:25:11 +0000 (19:25 +0100)]
Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
The HEAD@{...} syntax was documented in git-rev-parse manpage, which
is hard to find by someone looking for the documentation of porcelain.
git-reflog is probably the place where one expects to find this.
While I'm there, "git revlog show whatever" was also undocumented.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brian Downing [Mon, 19 Nov 2007 16:58:51 +0000 (10:58 -0600)]
config: clarify compression defaults
* Clarify that core.compression provides a system-wide default to
other compression parameters.
* Explain that the default for pack.compression, -1, is "a default
compromise between speed and compression (currently equivalent
to level 6)" according to zlib.h.
Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Anton Gyllenberg [Mon, 19 Nov 2007 10:37:16 +0000 (12:37 +0200)]
gitview: import only one of gtksourceview and gtksourceview2
Importing both gtksourceview and gtksourceview2 will make python segfault
on my system (ubuntu 7.10). Change so that gtksourceview is only imported
if importing gtksourceview2 fails. This should be safe as gtksourceview
is only used if gtksourceview2 is not available.
Signed-off-by: Anton Gyllenberg <anton@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
David D. Kilzer [Mon, 19 Nov 2007 04:14:55 +0000 (20:14 -0800)]
git-send-email: show all headers when sending mail
As a git newbie, it was confusing to set an In-Reply-To header but then
not see it printed when the git-send-email command was run.
This patch prints all headers that would be sent to sendmail or an SMTP
server instead of only printing From, Subject, Cc, To. It also removes
the now-extraneous Date header after the "Log says" line.
Added test to t/t9001-send-email.sh.
Signed-off-by: David D. Kilzer <ddkilzer@kilzer.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 19 Nov 2007 08:19:15 +0000 (00:19 -0800)]
Merge branch 'maint'
* maint:
Documentation: Fix references to deprecated commands
user-manual: mention "..." in "Generating diffs", etc.
user-manual: Add section "Why bisecting merge commits can be harder ..."
git-remote.txt: fix example url
Junio C Hamano [Mon, 19 Nov 2007 07:56:01 +0000 (23:56 -0800)]
Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint
* 'maint' of git://linux-nfs.org/~bfields/git:
Documentation: Fix references to deprecated commands
user-manual: mention "..." in "Generating diffs", etc.
user-manual: Add section "Why bisecting merge commits can be harder ..."
git-remote.txt: fix example url
Carlos Rica [Fri, 9 Nov 2007 13:42:56 +0000 (14:42 +0100)]
Make builtin-tag.c use parse_options.
Also, this removes those tests ensuring that repeated
-m options don't allocate memory more than once, because now
this is done after parsing options, using the last one
when more are given. The same for -F.
Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 13 Nov 2007 05:13:05 +0000 (21:13 -0800)]
git-clean: Fix error message if clean.requireForce is not set.
It was distracting to see this error message:
clean.requireForce set and -n or -f not given; refusing to clean
even though clean.requireForce was not set at all. This patch distinguishes
the cases and gives a different message depending on whether the
configuration variable is not set or set to true.
Junio C Hamano [Sat, 17 Nov 2007 18:51:16 +0000 (10:51 -0800)]
Move gitk to its own subdirectory
This is to prepare for gitk i18n effort that makes gitk not a single file
project anymore. We may use subproject to bind git.git and gitk.git more
loosely in the future, but we do not want to require everybody to have
subproject aware git to be able to pull from git.git yet.
Christian Couder [Sun, 18 Nov 2007 15:34:03 +0000 (16:34 +0100)]
Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
Previously we tested if the "$GIT_DIR/refs/bisect" directory
existed, to check if we were bisecting.
Now with packed refs, it is simpler to check if the file
"$GIT_DIR/BISECT_NAMES" exists, as it is already created when
starting bisection and removed when reseting bisection.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
J. Bruce Fields [Mon, 19 Nov 2007 00:18:27 +0000 (19:18 -0500)]
user-manual: mention "..." in "Generating diffs", etc.
We should mention the use of the "..." syntax for git-diff here. The
note about the difference between diff and the combined output of
git-format-patch then no longer fits so well, so remove it. Add a
reference to the git-format-patch[1] manpage.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Junio C Hamano [Mon, 19 Nov 2007 00:03:24 +0000 (16:03 -0800)]
Merge branch 'lt/rev-list-interactive'
* lt/rev-list-interactive:
Fix parent rewriting in --early-output
revision walker: mini clean-up
Enhance --early-output format
Add "--early-output" log flag for interactive GUI use
Simplify topo-sort logic
Junio C Hamano [Sun, 18 Nov 2007 23:50:16 +0000 (15:50 -0800)]
Merge branch 'ph/diffopts'
* ph/diffopts:
Reorder diff_opt_parse options more logically per topics.
Make the diff_options bitfields be an unsigned with explicit masks.
Use OPT_BIT in builtin-pack-refs
Use OPT_BIT in builtin-for-each-ref
Use OPT_SET_INT and OPT_BIT in builtin-branch
parse-options new features.
Steffen Prohaska [Sat, 10 Nov 2007 13:49:54 +0000 (14:49 +0100)]
user-manual: Add section "Why bisecting merge commits can be harder ..."
This commit adds a discussion of the challenge of bisecting
merge commits to the user manual. The original author is
Junio C Hamano <gitster@pobox.com>, who posted the text to
the mailing list <http://marc.info/?l=git&m=119403257315527&w=2>.
His email was adapted for the manual.
The discussion is added to "Rewriting history and maintainig
patch series". The text added requires good understanding of
merging and rebasing. Therefore it should not be placed too
early in the manual. Right after the section on "Problems with
rewriting history", the discussion of bisect gives another reason
for linearizing as much of the history as possible.
The text includes suggestions and fixes by
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> and
Benoit Sigoure <tsuna@lrde.epita.fr>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Guido Ostkamp [Fri, 16 Nov 2007 18:59:58 +0000 (19:59 +0100)]
Use compat mkdtemp() on Solaris boxes
Define NO_MKDTEMP for all variants of SunOS; Solaris 10 does not
have mkdtemp() and all the other versions our Makefile knows
about don't have it either.
NO_{SETENV,UNSETENV,C99_FORMAT,STRTOUMAX} definitions cannot be
unified across versions. Beginning with Solaris 10, the C-library
provides unsetenv(), setenv() and strtoumax(). Also 'z'/'t' formats
are supported. However, older versions of Solaris do not support
these.
Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Sun, 18 Nov 2007 08:08:22 +0000 (03:08 -0500)]
send-pack: fix "everything up-to-date" message
This has always been slightly inaccurate, since it used the
new_refs counter, which really meant "did we send any
objects," so deletions were not counted.
It has gotten even worse with recent patches, since we no
longer look at the 'ret' value, meaning we would say "up to
date" if non-ff pushes were rejected.
Instead, we now claim up to date iff every ref is either
unmatched or up to date. Any other case should already have
generated a status line.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Sun, 18 Nov 2007 07:16:52 +0000 (02:16 -0500)]
send-pack: tighten remote error reporting
Previously, we set all ref pushes to 'OK', and then marked
them as errors if the remote reported so. This has the
problem that if the remote dies or fails to report a ref, we
just assume it was OK.
Instead, we use a new non-OK state to indicate that we are
expecting status (if the remote doesn't support the
report-status feature, we fall back on the old behavior).
Thus we can flag refs for which we expected a status, but
got none (conversely, we now also print a warning for refs
for which we get a status, but weren't expecting one).
This also allows us to simplify the receive_status exit
code, since each ref is individually marked with failure
until we get a success response. We can just print the usual
status table, so the user still gets a sense of what we were
trying to do when the failure happened.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shawn O. Pearce [Sun, 18 Nov 2007 09:31:37 +0000 (04:31 -0500)]
Fix warning about bitfield in struct ref
cache.h:503: warning: type of bit-field 'force' is a GCC extension
cache.h:504: warning: type of bit-field 'merge' is a GCC extension
cache.h:505: warning: type of bit-field 'nonfastforward' is a GCC extension
cache.h:506: warning: type of bit-field 'deletion' is a GCC extension
So we change it to an 'unsigned int' which is not a GCC extension.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 18 Nov 2007 05:39:37 +0000 (21:39 -0800)]
Merge branch 'ph/parseopt-sh'
* ph/parseopt-sh:
git-quiltimport.sh fix --patches handling
git-am: -i does not take a string parameter.
sh-setup: don't let eval output to be shell-expanded.
git-sh-setup: fix parseopt `eval` string underquoting
Give git-am back the ability to add Signed-off-by lines.
git-rev-parse --parseopt
scripts: Add placeholders for OPTIONS_SPEC
Migrate git-repack.sh to use git-rev-parse --parseopt
Migrate git-quiltimport.sh to use git-rev-parse --parseopt
Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
Migrate git-instaweb.sh to use git-rev-parse --parseopt
Migrate git-merge.sh to use git-rev-parse --parseopt
Migrate git-am.sh to use git-rev-parse --parseopt
Migrate git-clone to use git-rev-parse --parseopt
Migrate git-clean.sh to use git-rev-parse --parseopt.
Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseopt
Add a parseopt mode to git-rev-parse to bring parse-options to shell scripts.
Junio C Hamano [Sun, 18 Nov 2007 05:18:14 +0000 (21:18 -0800)]
grep -An -Bm: fix invocation of external grep command
When building command line to invoke external grep, the
arguments to -A/-B/-C options were placd in randarg[] buffer,
but the code forgot that snprintf() does not count terminating
NUL in its return value. This caused "git grep -A1 -B2" to
invoke external grep with "-B21 -A1".
Johannes Sixt [Sat, 17 Nov 2007 22:09:28 +0000 (23:09 +0100)]
fetch-pack: Prepare for a side-band demultiplexer in a thread.
get_pack() receives a pair of file descriptors that communicate with
upload-pack at the remote end. In order to support the case where the
side-band demultiplexer runs in a thread, and, hence, in the same process
as the main routine, we must not close the readable file descriptor early.
The handling of the readable fd is changed in the case where upload-pack
supports side-band communication: The old code closed the fd after it was
inherited to the side-band demultiplexer process. Now we do not close it.
The caller (do_fetch_pack) will close it later anyway. The demultiplexer
is the only reader, it does not matter that the fd remains open in the
main process as well as in unpack-objects/index-pack, which inherits it.
The writable fd is not needed in get_pack(), hence, the old code closed
the fd. For symmetry with the readable fd, we now do not close it; the
caller (do_fetch_pack) will close it later anyway. Therefore, the new
behavior is that the channel now remains open during the entire
conversation, but this has no ill effects because upload-pack does not read
from it once it has begun to send the pack data. For the same reason it
does not matter that the writable fd is now inherited to the demultiplexer
and unpack-objects/index-pack processes.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 18 Nov 2007 00:40:03 +0000 (16:40 -0800)]
Merge git://git.bogomips.org/git-svn
* git://git.bogomips.org/git-svn:
git-svn: Fix a typo and add a comma in an error message in git-svn
git-svn log: handle unreachable revisions like "svn log"
git-svn log: include commit log for the smallest revision in a range
git-svn log: fix ascending revision ranges
git-svn's dcommit must use subversion's config
git-svn: add tests for command-line usage of init and clone commands
David D Kilzer [Mon, 12 Nov 2007 06:56:52 +0000 (22:56 -0800)]
git-svn log: handle unreachable revisions like "svn log"
When unreachable revisions are given to "svn log", it displays all commit
logs in the given range that exist in the current tree. (If no commit
logs are found in the current tree, it simply prints a single commit log
separator.) This patch makes "git-svn log" behave the same way.
Ten tests added to t/t9116-git-svn-log.sh.
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net> Acked-by: Eric Wong <normalperson@yhbt.net>
David D Kilzer [Sun, 11 Nov 2007 06:10:34 +0000 (22:10 -0800)]
git-svn log: include commit log for the smallest revision in a range
The "svn log -rM:N" command shows commit logs inclusive in the range [M,N].
Previously "git-svn log" always excluded the commit log for the smallest
revision in a range, whether the range was ascending or descending. With
this patch, the smallest revision in a range is always shown.
Updated tests for ascending and descending revision ranges.
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net> Acked-by: Eric Wong <normalperson@yhbt.net>
When doing dcommit git-svn must use subversion's config or newly created
files will not include svn's properties
(defined in [auto-props] with 'enable-auto-props = yes').
Signed-off-by: Konstantin V. Arkhipov <voxus@onphp.org> Acked-by: Eric Wong <normalperson@yhbt.net>
Jeff King [Sat, 17 Nov 2007 12:56:03 +0000 (07:56 -0500)]
send-pack: assign remote errors to each ref
This lets us show remote errors (e.g., a denied hook) along
with the usual push output.
There is a slightly clever optimization in receive_status
that bears explanation. We need to correlate the returned
status and our ref objects, which naively could be an O(m*n)
operation. However, since the current implementation of
receive-pack returns the errors to us in the same order that
we sent them, we optimistically look for the next ref to be
looked up to come after the last one we have found. So it
should be an O(m+n) merge if the receive-pack behavior
holds, but we fall back to a correct but slower behavior if
it should change.
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Sat, 17 Nov 2007 12:55:15 +0000 (07:55 -0500)]
send-pack: check ref->status before updating tracking refs
Previously, we manually checked the 'NONE' and 'UPTODATE'
conditions. Now that we have ref->status, we can easily
say "only update if we pushed successfully".
This adds a test for and fixes a regression introduced in ed31df31 where deleted refs did not have their tracking
branches removed. This was due to a bogus per-ref error test
that is superseded by the more accurate ref->status flag.
Signed-off-by: Jeff King <peff@peff.net> Completely-Acked-By: Alex "Sleepy" Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Sat, 17 Nov 2007 12:54:27 +0000 (07:54 -0500)]
send-pack: track errors for each ref
Instead of keeping the 'ret' variable, we instead have a
status flag for each ref that tracks what happened to it.
We then print the ref status after all of the refs have
been examined.
This paves the way for three improvements:
- updating tracking refs only for non-error refs
- incorporating remote rejection into the printed status
- printing errors in a different order than we processed
(e.g., consolidating non-ff errors near the end with
a special message)
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Alex Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mike Hommey [Fri, 16 Nov 2007 22:02:08 +0000 (23:02 +0100)]
Fix and improve t7004 (git-tag tests)
Brown paper bag fix to avoid using non portable sed syntax. The
test by itself didn't catch what it was supposed to, anyways.
The new test first checks if git-tag correctly errors out when
the user exited the editor without editing the file. Then it
checks if what the user was presented in the editor was any
useful, which we define as the following:
* It begins with a single blank line, where the invoked editor
would typically place the editing curser at, so that the user
can immediately start typing;
* It has some instruction but that comes after that initial
blank line, all lines prefixed with "#". We specifically do
not check for the wording of this instruction.
* And it has nothing else, as the expected behaviour is "Hey
you did not leave any message".
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Linus Torvalds [Sun, 11 Nov 2007 23:35:23 +0000 (23:35 +0000)]
Fix rev-list when showing objects involving submodules
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees. This is not so. Since we do
not traverse into submodules (yet), the gitlinks should be ignored.
In general, we should try to start moving away from using the
"S_ISLNK()" like things for internal git state. It was a mistake to
just assume the numbers all were same across all systems in the first
place. This implementation converts to the "object_type", and then
uses a case statement.
Noticed by Ilari on IRC.
Test script taken from an earlier version by Dscho.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 16 Nov 2007 09:15:41 +0000 (01:15 -0800)]
Fix per-directory exclude handing for "git add"
In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.
While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string. The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.
The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Junio C Hamano [Sat, 17 Nov 2007 01:05:02 +0000 (17:05 -0800)]
core.excludesfile clean-up
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable. The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.
* git-ls-files does not notice any of the "ignore" files by
default, as it predates the standardized set of ignore files.
The calling scripts established the convention to use
.git/info/exclude, .gitignore, and later core.excludesfile.
* git-add and git-status know about it because they call
add_excludes_from_file() directly with their own notion of
which standard set of ignore files to use. This is just a
stupid duplication of code that need to be updated every time
the definition of the standard set of ignore files is
changed.
* git-read-tree takes --exclude-per-directory=<gitignore>,
not because the flexibility was needed. Again, this was
because the option predates the standardization of the ignore
files.
* git-merge-recursive uses hardcoded per-directory .gitignore
and nothing else. git-clean (scripted version) does not
honor core.* because its call to underlying ls-files does not
know about it. git-clean in C (parked in 'pu') doesn't either.
We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way. I am somewhat reluctant to make such a change.
On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands. I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.
This patch is the first step to untangle this mess.
The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Wincent Colaiuta [Fri, 16 Nov 2007 13:25:10 +0000 (14:25 +0100)]
Fix t9101 test failure caused by Subversion "auto-props"
If a user has an "auto-prop" in his/her ~/.subversion/config file for
automatically setting the svn:keyword Id property on all ".c" files
(a reasonably common configuration in the Subversion world) then one
of the "svn propset" operations in the very first test would become a
no-op, which in turn would make the next commit a no-op.
This then caused the 25th test ('test propget') to fail because it
expects a certain number of commits to have taken place but the actual
number of commits was off by one.
Björn Steinbrink identified the "auto-prop" feature as the cause
of the failure. This patch avoids it by passing the "--no-auto-prop"
flag to "svn import" when setting up the test repository, thus ensuring
that the "svn propset" operation is no longer a no-op, regardless of the
users' settings in their config.
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 16 Nov 2007 10:49:09 +0000 (05:49 -0500)]
git-send-email: add charset header if we add encoded 'From'
We sometimes pick out the original rfc822 'From' header and
include it in the body of the message. If the original
author's name needs encoding, then we should specify that in
the content-type header.
If we already had a content-type header in the mail, then we
may need to re-encode. The logic is there to detect
this case, but it doesn't actually do the re-encoding.
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Thu, 15 Nov 2007 08:47:53 +0000 (00:47 -0800)]
git-bisect: modernize branch shuffling hack
When switching to a new rev, we first made "new-bisect" branch to
point at the chosen commit, attempt to switch to it, and then
finally renamed the new-bisect branch to bisect by hand when
successful. This is so that we can catch checkout failure (your
local modification may interfere with switching to the chosen
version) without losing information on which commit the next
attempt should be made.
Rewrite it using a more modern form but without breaking the
safety.
Junio C Hamano [Thu, 15 Nov 2007 08:39:57 +0000 (00:39 -0800)]
git-bisect: war on "sed"
We do not need to pipe "echo" to "sed" only to strip refs/heads/
from the beginning. We are assuming not-so-ancient shells these
days.
Also there is no need to avoid assuming \012 is the LF; we do
not run on EBCDIC, sorry. Other parts of the script already
uses tr to convert separator to LF that way.
Simon Hausmann [Thu, 15 Nov 2007 09:38:45 +0000 (10:38 +0100)]
git-p4: Fix direct import from perforce after fetching changes through git from origin
When using an existing git repository to cache the perforce import we don't
fetch the branch mapping from perforce as that is a slow operation. However
the origin repository may not be fully up-to-date and therefore it may be
necessary to import more changes directly from Perforce.
Such a direct import needs self.knownBranches to be set up though, so
initialize it from the existing p4/* git branches.
Signed-off-by: Simon Hausmann <simon@lst.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Fri, 16 Nov 2007 09:15:41 +0000 (01:15 -0800)]
Fix per-directory exclude handing for "git add"
In "dir_struct", each exclusion element in the exclusion stack records a
base string (pointer to the beginning with length) so that we can tell
where it came from, but this pointer is just pointing at the parameter
that is given by the caller to the push_exclude_per_directory()
function.
While read_directory_recursive() runs, calls to excluded() makes use
the data in the exclusion elements, including this base string. The
caller of read_directory_recursive() is not supposed to free the
buffer it gave to push_exclude_per_directory() earlier, until it
returns.
The test case Bruce Stephens gave in the mailing list discussion
was simplified and added to the t3700 test.
Nicolas Pitre [Thu, 15 Nov 2007 17:24:17 +0000 (12:24 -0500)]
rehabilitate some t5302 tests on 32-bit off_t machines
Commit 8ed2fca458d085f12c3c6808ef4ddab6aa40ef14 was a bit draconian in
skipping certain tests which should be perfectly valid even on platform
with a 32-bit off_t.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Tue, 13 Nov 2007 20:05:06 +0000 (21:05 +0100)]
Allow ETC_GITCONFIG to be a relative path.
If ETC_GITCONFIG is not an absolute path, interpret it relative to
--exec-dir. This makes the installed binaries relocatable because the
prefix is not compiled-in.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Tue, 13 Nov 2007 20:05:05 +0000 (21:05 +0100)]
Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
In a subsequent patch the path to the system-wide config file will be
computed. This is a preparation for that change. It turns all accesses
of ETC_GITCONFIG into function calls. There is no change in behavior.
As a consequence, config.c is the only file that needs the definition of
ETC_GITCONFIG. Hence, -DETC_GITCONFIG is removed from the CFLAGS and a
special build rule for config.c is introduced. As a side-effect, changing
the defintion of ETC_GITCONFIG (e.g. in config.mak) does not trigger a
complete rebuild anymore.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes Sixt [Tue, 13 Nov 2007 20:05:04 +0000 (21:05 +0100)]
Allow a relative builtin template directory.
In order to make git relocatable (i.e. not have the prefix compiled-in)
the template directory must depend on the location where this git instance
is found, which is GIT_EXEC_DIR.
The exec path is prepended only if the compiled-in default template
directory is to be used and that is relative. Any relative directories
that are specified via environment variable or the --exec-dir switch are
taken as is.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 14 Nov 2007 08:05:00 +0000 (00:05 -0800)]
core.excludesfile clean-up
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable. The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.
* git-ls-files does not notice any of the "ignore" files by
default, as it predates the standardized set of ignore files.
The calling scripts established the convention to use
.git/info/exclude, .gitignore, and later core.excludesfile.
* git-add and git-status know about it because they call
add_excludes_from_file() directly with their own notion of
which standard set of ignore files to use. This is just a
stupid duplication of code that need to be updated every time
the definition of the standard set of ignore files is
changed.
* git-read-tree takes --exclude-per-directory=<gitignore>,
not because the flexibility was needed. Again, this was
because the option predates the standardization of the ignore
files.
* git-merge-recursive uses hardcoded per-directory .gitignore
and nothing else. git-clean (scripted version) does not
honor core.* because its call to underlying ls-files does not
know about it. git-clean in C (parked in 'pu') doesn't either.
We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way. I am somewhat reluctant to make such a change.
On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands. I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.
This patch is the first step to untangle this mess.
The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().
Junio C Hamano [Wed, 14 Nov 2007 22:26:04 +0000 (14:26 -0800)]
Merge branch 'sp/fetch-fix'
* sp/fetch-fix:
git-fetch: avoid local fetching from alternate (again)
rev-list: Introduce --quiet to avoid /dev/null redirects
run-command: Support sending stderr to /dev/null
git-fetch: Always fetch tags if the object they reference exists
Junio C Hamano [Wed, 14 Nov 2007 22:25:46 +0000 (14:25 -0800)]
Merge branch 'bs/maint-commit-options'
* bs/maint-commit-options:
git-commit: Add tests for invalid usage of -a/--interactive with paths
git-commit.sh: Fix usage checks regarding paths given when they do not make sense
Junio C Hamano [Wed, 14 Nov 2007 22:15:40 +0000 (14:15 -0800)]
Merge branch 'jc/maint-add-sync-stat'
* jc/maint-add-sync-stat:
t2200: test more cases of "add -u"
git-add: make the entry stat-clean after re-adding the same contents
ce_match_stat, run_diff_files: use symbolic constants for readability
Junio C Hamano [Wed, 14 Nov 2007 22:05:47 +0000 (14:05 -0800)]
Merge branch 'jc/stash-create'
* jc/stash-create:
git-stash: Fix listing stashes
git-merge: no reason to use cpio anymore
Revert "rebase: allow starting from a dirty tree."
rebase: allow starting from a dirty tree.
stash: implement "stash create"
Junio C Hamano [Wed, 14 Nov 2007 22:04:25 +0000 (14:04 -0800)]
Merge branch 'bg/format-patch-N'
* bg/format-patch-N:
Rearrange git-format-patch synopsis to improve clarity.
format-patch: Test --[no-]numbered and format.numbered
format-patch: Add configuration and off switch for --numbered
Junio C Hamano [Wed, 14 Nov 2007 22:04:19 +0000 (14:04 -0800)]
Merge branch 'np/progress'
* np/progress:
nicer display of thin pack completion
make display of total transferred fully accurate
remove dead code from the csum-file interface
git-fetch: be even quieter.
make display of total transferred more accurate
sideband.c: ESC is spelled '\033' not '\e' for portability.
fix display overlap between remote and local progress
Linus Torvalds [Tue, 13 Nov 2007 07:16:08 +0000 (23:16 -0800)]
Fix parent rewriting in --early-output
We cannot tell a node that has been checked and found not to be
interesting (which does not have the TREECHANGE flag) from a
node that hasn't been checked if it is interesting or not,
without relying on something else, such as object->parsed.
But an object can get the "parsed" flag for other reasons.
Which means that "TREECHANGE" has the wrong polarity.
This changes the way how the path pruning logic marks an
uninteresting commits. From now on, we consider a commit
interesting by default, and explicitly mark the ones we decided
to prune. The flag is renamed to "TREESAME".
Then, this fixes the logic to show the early output with
incomplete pruning. It basically says "a commit that has
TREESAME set is kind-of-UNINTERESTING", but obviously in a
different way than an outright UNINTERESTING commit. Until we
parse and examine enough parents to determine if a commit
becomes surely "kind-of-UNINTERESTING", we avoid rewriting
the ancestry so that later rounds can fix things up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Linus Torvalds [Sun, 11 Nov 2007 23:35:23 +0000 (23:35 +0000)]
Fix rev-list when showing objects involving submodules
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees. This is not so. Since we do
not traverse into submodules (yet), the gitlinks should be ignored.
In general, we should try to start moving away from using the
"S_ISLNK()" like things for internal git state. It was a mistake to
just assume the numbers all were same across all systems in the first
place. This implementation converts to the "object_type", and then
uses a case statement.
Noticed by Ilari on IRC.
Test script taken from an earlier version by Dscho.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 14 Nov 2007 11:37:18 +0000 (03:37 -0800)]
Merge branch 'maint'
* maint:
git-clean: honor core.excludesfile
Documentation: Fix man page breakage with DocBook XSL v1.72
git-remote.txt: fix typo
core-tutorial.txt: Fix argument mistake in an example.
replace reference to git-rm with git-reset in git-commit doc
Grammar fixes for gitattributes documentation
Don't allow fast-import tree delta chains to exceed maximum depth
revert/cherry-pick: allow starting from dirty work tree.
t/t3404: fix test for a bogus todo file.
Junio C Hamano [Wed, 14 Nov 2007 11:11:37 +0000 (03:11 -0800)]
Merge branch 'ar/send-pack-remote-track' into jk/send-pack
* ar/send-pack-remote-track:
Update the tracking references only if they were succesfully updated on remote
Add a test checking if send-pack updated local tracking branches correctly
projects / git.git / log