git/builtin/push.c, branch v2.0.2

Merge branch 'cc/starts-n-ends-with-endgame'

2014-03-07T23:18:28Z

prefixcmp/suffixcmp are gone.

Merge branch 'gj/push-more-verbose-advice'

2014-03-07T23:17:20Z

Merge branch 'jc/push-2.0-default-to-simple'

2014-03-07T23:13:15Z

Finally update the "git push" default behaviour to "simple".

Merge branch 'jc/push-refmap'

2013-12-27T22:57:50Z

Make "git push origin master" update the same ref that would be updated by our 'master' when "git push origin" (no refspecs) is run while the 'master' branch is checked out, which makes "git push" more symmetric to "git fetch" and more usable for the triangular workflow. * jc/push-refmap: push: also use "upstream" mapping when pushing a single ref push: use remote.$name.push as a refmap builtin/push.c: use strbuf instead of manual allocation

push: also use "upstream" mapping when pushing a single ref

2013-12-04T23:12:34Z

When the user is using the 'upstream' mode, these commands: $ git push $ git push origin would find the 'upstream' branch for the current branch, and then push the current branch to update it. However, pushing a single branch explicitly, i.e. $ git push origin $(git symbolic-ref --short HEAD) would not go through the same ref mapping process, and ends up updating the branch at 'origin' of the same name, which may not necessarily be the upstream of the branch being pushed. In the spirit similar to the previous one, map a colon-less refspec using the upstream mapping logic. Signed-off-by: Junio C Hamano

push: use remote.$name.push as a refmap

2013-12-04T23:11:08Z

Since f2690487 (fetch: opportunistically update tracking refs, 2013-05-11), we stopped taking a non-storing refspec given on the command line of "git fetch" literally, and instead started mapping it via remote.$name.fetch refspecs. This allows $ git fetch origin master from the 'origin' repository, which is configured with [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* to update refs/remotes/origin/master with the result, as if the command line were $ git fetch origin +master:refs/remotes/origin/master to reduce surprises and improve usability. Before that change, a refspec on the command line without a colon was only to fetch the history and leave the result in FETCH_HEAD, without updating the remote-tracking branches. When you are simulating a fetch from you by your mothership with a push by you into your mothership, instead of having: [remote "satellite"] fetch = +refs/heads/*:refs/remotes/satellite/* on the mothership repository and running: mothership$ git fetch satellite you would have: [remote "mothership"] push = +refs/heads/*:refs/remotes/satellite/* on your satellite machine, and run: satellite$ git push mothership Because we so far did not make the corresponding change to the push side, this command: satellite$ git push mothership master does _not_ allow you on the satellite to only push 'master' out but still to the usual destination (i.e. refs/remotes/satellite/master). Implement the logic to map an unqualified refspec given on the command line via the remote.$name.push refspec. This will bring a bit more symmetry between "fetch" and "push". Signed-off-by: Junio C Hamano

builtin/push.c: use strbuf instead of manual allocation

2013-12-03T22:47:18Z

The command line arguments given to "git push" are massaged into a list of refspecs in set_refspecs() function. This was implemented using xmalloc, strcpy and friends, but it is much easier to read if done using strbuf. Signed-off-by: Junio C Hamano

push: switch default from "matching" to "simple"

2013-11-13T22:12:37Z

We promised to change the behaviour of lazy "git push [there]" that does not say what to push on the command line from "matching" to "simple" in Git 2.0. This finally flips that bit. Helped-by: Matthieu Moy Signed-off-by: Junio C Hamano

push: enhance unspecified push default warning

2013-11-13T22:12:23Z

When the unset push.default warning message is displayed this may be the first time many users encounter push.default. Explain in the warning message in a compact manner what push.default is and what the change means to the end-user to help the users decide. Signed-off-by: Greg Jacobson Helped-by: Jonathan Nieder Helped-by: Matthieu Moy Helped-by: Marc Branchaud Signed-off-by: Junio C Hamano

Merge branch 'nd/push-no-thin'

2013-09-11T21:56:59Z

"git push --no-thin" was a no-op by mistake. * nd/push-no-thin: push: respect --no-thin