1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 16:52:59 +01:00
Commit graph

19339 commits

Author SHA1 Message Date
Junio C Hamano
da02ca508b check_path(): allow symlinked directories to checkout-index --prefix
Merlyn noticed that Documentation/install-doc-quick.sh no longer correctly
removes old installed documents when the target directory has a leading
path that is a symlink.  It turns out that "checkout-index --prefix" was
broken by recent b6986d8 (git-checkout: be careful about untracked
symlinks, 2009-07-29).

I suspect has_symlink_leading_path() could learn the third parameter
(prefix that is allowed to be symlinked directories) to allow us to retire
a similar function has_dirs_only_path().

Another avenue of fixing this I considered was to get rid of base_dir and
base_dir_len from "struct checkout", and instead make "git checkout-index"
when run with --prefix mkdir the leading path and chdir in there.  It
might be the best longer term solution to this issue, as the base_dir
feature is used only by that rather obscure codepath as far as I know.

But at least this patch should fix this breakage.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18 03:32:45 -07:00
Jeff King
13354f5377 docs: describe impact of repack on "clone -s"
The effects of repacking on a repository with alternates are a bit
subtle. The two main things users will want are:

  1. Not to waste disk space by accidentally copying objects which could
     be shared.

  2. Copying all objects explicitly to break the dependency on the source
     repo.

This patch describes both under the "clone -s" documentation. It makes
sense to put it there rather than in git-repack.txt for both cases.

For (1), we are warning the user who is using "clone -s" about what _not_
to do, so we need to get their attention when reading about "clone -s".

For (2), we are telling them how git-repack can be used to accomplish a
task, but until they know that git-repack is the right tool, they have no
reason to look at the repack documentation.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-17 00:03:39 -07:00
Thomas Rast
3d792161b1 add -p: do not attempt to coalesce mode changes
In 0392513 (add-interactive: refactor mode hunk handling, 2009-04-16),
we merged the interaction loops for mode changes and hunk staging.
This was fine at the time, because 0beee4c (git-add--interactive:
remove hunk coalescing, 2008-07-02) removed hunk coalescing.

However, in 7a26e65 (Revert "git-add--interactive: remove hunk
coalescing", 2009-05-16), we resurrected it.  Since then, the code
would attempt in vain to merge mode changes with diff hunks,
corrupting both in the process.

We add a check to the coalescing loop to ensure it only looks at diff
hunks, thus skipping mode changes.

Noticed-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15 10:36:59 -07:00
Kirill Smelkov
87ca2eaade git add -p: demonstrate failure when staging both mode and hunk
When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:

    $ echo content >> file
    $ chmod +x file
    $ git add -p
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    old mode 100644
    new mode 100755
    Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
    @@ -0,0 +1 @@
    +content
    Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
    Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
    Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
    fatal: corrupt patch at line 5
    diff --git a/file b/file
    index e69de29..d95f3ad
    --- a/file
    +++ b/file
    @@ -,0 + @@
    +content

Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15 10:36:29 -07:00
Junio C Hamano
2cd9c2aff0 Merge branch 'maint-1.6.3' into maint
* maint-1.6.3:
  Change mentions of "git programs" to "git commands"
  Documentation: merge: one <remote> is required
  help.c: give correct structure's size to memset()
2009-08-12 16:15:55 -07:00
Matthieu Moy
07436e43da push: point to 'git pull' and 'git push --force' in case of non-fast forward
'git push' failing because of non-fast forward is a very common situation,
and a beginner does not necessarily understand "fast forward" immediately.

Add a new section to the git-push documentation and refer them to it.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12 16:15:47 -07:00
Paul Bolle
e89df7dcda Documentation: add: <filepattern>... is optional
<filepattern>... is optional (e.g. when the --all or --update
options are used) so use square brackets in the synopsis.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12 16:15:47 -07:00
Ori Avtalion
57f6ec0290 Change mentions of "git programs" to "git commands"
Most of the docs and printouts refer to "commands" when discussing what
the end users call via the "git" top-level program. We should refer them
as "git programs" when we discuss the fact that the commands are
implemented as separate programs, but in other contexts, it is better to
use the term "git commands" consistently.

Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12 16:14:41 -07:00
Paul Bolle
22f1fb66be Documentation: merge: one <remote> is required
merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12 16:14:32 -07:00
Johan Herland
0b74f5dc3a help.c: give correct structure's size to memset()
These two structures are of the same type, but we'd better be consistent.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-12 16:14:31 -07:00
Junio C Hamano
e532e7b08f Merge branch 'maint-1.6.3' into maint
* maint-1.6.3:
  Fix typos in git-remote.txt and git-symbolic-ref.txt
2009-08-10 22:23:48 -07:00
Štěpán Němec
75f492ace7 Fix typos in git-remote.txt and git-symbolic-ref.txt
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10 19:05:00 -07:00
Nicolas Sebrecht
af12fb7b30 git-am: print fair error message when format detection fails
Avoid git ending with this message:
	"Patch format  is not supported."

With improved error message in the format detection failure case by
Giuseppe Bilotta.

Signed-off-by: Nicolas Sebrecht <ni.s@laposte.net>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10 16:54:29 -07:00
Junio C Hamano
584c43567b am: allow individual e-mail files as input
We traditionally allowed a mbox file or a directory name of a maildir (but
never an individual file inside a maildir) to be given to "git am".  Even
though an individual file in a maildir (or more generally, a piece of
RFC2822 e-mail) is not a mbox file, it contains enough information to
create a commit out of it, so there is no reason to reject one.  Running
mailsplit on such a file feels stupid, but it does not hurt.

This builds on top of a5a6755 (git-am foreign patch support: introduce
patch_format, 2009-05-27) that introduced mailbox format detection.  The
codepath to deal with a mbox requires it to begin with "From " line and
also allows it to begin with "From: ", but a random piece of e-mail can
and often do begin with any valid RFC2822 header lines.

Instead of checking the first line, we extract all the lines up to the
first empty line, and make sure they look like e-mail headers.

A test is added to t4150 to demonstrate this feature.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10 16:54:23 -07:00
Johannes Schindelin
0a7f448355 Correctly mark cover letters' encodings if they are not pure ASCII
If your name is, say, Üwë, you want your cover letters to appear
correctly.  Convince format-patch to mark it as 8-bit.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10 14:39:41 -07:00
Johannes Schindelin
28e9cf6512 Expose the has_non_ascii() function
This function is useful outside of log-tree.c, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-10 14:39:39 -07:00
Mark A Rada
f0e588dffc git-instaweb: fix mod_perl detection for apache2
The script was looking for something that matched the '^our $gitbin'
regex, which no longer exists in gitweb.cgi.

Now it looks for 'MOD_PERL', which should be on the line that checks
to see if the script is running in a mod_perl environment.

Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 18:38:47 -07:00
Jeff King
69a8b7c741 merge: indicate remote tracking branches in merge message
Previously when merging directly from a local tracking
branch like:

  git merge origin/master

The merge message said:

   Merge commit 'origin/master'

     * commit 'origin/master':
       ...

Instead, let's be more explicit about what we are merging:

   Merge remote branch 'origin/master'

     * origin/master:
       ...

We accomplish this by recognizing remote tracking branches
in git-merge when we build the simulated FETCH_HEAD output
that we feed to fmt-merge-msg.

In addition to a new test in t7608, we have to tweak the
expected output of t3409, which does such a merge.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 12:34:21 -07:00
Jeff King
751c59746c merge: fix incorrect merge message for ambiguous tag/branch
If we have both a tag and a branch named "foo", then calling
"git merge foo" will warn about the ambiguous ref, but merge
the tag.

When generating the commit message, though, we simply
checked whether "refs/heads/foo" existed, and if it did,
assumed it was a branch. This led to the statement "Merge
branch 'foo'" in the commit message, which is quite wrong.

Instead, we should use dwim_ref to find the actual ref used,
and describe it appropriately.

In addition to the test in t7608, we must also tweak the
expected output of t4202, which was accidentally triggering
this bug.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 12:34:20 -07:00
Jeff King
ce06461846 add tests for merge message headings
When calling "git merge $X", we automatically generate a
commit message containing something like "Merge branch
'$X'". This test script checks that those messages say what
they should, and exposes a failure when merging a refname
that is ambiguous between a tag and a branch.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 12:34:19 -07:00
Johannes Sixt
b6b0737d02 t6035-merge-dir-to-symlink depends on SYMLINKS prerequisite
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-09 10:37:24 -07:00
Junio C Hamano
5dc36a5888 Merge branch 'maint-1.6.3' into maint
* maint-1.6.3:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used
2009-08-07 20:44:26 -07:00
Junio C Hamano
39836a2e3c Merge branch 'maint-1.6.2' into maint-1.6.3
* maint-1.6.2:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used
2009-08-07 20:44:15 -07:00
Junio C Hamano
e72263a1f8 Merge branch 'maint-1.6.1' into maint-1.6.2
* maint-1.6.1:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used
2009-08-07 20:44:09 -07:00
Junio C Hamano
0d5055665c Merge branch 'maint-1.6.0' into maint-1.6.1
* maint-1.6.0:
  verify-pack -v: do not report "chain length 0"
  t5510: harden the way verify-pack is used
2009-08-07 20:44:02 -07:00
Junio C Hamano
262b04fa8d verify-pack -v: do not report "chain length 0"
When making a histogram of delta chain length in the pack, the program
collects number of objects whose delta depth exceeds the MAX_CHAIN limit
in histogram[0], and showed it as the number of items that exceeds the
limit correctly.  HOWEVER, it also showed the same number labeled as
"chain length = 0".

In fact, we are not showing the number of objects whose chain length is
zero, i.e. the base objects.  Correct this.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-07 20:42:45 -07:00
Junio C Hamano
2e674a9d09 t5510: harden the way verify-pack is used
The test ignored the exit status from verify pack command, and also relied
on not seeing any delta chain statistics.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-07 20:42:45 -07:00
Nicolas Pitre
5749b0b2f9 don't let the delta cache grow unbounded in 'git repack'
I have 4GB of RAM on my system which should, in theory, be quite enough
to repack a 600 MB repository.  However the unbounded delta cache size
always pushes it into swap, at which point everything virtually comes to
a halt.  So unbounded caches are never a good idea.

A default of 256MB should be a good compromize between memory usage and
speed where medium sized repositories are still likely to fit in the
cache with a reasonable memory usage, and larger repositories are going
to take quite some time to repack already anyway.

While at it, clarify the associated config variable documentation
entries a bit.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 20:14:54 -07:00
Junio C Hamano
f0df1293ac Merge branch 'maint-1.6.3' into maint
* maint-1.6.3:
  Better usage string for reflog.
  hg-to-git: don't import the unused popen2 module
  send-email: remove debug trace
  config: Keep inner whitespace verbatim
2009-08-05 12:37:24 -07:00
Zoltán Füzesi
5ed5bbc7e1 gitweb: parse_commit_text encoding fix
Call to_utf8 when parsing author and committer names, otherwise they will appear
with bad encoding if they written by using chop_and_escape_str.

Signed-off-by: Zoltán Füzesi <zfuzesi@eaglet.hu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 12:37:13 -07:00
Jakub Narebski
46068383aa gitweb/README: Document $base_url
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 12:36:38 -07:00
Jens Lehmann
85738ba3df Documentation: git submodule: add missing options to synopsis
The option --merge was missing for submodule update and --cached for
submodule summary.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 12:36:38 -07:00
Matthieu Moy
e77095e8b8 Better usage string for reflog.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-05 09:45:00 -07:00
Miklos Vajna
b0c051d1a0 hg-to-git: don't import the unused popen2 module
Importing the popen2 module in Python-2.6 results in the
"DeprecationWarning: The popen2 module is deprecated.  Use the
subprocess module." message. The module itself isn't used in fact, so
just removing it solves the problem.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-04 15:20:45 -07:00
Erik Faye-Lund
69931b7183 send-email: remove debug trace
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
2009-08-04 15:20:35 -07:00
Björn Steinbrink
ebdaae372b config: Keep inner whitespace verbatim
Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.

Reported-by: John te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-31 08:38:30 -07:00
Junio C Hamano
c94736a27f merge-recursive: don't segfault while handling rename clashes
When a branch moves A to B while the other branch created B (or moved C to
B), the code tried to rename one of them to B~something to preserve both
versions, and failed to register temporary resolution for the original
path B at stage#0 during virtual ancestor computation.  This left the
index in unmerged state and caused a segfault.

A better solution is to merge these two versions of B's in place and use
the (potentially conflicting) result as the intermediate merge result in
the virtual ancestor.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-30 19:25:05 -07:00
Linus Torvalds
b6986d8a75 git-checkout: be careful about untracked symlinks
This fixes the case where an untracked symlink that points at a directory
with tracked paths confuses the checkout logic, demostrated in t6035.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 20:24:28 -07:00
Kjetil Barvik
77716755cb lstat_cache: guard against full match of length of 'name' parameter
longest_path_match() in symlinks.c does exactly what it's name says,
but in some cases that match can be too long, since the
has_*_leading_path() functions assumes that the match will newer be as
long as the name string given to the function.

fix this by adding an extra if test which checks if the match length
is equal to the 'len' parameter.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 20:20:12 -07:00
Pickens, James E
4f6339b0c3 Demonstrate bugs when a directory is replaced with a symlink
This test creates two directories, a/b and a/b-2, then replaces a/b with
a symlink to a/b-2, then merges that change into the 'baseline' commit,
which contains an unrelated change.

There are two bugs:
1. 'git checkout' incorrectly deletes work tree file a/b-2/d.
2. 'git merge' incorrectly deletes work tree file a/b-2/d.

The test goes on to create another branch in which a/b-2 is replaced
with a symlink to a/b (i.e., the reverse of what was done the first
time), and merge it into the 'baseline' commit.

There is a different bug:
3. The merge should be clean, but git reports a conflict.

Signed-off-by: James Pickens <james.e.pickens@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 20:18:25 -07:00
Junio C Hamano
a0f4afbe87 clean: require double -f options to nuke nested git repository and work tree
When you have an embedded git work tree in your work tree (be it
an orphaned submodule, or an independent checkout of an unrelated
project), "git clean -d -f" blindly descended into it and removed
everything.  This is rarely what the user wants.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 12:22:30 -07:00
Junio C Hamano
0a53e9ddea GIT 1.6.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 00:32:42 -07:00
Junio C Hamano
441b40d833 Sync with 1.6.3.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-29 00:00:56 -07:00
Junio C Hamano
e276f018f2 GIT 1.6.3.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28 23:59:30 -07:00
Stephen Boyd
5c6d8bb290 config.txt: document add.ignore-errors
Use the description of "--ignore-errors" from git-add.txt as
inspiration.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28 23:56:01 -07:00
Tom Grennan
33016c4913 request-pull: allow ls-remote to notice remote.$nickname.uploadpack
The location to pull from should be converted from the configured nickname
to URL in the message, but ls-remote should be fed the nickname so that
the command uses remote.$nickname.* variables, most notably "uploadpack".

Signed-off-by: Tom Grennan <tgrennan@redback.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28 23:31:38 -07:00
David Kågedal
f552e51ef9 Update the documentation of the raw diff output format
This includes mentioning the initial hash output of diff-tree, and
changes the header to "raw output format" which is more descriptive.

Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28 13:32:59 -07:00
Michael J Gruber
02944cc492 git-rerere.txt: Clarify ambiguity of the config variable
Use the less ambiguous
"set variable foo in order to enable bar"
rather than
"set variable foo to enable bar" which may trick users into
assuming that "enable" is a good value for "foo".

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-28 13:30:42 -07:00
Eric Wong
df73af5f66 t9143: do not fail if Compress::Zlib is missing
"git svn gc" will not compress unhandled.log files if
Compress::Zlib is missing.  However, leftover index files should
always be removed, so add a test for this behavior as well.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-26 11:51:45 -07:00
Sean Estabrooks
e24c76bf09 Trivial path quoting fixes in git-instaweb
Bodo Schlecht noticed that Instaweb didn't propely quote all
path instances in the Apache config file it generated.

Acked-by: Eric Wong <normalperson@yhbt.net>

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-26 11:27:27 -07:00