1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00
Commit graph

1247 commits

Author SHA1 Message Date
Junio C Hamano
eb69934bbd builtin/add.c: use path_excluded()
This only happens in --ignore-missing --dry-run codepath which
presumably nobody should care, but is for completeness.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-05 21:44:22 -07:00
Junio C Hamano
782cd4c0f6 path_excluded(): update API to less cache-entry centric
It was stupid of me to make the API too much cache-entry specific;
the caller may want to check arbitrary pathname without having a
corresponding cache-entry to see if a path is ignored.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-05 21:22:36 -07:00
Junio C Hamano
eb41775ecc ls-files -i: pay attention to exclusion of leading paths
"git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.

The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory.  This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.

The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.

Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03 16:05:42 -07:00
Junio C Hamano
6d5c16a90c Merge branch 'tr/cache-tree' into maint-1.7.8
* tr/cache-tree:
  t0090: be prepared that 'wc -l' writes leading blanks
  reset: update cache-tree data when appropriate
  commit: write cache-tree data when writing index anyway
  Refactor cache_tree_update idiom from commit
  Test the current state of the cache-tree optimization
  Add test-scrap-cache-tree
2012-04-09 13:40:32 -07:00
Junio C Hamano
39af78961d Merge branch 'jc/advise-i18n' into maint-1.7.8
* jc/advise-i18n:
  i18n of multi-line advice messages
2012-03-20 15:25:38 -07:00
Junio C Hamano
5a6a939481 Merge branch 'maint-1.7.7' into maint
* maint-1.7.7:
  Update draft release notes to 1.7.7.6
  Update draft release notes to 1.7.6.6
  thin-pack: try harder to use preferred base objects as base
2012-01-12 23:31:46 -08:00
Junio C Hamano
901c907d83 Merge branch 'maint-1.7.6' into maint-1.7.7
* maint-1.7.6:
  Update draft release notes to 1.7.6.6
  thin-pack: try harder to use preferred base objects as base
2012-01-12 23:31:05 -08:00
Jeff King
15f07e061e thin-pack: try harder to use preferred base objects as base
When creating a pack using objects that reside in existing packs, we try
to avoid recomputing futile delta between an object (trg) and a candidate
for its base object (src) if they are stored in the same packfile, and trg
is not recorded as a delta already. This heuristics makes sense because it
is likely that we tried to express trg as a delta based on src but it did
not produce a good delta when we created the existing pack.

As the pack heuristics prefer producing delta to remove data, and Linus's
law dictates that the size of a file grows over time, we tend to record
the newest version of the file as inflated, and older ones as delta
against it.

When creating a thin-pack to transfer recent history, it is likely that we
will try to send an object that is recorded in full, as it is newer.  But
the heuristics to avoid recomputing futile delta effectively forbids us
from attempting to express such an object as a delta based on another
object. Sending an object in full is often more expensive than sending a
suboptimal delta based on other objects, and it is even more so if we
could use an object we know the receiving end already has (i.e. preferred
base object) as the delta base.

Tweak the recomputation avoidance logic, so that we do not punt on
computing delta against a preferred base object.

The effect of this change can be seen on two simulated upload-pack
workloads. The first is based on 44 reflog entries from my git.git
origin/master reflog, and represents the packs that kernel.org sent me git
updates for the past month or two. The second workload represents much
larger fetches, going from git's v1.0.0 tag to v1.1.0, then v1.1.0 to
v1.2.0, and so on.

The table below shows the average generated pack size and the average CPU
time consumed for each dataset, both before and after the patch:

                  dataset
            | reflog | tags
---------------------------------
     before | 53358  | 2750977
size  after | 32398  | 2668479
     change |   -39% |      -3%
---------------------------------
     before |  0.18  | 1.12
CPU   after |  0.18  | 1.15
     change |    +0% |      +3%

This patch makes a much bigger difference for packs with a shorter slice
of history (since its effect is seen at the boundaries of the pack) though
it has some benefit even for larger packs.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-12 23:06:20 -08:00
Junio C Hamano
9a8e485430 Merge branch 'jv/maint-config-set' into maint
* jv/maint-config-set:
  Fix an incorrect reference to --set-all.
2011-12-28 12:03:19 -08:00
Junio C Hamano
9b0b0b4f45 Merge branch 'jc/checkout-m-twoway' into maint
* jc/checkout-m-twoway:
  t/t2023-checkout-m.sh: fix use of test_must_fail
  checkout_merged(): squelch false warning from some gcc
  Test 'checkout -m -- path'
  checkout -m: no need to insist on having all 3 stages
2011-12-28 11:44:54 -08:00
Junio C Hamano
b42e81afe2 Merge branch 'jk/maint-strbuf-missing-init' into maint
* jk/maint-strbuf-missing-init:
  commit, merge: initialize static strbuf
2011-12-28 11:42:46 -08:00
Junio C Hamano
770dd00ebd Merge branch 'jn/maint-sequencer-fixes' into maint
* jn/maint-sequencer-fixes:
  revert: stop creating and removing sequencer-old directory
  Revert "reset: Make reset remove the sequencer state"
  revert: do not remove state until sequence is finished
  revert: allow single-pick in the middle of cherry-pick sequence
  revert: pass around rev-list args in already-parsed form
  revert: allow cherry-pick --continue to commit before resuming
  revert: give --continue handling its own function
2011-12-28 11:32:39 -08:00
Junio C Hamano
699eb54876 Merge branch 'jk/maint-mv' into maint
* jk/maint-mv:
  mv: be quiet about overwriting
  mv: improve overwrite warning
  mv: make non-directory destination error more clear
  mv: honor --verbose flag
  docs: mention "-k" for both forms of "git mv"
2011-12-28 11:32:36 -08:00
Junio C Hamano
7a5638a159 Merge branch 'jk/fetch-no-tail-match-refs' into maint
* jk/fetch-no-tail-match-refs:
  connect.c: drop path_match function
  fetch-pack: match refs exactly
  t5500: give fully-qualified refs to fetch-pack
  drop "match" parameter from get_remote_heads
2011-12-28 11:32:36 -08:00
Junio C Hamano
474294963e Merge branch 'ci/stripspace-docs' into maint
* ci/stripspace-docs:
  Update documentation for stripspace
2011-12-28 11:32:35 -08:00
Junio C Hamano
79587741cb Merge branch 'jn/branch-move-to-self' into maint
* jn/branch-move-to-self:
  Allow checkout -B <current-branch> to update the current branch
  branch: allow a no-op "branch -M <current-branch> HEAD"
2011-12-28 11:32:33 -08:00
Jelmer Vernooij
67e223edc4 Fix an incorrect reference to --set-all.
Signed-off-by: Jelmer Vernooij <jelmer@samba.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-27 11:14:18 -08:00
Junio C Hamano
23cb5bf3b3 i18n of multi-line advice messages
Advice messages are by definition meant for human end-users, and prime
candidates for i18n/l10n. They tend to also be more verbose to be helpful,
and need to be longer than just one line.

Although we do not have parameterized multi-line advice messages yet, once
we do, we cannot emit such a message like this:

    advise(_("Please rename %s to something else"), gostak);
    advise(_("so that we can avoid distimming %s unnecessarily."), doshes);

because some translations may need to have the replacement of 'gostak' on
the second line (or 'doshes' on the first line). Some languages may even
need to use three lines in order to fit the same message within a
reasonable width.

Instead, it has to be a single advise() construct, like this:

    advise(_("Please rename %s to something else\n"
             "so that we can avoid distimming %s unnecessarily."),
           gostak, doshes);

Update the advise() function and its existing callers to

 - take a format string that can be multi-line and translatable as a
   whole;
 - use the string and the parameters to form a localized message; and
 - show each line in the result with the localization of the "hint: ".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-22 11:21:26 -08:00
Junio C Hamano
406cc9b822 Merge branch 'bc/maint-apply-check-no-patch' into maint
* bc/maint-apply-check-no-patch:
  builtin/apply.c: report error on failure to recognize input
  t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-21 11:42:45 -08:00
Carlos Martín Nieto
a31275d6ff clone: the -o option has nothing to do with <branch>
It is to give an alternate <name> instead of "origin" to the remote
we are cloning from.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-21 11:26:30 -08:00
Michael Schubert
967cf9867d builtin/log: remove redundant initialization
"abbrev" and "commit_format" in struct rev_info get initialized in
init_revisions - no need to reinit in cmd_log_init_defaults.

Signed-off-by: Michael Schubert <mschub@elegosoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-21 11:15:56 -08:00
Junio C Hamano
f1f509cc45 Merge branch 'ms/commit-cc-option-helpstring' into maint
* ms/commit-cc-option-helpstring:
  builtin/commit: add missing '/' in help message
2011-12-21 10:50:20 -08:00
Ævar Arnfjörð Bjarmason
97f261b1e7 builtin/init-db.c: eliminate -Wformat warning on Solaris
On Solaris systems we'd warn about an implicit cast of mode_t when we
printed things out with the %d format. We'd get this warning under GCC
4.6.0 with Solaris headers:

    builtin/init-db.c: In function ‘separate_git_dir’:
    builtin/init-db.c:354:4: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘mode_t’ [-Wformat]

We've been doing this ever since v1.7.4.1-296-gb57fb80. Just work
around this by adding an explicit cast.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-20 16:02:08 -08:00
Junio C Hamano
03f94ae9f9 Update jk/maint-strbuf-missing-init to builtin/ rename 2011-12-18 00:28:16 -08:00
Junio C Hamano
335c6e403d checkout_merged(): squelch false warning from some gcc
gcc 4.6.2 (there may be others) does not realize that the variable "mode"
can never be used uninitialized in this function and issues a false warning
under -Wuninitialized option.

Squelch it with an unnecessary initialization; it is not like a single
assignment matters to the performance in this codepath that writes out
to the filesystem with checkout_entry() anyway.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-15 10:10:11 -08:00
Junio C Hamano
2e8722fc9e Merge branch 'jc/maint-pack-object-cycle' into maint
* jc/maint-pack-object-cycle:
  pack-object: tolerate broken packs that have duplicated objects

Conflicts:
	builtin/pack-objects.c
2011-12-13 22:04:50 -08:00
Junio C Hamano
68f80f5490 Merge branch 'jc/index-pack-reject-dups' into maint
* jc/index-pack-reject-dups:
  receive-pack, fetch-pack: reject bogus pack that records objects twice
2011-12-13 22:03:36 -08:00
Junio C Hamano
df6246ed78 Merge branch 'nd/misc-cleanups' into maint
* nd/misc-cleanups:
  unpack_object_header_buffer(): clear the size field upon error
  tree_entry_interesting: make use of local pointer "item"
  tree_entry_interesting(): give meaningful names to return values
  read_directory_recursive: reduce one indentation level
  get_tree_entry(): do not call find_tree_entry() on an empty tree
  tree-walk.c: do not leak internal structure in tree_entry_len()
2011-12-13 22:02:51 -08:00
Junio C Hamano
8311158c66 Merge branch 'maint-1.7.7' into maint
* maint-1.7.7:
  Git 1.7.7.5
  Git 1.7.6.5
  blame: don't overflow time buffer
  fetch: create status table using strbuf
  checkout,merge: loosen overwriting untracked file check based on info/exclude
  cast variable in call to free() in builtin/diff.c and submodule.c
  apply: get rid of useless x < 0 comparison on a size_t type

Conflicts:
	Documentation/git.txt
	GIT-VERSION-GEN
	RelNotes
	builtin/fetch.c
2011-12-13 21:58:51 -08:00
Junio C Hamano
c0eb9ccfb9 Merge branch 'ab/clang-lints' into maint-1.7.7
* ab/clang-lints:
  cast variable in call to free() in builtin/diff.c and submodule.c
  apply: get rid of useless x < 0 comparison on a size_t type
2011-12-13 21:47:51 -08:00
Junio C Hamano
3b425656a4 Merge branch 'nd/maint-ignore-exclude' into maint-1.7.7
* nd/maint-ignore-exclude:
  checkout,merge: loosen overwriting untracked file check based on info/exclude
2011-12-13 21:47:08 -08:00
Junio C Hamano
7857e3246f Merge branch 'maint-1.7.6' into maint-1.7.7
* maint-1.7.6:
  Git 1.7.6.5
  blame: don't overflow time buffer
  fetch: create status table using strbuf

Conflicts:
	Documentation/git.txt
	GIT-VERSION-GEN
	RelNotes
2011-12-13 21:44:56 -08:00
Junio C Hamano
52b195f2b8 Merge branch 'jk/maint-fetch-status-table' into maint-1.7.6
* jk/maint-fetch-status-table:
  fetch: create status table using strbuf
2011-12-13 21:21:30 -08:00
Junio C Hamano
43176d1e4c Merge branch 'jc/maint-name-rev-all' into maint-1.7.6
* jc/maint-name-rev-all:
  name-rev --all: do not even attempt to describe non-commit object
2011-12-13 21:12:34 -08:00
Jeff King
c3ea051544 blame: don't overflow time buffer
When showing the raw timestamp, we format the numeric
seconds-since-epoch into a buffer, followed by the timezone
string. This string has come straight from the commit
object. A well-formed object should have a timezone string
of only a few bytes, but we could be operating on data
pushed by a malicious user.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13 21:09:06 -08:00
Jeff King
1e7ba0f9ca fetch-pack: match refs exactly
When we are determining the list of refs to fetch via
fetch-pack, we have two sets of refs to compare: those on
the remote side, and a "match" list of things we want to
fetch. We iterate through the remote refs alphabetically,
seeing if each one is wanted by the "match" list.

Since def88e9 (Commit first cut at "git-fetch-pack",
2005-07-04), we have used the "path_match" function to do a
suffix match, where a remote ref is considered wanted if
any of the "match" elements is a suffix of the remote
refname.

This enables callers of fetch-pack to specify unqualified
refs and have them matched up with remote refs (e.g., ask
for "A" and get remote's "refs/heads/A"). However, if you
provide a fully qualified ref, then there are corner cases
where we provide the wrong answer. For example, given a
remote with two refs:

   refs/foo/refs/heads/master
   refs/heads/master

asking for "refs/heads/master" will first match
"refs/foo/refs/heads/master" by the suffix rule, and we will
erroneously fetch it instead of refs/heads/master.

As it turns out, all callers of fetch_pack do provide
fully-qualified refs for the match list. There are two ways
fetch_pack can get match lists:

  1. Through the transport code (i.e., via git-fetch)

  2. On the command-line of git-fetch-pack

In the first case, we will always be providing the names of
fully-qualified refs from "struct ref" objects. We will have
pre-matched those ref objects already (since we have to
handle more advanced matching, like wildcard refspecs), and
are just providing a list of the refs whose objects we need.

In the second case, users could in theory be providing
non-qualified refs on the command-line. However, the
fetch-pack documentation claims that refs should be fully
qualified (and has always done so since it was written in
2005).

Let's change this path_match call to simply check for string
equality, matching what the callers of fetch_pack are
expecting.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13 10:17:50 -08:00
Jeff King
afe7c5ff1f drop "match" parameter from get_remote_heads
The get_remote_heads function reads the list of remote refs
during git protocol session. It dates all the way back to
def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04).
At that time, the idea was to come up with a list of refs we
were interested in, and then filter the list as we got it
from the remote side.

Later, 1baaae5 (Make maximal use of the remote refs,
2005-10-28) stopped filtering at the get_remote_heads layer,
letting us use the non-matching refs to find common history.

As a result, all callers now simply pass an empty match
list (and any future callers will want to do the same). So
let's drop these now-useless parameters.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13 10:08:24 -08:00
Conrad Irwin
497215d881 Update documentation for stripspace
Tell the user what this command is intended for, and expand the
description of what it does.

Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 16:48:54 -08:00
Jeff King
534376ca04 mv: be quiet about overwriting
When a user asks us to force a mv and overwrite the
destination, we print a warning. However, since a typical
use would be:

  $ git mv one two
  fatal: destination exists, source=one, destination=two
  $ git mv -f one two
  warning: overwriting 'two'

this warning is just noise. We already know we're
overwriting; that's why we gave -f!

This patch silences the warning unless "--verbose" is given.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 15:43:45 -08:00
Jeff King
cd40b05d13 mv: improve overwrite warning
When we try to "git mv" over an existing file, the error
message is fairly informative:

  $ git mv one two
  fatal: destination exists, source=one, destination=two

When the user forces the overwrite, we give a warning:

  $ git mv -f one two
  warning: destination exists; will overwrite!

This is less informative, but still sufficient in the simple
rename case, as there is only one rename happening.

But when moving files from one directory to another, it
becomes useless:

  $ mkdir three
  $ touch one two three/one
  $ git add .
  $ git mv one two three
  fatal: destination exists, source=one, destination=three/one
  $ git mv -f one two three
  warning: destination exists; will overwrite!

The first message is helpful, but the second one gives us no
clue about what was overwritten. Let's mention the name of
the destination file:

  $ git mv -f one two three
  warning: overwriting 'three/one'

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 15:43:38 -08:00
Jonathan Nieder
d596118d7a revert: stop creating and removing sequencer-old directory
Now that "git reset" no longer implicitly removes .git/sequencer that
the operator may or may not have wanted to keep, the logic to write a
backup copy of .git/sequencer and remove it when stale is not needed
any more.  Simplify the sequencer API and repository layout by
dropping it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:33:53 -08:00
Jonathan Nieder
218b65fbf9 revert: do not remove state until sequence is finished
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes
the sequencer state just before applying the final patch.  In the
single-pick case, that was a good thing, since --abort and --continue
work fine without access to such state and removing it provides a
signal that git should not complain about the need to clobber it ("a
cherry-pick or revert is already in progress") in sequences like the
following:

	git cherry-pick foo
	git read-tree -m -u HEAD; # forget that; let's try a different one
	git cherry-pick bar

After the recent patch "allow single-pick in the middle of cherry-pick
sequence" we don't need that hack any more.  In the new regime, a
traditional "git cherry-pick <commit>" command never looks at
.git/sequencer, so we do not need to cripple "git cherry-pick
<commit>..<commit>" for it any more.

So now you can run "git cherry-pick --abort" near the end of a
multi-pick sequence and it will abort the entire sequence, instead of
misbehaving and aborting just the final commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:33:53 -08:00
Jonathan Nieder
7acaaac275 revert: allow single-pick in the middle of cherry-pick sequence
After messing up a difficult conflict resolution in the middle of a
cherry-pick sequence, it can be useful to be able to

	git checkout HEAD . && git cherry-pick that-one-commit

to restart the conflict resolution. The current code however errors out
saying that another cherry-pick is already in progress.

Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:32:16 -08:00
Jonathan Nieder
7f13334e07 revert: pass around rev-list args in already-parsed form
Since 7e2bfd3f (revert: allow cherry-picking more than one commit,
2010-07-02), the pick/revert machinery has kept track of the set of
commits to be cherry-picked or reverted using commit_argc and
commit_argv variables, storing the corresponding command-line
parameters.

Future callers as other commands are built in (am, rebase, sequencer)
may find it easier to pass rev-list options to this machinery in
already-parsed form.  Teach cmd_cherry_pick and cmd_revert to parse
the rev-list arguments in advance and pass the commit set to
pick_revisions() as a rev_info structure.

Original patch by Jonathan, tweaks and test from Ram.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:32:16 -08:00
Jonathan Nieder
093a309136 revert: allow cherry-pick --continue to commit before resuming
When "git cherry-pick ..bar" encounters conflicts, permit the operator
to use cherry-pick --continue after resolving them as a shortcut for
"git commit && git cherry-pick --continue" to record the resolution
and carry on with the rest of the sequence.

This improves the analogy with "git rebase" (in olden days --continue
was the way to preserve authorship when a rebase encountered
conflicts) and fits well with a general UI goal of making "git cmd
--continue" save humans the trouble of deciding what to do next.

Example: after encountering a conflict from running "git cherry-pick
foo bar baz":

	CONFLICT (content): Merge conflict in main.c
	error: could not apply f78a8d98c... bar!
	hint: after resolving the conflicts, mark the corrected paths
	hint: with 'git add <paths>' or 'git rm <paths>'
	hint: and commit the result with 'git commit'

We edit main.c to resolve the conflict, mark it acceptable with "git
add main.c", and can run "cherry-pick --continue" to resume the
sequence.

	$ git cherry-pick --continue
	[editor opens to confirm commit message]
	[master 78c8a8c98] bar!
	 1 files changed, 1 insertions(+), 1 deletions(-)
	[master 87ca8798c] baz!
	 1 files changed, 1 insertions(+), 1 deletions(-)

This is done for both codepaths to pick multiple commits and a single
commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:31:32 -08:00
Jonathan Nieder
1df9bf46d6 revert: give --continue handling its own function
This makes pick_revisions() a little shorter and easier to read
straight through.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 13:06:36 -08:00
Jeff King
77471646d3 mv: make non-directory destination error more clear
If you try to "git mv" multiple files onto another
non-directory file, you confusingly get the "usage" message:

  $ touch one two three
  $ git add .
  $ git mv one two three
  usage: git mv [options] <source>... <destination>
  [...]

From the user's perspective, that makes no sense. They just
gave parameters that exactly match that usage!

This behavior dates back to the original C version of "git
mv", which had a usage message like:

  usage: git mv (<source> <destination> | <source>...  <destination>)

This was slightly less confusing, because it at least
mentions that there are two ways to invoke (but it still
isn't clear why what the user provided doesn't work).

Instead, let's show an error message like:

  $ git mv one two three
  fatal: destination 'three' is not a directory

We could leave the usage message in place, too, but it
doesn't actually help here. It contains no hints that there
are two forms, nor that multi-file form requires that the
endpoint be a directory. So it just becomes useless noise
that distracts from the real error.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 11:55:46 -08:00
Jeff King
07b8738967 mv: honor --verbose flag
The code for a verbose flag has been here since "git mv" was
converted to C many years ago, but actually getting the "-v"
flag from the command line was accidentally lost in the
transition.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12 11:52:31 -08:00
Jeff King
5914f2d057 fetch: create status table using strbuf
When we fetch from a remote, we print a status table like:

  From url
   * [new branch]   foo -> origin/foo

We create this table in a static buffer using sprintf. If
the remote refnames are long, they can overflow this buffer
and smash the stack.

Instead, let's use a strbuf to build the string.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09 23:17:00 -08:00
Thomas Rast
6c52ec8a9a reset: update cache-tree data when appropriate
In the case of --mixed and --hard, we throw away the old index and
rebuild everything from the tree argument (or HEAD).  So we have an
opportunity here to fill in the cache-tree data, just as read-tree
did.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-06 15:13:39 -08:00