Commit graph

28 commits

Author SHA1 Message Date
Junio C Hamano f3f973a017 Merge branch 'fc/apply-p2-get-header-name'
* fc/apply-p2-get-header-name:
  test: git-apply -p2 rename/chmod only
  Fix git-apply with -p greater than 1
2010-11-29 17:52:33 -08:00
Junio C Hamano f565f6e065 Merge branch 'ak/apply-non-git-epoch'
* ak/apply-non-git-epoch:
  apply: handle patches with funny filename and colon in timezone
  apply: Recognize epoch timestamps with : in the timezone
2010-11-29 17:52:31 -08:00
Junio C Hamano 20f84c8f56 Merge branch 'rs/opt-help-text'
* rs/opt-help-text:
  verify-tag: document --verbose
  branch: improve --verbose description
  archive: improve --verbose description
  Describe various forms of "be quiet" using OPT__QUIET
  add OPT__FORCE
  add description parameter to OPT__QUIET
  add description parameter to OPT__DRY_RUN
  add description parameter to OPT__VERBOSE
2010-11-24 15:55:19 -08:00
René Scharfe fd03881a48 add description parameter to OPT__VERBOSE
Allows better help text to be defined than "be verbose".  Also make use
of the macro in places that already had a different description.  No
object code changes intended.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-15 09:56:51 -08:00
Jonathan Nieder 2d502e1f37 apply: handle patches with funny filename and colon in timezone
Some patches have a timezone formatted like '-08:00' instead of
'-0800' in their ---/+++ lines (e.g. http://lwn.net/Articles/131729/).
Take this into account when searching for the start of the timezone
(which is the end of the filename).

This does not actually affect the outcome of patching unless (1) a
file being patched has a non-' ' whitespace character (e.g., tab) in
its filename, or (2) the patch is whitespace-damaged, so the tab
between filename and timestamp has been replaced with spaces.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-10 08:42:40 -08:00
Federico Cuello cefd43b7f9 Fix git-apply with -p greater than 1
Fix the case when the patch is a rename or mode-change only
and -p is used with a value greater than one.
The git_header_name function did not remove more than one path
component.

Signed-off-by: Federico Cuello <fedux@lugmen.org.ar>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-05 14:23:55 -07:00
Jeff King 24305cd700 apply: don't segfault on binary files with missing data
Usually when applying a binary diff generated without
--binary, it will be rejected early, as we don't even have
the full sha1 of the pre- and post-images.

However, if the diff is generated with --full-index (but not
--binary), then we will actually try to apply it. If we have
the postimage blob, then we can take a shortcut and never
even look at the binary diff at all (e.g., this can happen
when rebasing changes within a repository).

If we don't have the postimage blob, though, we try to look
at the actual fragments, of which there are none, and get a
segfault. This patch checks explicitly for that case and
complains to the user instead of segfaulting. We need to
keep the check at a low level so that the "shortcut" case
above continues to work.

We also add a test that demonstrates the segfault. While
we're at it, let's also explicitly test the shortcut case.

Reported-by: Rafaël Carré <rafael.carre@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-29 14:13:33 -07:00
Anders Kaseorg a1980c4efc apply: Recognize epoch timestamps with : in the timezone
Some patches have a timezone formatted like ‘-08:00’ instead of
‘-0800’ (e.g. http://lwn.net/Articles/131729/), so git apply would
fail to recognize the epoch timestamp of deleted files and would
create empty files instead.  Teach it to support both formats, and add
a test case.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13 16:39:45 -07:00
Junio C Hamano 9502751181 Merge branch 'jn/apply-filename-with-sp'
* jn/apply-filename-with-sp:
  apply: handle traditional patches with space in filename
  tests: exercise "git apply" with weird filenames
  apply: split quoted filename handling into new function
2010-09-03 09:43:44 -07:00
Junio C Hamano 633142d868 Merge branch 'jn/paginate-fix'
* jn/paginate-fix:
  t7006 (pager): add missing TTY prerequisites
  merge-file: run setup_git_directory_gently() sooner
  var: run setup_git_directory_gently() sooner
  ls-remote: run setup_git_directory_gently() sooner
  index-pack: run setup_git_directory_gently() sooner
  config: run setup_git_directory_gently() sooner
  bundle: run setup_git_directory_gently() sooner
  apply: run setup_git_directory_gently() sooner
  grep: run setup_git_directory_gently() sooner
  shortlog: run setup_git_directory_gently() sooner
  git wrapper: allow setup_git_directory_gently() be called earlier
  setup: remember whether repository was found
  git wrapper: introduce startup_info struct

Conflicts:
	builtin/index-pack.c
2010-08-31 16:23:31 -07:00
Jonathan Nieder 5a12c8864b apply: handle traditional patches with space in filename
To discover filenames from the --- and +++ lines in a traditional
unified diff, currently "git apply" scans forward for a whitespace
character on each line and stops there.  It can't use the whole line
because "diff -u" likes to include timestamps, like so:

 --- foo	2000-07-12 16:56:50.020000414 -0500
 +++ bar	2010-07-12 16:56:50.020000414 -0500

The whitespace-seeking heuristic works great, even when the tab
has been converted to spaces by some email + copy-and-paste
related corruption.

Except for one problem: if the filename itself contains whitespace,
the inferred filename will be too short.

When Giuseppe ran into this problem, it was for a file creation
patch (for debian/licenses/LICENSE.global BSD-style Chromium).
So one can't use the list of files present in the index to deduce an
appropriate filename (not to mention that way lies madness; see
v0.99~402, 2005-05-31).

Instead, look for a timestamp and use that if present to mark the end
of the filename.  If no timestamp is present, the old heuristic is
used, with one exception: the space character \040 is not considered
terminating whitespace any more unless it is followed by a timestamp.

Reported-by: Giuseppe Iuculano <iuculano@debian.org>
Acked-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21 23:04:29 -07:00
Jonathan Nieder bb7306b5a3 apply: split quoted filename handling into new function
The new find_name_gnu() function handles new-style '--- "a/foo"'
patch header lines, leaving find_name() itself a bit less
daunting.

Functional change: do not clobber the p-value when there are not
enough path components in a quoted file name to honor it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-21 23:04:22 -07:00
Nguyễn Thái Ngọc Duy d1ea896290 apply: run setup_git_directory_gently() sooner
As v1.7.2~16^2 (2010-07-14) explains, without this change,
“git --paginate apply” can ignore the repository-local
“[core] pager” configuration.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-15 19:56:10 -07:00
Junio C Hamano 18cdf802ca Teach "apply --index-info" to handle rename patches
With v1.5.3.2~14 (apply --index-info: fall back to current index for
mode changes, 2007-09-17), git apply learned to stop worrying
about the lack of diff index line when a file already present in the
current index had no content change.

But it still worries too much: for rename patches, it is checking
that both the old and new filename are present in the current
index.  This makes no sense, since a file rename generally
involves creating a file there was none before.

So just check the old filename.

Noticed while trying to use “git rebase” with diff.renames = copies.

[jn: add tests]

Reported-by: David D. Kilzer <ddkilzer@kilzer.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23 14:44:38 -07:00
Junio C Hamano a53deac89e Merge branch 'jp/string-list-api-cleanup'
* jp/string-list-api-cleanup:
  string_list: Fix argument order for string_list_append
  string_list: Fix argument order for string_list_lookup
  string_list: Fix argument order for string_list_insert_at_index
  string_list: Fix argument order for string_list_insert
  string_list: Fix argument order for for_each_string_list
  string_list: Fix argument order for print_string_list
2010-06-30 11:55:38 -07:00
Julian Phillips 1d2f80fa79 string_list: Fix argument order for string_list_append
Update the definition and callers of string_list_append to use the
string_list as the first argument.  This helps make the string_list
API easier to use by being more consistent.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27 10:06:52 -07:00
Julian Phillips e8c8b7139c string_list: Fix argument order for string_list_lookup
Update the definition and callers of string_list_lookup to use the
string_list as the first argument.  This helps make the string_list
API easier to use by being more consistent.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27 10:06:51 -07:00
Julian Phillips 78a395d371 string_list: Fix argument order for string_list_insert
Update the definition and callers of string_list_insert to use the
string_list as the first argument.  This helps make the string_list
API easier to use by being more consistent.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-27 10:06:51 -07:00
Junio C Hamano 8d676d85f7 Merge branch 'gv/portable'
* gv/portable:
  test-lib: use DIFF definition from GIT-BUILD-OPTIONS
  build: propagate $DIFF to scripts
  Makefile: Tru64 portability fix
  Makefile: HP-UX 10.20 portability fixes
  Makefile: HPUX11 portability fixes
  Makefile: SunOS 5.6 portability fix
  inline declaration does not work on AIX
  Allow disabling "inline"
  Some platforms lack socklen_t type
  Make NO_{INET_NTOP,INET_PTON} configured independently
  Makefile: some platforms do not have hstrerror anywhere
  git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition
  test_cmp: do not use "diff -u" on platforms that lack one
  fixup: do not unconditionally disable "diff -u"
  tests: use "test_cmp", not "diff", when verifying the result
  Do not use "diff" found on PATH while building and installing
  enums: omit trailing comma for portability
  Makefile: -lpthread may still be necessary when libc has only pthread stubs
  Rewrite dynamic structure initializations to runtime assignment
  Makefile: pass CPPFLAGS through to fllow customization

Conflicts:
	Makefile
	wt-status.h
2010-06-21 06:02:44 -07:00
Gary V. Vaughan 4b05548fc0 enums: omit trailing comma for portability
Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX
5.1 fails to compile git.

enum style is inconsistent already, with some enums declared on one
line, some over 3 lines with the enum values all on the middle line,
sometimes with 1 enum value per line... and independently of that the
trailing comma is sometimes present and other times absent, often
mixing with/without trailing comma styles in a single file, and
sometimes in consecutive enum declarations.

Clearly, omitting the comma is the more portable style, and this patch
changes all enum declarations to use the portable omitted dangling
comma style consistently.

Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-31 16:59:27 -07:00
Junio C Hamano b7511571e3 Merge branch 'bg/apply-blank-trailing-context'
* bg/apply-blank-trailing-context:
  apply: Allow blank *trailing* context lines to match beyond EOF
2010-05-08 22:37:41 -07:00
Junio C Hamano c58c5129d6 Merge branch 'cw/ws-indent-with-tab'
* cw/ws-indent-with-tab:
  whitespace: tests for git-apply --whitespace=fix with tab-in-indent
  whitespace: add tab-in-indent support for --whitespace=fix
  whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dst
  whitespace: tests for git-diff --check with tab-in-indent error class
  whitespace: add tab-in-indent error class
  whitespace: we cannot "catch all errors known to git" anymore
2010-05-08 22:35:35 -07:00
Junio C Hamano 3ecaa3b6a5 Merge branch 'pc/remove-warn'
* pc/remove-warn:
  Remove a redundant errno test in a usage of remove_path
  Introduce remove_or_warn function
  Implement the rmdir_or_warn function
  Generalise the unlink_or_warn function
2010-05-08 22:32:59 -07:00
Junio C Hamano 3b0c19663e Merge branch 'maint'
* maint:
  Let check_preimage() use memset() to initialize "struct checkout"
  fetch/push: fix usage strings
2010-04-09 22:43:18 -07:00
Chris Webb d511bd330d whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dst
To implement --whitespace=fix for tab-in-indent, we have to allow for the
possibility that whitespace can increase in size when it is fixed, expanding
tabs to to multiple spaces in the initial indent.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-04 14:21:54 -07:00
Peter Collingbourne 80d706afed Introduce remove_or_warn function
This patch introduces the remove_or_warn function which is a
generalised version of the {unlink,rmdir}_or_warn functions.  It takes
an additional parameter indicating the mode of the file to be removed.

The patch also modifies certain functions to use remove_or_warn
where appropriate, and adds a test case for a bug fixed by the use
of remove_or_warn.

Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28 09:53:04 -07:00
Junio C Hamano 31fbae0f81 Merge branch 'bg/apply-fix-blank-at-eof'
* bg/apply-fix-blank-at-eof:
  t3417: Add test cases for "rebase --whitespace=fix"
  t4124: Add additional tests of --whitespace=fix
  apply: Allow blank context lines to match beyond EOF
  apply: Remove the quick rejection test
  apply: Don't unnecessarily update line lengths in the preimage
2010-03-20 11:29:35 -07:00
Linus Torvalds 81b50f3ce4 Move 'builtin-*' into a 'builtin/' subdirectory
This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of

	[torvalds@nehalem git]$ em buil<tab>
	Display all 180 possibilities? (y or n)
	[torvalds@nehalem git]$ em builtin-sh
	builtin-shortlog.c     builtin-show-branch.c  builtin-show-ref.c
	builtin-shortlog.o     builtin-show-branch.o  builtin-show-ref.o
	[torvalds@nehalem git]$ em builtin-shor<tab>
	builtin-shortlog.c  builtin-shortlog.o
	[torvalds@nehalem git]$ em builtin-shortlog.c

you get

	[torvalds@nehalem git]$ em buil<tab>		[type]
	builtin/   builtin.h
	[torvalds@nehalem git]$ em builtin		[auto-completes to]
	[torvalds@nehalem git]$ em builtin/sh<tab>	[type]
	shortlog.c     shortlog.o     show-branch.c  show-branch.o  show-ref.c     show-ref.o
	[torvalds@nehalem git]$ em builtin/sho		[auto-completes to]
	[torvalds@nehalem git]$ em builtin/shor<tab>	[type]
	shortlog.c  shortlog.o
	[torvalds@nehalem git]$ em builtin/shortlog.c

which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.

NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead.  I think bash has some cut-off
around 100 choices or something.

So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion.  But you can
simulate that by using 'ls' instead, or something similar.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-22 14:29:41 -08:00
Renamed from builtin-apply.c (Browse further)