Mirror of https://git.kernel.org/pub/scm/git/git.git/ https://www.git.shady.money/git/atom?h=v1.9.2 2014-01-17T20:04:29Z 2014-01-17T20:04:29Z Junio C Hamano gitster@pobox.com 2014-01-17T20:04:29Z urn:sha1:d8cf714c0edf261a2bcc126fc240b10ed04a5b8d Finishing touches so that an expected error message will not leak to the UI. * jk/pull-rebase-using-fork-point: pull: suppress error when no remoteref is found 2014-01-17T20:03:32Z John Keeping john@keeping.me.uk 2014-01-17T20:00:20Z urn:sha1:ffc2b483dee43c2687088d4c73d7532fda855050 Commit 48059e4 (pull: use merge-base --fork-point when appropriate, 2013-12-08) incorrectly assumes that get_remote_merge_branch will either yield a non-empty string or return an error, but there are circumstances where it will yield an empty string. The previous code then invoked git-rev-list with no arguments, which results in an error suppressed by redirecting stderr to /dev/null. Now we invoke git-merge-base with an empty branch name, which also results in an error. Suppress this in the same way. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-12-27T22:58:08Z Junio C Hamano gitster@pobox.com 2013-12-27T22:58:08Z urn:sha1:2b0a564e02528e006d23e3318d0d2869fb239425 * jk/pull-rebase-using-fork-point: rebase: use reflog to find common base with upstream pull: use merge-base --fork-point when appropriate 2013-12-09T21:05:20Z John Keeping john@keeping.me.uk 2013-12-08T12:47:25Z urn:sha1:48059e405028ebf8a09c5a9aede89dfb460cce98 Since commit d96855f (merge-base: teach "--fork-point" mode, 2013-10-23) we can replace a shell loop in git-pull with a single call to git-merge-base. So let's do so. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-10-30T21:16:36Z Michael Haggerty mhagger@alum.mit.edu 2013-10-30T05:32:59Z urn:sha1:c5a84e92a2fe9e8748e32341c344d7a6c0f52a50 Previously, fetch's "--tags" option was considered equivalent to specifying the refspec "refs/tags/*:refs/tags/*" on the command line; in particular, it caused the remote.<name>.refspec configuration to be ignored. But it is not very useful to fetch tags without also fetching other references, whereas it *is* quite useful to be able to fetch tags *in addition to* other references. So change the semantics of this option to do the latter. If a user wants to fetch *only* tags, then it is still possible to specifying an explicit refspec: git fetch <remote> 'refs/tags/*:refs/tags/*' Please note that the documentation prior to 1.8.0.3 was ambiguous about this aspect of "fetch --tags" behavior. Commit f0cb2f137c 2012-12-14 fetch --tags: clarify documentation made the documentation match the old behavior. This commit changes the documentation to match the new behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-09-17T18:42:34Z Junio C Hamano gitster@pobox.com 2013-09-17T18:42:34Z urn:sha1:c8ccfc9cdf3381525cce718c846bc62fd86767f7 * fc/trivial: pull: use $curr_branch_short more add: trivial style cleanup reset: trivial style cleanup branch: trivial style fix reset: trivial refactoring 2013-09-08T18:39:30Z René Scharfe l.s.r@web.de 2013-09-08T15:21:44Z urn:sha1:b07f7296080b20f5cc2069ce2761cacdd79b3432 One of the first things git-pull.sh does is setting $curr_branch to the target of HEAD and $curr_branch_short to the same but with the leading "refs/heads/" removed. Simplify the code by using $curr_branch_short instead of setting $curr_branch to the same shortened value. The only other use of $curr_branch in that function doesn't have to be replaced with $curr_branch_short because it just checks if the string is empty. That property is the same with or without the prefix unless HEAD points to "refs/heads/" alone, which is invalid. Noticed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-09-04T19:45:48Z Stephen Haberman stephen@exigencecorp.com 2013-08-13T03:43:42Z urn:sha1:66713ef3b00933755cdeff1ae823dda7b5843640 If a user is working on master, and has merged in their feature branch, but now has to "git pull" because master moved, with pull.rebase their feature branch will be flattened into master. This is because "git pull" currently does not know about rebase's preserve merges flag, which would avoid this behavior, as it would instead replay just the merge commit of the feature branch onto the new master, and not replay each individual commit in the feature branch. Add a --rebase=preserve option, which will pass along --preserve-merges to rebase. Also add 'preserve' to the allowed values for the pull.rebase config setting. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-07-12T19:04:06Z Junio C Hamano gitster@pobox.com 2013-07-12T19:04:06Z urn:sha1:5b307e95e880b95eafd36e93251c6638c222dcf4 * jk/pull-to-integrate: pull: change the description to "integrate" changes push: avoid suggesting "merging" remote changes 2013-07-08T19:44:01Z John Keeping john@keeping.me.uk 2013-07-07T19:02:15Z urn:sha1:153d7265ef1277c1c9971780ad035a530e305f78 Since git-pull learned the --rebase option it has not just been about merging changes from a remote repository (where "merge" is in the sense of "git merge"). Change the description to use "integrate" instead of "merge" in order to reflect this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>