Anyplace we talk about the address of a remote repository we always
refer to it as a URL, especially in the configuration file and
.git/remotes where we call it "remote.$n.url" or start the first
line with "URL:".  Calling this value a uri within the internal C
code just doesn't jive well with our commonly accepted terms.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

My prior bug fix for git-push titled "Don't configure remote "." to
fetch everything to itself" actually broke t5520 as we were unable
to evaluate a branch configuration of:

  [branch "copy"]
    remote = .
    merge = refs/heads/master

as remote "." did not have a "remote...fetch" configuration entry to
offer up refs/heads/master as a possible candidate available to be
fetched and merged.  In shell script git-fetch and prior to the above
mentioned commit this was hardcoded for a url of "." to be the set of
local branches.

Chasing down this bug led me to the conclusion that our prior behavior
with regards to branch.$name.merge was incorrect.  In the shell script
based git-fetch implementation we only fetched and merged a branch if
it appeared both in branch.$name.merge *and* in remote.$r.fetch, where
$r = branch.$name.remote.  In other words in the following config file:

  [remote "origin"]
    url = git://git.kernel.org/pub/scm/git/git.git
    fetch = refs/heads/master:refs/remotes/origin/master
  [branch "master"]
    remote = origin
    merge = refs/heads/master
  [branch "pu"]
    remote = origin
    merge = refs/heads/pu

Attempting to run `git pull` while on branch "pu" would always give
the user "Already up-to-date" as git-fetch did not fetch pu and thus
did not mark it for merge in .git/FETCH_HEAD.  The configured merge
would always be ignored and the user would be left scratching her
confused head wondering why merge did not work on "pu" but worked
fine on "master".

If we are using the "default fetch" specification for the current
branch and the current branch has a branch.$name.merge configured
we now union it with the list of refs in remote.$r.fetch.  This
way the above configuration does what the user expects it to do,
which is to fetch only "master" by default but when on "pu" to
fetch both "master" and "pu".

This uncovered some breakage in the test suite where old-style Cogito
branches (.git/branches/$r) did not fetch the branches listed in
.git/config for merging and thus did not actually merge them if the
user tried to use `git pull` on that branch.  Junio and I discussed
it on list and felt that the union approach here makes more sense to
DWIM for the end-user than silently ignoring their configured request
so the test vectors for t5515 have been updated to include for-merge
lines in .git/FETCH_HEAD where they have been configured for-merge
in .git/config.

Since we are now performing a union of the fetch specification and
the merge specification and we cannot allow a branch to be listed
twice (otherwise it comes out twice in .git/FETCH_HEAD) we need to
perform a double loop here over all of the branch.$name.merge lines
and try to set their merge flag if we have already schedule that
branch for fetching by remote.$r.fetch.  If no match is found then
we must add new specifications to fetch the branch but not store it
as no local tracking branch has been designated.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we are fetching something and were configured to do a forced
fetch and have no local ref to store the fetched object into we
cannot mark the local ref as having a forced update.  Instead we
should just silently discard the + request.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When we are talking about a remote URI of "." we are really talking
about *this* repository that we are fetching into or pushing out of.
There are no matching tracking branches for this repository; we
do not attempt to map a ref back to ourselves as this would either
create an infinite cycle (for example "fetch = +refs/*:refs/mine/*")
or it causes problems when we attempt to push back to ourselves.

So we really cannot setup a remote like this:

  [remote "."]
    url = .
    fetch = +refs/*:refs/*

In the case of `git push . B:T` to fast-forward branch T to B's
current commit git-send-pack will update branch T to B, assuming that
T is the remote tracking branch for B.  This update is performed
immediately before git-send-pack asks git-receive-pack to perform
the same update, and git-receive-pack then fails because T is not
where git-send-pack told it to expect T to be at.

In the case of `git fetch .` we really should do the same thing as
`git fetch $otherrepo`, that is load .git/FETCH_HEAD with the commit
of HEAD, so that `git pull .` will report "Already up-to-date".
We have always behaved like this before on this insane request and
we should at least continue to behave the same way.  With the above
(bad) remote configuration we were instead getting fetch errors
about funny refs, e.g. "refs/stash".
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Also exports parse_ref_spec().
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This adds full parsing for branch.<name> sections and functions to
interpret the results usefully. It incidentally corrects the fetch
configuration information for legacy branches/* files with '#'
characters in the URLs.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The function for_each_remote() does exactly what the name
suggests.

The function remote_find_tracking() was extended to be able to
search remote refs for a given local ref.  The caller sets
either src or dst (but not both) in the refspec parameter, and
remote_find_tracking() will fill in the other and return 0.

Both changes are required for the next step: simplification of
git-branch's --track functionality.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Functions for managing ref lists were named based on their use in
match_refs (for push). For fetch, they will be used for other purposes, so
rename them as a separate patch to make the future code readable.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instead of open-coding allocation wherever it happens, have a function.
Also, add a function to free a list of refs, which we currently never
actually do.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "git push" is run without any refspec (neither on the
command line nor in the config), we used to push "matching refs"
in the sense that anything under refs/ hierarchy that exist on
both ends were updated.  This used to be a sane default for
publishing your repository to another back when we did not have
refs/remotes/ hierarchy, but it does not make much sense these
days.

This changes the semantics to push only "matching branches".
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Refspecs with no colons are left with no dst value, because they are
interepreted differently for fetch and push. For push, they mean to
reuse the src side. Fix this for patterns.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are only a dozen or so uses of strdup in all of git.
Of those, most seem ok, but this one isn't:
Signed-off-by: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Earlier, when the local repository has a branch "frotz" and the
remote repository has a tag "frotz" (but not branch "frotz"),
"git-push frotz" mistakenly updated the tag at the remote side.
This was because the partial refname matching code was applied
independently on both source and destination side.

With this fix, when a colon-less refspec is given to git-push,
we first match it with the refs in the source repository, and
update the matching ref in the destination repository.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "git push A:B" is given, and A (or B) is not a full refname
that begins with refs/, we require an unambiguous match with an
existing ref.  For this purpose, a match with a local branch or
a tag (i.e. refs/heads/A and refs/tags/A) is called a "strong
match", and any other match is called a "weak match".  A partial
refname is unambiguous when there is only one strong match with
any number of weak matches, or when there is only one weak match
and no other match.

However, as reported by Sparse with Ramsay Jones recently,
count_refspec_match() function had a bug where a variable in an
inner block masked a different variable of the same name, which
caused the weak matches to be ignored.

This fixes it, and adds tests for the fix.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When checking what ref the source refspec matches, we have no
business setting the default for the destination, so move that
code lower.  Also simplify the result from the code block that
matches the source side by making it set matched_src only upon
unambiguous match.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This refactors open-coded sequence to create a new "struct ref"
and link it to the tail of dst list into a new function.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This does not change functionality; just splits one block that
is deeply nested and indented out of a huge loop into a separate
function.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Otherwise

    git push 'remote-name' 'refs/heads/*:refs/remotes/other/*'

will consider references in "refs/heads" of the remote repository
"remote-name", instead of the ones in "refs/remotes/other", which
the given refspec clearly means.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This means that send-pack and http-push will support pattern refspecs,
so builtin-push.c doesn't have to expand them, and also git push can
just turn --tags into "refs/tags/*", further simplifying
builtin-push.c

check_ref_format() gets a third "conditionally okay" result for
something that's valid as a pattern but not as a particular ref.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

These follow the pattern of the push side configuration, but aren't
taken from anywhere else, because git-fetch is still in shell.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The new parser is different from the one in builtin-push in two ways:
the default is to use the current branch's remote, if there is one,
before "origin"; and config is used in preference to remotes.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>