diff options
author | Junio C Hamano <gitster@pobox.com> | 2012-02-05 16:22:12 -0800 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2012-02-05 16:30:26 -0800 |
commit | b5c9f1c1b0ed9c91463b9f46a7c9dff3efc53773 (patch) | |
tree | d7b10b778105afb6e211242204bb13d1c648d627 /t/t9112-git-svn-md5less-file.sh | |
parent | Git 1.7.9 (diff) | |
download | tgif-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