user/sven/git.git/git-parse-remote.sh, branch v1.6.5.4

parse-remote: remove unused functions

2009-06-12T02:50:45Z

Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano

parse-remote: support default reflist in get_remote_merge_branch

2009-06-12T02:50:34Z

Expand get_remote_merge_branch to compute the tracking branch to merge when called without arguments (or only the remote name). This allows "git pull --rebase" without arguments (default upstream branch) to work with a rebased upstream. With explicit arguments it already worked. Also add a test to check for this case. Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano

parse-remote: function to get the tracking branch to be merge

2009-06-12T02:49:59Z

The only user of get_remote_refs_for_fetch was "git pull --rebase" and it only wanted the tracking branch to be merge. So, add a simple function (get_remote_merge_branch) with this new meaning. No behavior changes. The new function behaves like the old code in "git pull --rebase". In particular, it only works with the default refspec mapping and with remote branches, not tags. Signed-off-by: Santi Béjar Signed-off-by: Junio C Hamano

Convert to use quiet option when available

2009-04-23T02:05:37Z

A minor fix that eliminates usage of "2>/dev/null" when --quiet or -q has already been implemented. Signed-off-by: Dan Loewenherz Signed-off-by: Junio C Hamano

Rewrite "git-frotz" to "git frotz"

2007-07-03T05:52:14Z

This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano

Allow fetching references from any namespace

2007-05-12T16:36:06Z

not only from the three defined: heads, tags and remotes. Noticed when I tried to fetch the references created by git-p4-import.bat: they are placed into separate namespace (refs/p4import/, to avoid showing them in git-branch output). As canon_refs_list_for_fetch always prepended refs/heads/ it was impossible, and annoying: it worked before. Normally, the p4import references are useless anywhere but in the directory managed by perforce, but in this special case the cloned directory was supposed to be a backup, including the p4import branch: it keeps information about where the imported perforce state came from. Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

git-fetch, git-branch: Support local --track via a special remote '.'

2007-03-16T09:10:12Z

This patch adds support for a dummy remote '.' to avoid having to declare a fake remote like [remote "local"] url = . fetch = refs/heads/*:refs/heads/* Such a builtin remote simplifies the operation of "git-fetch", which will populate FETCH_HEAD but will not pretend that two repositories are in use, will not create a thin pack, and will not perform any useless remapping of names. The speed improvement is around 20%, and it should improve more if "git-fetch" is converted to a builtin. To this end, git-parse-remote is grown with a new kind of remote, 'builtin'. In git-fetch.sh, we treat the builtin remote specially in that it needs no pack/store operations. In fact, doing git-fetch on a builtin remote will simply populate FETCH_HEAD appropriately. The patch also improves of the --track/--no-track support, extending it so that branch..remote items referring '.' can be created. Finally, it fixes a typo in git-checkout.sh. Signed-off-by: Paolo Bonzini Signed-off-by: Junio C Hamano

Use stdin reflist passing in parse-remote

2007-02-14T05:43:53Z

Use the new stdin reflist passing mechanism for the call to fetch--tool expand-refs-wildcard, allowing passing of more than ~128K of reflist data. Signed-off-by: Julian Phillips Signed-off-by: Junio C Hamano

git-fetch: rewrite expand_ref_wildcard in C

2007-02-14T05:43:53Z

This does not seem to make measurable improvement when dealing with 1000 unpacked refs, but we would need something like it if we were to do a full rewrite in C somedaoy. Signed-off-by: Junio C Hamano

Revert "Allow branch.*.merge to talk about remote tracking branches."

2007-02-05T00:58:30Z

This reverts commit 80c797764a6b6a373f0f1f47d7f56b0d950418a9. Back when I committed this, it seemed to be a good idea. People who always use remote tracking branches can optionally use the local name they happen to use to specify what to merge, which meant that I did not have to teach them why we use the name at the remote side every time they are confused. But allowing it seems to break other people's scripts. The real solution is not to allow more ways to express the same thing, but to educate people to use the right syntax. Signed-off-by: Junio C Hamano