summaryrefslogtreecommitdiff
path: root/t/t9112-git-svn-md5less-file.sh
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2012-02-05 16:22:12 -0800
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-02-05 16:30:26 -0800
commitb5c9f1c1b0ed9c91463b9f46a7c9dff3efc53773 (patch)
treed7b10b778105afb6e211242204bb13d1c648d627 /t/t9112-git-svn-md5less-file.sh
parentGit 1.7.9 (diff)
downloadtgif-b5c9f1c1b0ed9c91463b9f46a7c9dff3efc53773.tar.xz
merge: do not create a signed tag merge under --ff-only option
Starting at release v1.7.9, if you ask to merge a signed tag, "git merge" always creates a merge commit, even when the tag points at a commit that happens to be a descendant of your current commit. Unfortunately, this interacts rather badly for people who use --ff-only to make sure that their branch is free of local developments. It used to be possible to say: $ git checkout -b frotz v1.7.9~30 $ git merge --ff-only v1.7.9 and expect that the resulting tip of frotz branch matches v1.7.9^0 (aka the commit tagged as v1.7.9), but this fails with the updated Git with: fatal: Not possible to fast-forward, aborting. because a merge that merges v1.7.9 tag to v1.7.9~30 cannot be created by fast forwarding. We could teach users that now they have to do $ git merge --ff-only v1.7.9^0 but it is far more pleasant for users if we DWIMmed this ourselves. When an integrator pulls in a topic from a lieutenant via a signed tag, even when the work done by the lieutenant happens to fast-forward, the integrator wants to have a merge record, so the integrator will not be asking for --ff-only when running "git pull" in such a case. Therefore, this change should not regress the support for the use case v1.7.9 wanted to add. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t9112-git-svn-md5less-file.sh')
0 files changed, 0 insertions, 0 deletions