Commit Graph

64 Commits

Author SHA1 Message Date
Tuncer Ayaz
7f87aff22c Teach/Fix pull/fetch -q/-v options
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14 17:18:32 -08:00
Junio C Hamano
ca6c06b2ef Merge branch 'js/maint-fetch-update-head'
* js/maint-fetch-update-head:
  pull: allow "git pull origin $something:$current_branch" into an unborn branch
  Fix fetch/pull when run without --update-head-ok

Conflicts:
	t/t5510-fetch.sh
2008-10-21 17:58:21 -07:00
René Scharfe
59c69c0c65 make alloc_ref_from_str() the new alloc_ref()
With all calls to alloc_ref() gone, we can remove it and then we're free
to give alloc_ref_from_str() the shorter name.  It's a much nicer
interface, as the callers always need to have a name string when they
allocate a ref anyway and don't need to calculate and pass its length+1
any more.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-18 06:53:47 -07:00
Johannes Schindelin
8ee5d73137 Fix fetch/pull when run without --update-head-ok
Some confusing tutorials suggested that it would be a good idea to fetch
into the current branch with something like this:

	git fetch origin master:master

(or even worse: the same command line with "pull" instead of "fetch").
While it might make sense to store what you want to pull, it typically is
plain wrong when the current branch is "master".  This should only be
allowed when (an incorrect) "git pull origin master:master" tries to work
around by giving --update-head-ok to underlying "git fetch", and otherwise
we should refuse it, but somewhere along the lines we lost that behavior.

The check for the current branch is now _only_ performed in non-bare
repositories, which is an improvement from the original behaviour.

Some newer tests were depending on the broken behaviour of "git fetch"
this patch fixes, and have been adjusted.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-13 10:46:03 -07:00
Heikki Orsila
05207a2881 Start conforming code to "git subcmd" style part 2
User notifications are presented as 'git cmd', and code comments
are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.

Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-09 08:41:29 -07:00
Johannes Schindelin
c455c87c5c Rename path_list to string_list
The name path_list was correct for the first usage of that data structure,
but it really is a general-purpose string list.

$ perl -i -pe 's/path-list/string-list/g' $(git grep -l path-list)
$ perl -i -pe 's/path_list/string_list/g' $(git grep -l path_list)
$ git mv path-list.h string-list.h
$ git mv path-list.c string-list.c
$ perl -i -pe 's/has_path/has_string/g' $(git grep -l has_path)
$ perl -i -pe 's/path/string/g' string-list.[ch]
$ git mv Documentation/technical/api-path-list.txt \
	Documentation/technical/api-string-list.txt
$ perl -i -pe 's/strdup_paths/strdup_strings/g' $(git grep -l strdup_paths)

... and then fix all users of string-list to access the member "string"
instead of "path".

Documentation/technical/api-string-list.txt needed some rewrapping, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21 19:11:50 -07:00
Stephan Beyer
1b1dd23f2d Make usage strings dash-less
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form.  So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.

This patch makes git commands show the dash-less version.

For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 14:12:48 -07:00
Jeff King
f3cb169bc9 fetch: give a hint to the user when local refs fail to update
There are basically two categories of update failures for
local refs:

  1. problems outside of git, like disk full, bad
     permissions, etc.

  2. D/F conflicts on tracking branch ref names

In either case, there should already have been an error
message. In case '1', hopefully enough information has
already been given that the user can fix it. In the case of
'2', we can hint that the user can clean up their tracking
branch area by using 'git remote prune'.

Note that we don't actually know _which_ case we have, so
the user will receive the hint in case 1, as well. In this
case the suggestion won't do any good, but hopefully the
user is smart enough to figure out that it's just a hint.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-29 23:47:41 -07:00
Jeff King
6315472eed fetch: report local storage errors in status table
Previously, if there was an error while storing a local
tracking ref, the low-level functions would report an error,
but fetch's status output wouldn't indicate any problem.
E.g., imagine you have an old "refs/remotes/origin/foo/bar" but
upstream has deleted "foo/bar" in favor of a new branch
"foo". You would get output like this:

  error: there are still refs under 'refs/remotes/origin/foo'
  From $url_of_repo
   * [new branch]      foo        -> origin/foo

With this patch, the output takes into account the status of
updating the local ref:

  error: there are still refs under 'refs/remotes/origin/foo'
  From $url_of_repo
   ! [new branch]      foo        -> origin/foo  (unable to update local ref)

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-27 16:22:51 -07:00
Dmitry V. Levin
efb98b4453 builtin-fetch.c (store_updated_refs): Honor update_local_ref() return value
Sync with builtin-fetch--tool.c where append_fetch_head()
honors update_local_ref() return value.

This fixes non fast forward fetch exit status,
http://bugzilla.altlinux.org/show_bug.cgi?id=15037

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-28 10:47:12 -07:00
Junio C Hamano
b84c343c88 Merge branch 'db/clone-in-c'
* db/clone-in-c:
  Add test for cloning with "--reference" repo being a subset of source repo
  Add a test for another combination of --reference
  Test that --reference actually suppresses fetching referenced objects
  clone: fall back to copying if hardlinking fails
  builtin-clone.c: Need to closedir() in copy_or_link_directory()
  builtin-clone: fix initial checkout
  Build in clone
  Provide API access to init_db()
  Add a function to set a non-default work tree
  Allow for having for_each_ref() list extra refs
  Have a constant extern refspec for "--tags"
  Add a library function to add an alternate to the alternates file
  Add a lockfile function to append to a file
  Mark the list of refs to fetch as const

Conflicts:

	cache.h
	t/t5700-clone-reference.sh
2008-05-25 13:41:37 -07:00
Krzysztof Kowalczyk
737922aa64 alloc_ref_from_str(): factor out a common pattern of alloc_ref from string
Also fix an underallocation in walker.c::interpret_target().

Signed-off-by: Krzysztof Kowalczyk <kkowalczyk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-11 09:04:37 -07:00
Junio C Hamano
9c36e1700f Merge branch 'jk/fetch-status'
* jk/fetch-status:
  git-fetch: always show status of non-tracking-ref fetches
2008-05-05 19:16:12 -07:00
Daniel Barkalow
e0aaa29ff3 Have a constant extern refspec for "--tags"
The refspec refs/tags/*:refs/tags/* is sufficiently common and generic
to merit having a constant instead of generating it as needed.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 17:41:44 -07:00
Alex Riesen
7b7f39eae6 Fix use after free() in builtin-fetch
As reported by Dave Jones:

Since master.kernel.org updated to latest, I noticed that I could crash
git-fetch by doing this..

export KERNEL=/pub/scm/linux/kernel/git/
git fetch $KERNEL/torvalds/linux-2.6 master:linus

(gdb) bt
 0  0x000000349fd6d44b in free () from /lib64/libc.so.6
 1  0x000000000048f4eb in transport_unlock_pack (transport=0x7ce530) at transport.c:811
 2  0x000000349fd31b25 in exit () from /lib64/libc.so.6
 3  0x00000000004043d8 in handle_internal_command (argc=3, argv=0x7fffea4449f0) at git.c:379
 4  0x0000000000404547 in main (argc=3, argv=0x7fffea4449f0) at git.c:443
 5  0x000000349fd1c784 in __libc_start_main () from /lib64/libc.so.6
 6  0x0000000000403ef9 in ?? ()
 7  0x00007fffea4449d8 in ?? ()
 8  0x0000000000000000 in ?? ()

I then remembered, my .bashrc has this..

export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))

which is handy for showing up such bugs.

More info on this glibc feature is at http://udrepper.livejournal.com/11429.html

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-28 23:57:47 -07:00
Jeff King
e5c49826d2 git-fetch: always show status of non-tracking-ref fetches
Previously, a fetch like:

  git fetch git://some/url

would show no ref status output (just the object downloading
status, if there was any), leading to some confusion.

With this patch, we now show the usual ref table, with
remote refs going into FETCH_HEAD. Previously this output
was shown only if "-v"erbose was specified.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10 01:02:59 -07:00
Jeff King
f59774add4 git-fetch: fix status output when not storing tracking ref
There was code in update_local_ref for handling this case,
but it never actually got called. It assumed that storing in
FETCH_HEAD meant a blank peer_ref name, but we actually have
a NULL peer_ref in this case, so we never even made it to
the update_local_ref function.

On top of that, the display formatting was different from
all of the other cases, probably owing to the fact that
nobody had ever actually seen the output.

This patch harmonizes the output with the other cases and
moves the detection of this case into store_updated_refs,
where we can actually trigger it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10 00:30:44 -07:00
Kevin Ballard
f53423b0e0 git-fetch: Don't trigger a bus error when given the refspec "tag"
When git-fetch encounters the refspec "tag" it assumes that the next
argument will be a tag name. If there is no next argument, it should
die gracefully instead of erroring.

Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-05 16:31:45 -07:00
Junio C Hamano
46220ca100 remote.c: Fix overtight refspec validation
We tightened the refspec validation code in an earlier commit ef00d15
(Tighten refspec processing, 2008-03-17) per my suggestion, but the
suggestion was misguided to begin with and it broke this usage:

    $ git push origin HEAD~12:master

The syntax of push refspecs and fetch refspecs are similar in that they
are both colon separated LHS and RHS (possibly prefixed with a + to
force), but the similarity ends there.  For example, LHS in a push refspec
can be anything that evaluates to a valid object name at runtime (except
when colon and RHS is missing, or it is a glob), while it must be a
valid-looking refname in a fetch refspec.  To validate them correctly, the
caller needs to be able to say which kind of refspecs they are.  It is
unreasonable to keep a single interface that cannot tell which kind it is
dealing with, and ask it to behave sensibly.

This commit separates the parsing of the two into different functions, and
clarifies the code to implement the parsing proper (i.e. splitting into
two parts, making sure both sides are wildcard or neither side is).

This happens to also allow pushing a commit named with the esoteric "look
for that string" syntax:

    $ git push ../test.git ':/remote.c: Fix overtight refspec:master'

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-22 23:46:17 -07:00
Junio C Hamano
16007f3916 Merge branch 'maint'
* maint:
  merge-file: handle empty files gracefully
  merge-recursive: handle file mode changes
  Minor wording changes in the keyboard descriptions in git-add --interactive.
  git fetch: Take '-n' to mean '--no-tags'
  quiltimport: fix misquoting of parsed -p<num> parameter
  git-quiltimport: better parser to grok "enhanced" series files.
2008-03-14 00:16:42 -07:00
Johannes Schindelin
e7951290f6 git fetch: Take '-n' to mean '--no-tags'
Prior to commit 8320199 (Rewrite builtin-fetch option parsing to use
parse_options().), we understood '-n' as a short option to mean "don't
fetch tags from the remote". This patch reinstates behaviour similar,
but not identical to the pre commit 8320199 times.

Back then, -n always overrode --tags, so if both --tags and -n was
given on command-line, no tags were fetched regardless of argument
ordering. Now we use a "last entry wins" strategy, so '-n --tags'
means "fetch tags".

Since it's patently absurd to say both --tags and --no-tags, this
shouldn't matter in practice.

Spotted-by: Artem Zolochevskiy <azol@altlinux.org>
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13 00:31:18 -07:00
Shawn O. Pearce
41fa7d2eae Teach git-fetch to exploit server side automatic tag following
If the remote peer upload-pack process supports the include-tag
protocol extension then we can avoid running a second fetch cycle
on the client side by letting the server send us the annotated tags
along with the objects it is packing for us.  In the following graph
we can now fetch both "tag1" and "tag2" on the same connection that
we fetched "master" from the remote when we only have L available
on the local side:

         T - tag1          S - tag2
        /                 /
   L - o ------ o ------ B
    \                     \
     \                     \
      origin/master         master

The objects for "tag1" are implicitly downloaded without our direct
knowledge.  The existing "quickfetch" optimization within git-fetch
discovers that tag1 is complete after the first connection and does
not open a second connection.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-04 23:28:15 -08:00
Shawn O. Pearce
cf7f929a10 Teach git-fetch to grab a tag at the same time as a commit
If the situation is the following on the remote and L is the common
base between both sides:

          T - tag1    S - tag2
         /           /
    L - A - O - O - B
     \               \
      origin/master   master

and we have decided to fetch "master" to acquire the range L..B we
can also nab tag S at the same time during the first connection,
as we can clearly see from the refs advertised by upload-pack that
S^{} = B and master = B.

Unfortunately we still cannot nab T at the same time as we are not
able to see that T^{} will also be in the range implied by L..B.
Such computations must be performed on the remote side (not yet
supported) or on the client side as post-processing (the current
behavior).

This optimization is an extension of the previous one in that it
helps on projects which tend to publish both a new commit and a
new tag, then lay idle for a while before publishing anything else.
Most followers are able to download both the new commit and the new
tag in one connection, rather than two.  git.git tends to follow
such patterns with its roughly once-daily updates from Junio.

A protocol extension and additional server side logic would be
necessary to also ensure T is grabbed on the first connection.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
767f176a1f Make git-fetch follow tags we already have objects for sooner
If autofollowing of tags is enabled, we see a new tag on the remote
that we don't have, and we already have the SHA-1 object that the
tag is peeled to, then we can fetch the tag while we are fetching
the other objects on the first connection.

This is a slight optimization for projects that have a habit of
tagging a release commit after most users have already seen and
downloaded that commit object through a prior fetch session. In
such cases the users may still find new objects in branch heads,
but the new tag will now also be part of the first pack transfer
and the subsequent connection to autofollow tags is not required.

Currently git.git does not benefit from this optimization as any
release usually gets a new commit at the same time that it gets a
new release tag, however git-gui.git and many other projects are
in the habit of tagging fairly old commits.

Users who did not already have the tagged commit still require
opening a second connection to autofollow the tag, as we are unable
to determine on the client side if $tag^{} will be sent to the
client during the first transfer or not.  Such computation must be
performed on the remote side of the connection and is deferred to
another series of changes.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
49d58fd077 Free the path_lists used to find non-local tags in git-fetch
To support calling find_non_local_tags() more than once in a single
git-fetch process we need the existing_refs to be stack-allocated
so it resets on the second call.  We also should free the path
lists to avoid unnecessary memory leaking.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
c50b2b4799 Allow builtin-fetch's find_non_local_tags to append onto a list
By allowing the function to append onto the end of an existing list
we can do more interesting things, like join the list of tags we
want to fetch into the first fetch, rather than the second.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
5aaf7f2afb Ensure tail pointer gets setup correctly when we fetch HEAD only
If we ever decided to append onto the end of this list the tail
pointer must be looking at the right memory cell at the end of
the HEAD ref_map.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
7f98428d4b Remove unnecessary delaying of free_refs(ref_map) in builtin-fetch
We can free this ref_map as soon as the fetch is complete.  It is not
used for the automatic tag following, nor is it used to disconnect the
transport.  This avoids some confusion about why we are holding onto
these refs while following tags.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Shawn O. Pearce
ff655a69df Remove unused variable in builtin-fetch find_non_local_tags
Apparently fetch_map is passed through, but is not actually used.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-03 00:05:45 -08:00
Daniel Barkalow
ba227857d2 Reduce the number of connects when fetching
This shares the connection between getting the remote ref list and
getting objects in the first batch. (A second connection is still used
to follow tags).

When we do not fetch objects (i.e. either ls-remote disconnects after
getting list of refs, or we decide we are already up-to-date), we
clean up the connection properly; otherwise the connection is left
open in need of cleaning up to avoid getting an error message from
the remote end when ssh is used.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05 00:40:18 -08:00
Kristian Høgsberg
8320199873 Rewrite builtin-fetch option parsing to use parse_options().
This gets a little tricky because of the way --tags and --no-tags
are handled, and the "tag <name>" syntax needs a little hand-holding too.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-04 23:48:39 -08:00
Kristian Høgsberg
2d324efad6 Use a strbuf for copying the command line for the reflog.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-04 01:20:06 -08:00
André Goddard Rosa
d6617c7cde Error out when user doesn't have access permission to the repository
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
2007-11-30 13:10:11 -08:00
Junio C Hamano
fd200790dc Merge branch 'jk/send-pack'
* jk/send-pack: (24 commits)
  send-pack: cluster ref status reporting
  send-pack: fix "everything up-to-date" message
  send-pack: tighten remote error reporting
  make "find_ref_by_name" a public function
  Fix warning about bitfield in struct ref
  send-pack: assign remote errors to each ref
  send-pack: check ref->status before updating tracking refs
  send-pack: track errors for each ref
  git-push: add documentation for the newly added --mirror mode
  Add tests for git push'es mirror mode
  Update the tracking references only if they were succesfully updated on remote
  Add a test checking if send-pack updated local tracking branches correctly
  git-push: plumb in --mirror mode
  Teach send-pack a mirror mode
  send-pack: segfault fix on forced push
  Reteach builtin-ls-remote to understand remotes
  send-pack: require --verbose to show update of tracking refs
  receive-pack: don't mention successful updates
  more terse push output
  Build in ls-remote
  ...
2007-11-24 16:45:37 -08:00
Junio C Hamano
f5f6cb87de 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
2007-11-14 14:26:04 -08:00
Junio C Hamano
a108e53861 Merge branch 'db/remote-builtin' into jk/send-pack
* db/remote-builtin:
  Reteach builtin-ls-remote to understand remotes
  Build in ls-remote
  Use built-in send-pack.
  Build-in send-pack, with an API for other programs to call.
  Build-in peek-remote, using transport infrastructure.
  Miscellaneous const changes and utilities

Conflicts:

	transport.c
2007-11-14 03:09:52 -08:00
Shawn O. Pearce
4191c35671 git-fetch: avoid local fetching from alternate (again)
Back in e3c6f240fd Junio taught
git-fetch to avoid copying objects when we are fetching from
a repository that is already registered as an alternate object
database.  In such a case there is no reason to copy any objects
as we can already obtain them through the alternate.

However we need to ensure the objects are all reachable, so we
run `git rev-list --objects $theirs --not --all` to verify this.
If any object is missing or unreadable then we need to fetch/copy
the objects from the remote.  When a missing object is detected
the git-rev-list process will exit with a non-zero exit status,
making this condition quite easy to detect.

Although git-fetch is currently a builtin (and so is rev-list)
we cannot invoke the traverse_objects() API at this point in the
transport code.  The object walker within traverse_objects() calls
die() as soon as it finds an object it cannot read.  If that happens
we want to resume the fetch process by calling do_fetch_pack().
To get around this we spawn git-rev-list into a background process
to prevent a die() from killing the foreground fetch process,
thus allowing the fetch process to resume into do_fetch_pack()
if copying is necessary.

We aren't interested in the output of rev-list (a list of SHA-1
object names that are reachable) or its errors (a "spurious" error
about an object not being found as we need to copy it) so we redirect
both stdout and stderr to /dev/null.

We run this git-rev-list based check before any fetch as we may
already have the necessary objects local from a prior fetch.  If we
don't then its very likely the first $theirs object listed on the
command line won't exist locally and git-rev-list will die very
quickly, allowing us to start the network transfer.  This test even
on remote URLs may save bandwidth if someone runs `git pull origin`,
sees a merge conflict, resets out, then redoes the same pull just
a short time later.  If the remote hasn't changed between the two
pulls and the local repository hasn't had git-gc run in it then
there is probably no need to perform network transfer as all of
the objects are local.

Documentation for the new quickfetch function was suggested and
written by Junio, based on his original comment in git-fetch.sh.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-11-11 17:09:55 -08:00
Shawn O. Pearce
a3b0079c6a git-fetch: Always fetch tags if the object they reference exists
Previously git-fetch.sh used `git cat-file -t` to determine if an
object referenced by a tag exists, and if so fetch that tag locally.
This was subtly broken during the port to C based builtin-fetch as
lookup_object() only works to locate an object if it was previously
accessed by the transport.  Not all transports will access all
objects in this way, so tags were not always being fetched.

The rsync transport never loads objects into the internal object
table so automated tag following didn't work if rsync was used.
Automated tag following also didn't work on the native transport
if the new tag was behind the common point(s) negotiated between
the two ends of the connection as the tag's referrant would not
be loaded into the internal object table.  Further the automated
tag following was broken with the HTTP commit walker if the new
tag's referrant was behind an existing ref, as the walker would
stop before loading the tag's referrant into the object table.

Switching to has_sha1_file() restores the original behavior from
the shell script by checking if the object exists in the ODB,
without relying on the state left behind by a transport.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-11-11 17:09:55 -08:00
Pierre Habouzit
9ef4272bea git-fetch: be even quieter.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:53:14 -08:00
Junio C Hamano
33e12acafe Merge branch 'np/fetch'
* np/fetch:
  git-fetch: more terse fetch output
2007-11-04 01:06:48 -07:00
Steven Grimm
4b7bbdd14c builtin-fetch: Add "-q" as a synonym for "--quiet"
"-q" is the very first option described in the git-fetch manpage, and it
isn't supported.

Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-03 21:37:30 -07:00
Daniel Barkalow
4577370e9b Miscellaneous const changes and utilities
The list of remote refs in struct transport should be const, because
builtin-fetch will get confused if it changes.

The url in git_connect should be const (and work on a copy) instead of
requiring the caller to copy it.

match_refs doesn't modify the refspecs it gets.

get_fetch_map and get_remote_ref don't change the list they get.

Allow transport get_refs_list methods to modify the struct transport.

Add a function to copy a list of refs, when a function needs a mutable
copy of a const list.

Add a function to check the type of a ref, as per the code in connect.c

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 22:40:43 -07:00
Nicolas Pitre
165f390250 git-fetch: more terse fetch output
This makes the fetch output much more terse and prettier on a 80 column
display, based on a consensus reached on the mailing list.  Here's an
example output:

Receiving objects: 100% (5439/5439), 1.60 MiB | 636 KiB/s, done.
Resolving deltas: 100% (4604/4604), done.
From git://git.kernel.org/pub/scm/git/git
 ! [rejected]        html -> origin/html  (non fast forward)
   136e631..f45e867  maint -> origin/maint  (fast forward)
   9850e2e..44dd7e0  man -> origin/man  (fast forward)
   3e4bb08..e3d6d56  master -> origin/master  (fast forward)
   fa3665c..536f64a  next -> origin/next  (fast forward)
 + 4f6d9d6...768326f pu -> origin/pu  (forced update)
 * [new branch]      todo -> origin/todo

Some portions of this patch have been extracted from earlier proposals
by Jeff King and Shawn Pearce.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 22:36:31 -07:00
Junio C Hamano
9ad7c5ae8a git-fetch: do not fail when remote branch disappears
When the branch named with branch.$name.merge is not covered by
the fetch configuration for the remote repository named with
branch.$name.remote, we automatically add that branch to the set
of branches to be fetched.  However, if the remote repository
does not have that branch (e.g. it used to exist, but got
removed), this is not a reason to fail the git-fetch itself.

The situation however will be noticed if git-fetch was called by
git-pull, as the resulting FETCH_HEAD would not have any entry
that is marked for merging.

Acked-By: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-28 14:06:39 -07:00
Shawn O. Pearce
cfa5b2b7fa Avoid scary errors about tagged trees/blobs during git-fetch
This is the same bug as 42a32174b6.
The warning "Object $X is a tree, not a commit" is bogus and is
not relevant here.  If its not a commit we just need to make sure
we don't mark it for merge as we fill out FETCH_HEAD.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-19 03:47:07 -04:00
Johannes Schindelin
da0204df58 fetch: if not fetching from default remote, ignore default merge
When doing "git fetch <remote>" on a remote that does not have the
branch referenced in branch.<current-branch>.merge, git fetch failed.
It failed because it tried to add the "merge" ref to the refs to be
fetched.

Fix that.  And add a test case.

Incidentally, this unconvered a bug in our own test suite, where
"git pull <some-path>" was expected to merge the ref given in the
defaults, even if not pulling from the default remote.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-16 01:24:18 -04:00
Daniel Barkalow
2467a4fa03 Remove duplicate ref matches in fetch
If multiple refspecs matched the same ref, the update would be
processed multiple times. Now having the same destination for the same
source has no additional effect, and having the same destination for
different sources is an error.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15 20:28:06 -04:00
Daniel Barkalow
2b5a06edca Restore default verbosity for http fetches.
This adds a verbosity level below 0 for suppressing default messages
with --quiet, and makes the default for http be verbose instead of
quiet. This matches the behavior of the shell script version of git-fetch.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-02 21:12:01 -07:00
Daniel Barkalow
cfb8f898a8 Allow abbreviations in the first refspec to be merged
The config item for a refspec side and the ref name that it matches
aren't necessarily character-for-character identical. We actually want
to merge a ref by default if: there is no per-branch config, it is the
found result of looking for the match for the first refspec, and the
first refspec is not a pattern. Beyond that, anything that
get_fetch_map() thinks matches is fine.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29 22:11:52 -07:00
Shawn O. Pearce
824d5776c3 Refactor struct transport_ops inlined into struct transport
Aside from reducing the code by 20 lines this refactoring removes
a level of indirection when trying to access the operations of a
given transport "instance", making the code clearer and easier to
follow.

It also has the nice effect of giving us the benefits of C99 style
struct initialization (namely ".fetch = X") without requiring that
level of language support from our compiler.  We don't need to worry
about new operation methods being added as they will now be NULL'd
out automatically by the xcalloc() we use to create the new struct
transport we supply to the caller.

This pattern already exists in struct walker, so we already have
a precedent for it in Git.  We also don't really need to worry
about any sort of performance decreases that may occur as a result
of filling out 4-8 op pointers when we make a "struct transport".
The extra few CPU cycles this requires over filling in the "struct
transport_ops" is killed by the time it will take Git to actually
*use* one of those functions, as most transport operations are
going over the wire or will be copying object data locally between
two directories.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19 03:22:31 -07:00