Commit graph

11 commits

Author SHA1 Message Date
Denton Liu
d540b70c85 merge: cleanup messages like commit
This change allows git-merge messages to be cleaned up with the
commit.cleanup configuration or --cleanup option, just like how
git-commit does it.

We also give git-pull the option of --cleanup so that it can also take
advantage of this change.

Finally, add testing to ensure that messages are properly cleaned up.
Note that some newlines that were added to the commit message were
removed so that if a file were read via -F, it would be copied
faithfully.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-18 13:49:29 +09:00
W. Trevor King
3a4d2c7437 pull: pass --signoff/--no-signoff to "git merge"
merge can take --signoff, but without pull passing --signoff down, it
is inconvenient to use; allow 'pull' to take the option and pass it
through.

The order of options in merge-options.txt is mostly alphabetical by
long option since 7c85d274 (Documentation/merge-options.txt: order
options in alphabetical groups, 2009-10-22).  The long-option bit
didn't make it into the commit message, but it's under the fold in
[1].  I've put --signoff between --log and --stat to preserve the
alphabetical order.

[1]: https://public-inbox.org/git/87iqe7zspn.fsf@jondo.cante.net/

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-13 10:47:36 +09:00
Junio C Hamano
09c2cb877a pull: pass --allow-unrelated-histories to "git merge"
The previous commit said:

    We could add the same option to "git pull" and have it passed
    through to underlying "git merge".  I do not have a fundamental
    opposition against such a feature, but this commit does not do
    so and instead leaves it as low-hanging fruit for others,
    because such a "two project merge" would be done after fetching
    the other project into some location in the working tree of an
    existing project and making sure how well they fit together, it
    is sufficient to allow a local merge without such an option
    pass-through from "git pull" to "git merge".

Prepare a patch to make it a reality, just in case it is needed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-21 11:58:51 -07:00
Paul Tan
eb2a8d9ed3 pull: handle git-fetch's options as well
While parsing the command-line arguments, git-pull stops parsing at the
first unrecognized option, assuming that any subsequent options are for
git-fetch, and can thus be kept in the shell's positional parameters
list, so that it can be passed to git-fetch via the expansion of "$@".

However, certain functions in git-pull assume that the positional
parameters do not contain any options:

* error_on_no_merge_candidates() uses the number of positional
  parameters to determine which error message to print out, and will
  thus print the wrong message if git-fetch's options are passed in as
  well.

* the call to get_remote_merge_branch() assumes that the positional
  parameters only contains the optional repo and refspecs, and will
  thus silently fail if git-fetch's options are passed in as well.

* --dry-run is a valid git-fetch option, but if provided after any
  git-fetch options, it is not recognized by git-pull and thus git-pull
  will continue to run the merge or rebase.

Fix these bugs by teaching git-pull to parse git-fetch's options as
well. Add tests to prevent regressions.

This removes the limitation where git-fetch's options have to come after
git-merge's and git-rebase's options on the command line. Update the
documentation to reflect this.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-02 13:36:22 -07:00
Paul Tan
5504f13a7c t5521: test --dry-run does not make any changes
Test that when --dry-run is provided to git-pull, it does not make any
changes, namely:

* --dry-run gets passed to git-fetch, so no FETCH_HEAD will be created
  and no refs will be fetched.

* The index and work tree will not be modified.

Signed-off-by: Paul Tan <pyokagan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29 09:16:01 -07:00
Junio C Hamano
ca8d148daf test: test_must_be_empty helper
There are quite a lot places where an output file is expected to be
empty, and we fail the test when it is not.  The output from running
the test script with -i -v can be helped if we showed the unexpected
contents at that point.

We could of course do

    >expected.empty && test_cmp expected.empty actual

but this is commmon enough to be done with a dedicated helper.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-09 16:45:14 -07:00
Peter Eisentraut
ce4c4d4ec3 pull: Apply -q and -v options to rebase mode as well
git pull passed -q and -v only to git merge, but they can be useful for
git rebase as well, so pass them there, too.

In particular, using -q shuts up the "Already up-to-date." message.
Especially, a new test script runs the same "pull --rebase" twice to
make sure both cases are quiet, when it has something to fetch and
when it is already up to date.

Signed-off-by: Peter Eisentraut <peter@eisentraut.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16 23:30:08 -07:00
Junio C Hamano
e6cc51046f fetch --all/--multiple: keep all the fetched branch information
Since "git fetch" learned "--all" and "--multiple" options, it has become
tempting for users to say "git pull --all".  Even though it may fetch from
remotes that do not need to be fetched from for merging with the current
branch, it is handy.

"git fetch" however clears the list of fetched branches every time it
contacts a different remote.  Unless the current branch is configured to
merge with a branch from a remote that happens to be the last in the list
of remotes that are contacted, "git pull" that fetches from multiple
remotes will not be able to find the branch it should be merging with.

Make "fetch" clear FETCH_HEAD (unless --append is given) and then append
the list of branches fetched to it (even when --append is not given).  That
way, "pull" will be able to find the data for the branch being merged in
FETCH_HEAD no matter where the remote appears in the list of remotes to be
contacted by "git fetch".

Reported-by: Michael Lukashov
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24 11:16:36 -08:00
Junio C Hamano
bba5322a71 builtin-fetch --all/--multi: propagate options correctly
When running a subfetch, the code propagated some options but not others.
Propagate --force, --update-head-ok and --keep options as well.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24 10:51:07 -08:00
Junio C Hamano
13e65fe631 t5521: fix and modernize
All of these tests were bogus, as they created new directory and tried to
run "git pull" without even running "git init" in there.  They were mucking
with the repository in $TEST_DIRECTORY.

While fixing it, modernize the style not to chdir around outside of
subshell.  Otherwise a failed test will take us to an unexpected directory
and we need to chdir back to the test directory in each test, which is
ugly and error prone.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24 10:41:12 -08:00
Tuncer Ayaz
7f87aff22c Teach/Fix pull/fetch -q/-v options
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14 17:18:32 -08:00