delta/git.git/Documentation/git-merge.txt, branch hv/mv-nested-submodules-test

Documentation/git-merge: explain --continue

2017-08-22T00:12:44+00:00

Currently, 'git merge --continue' is mentioned but not explained.

Explain it.

Signed-off-by: Michael J Gruber 
Signed-off-by: Junio C Hamano

Merge branch 'jc/merge-drop-old-syntax'

2017-03-30T21:07:13+00:00

Stop supporting "git merge  HEAD " syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.

* jc/merge-drop-old-syntax:
  merge: drop 'git merge  HEAD ' syntax

merge: add '--continue' option as a synonym for 'git commit'

2016-12-14T18:02:04+00:00

Teach 'git merge' the --continue option which allows 'continuing' a
merge by completing it. The traditional way of completing a merge after
resolving conflicts is to use 'git commit'. Now with commands like 'git
rebase' and 'git cherry-pick' having a '--continue' option adding such
an option to 'git merge' presents a consistent UI.

Signed-off-by: Chris Packham 
Signed-off-by: Junio C Hamano

pull: pass --allow-unrelated-histories to "git merge"

2016-04-21T18:58:51+00:00

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

merge: refuse to create too cool a merge by default

2016-03-23T19:04:48+00:00

While it makes sense to allow merging unrelated histories of two
projects that started independently into one, in the way "gitk" was
merged to "git" itself aka "the coolest merge ever", such a merge is
still an unusual event.	 Worse, if somebody creates an independent
history by starting from a tarball of an established project and
sends a pull request to the original project, "git merge" however
happily creates such a merge without any sign of something unusual
is happening.

Teach "git merge" to refuse to create such a merge by default,
unless the user passes a new "--allow-unrelated-histories" option to
tell it that the user is aware that two unrelated projects are
merged.

Because such a "two project merge" is a rare event, a configuration
option to always allow such a merge is not added.

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".  Many tests that are updated by this patch does the
pass-through manually by turning:

	git pull something

into its equivalent:

	git fetch something &&
	git merge --allow-unrelated-histories FETCH_HEAD

If somebody is inclined to add such an option, updated tests in this
change need to be adjusted back to:

	git pull --allow-unrelated-histories something

Signed-off-by: Junio C Hamano

Merge branch 'mm/keyid-docs'

2015-10-05T19:30:26+00:00

Very small number of options take a parameter that is optional
(which is not a great UI element as they can only appear at the end
of the command line).  Add notice to documentation of each and
every one of them.

* mm/keyid-docs:
  Documentation: explain optional arguments better
  Documentation/grep: fix documentation of -O
  Documentation: use 'keyid' consistently, not 'key-id'

Documentation: explain optional arguments better

2015-09-21T17:48:23+00:00

Improve the documentation of commands taking optional arguments in two
ways:

* Documents the behavior of '-O' (for grep) and '-S' (for commands
  creating commits) when used without the optional argument.

* Document the syntax of these options.

For the second point, the behavior is documented in gitcli(7), but it is
easy for users to miss, and hard for the same user to understand why e.g.
"git status -u no" does not work.

Document this explicitly in the documentation of each short option having
an optional argument: they are the most error prone since there is no '='
sign between the option and its argument.

Signed-off-by: Matthieu Moy 
Reviewed-by: Jeff King 
Signed-off-by: Junio C Hamano

Documentation: use 'keyid' consistently, not 'key-id'

2015-09-21T17:48:17+00:00

Signed-off-by: Matthieu Moy 
Reviewed-by: Jeff King 
Signed-off-by: Junio C Hamano

Merge branch 'po/doc-branch-desc'

2015-09-17T19:29:03+00:00

The branch descriptions that are set with "git branch --edit-description"
option were used in many places but they weren't clearly documented.

* po/doc-branch-desc:
  doc: show usage of branch description

doc: show usage of branch description

2015-09-14T19:50:33+00:00

The branch description will be included in 'git format-patch
--cover-letter' and in 'git pull-request' emails. It can also
be used in the automatic merge message. Tell the reader.

While here, clarify that the description may be a multi-line
explanation of the purpose of the branch's patch series.

Signed-off-by: Philip Oakley 
Signed-off-by: Junio C Hamano