user/sven/git.git/remote.c, branch v1.8.3.3

remote.c: introduce branch..pushremote

2013-04-02T17:41:43Z

This new configuration variable overrides `remote.pushdefault` and `branch..remote` for pushes. When you pull from one place (e.g. your upstream) and push to another place (e.g. your own publishing repository), you would want to set `remote.pushdefault` to specify the remote to push to for all branches, and use this option to override it for a specific branch. Signed-off-by: Ramkumar Ramachandra Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

remote.c: introduce remote.pushdefault

2013-04-02T17:41:42Z

This new configuration variable defines the default remote to push to, and overrides `branch..remote` for all branches. It is useful in the typical triangular-workflow setup, where the remote you're fetching from is different from the remote you're pushing to. Signed-off-by: Ramkumar Ramachandra Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

remote.c: introduce a way to have different remotes for fetch/push

2013-04-02T17:41:42Z

Currently, do_push() in push.c calls remote_get(), which gets the configured remote for fetching and pushing. Replace this call with a call to pushremote_get() instead, a new function that will return the remote configured specifically for pushing. This function tries to work with the string pushremote_name, before falling back to the codepath of remote_get(). This patch has no visible impact, but serves to enable future patches to introduce configuration variables to set pushremote_name. For example, you can now do the following in handle_config(): if (!strcmp(key, "remote.pushdefault")) git_config_string(&pushremote_name, key, value); Then, pushes will automatically go to the remote specified by remote.pushdefault. Signed-off-by: Ramkumar Ramachandra Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

remote.c: simplify a bit of code using git_config_string()

2013-04-02T17:41:41Z

A small segment where handle_config() parses the branch.remote configuration variable can be simplified using git_config_string(). Signed-off-by: Ramkumar Ramachandra Reviewed-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/nobody-sets-src-peer-ref'

2013-04-01T16:05:35Z

Dead code removal. * jc/nobody-sets-src-peer-ref: match_push_refs(): nobody sets src->peer_ref anymore

Merge branch 'jc/push-follow-tag'

2013-03-25T21:00:41Z

The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()

Merge branch 'jc/fetch-raw-sha1'

2013-03-21T21:02:27Z

Allows requests to fetch objects at any tip of refs (including hidden ones). It seems that there may be use cases even outside Gerrit (e.g. $gmane/215701). * jc/fetch-raw-sha1: fetch: fetch objects by their exact SHA-1 object names upload-pack: optionally allow fetching from the tips of hidden refs fetch: use struct ref to represent refs to be fetched parse_fetch_refspec(): clarify the codeflow a bit

push: --follow-tags

2013-03-05T21:39:46Z

The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else. With this option, you would also push all annotated tags that can be reached from that commit to the other side. Signed-off-by: Junio C Hamano

match_push_refs(): nobody sets src->peer_ref anymore

2013-03-04T23:01:11Z

In ancient times, we used to disallow the same source ref to be pushed to more than one places, e.g. "git push there master:master master:naster" was disallowed. We later lifted this restriction with db27ee63929f (send-pack: allow the same source to be pushed more than once., 2005-08-06) and there no longer is anybody that sets peer_ref for the source side of the ref list in the push codepath since then. Remove one leftover no-op in a loop that iterates over the source side of ref list (i.e. our local ref) to see if it can/should be sent to a matching destination ref while skipping ones that is marked with peer_ref (which will never exist, so we do not skip anything). Signed-off-by: Junio C Hamano

fetch: fetch objects by their exact SHA-1 object names

2013-02-07T22:07:53Z

Teach "git fetch" to accept an exact SHA-1 object name the user may obtain out of band on the LHS of a pathspec, and send it on a "want" message when the server side advertises the allow-tip-sha1-in-want capability. Signed-off-by: Junio C Hamano