| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Doc update.
* ml/doc-merge-updates:
Documentation/git-merge.txt: use backticks for command wrapping
Documentation/git-merge.txt: fix reference to synopsis
|
|
As René found in the guidance from CodingGuidelines:
Literal examples (e.g. use of command-line options, command names,
branch names, URLs, pathnames (files and directories), configuration
and environment variables) must be typeset in monospace (i.e. wrapped
with backticks)
So all instances of single and double quotes for wraping said examples
were replaced with simple backticks.
Suggested-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
437591a9d738 combined the synopsis of "The second syntax" (meaning `git
merge --abort`) and "The third syntax" (for `git merge --continue`) into
this single line:
git merge (--continue | --abort | --quit)
but it was still referred to when describing the preconditions that have
to be fulfilled to run the respective actions. In other words:
References by number are no longer valid after a merge of some of the
synopses.
Also the previous version of the documentation did not acknowledge that
`--no-commit` would result in the precondition being fulfilled (thanks
to Elijah Newren and Junio C Hamano for pointing that out).
This change also groups `--abort` and `--continue` together when
explaining the prerequisites in order to avoid duplication.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
A handful of manual pages called AUTO_MERGE a "special ref", but
there is nothing special about it. It merely is yet another
pseudoref.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Diff best viewed with --color-diff.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Since 5291828df8 (merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a
conflict, 2021-03-20), when using the 'ort' merge strategy, the special
ref AUTO_MERGE is written when a merge operation results in conflicts.
This ref points to a tree recording the conflicted state of the working
tree and is very useful during conflict resolution. However, this ref is
not documented.
Add some documentation for AUTO_MERGE in git-diff(1), git-merge(1),
gitrevisions(7) and in the user manual.
In git-diff(1), mention it at the end of the description section, when
we mention that the command also accepts trees instead of commits, and
also add an invocation to the "Various ways to check your working tree"
example.
In git-merge(1), add a step to the list of things that happen "when it
is not obvious how to reconcile the changes", under the "True merge"
section. Also mention AUTO_MERGE in the "How to resolve conflicts"
section, when mentioning 'git diff'.
In gitrevisions(7), add a mention of AUTO_MERGE along with the other
special refs.
In the user manual, add a paragraph describing AUTO_MERGE to the
"Getting conflict-resolution help during a merge" section, and include
an example of a 'git diff AUTO_MERGE' invocation for the example
conflict used in that section. Note that for uniformity we do not use
backticks around AUTO_MERGE here since the rest of the document does not
typeset special refs differently.
Closes: https://github.com/gitgitgadget/git/issues/1471
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The "True merge" section of the 'git merge' documentation mentions that
in case of conflicts, the conflicted working tree files contain "the
result of the "merge" program". This probably refers to RCS's 'merge'
program, which is mentioned further down under "How conflicts are
presented".
Since it is not clear at that point of the document which program is
referred to, and since most modern readers probably do not relate to RCS
anyway, let's just write "the merge operation" instead.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The fact that 'git merge' writes 'ORIG_HEAD' before performing the merge
is missing from the documentation of the command.
Mention it in the 'Description' section.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Acked-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Share the text used to explain configuration variables used by "git
<subcmd>" in "git help <subcmd>" with the text from "git help config".
* ab/dedup-config-and-command-docs:
docs: add CONFIGURATION sections that fuzzy map to built-ins
docs: add CONFIGURATION sections that map to a built-in
log docs: de-duplicate configuration sections
difftool docs: de-duplicate configuration sections
notes docs: de-duplicate and combine configuration sections
apply docs: de-duplicate configuration sections
send-email docs: de-duplicate configuration sections
grep docs: de-duplicate configuration sections
docs: add and use include template for config/* includes
|
|
In b6a8d09f6d8 (gc docs: include the "gc.*" section from "config" in
"gc", 2019-04-07) the "git gc" documentation was made to include the
config/gc.txt in its "CONFIGURATION" section. We do that in several
other places, but "git gc" was the only one with a blurb above the
include to orient the reader.
We don't want readers to carefully scrutinize "git-config(1)" and
"git-gc(1)" looking for discrepancies, instead we should tell them
that the latter includes a part of the former.
This change formalizes that wording in two new templates to be
included, one for the "git gc" case where the entire section is
included from "git-config(1)", and another for when the inclusion of
"git-config(1)" follows discussion unique to that documentation. In
order to use that re-arrange the order of those being discussed in the
"git-merge(1)" documentation.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The `--rerere-autoupdate` option is shared across 5 commands, and
are described the same way because it works exactly the same way in
these commands.
Create a separate file and include it from the help pages for these
commands, so that we can improve the description at one place to
improve all of them at once, and keep them in sync.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The default merge message prepared by "git merge" records the name
of the current branch; the name can be overridden with a new option
to allow users to pretend a merge is made on a different branch.
* jc/merge-detached-head-name:
merge: allow to pretend a merge is made into a different branch
|
|
When a series of patches for a topic-B depends on having topic-A,
the workflow to prepare the topic-B branch would look like this:
$ git checkout -b topic-B main
$ git merge --no-ff --no-edit topic-A
$ git am <mbox-for-topic-B
When topic-A gets updated, recreating the first merge and rebasing
the rest of the topic-B, all on detached HEAD, is a useful
technique. After updating topic-A with its new round of patches:
$ git checkout topic-B
$ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}')
$ git checkout --detach $prev^1
$ git merge --no-ff --no-edit topic-A
$ git rebase --onto HEAD $prev @{-1}^0
$ git checkout -B @{-1}
This will
(0) check out the current topic-B.
(1) find the previous merge of topic-A into topic-B.
(2) detach the HEAD to the parent of the previous merge.
(3) merge the updated topic-A to it.
(4) reapply the patches to rebuild the rest of topic-B.
(5) update topic-B with the result.
without contaminating the reflog of topic-B too much. topic-B@{1}
is the "logically previous" state before topic-A got updated, for
example. At (4), comparison (e.g. range-diff) between HEAD and
@{-1} is a meaningful way to sanity check the result, and the same
can be done at (5) by comparing topic-B and topic-B@{1}.
But there is one glitch. The merge into the detached HEAD done in
the step (3) above gives us "Merge branch 'topic-A' into HEAD", and
does not say "into topic-B".
Teach the "--into-name=<branch>" option to "git merge" and its
underlying "git fmt-merge-message", to pretend as if we were merging
into <branch>, no matter what branch we are actually merging into,
when they prepare the merge message. The pretend name honors the
usual "into <target>" suppression mechanism, which can be seen in
the tests added here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
git-pull.txt includes merge-options.txt, which is written assuming
merges will happen. git-pull has allowed rebases for many years; update
the documentation to reflect that.
While at it, pass any `--signoff` flag through to the rebase backend too
so that we don't have to document it as merge-specific. Rebase has
supported the --signoff flag for years now as well.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
In documentation pertaining to autostash behavior, we refer to the
"stash reflog". This description is too low-level as the reflog refers
to an implementation detail of how the stash works and, for end-users,
they do not need to be aware of this at all.
Change references of "stash reflog" to "stash list", which should
provide more accessible terminology for end-users.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
In rebase, one can pass the `--autostash` option to cause the worktree
to be automatically stashed before continuing with the rebase. This
option is missing in merge, however.
Implement the `--autostash` option and corresponding `merge.autoStash`
option in merge which stashes before merging and then pops after.
This option is useful when a developer has some local changes on a topic
branch but they realize that their work depends on another branch.
Previously, they had to run something like
git fetch ...
git stash push
git merge FETCH_HEAD
git stash pop
but now, that is reduced to
git fetch ...
git merge --autostash FETCH_HEAD
When an autostash is generated, it is automatically reapplied to the
worktree only in three explicit situations:
1. An incomplete merge is commit using `git commit`.
2. A merge completes successfully.
3. A merge is aborted using `git merge --abort`.
In all other situations where the merge state is removed using
remove_merge_branch_state() such as aborting a merge via
`git reset --hard`, the autostash is saved into the stash reflog
instead keeping the worktree clean.
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Suggested-by: Alban Gruin <alban.gruin@gmail.com>
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
f8b863598c ("builtin/merge: honor commit-msg hook for merges", 2017-09-07)
introduced the no-verify flag to merge for bypassing the commit-msg
hook, though in a different way from the implementation in commit.c.
Change the implementation in merge.c to be the same as in commit.c so
that both do the same in the same way. This also changes the output of
"git merge --help" to be more clear that the hook return code is
respected by default.
[js: * reworded commit message
* squashed documentation changes from original series' patch 3/4
]
Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Josh Steadmon <steadmon@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Two new commands "git switch" and "git restore" are introduced to
split "checking out a branch to work on advancing its history" and
"checking out paths out of the index and/or a tree-ish to work on
advancing the current history" out of the single "git checkout"
command.
* nd/switch-and-restore: (46 commits)
completion: disable dwim on "git switch -d"
switch: allow to switch in the middle of bisect
t2027: use test_must_be_empty
Declare both git-switch and git-restore experimental
help: move git-diff and git-reset to different groups
doc: promote "git restore"
user-manual.txt: prefer 'merge --abort' over 'reset --hard'
completion: support restore
t: add tests for restore
restore: support --patch
restore: replace --force with --ignore-unmerged
restore: default to --source=HEAD when only --staged is specified
restore: reject invalid combinations with --staged
restore: add --worktree and --staged
checkout: factor out worktree checkout code
restore: disable overlay mode by default
restore: make pathspec mandatory
restore: take tree-ish from --source option instead
checkout: split part of it to new command 'restore'
doc: promote "git switch"
...
|
|
Docfix.
* pw/doc-synopsis-markup-opmode-options:
show --continue/skip etc. consistently in synopsis
|
|
Command mode options that the user can choose one among many are
listed like this in the documentation:
git am (--continue | --skip | --abort | --quit)
They are listed on a single line and in parenthesis, because they
are not optional.
But documentation pages for some commands deviate from this norm.
Fix the merge and rebase docs to match this style.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
"git merge" learned "--quit" option that cleans up the in-progress
merge while leaving the working tree and the index still in a mess.
* nd/merge-quit:
merge: add --quit
merge: remove drop_save() in favor of remove_merge_branch_state()
|
|
This allows to cancel the current merge without resetting worktree/index,
which is what --abort is for. Like other --quit(s), this is often used
when you forgot that you're in the middle of a merge and already
switched away, doing different things. By the time you've realized, you
can't even continue the merge anymore.
This also makes all in-progress commands, am, merge, rebase, revert and
cherry-pick, take all three --abort, --continue and --quit (bisect has a
different UI).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
I added this option in git-checkout and git-merge in c1d7036b6b
(checkout,merge: disallow overwriting ignored files with
--no-overwrite-ignore - 2011-11-27) but did not remember to update
documentation. This completes that commit.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Spell out --no-rerere-autoupdate explictly to make searching
easier. This matches the other --no options in the man page.
Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The recursive merge strategy did not properly ensure there was no
change between HEAD and the index before performing its operation,
which has been corrected.
* en/dirty-merge-fixes:
merge: fix misleading pre-merge check documentation
merge-recursive: enforce rule that index matches head before merging
t6044: add more testcases with staged changes before a merge is invoked
merge-recursive: fix assumption that head tree being merged is HEAD
merge-recursive: make sure when we say we abort that we actually abort
t6044: add a testcase for index matching head, when head doesn't match HEAD
t6044: verify that merges expected to abort actually abort
index_has_changes(): avoid assuming operating on the_index
read-cache.c: move index_has_changes() from merge.c
|
|
This is consistent with `git commit` which, like `git merge`, supports
passing the commit message via `-m <msg>` and, unlike `git merge` before
this patch, via `-F <file>`.
It is useful to allow this for scripted use, or for the upcoming patch
to allow (re-)creating octopus merges in `git rebase --rebase-merges`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
builtin/merge.c contains this important requirement for merge strategies:
...the index must be in sync with the head commit. The strategies are
responsible to ensure this.
However, Documentation/git-merge.txt says:
...[merge will] abort if there are any changes registered in the index
relative to the `HEAD` commit. (One exception is when the changed
index entries are in the state that would result from the merge
already.)
Interestingly, prior to commit c0be8aa06b85 ("Documentation/git-merge.txt:
Partial rewrite of How Merge Works", 2008-07-19),
Documentation/git-merge.txt said much more:
...the index file must match the tree of `HEAD` commit...
[NOTE]
This is a bit of a lie. In certain special cases [explained
in detail]...
Otherwise, merge will refuse to do any harm to your repository
(that is...your working tree...and index are left intact).
So, this suggests that the exceptions existed because there were special
cases where it would case no harm, and potentially be slightly more
convenient for the user. While the current text in git-merge.txt does
list a condition under which it would be safe to proceed despite the index
not matching HEAD, it does not match what is actually implemented, in
three different ways:
* The exception is written to describe what unpack-trees allows. Not
all merge strategies allow such an exception, though, making this
description misleading. 'ours' and 'octopus' merges have strictly
enforced index==HEAD for a while, and the commit previous to this
one made 'recursive' do so as well.
* If someone did a three-way content merge on a specific file using
versions from the relevant commits and staged it prior to running
merge, then that path would technically satisfy the exception listed
in git-merge.txt. unpack-trees.c would still error out on the path,
though, because it defers the three-way content merge logic to other
parts of the code (resolve, octopus, or recursive) and has no way of
checking whether the index entry from before the merge will match
the end result of the merge.
* The exception as implemented in unpack-trees actually only checked
that the index matched the MERGE_HEAD version of the file and that
HEAD matched the merge base. Assuming no renames, that would indeed
provide cases where the index matches the end result we'd get from a
merge. But renames means unpack-trees is checking that it instead
matches something other than what the final result will be, risking
either erroring out when we shouldn't need to, or not erroring out
when we should and overwriting the user's staged changes.
In addition to the wording behind this exception being misleading, it is
also somewhat surprising to see how many times the code for the special
cases were wrong or the check to make sure the index matched head was
forgotten altogether:
* Prior to commit ee6566e8d70d ("[PATCH] Rewrite read-tree", 2005-09-05),
there were many cases where an unclean index entry was allowed (look for
merged_entry_allow_dirty()); it appears that in those cases, the merge
would have simply overwritten staged changes with the result of the
merge. Thus, the merge result would have been correct, but the user's
uncommitted changes could be thrown away without warning.
* Prior to commit 160252f81626 ("git-merge-ours: make sure our index
matches HEAD", 2005-11-03), the 'ours' merge strategy did not check
whether the index matched HEAD. If it didn't, the resulting merge
would include all the staged changes, and thus wasn't really an 'ours'
strategy.
* Prior to commit 3ec62ad9ffba ("merge-octopus: abort if index does not
match HEAD", 2016-04-09), 'octopus' merges did not check whether the
index matched HEAD, also resulting in any staged changes from before
the commit silently being folded into the resulting merge. commit
a6ee883b8eb5 ("t6044: new merge testcases for when index doesn't match
HEAD", 2016-04-09) was also added at the same time to try to test to
make sure all strategies did the necessary checking for the requirement
that the index match HEAD. Sadly, it didn't catch all the cases, as
evidenced by the remainder of this list...
* Prior to commit 65170c07d466 ("merge-recursive: avoid incorporating
uncommitted changes in a merge", 2017-12-21), merge-recursive simply
relied on unpack_trees() to do the necessary check, but in one special
case it avoided calling unpack_trees() entirely and accidentally ended
up silently including any staged changes from before the merge in the
resulting merge commit.
* The commit immediately before this one in this series noted that the
exceptions were written in a way that assumed no renames, making it
unsafe for merge-recursive to use. merge-recursive was modified to
use its own check to enforce that index==HEAD.
This history makes it very tempting to go into builtin/merge.c and replace
the comment that strategies must enforce that index matches HEAD with code
that just enforces it. At this point, that would only affect the
'resolve' strategy; all other strategies have each been modified to
manually enforce it. (However, note that index==HEAD is not strictly
enforced for fast-forward merges, as those are not considered a merge
strategy and they trigger in builtin/merge.c before the section in the
code where the relevant comment is found.)
But, even if we don't take the step of just fixing these problems by
enforcing index==HEAD for all strategies, we at least need to update this
misleading documentation in git-merge.txt. For now, just modify the claim
in Documentation/git-merge.txt to fix the error. The precise details
around combination of merges strategies and special cases probably is not
relevant to most users, so simply state that exceptions may exist but are
narrow and vary depending upon which merge strategy is in use.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Fix old merge glitch in Documentation during v2.13-rc0 era.
* mw/doc-merge-enumfix:
doc: update the order of the syntax `git merge --continue`
|
|
The syntax "git merge <message> HEAD <commit>" has been removed. The
order of the syntax should also be updated.
Signed-off-by: Meng-Sung Wu <mengsungwu@fortunewhite.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
"git pull" has been taught to accept "--[no-]signoff" option and
pass it down to "git merge".
* wk/pull-signoff:
pull: pass --signoff/--no-signoff to "git merge"
|
|
Doc updates.
* wk/merge-options-gpg-sign-doc:
Documentation/merge-options.txt: describe -S/--gpg-sign for 'pull'
|
|
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>
|
|
Pull has supported these since ea230d8 (pull: add the --gpg-sign
option, 2014-02-10). Insert in long-option alphabetical order
following 7c85d274 (Documentation/merge-options.txt: order options
in alphabetical groups, 2009-10-22).
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Message and doc updates.
* ma/up-to-date:
treewide: correct several "up-to-date" to "up to date"
Documentation/user-manual: update outdated example output
|
|
Killing "git merge --edit" before the editor returns control left
the repository in a state with MERGE_MSG but without MERGE_HEAD,
which incorrectly tells the subsequent "git commit" that there was
a squash merge in progress. This has been fixed.
* mg/killed-merge:
merge: save merge state earlier
merge: split write_merge_state in two
merge: clarify call chain
Documentation/git-merge: explain --continue
|
|
Follow the Oxford style, which says to use "up-to-date" before the noun,
but "up to date" after it. Don't change plumbing (specifically
send-pack.c, but transport.c (git push) also has the same string).
This was produced by grepping for "up-to-date" and "up to date". It
turned out we only had to edit in one direction, removing the hyphens.
Fix a typo in Documentation/git-diff-index.txt while we're there.
Reported-by: Jeffrey Manian <jeffrey.manian@gmail.com>
Reported-by: STEVEN WHITE <stevencharleswhitevoices@gmail.com>
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Currently, 'git merge --continue' is mentioned but not explained.
Explain it.
Signed-off-by: Michael J Gruber <git@grubix.eu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Some projects require every commit, even merges, to be signed off
[*1*]. Because "git merge" does not have a "--signoff" option like
"git commit" does, the user needs to add one manually when the
command presents an editor to describe the merge, or later use "git
commit --amend --signoff".
Help developers of these projects by teaching "--signoff" option to
"git merge".
*1* https://public-inbox.org/git/CAHv71zK5SqbwrBFX=a8-DY9H3KT4FEyMgv__p2gZzNr0WUAPUw@mail.gmail.com/T/#u
Requested-by: Dan Kohn <dan@linuxfoundation.org>
Signed-off-by: Łukasz Gryglicki <lukaszgryglicki@o2.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Stop supporting "git merge <message> HEAD <commit>" 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 <message> HEAD <commit>' syntax
|
|
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 <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
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>
|
|
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 <gitster@pobox.com>
|
|
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'
|
|
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 <Matthieu.Moy@imag.fr>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
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
|
|
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 <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
"git merge FETCH_HEAD" learned that the previous "git fetch" could
be to create an Octopus merge, i.e. recording multiple branches
that are not marked as "not-for-merge"; this allows us to lose an
old style invocation "git merge <msg> HEAD $commits..." in the
implementation of "git pull" script; the old style syntax can now
be deprecated.
* jc/merge:
merge: deprecate 'git merge <message> HEAD <commit>' syntax
merge: handle FETCH_HEAD internally
merge: decide if we auto-generate the message early in collect_parents()
merge: make collect_parents() auto-generate the merge message
merge: extract prepare_merge_message() logic out
merge: narrow scope of merge_names
merge: split reduce_parents() out of collect_parents()
merge: clarify collect_parents() logic
merge: small leakfix and code simplification
merge: do not check argc to determine number of remote heads
merge: clarify "pulling into void" special case
t5520: test pulling an octopus into an unborn branch
t5520: style fixes
merge: simplify code flow
merge: test the top-level merge driver
|
|
And then if we and our users survived the previous "start warning if
the old syntax is used" patch for a few years, we could apply this
to actually drop the support for the ancient syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The collect_parents() function now is responsible for
1. parsing the commits given on the command line into a list of
commits to be merged;
2. filtering these parents into independent ones; and
3. optionally calling fmt_merge_msg() via prepare_merge_message()
to prepare an auto-generated merge log message, using fake
contents that FETCH_HEAD would have had if these commits were
fetched from the current repository with "git pull . $args..."
Make "git merge FETCH_HEAD" to be the same as the traditional
git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits
invocation of the command in "git pull", where $commits are the ones
that appear in FETCH_HEAD that are not marked as not-for-merge, by
making it do a bit more, specifically:
- noticing "FETCH_HEAD" is the only "commit" on the command line
and picking the commits that are not marked as not-for-merge as
the list of commits to be merged (substitute for step #1 above);
- letting the resulting list fed to step #2 above;
- doing the step #3 above, using the contents of the FETCH_HEAD
instead of fake contents crafted from the list of commits parsed
in the step #1 above.
Note that this changes the semantics. "git merge FETCH_HEAD" has
always behaved as if the first commit in the FETCH_HEAD file were
directly specified on the command line, creating a two-way merge
whose auto-generated merge log said "merge commit xyz". With this
change, if the previous fetch was to grab multiple branches (e.g.
"git fetch $there topic-a topic-b"), the new world order is to
create an octopus, behaving as if "git pull $there topic-a topic-b"
were run. This is a deliberate change to make that happen, and
can be seen in the changes to t3033 tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This should improve readability. Compare "thislongname" and
"thisLongName". The following keys are left in unchanged. We can
decide what to do with them later.
- am.keepcr
- core.autocrlf .safecrlf .trustctime
- diff.dirstat .noprefix
- gitcvs.usecrlfattr
- gui.blamehistoryctx .trustmtime
- pull.twohead
- receive.autogc
- sendemail.signedoffbycc .smtpsslcertpath .suppresscc
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
There's no point in this:
% git merge
fatal: No commit specified and merge.defaultToUpstream not set.
We know the most likely scenario is that the user wants to merge the
upstream, and if not, he can set merge.defaultToUpstream to false.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
"When you need to use space, use dash" is a strange way to say that
you must not use a space. Because it is more common for the command
line descriptions to use dashed-multi-words, you do not even want to
use spaces in these places. Rephrase the documentation to avoid
this strangeness.
Fix a few existing multi-word argument help strings, i.e.
- GPG key-ids given to -S/--gpg-sign are "key-id";
- Refs used for storing notes are "notes-ref"; and
- Expiry timestamps given to --expire are "expiry-date".
and update the corresponding documentation pages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The option to gpg sign a merge commit is available but was not
documented. Use wording from the git-commit(1) manpage.
Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* maint-1.8.2:
Documentation/git-merge.txt: fix formatting of example block
|
|
You need at least four dashes in a line to have it recognized as listing
block delimiter by asciidoc.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* mm/merge-in-dirty-worktree-doc:
Documentation/git-merge.txt: weaken warning about uncommited changes
|
|
Commit 35d2fffd introduced 'git merge --abort' as a synonym to 'git reset
--merge', and added some failing tests in t7611-merge-abort.sh (search
'###' in this file) showing that 'git merge --abort' could not always
recover the pre-merge state.
Still, in many cases, 'git merge --abort' just works, and it is usually
considered that the ability to start a merge with uncommited changes is
an important property of Git.
Weaken the warning by discouraging only merge with /non-trivial/
uncommited changes.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
White-spaces, missing braces, standardize --[no-]foo.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* yd/doc-merge-annotated-tag:
Documentation: merging a tag is a special case
|
|
Document the 1.7.9 feature to merge a signed tag and keep that in
the mergetag header in the resulting commit better.
* yd/doc-merge-annotated-tag:
Documentation: merging a tag is a special case
|
|
When asking Git to merge a tag (such as a signed tag or annotated tag),
it will always create a merge commit even if fast-forward was possible.
It's like having --no-ff present on the command line.
It's a difference from the default behavior described in git-merge.txt.
It should be documented as an exception of "FAST-FORWARD MERGE" section
and "--ff" option description.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Yann Droneaud <ydroneaud@opteya.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This change was already done by 0e615b252f3 (Matthieu Moy, Tue Nov 2
2010, Replace "remote tracking" with "remote-tracking"), but new
instances of remote tracking (without dash) were introduced in the
meantime.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jeff King <peff@peff.net>
|
|
- (glossary) the quotes around the Wikipedia URL prevented its
linkification in frontends that support it; remove them
- (manual) newer version (SHA-1) == following, older == preceding, not
the other way around
- trivial typo and wording fixes
Signed-off-by: Štěpán Němec <stepnem@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Traditionally, a cleanly resolved merge was committed by "git merge" using
the auto-generated merge commit log message without invoking the editor.
After 5 years of use in the field, it turns out that people perform too
many unjustified merges of the upstream history into their topic branches.
These merges are not just useless, but they are often not explained well,
and making the end result unreadable when it gets time for merging their
history back to their upstream.
Earlier we added the "--edit" option to the command, so that people can
edit the log message to explain and justify their merge commits. Let's
take it one step further and spawn the editor by default when we are in an
interactive session (i.e. the standard input and the standard output are
pointing at the same tty device).
There may be existing scripts that leave the standard input and the
standard output of the "git merge" connected to whatever environment the
scripts were started, and such invocation might trigger the above
"interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable
can be set to "no" at the beginning of such scripts to use the historical
behaviour while the script runs.
Note that this backward compatibility is meant only for scripts, and we
deliberately do *not* support "merge.edit = yes/no/auto" configuration
option to allow people to keep the historical behaviour.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* jc/merge-sans-branch:
merge: merge with the default upstream branch without argument
merge: match the help text with the documentation
Conflicts:
builtin/merge.c
|
|
"git merge" without specifying any commit is a no-op by default.
A new option merge.defaultupstream can be set to true to cause such an
invocation of the command to merge the upstream branches configured for
the current branch by using their last observed values stored in their
remote tracking branches.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The point of these sections is generally to:
1. Give credit where it is due.
2. Give the reader an idea of where to ask questions or
file bug reports.
But they don't do a good job of either case. For (1), they
are out of date and incomplete. A much more accurate answer
can be gotten through shortlog or blame. For (2), the
correct contact point is generally git@vger, and even if you
wanted to cc the contact point, the out-of-date and
incomplete fields mean you're likely sending to somebody
useless.
So let's drop the fields entirely from all manpages except
git(1) itself. We already point people to the mailing list
for bug reports there, and we can update the Authors section
to give credit to the major contributors and point to
shortlog and blame for more information.
Each page has a "This is part of git" footer, so people can
follow that to the main git manpage.
|
|
* jh/notes-merge: (23 commits)
Provide 'git merge --abort' as a synonym to 'git reset --merge'
cmd_merge(): Parse options before checking MERGE_HEAD
Provide 'git notes get-ref' to easily retrieve current notes ref
git notes merge: Add testcases for merging notes trees at different fanouts
git notes merge: Add another auto-resolving strategy: "cat_sort_uniq"
git notes merge: --commit should fail if underlying notes ref has moved
git notes merge: List conflicting notes in notes merge commit message
git notes merge: Manual conflict resolution, part 2/2
git notes merge: Manual conflict resolution, part 1/2
Documentation: Preliminary docs on 'git notes merge'
git notes merge: Add automatic conflict resolvers (ours, theirs, union)
git notes merge: Handle real, non-conflicting notes merges
builtin/notes.c: Refactor creation of notes commits.
git notes merge: Initial implementation handling trivial merges only
builtin/notes.c: Split notes ref DWIMmery into a separate function
notes.c: Use two newlines (instead of one) when concatenating notes
(trivial) t3303: Indent with tabs instead of spaces for consistency
notes.h/c: Propagate combine_notes_fn return value to add_note() and beyond
notes.h/c: Allow combine_notes functions to remove notes
notes.c: Reorder functions in preparation for next commit
...
Conflicts:
builtin.h
|
|
Teach 'git merge' the --abort option, which verifies the existence of
MERGE_HEAD and then invokes 'git reset --merge' to abort the current
in-progress merge and attempt to reconstruct the pre-merge state.
The reason for adding this option is to provide a user interface for
aborting an in-progress merge that is consistent with the interface
for aborting a rebase ('git rebase --abort'), aborting the application
of a patch series ('git am --abort'), and aborting an in-progress notes
merge ('git notes merge --abort').
The patch includes documentation and testcases that explain and verify
the various scenarios in which 'git merge --abort' can run. The
testcases also document the cases in which 'git merge --abort' is
unable to correctly restore the pre-merge state (look for the '###'
comments towards the bottom of t/t7609-merge-abort.sh).
This patch has been improved by the following contributions:
- Jonathan Nieder: Move test documentation into test_description
Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Inside an element of an enumerated list, the second and subsequent
paragraphs need to lose their indent and have to be strung together with a
line with a single '+' on it instead. Otherwise the lines below are shown
in typewriter face, which just looks wrong.
Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
When the user specifies a message, use fmt_merge_msg_shortlog() to
append the shortlog.
Previously, when a message was specified, we ignored the merge title
("Merge <foo> into <bar>") and shortlog from fmt_merge_msg().
Update the documentation for -m to reflect this too.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Also move -X's description next to -s's in merge-options.txt.
This makes it easier to learn how to specify merge strategy options.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* 'doc-style/for-next' of git://repo.or.cz/git/trast:
Documentation: merge: use MERGE_HEAD to refer to the remote branch
Documentation: simplify How Merge Works
Documentation: merge: add a section about fast-forward
Documentation: emphasize when git merge terminates early
Documentation: merge: add an overview
Documentation: merge: move merge strategy list to end
Documentation: suggest `reset --merge` in How Merge Works section
Documentation: merge: move configuration section to end
Documentation: emphasise 'git shortlog' in its synopsis
Documentation: show-files is now called git-ls-files
Documentation: tiny git config manual tweaks
Documentation: git gc packs refs by default now
Conflicts:
Documentation/config.txt
|
|
commit 57bddb11 (Documentation/git-merge: reword references to
"remote" and "pull", 2010-01-07) fixed the manual to drop the
assumption that the other branch being merged is from a remote
repository. Unfortunately, in a few places, to do so it
introduced the antecedentless phrase "their versions". Worse, in
passages like the following, 'they' is playing two roles.
| highlighting changes from both the HEAD and their versions.
|
| * Look at the diffs on their own. 'git log --merge -p <path>'
Using HEAD and MERGE_HEAD nicely assigns terminology to "our" and
"their" sides. It also provides the reader with practice using
names that git will recognize on the command line.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
The user most likely does not care about the exact order of
operations because he cannot see it happening anyway. Instead,
try to explain what it means to merge two commits into a single
tree.
While at it:
- Change the heading to TRUE MERGE. The entire manual page is
about how merges work.
- Document MERGE_HEAD. It is a useful feature, since it makes
the parents of the intended merge commit easier to refer to.
- Do not assume commits named on the 'git merge' command line come
from another repository. For simplicity, the discussion of
conflicts still does assume that there is only one and it is a
branch head.
- Do not start list items with `code`. Otherwise, a toolchain bug
produces a line break in the generated nroff, resulting in odd
extra space.
Suggested-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
Novices sometimes find the behavior of 'git merge' in the
fast-forward case surprising. Describe it thoroughly.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
A merge-based operation in git can fail in two ways: one that
stops before touching anything, or one that goes ahead and
results in conflicts.
As the 'git merge' manual explains:
| A merge is always between the current `HEAD` and one or more
| commits (usually, branch head or tag), and the index file must
| match the tree of `HEAD` commit (i.e. the contents of the last commit)
| when it starts out.
Unfortunately, the placement of this sentence makes it easy to
skip over, and its formulation leaves the important point, that
any other attempted merge will be gracefully aborted, unspoken.
So give this point its own section and expand upon it.
Probably this could be simplified somewhat: after all, a change
registered in the index is just a special kind of local
uncommited change, so the second added paragraph is only a
special case of the first. It seemed more helpful to be explicit
here.
Inspired by <http://gitster.livejournal.com/25801.html>.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
The reader unfamiliar with the concepts of branching and merging
would have been completely lost. Try to help him with a diagram.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
So the section layout changes as follows:
NAME
SYNOPSIS
DESCRIPTION
OPTIONS
-MERGE STRATEGIES
HOW MERGE WORKS
HOW CONFLICTS ARE PRESENTED
HOW TO RESOLVE CONFLICTS
EXAMPLES
+MERGE STRATEGIES
CONFIGURATION
SEE ALSO
AUTHOR
DOCUMENTATION
GIT
NOTES
The first-time user will care more about conflicts than about
strategies other than 'recursive'.
One of the examples uses -s ours, but I do not think this hinders
readability.
Suggested-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
The 'merge' manual suggests 'reset' to cancel a merge at the end
of the Merge Strategies list. It is more logical to explain this
right before explaining how merge conflicts work, so the daunted
reader can have a way out when he or she needs it most.
While at it, make the advice more dependable and self-contained
by providing the --merge option.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
Configuration and environment variables belong to the back matter
of a manual page.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
* remotes/trast-doc/for-next:
Documentation: spell 'git cmd' without dash throughout
Documentation: format full commands in typewriter font
Documentation: warn prominently against merging with dirty trees
Documentation/git-merge: reword references to "remote" and "pull"
Conflicts:
Documentation/config.txt
Documentation/git-config.txt
Documentation/git-merge.txt
|
|
The documentation was quite inconsistent when spelling 'git cmd' if it
only refers to the program, not to some specific invocation syntax:
both 'git-cmd' and 'git cmd' spellings exist.
The current trend goes towards dashless forms, and there is precedent
in 647ac70 (git-svn.txt: stop using dash-form of commands.,
2009-07-07) to actively eliminate the dashed variants.
Replace 'git-cmd' with 'git cmd' throughout, except where git-shell,
git-cvsserver, git-upload-pack, git-receive-pack, and
git-upload-archive are concerned, because those really live in the
$PATH.
|
|
Use `code snippet` style instead of 'emphasis' for `git cmd ...`
according to the following rules:
* The SYNOPSIS sections are left untouched.
* If the intent is that the user type the command exactly as given, it
is `code`.
If the user is only loosely referred to a command and/or option, it
remains 'emphasised'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
We do this for both git-merge and git-pull, so as to hopefully alert
(over)users of git-pull to the issue.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
The git-merge manpage was written in terms of merging a "remote",
which is no longer the case: you merge local or remote-tracking
branches; pull is for actual remotes.
Adjust the manpage accordingly. We refer to the arguments as
"commits", and change instances of "remote" to "other" (where branches
are concerned) or "theirs" (where conflict sides are concerned).
Remove the single reference to "pulling".
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
|
|
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The "git pull" documentation has examples which follow an outdated
style. Update the examples to use "git merge" where appropriate and
move the examples to the corresponding manpages.
Furthermore,
- show that pull is equivalent to fetch and merge, which is still a
frequently asked question,
- explain the default fetch refspec.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Sounds better this way, at least to my ears. ("The syntax and
supported options of git merge" is a plural noun. "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The fmt-merge-message builtin can be invoked as "git fmt-merge-msg" rather
than through the hard link in GIT_EXEC_PATH. Although this is unlikely to
confuse most script writers, it should not hurt to make the documentation
a little clearer anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
As spotted by the eagle eyes of Jeff King.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
If literal text (asciidoc `...`) can be rendered in a differently from
normal text for each output format (man, HTML), then we do not need
extra quotes or other wrapping around inline literal text segments.
config.txt
Change '`...`' to `...`. In asciidoc, the single quotes provide
emphasis, literal text should be distintive enough.
Change "`...`" to `...`. These double quotes do not work if present
in the described config value, so drop them.
git-checkout.txt
Change "`...`" to `...` or `"..."`. All instances are command line
argument examples. One "`-`" becomes `-`. Two others are involve
curly braces, so move the double quotes inside the literal region to
indicate that they might need to be quoted on the command line of
certain shells (tcsh).
git-merge.txt
Change "`...`" to `...`. All instances are used to describe merge
conflict markers. The quotes should are not important.
git-rev-parse.txt
Change "`...`" to `...`. All instances are around command line
arguments where no in-shell quoting should be necessary.
gitcli.txt
Change `"..."` to `...`. All instances are around command line
examples or single command arguments. They do not semanticly belong
inside the literal text, and they are not needed outside it.
glossary-content.txt
user-manual.txt
Change "`...`" to `...`. All instances were around command lines.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Improve some minor language and format issues like hyphenation,
phrases, spacing, word order, comma, attributes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* jc/better-conflict-resolution:
Fix AsciiDoc errors in merge documentation
git-merge documentation: describe how conflict is presented
checkout --conflict=<style>: recreate merge in a non-default style
checkout -m: recreate merge when checking out of unmerged index
git-merge-recursive: learn to honor merge.conflictstyle
merge.conflictstyle: choose between "merge" and "diff3 -m" styles
rerere: understand "diff3 -m" style conflicts with the original
rerere.c: use symbolic constants to keep track of parsing states
xmerge.c: "diff3 -m" style clips merge reduction level to EAGER or less
xmerge.c: minimum readability fixups
xdiff-merge: optionally show conflicts in "diff3 -m" style
xdl_fill_merge_buffer(): separate out a too deeply nested function
checkout --ours/--theirs: allow checking out one side of a conflicting merge
checkout -f: allow ignoring unmerged paths when checking out of the index
Conflicts:
Documentation/git-checkout.txt
builtin-checkout.c
builtin-merge-recursive.c
t/t7201-co.sh
|
|
In the section on conflict markers, the "<<<<<<<" sequence is compiled by
AsciiDoc into invalid XML. A way to resolve this is by inserting something
between the last two characters in that sequence (i.e. between '<' and '"').
This patch encloses the conflict markers in backticks, which renders them
in a monospace font (in the HTML version; the manual page is unaffected),
and with the pleasant side-effect that it also fixes the AsciiDoc compile
problem.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
We took it granted that everybody knows how to read the RCS merge style
conflicts, and did not give illustrations in the documentation. Now we
are introducing an alternative output style, it is time to document this.
The lack of illustration has been bugging me for a long time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Dan Hensgen <dan@methodhead.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
When the SYNOPSIS says e.g. "<path>...", it is nice if the DESCRIPTION
also mentions "<path>..." and says the specified "paths" (note plural)
are used for $whatever. This fixes the obvious mismatches.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The old cox.net address is still getting mails from gitters.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The git-merge documentation's "HOW MERGE WORKS" section is confusingly
composed and actually omits the most interesting part, the merging of
the arguments into HEAD itself, surprisingly not actually mentioning
the fast-forward merge anywhere.
This patch replaces the "[NOTE]" screenful of highly technical details
by a single sentence summing up the interesting information, and instead
explains how are the arguments compared with HEAD and the three possible
inclusion states that are named "Already up-to-date", "Fast-forward"
and "True merge". It also makes it clear that the rest of the section
talks only about the true merge situation, and slightly expands the
talk on solving conflicts.
Junio initiated the removal of the Note screenful altogether and
offered many stylistical fixes.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Merge has always set ORIG_HEAD but never mentioned it, while we
recently added it to am and rebase. These facts should be reflected
in the documentation.
git-reset also sets ORIG_HEAD, but that fact is already mentioned in
the very first example so no changes were needed there.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The names of git commands are not meant to be entered at the
commandline; they are just names. So we render them in italics,
as is usual for command names in manpages.
Using
doit () {
perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }'
}
for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \
merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt
do
doit <"$i" >"$i+" && mv "$i+" "$i"
done
git diff
.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.
While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
As the "git" man page describes the "git" command at the end-user
level, it seems better to move it to man section 1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This option has the same effect as '--(no-)summary' (i.e. whether to
show a diffsat at the end of the merge or not), and it is consistent
with the '--stat' option of other git commands.
Documentation, tests, and bash completion are updaed accordingly, and the
old --summary option is marked as being deprected.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Include the new file from config.txt and git-merge.txt.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
A merge is not necessarily with a remote branch, it can be with any
commit.
Thanks to Paolo Ciarrocchi for pointing out the problem, and to
Nicolas Pitre for pointing out the fact that a merge is not
necessarily with a branch head.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Dave Peticolas <dave@krondo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* maint:
Update GIT 1.5.3.5 Release Notes
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
Fix --strategy parsing in git-rebase--interactive.sh
Make merge-recursive honor diff.renamelimit
cherry-pick/revert: more compact user direction message
core-tutorial: Use new syntax for git-merge.
git-merge: document but discourage the historical syntax
Prevent send-pack from segfaulting (backport from 'master')
Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
Conflicts:
git-rebase--interactive.sh
|
|
Historically "git merge" took its command line arguments in a
rather strange order. Document the historical syntax, and also
document clearly that it is not encouraged in new scripts.
There is no reason to deprecate the historical syntax, as the
current code can sanely tell which syntax the caller is using,
and existing scripts by people do use the historical syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
* lh/merge:
git-merge: add --ff and --no-ff options
git-merge: add support for --commit and --no-squash
git-merge: add support for branch.<name>.mergeoptions
git-merge: refactor option parsing
git-merge: fix faulty SQUASH_MSG
Add test-script for git-merge porcelain
|
|
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This enables per branch configuration of merge options. Currently, the most
useful options to specify per branch are --squash, --summary/--no-summary
and possibly --strategy, but all options are supported.
Note: Options containing whitespace will _not_ be handled correctly. Luckily,
the only option which can include whitespace is --message and it doesn't
make much sense to give that option a default value.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
Add "Configuration" section to describe merge.summary
configuration variable (which is mentioned in git-fmt-merge-msg(1)
man page, but it is a plumbing command), and merge.verbosity
configuration variable (so there is a place to make reference
from "Environment Variables" section of git(7) man page) to the
git-merge(1) man page. Also describe GIT_MERGE_VERBOSITY
environment.
The configuration variable merge.verbosity and environment variable
GIT_MERGE_VERBOSITY were introduced in commit 8c3275ab, which also
documented configuration variable but not environment variable.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
|
The diffstat can be controlled either with command-line options
(--summary|--no-summary) or with merge.diffstat. The default is
left as it was: diffstat is active by default.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Since `git add` is the approved porcelain for an end-user to invoke
when they want to manipulate the index, porcelain documentation
should steer the user to this command rather than the pure plumbing
update-index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Changed -m=<msg> to -m <msg> too.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Also reorders a handful entries to make each list sorted
alphabetically.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This teaches the oft-requested syntax
git merge $commit
to implement merging the named commit to the current branch.
This hopefully would make "git merge" usable as the first class
UI instead of being a mere backend for "git pull".
Most notably, $commit above can be any committish, so you can
say for example:
git merge js/shortlog~2
to merge early part of a topic branch without merging the rest
of it.
A custom merge message can be given with the new --message=<msg>
parameter. The message is prepended in front of the usual
"Merge ..." message autogenerated with fmt-merge-message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Morten Welinder says examples of resetting is really about
recovering from botched commit/pulls. I agree that pointers
from commands that cause a reset to be needed in the first place
would be very helpful.
Also reset examples did not mention "pull/merge" cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This hopefully concludes the latest updates that changes the
behaviour of the merge on an unsuccessful automerge. Instead of
collapsing the conflicted path in the index to show HEAD, we
leave it unmerged, now that diff-files can compare working tree
files with higher stages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
In git-merge documentation, add a section to describe what happens to
the index and working tree during merge, and what their cleanliness
requirements are before the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Refactored fetch options into separate fetch-options.txt.
Made git-merge use merge-options.
Made git-fetch use fetch-options.
Made git-pull use merge-options and fetch-options.
Added --help option to git-pull and git-format-patch scripts.
Rewrote Documentation/Makefile to dynamically determine
include dependencies.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
We do not accept multiple <refspecs> on one Pull:/Push: line
right now (we could lift this tentative workaround for the
broken refnames), but we have always accepted multiple such
lines, so use that form in the examples and discussion.
Also explicitly mention that Octopus is made only with an
explicit command line request and never from Pull: lines.
Add a couple of cross references.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
... and give a couple of examples of running 'git pull' against
local repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Simple description. It appears to be mostly internal command, but hey, it
is (it seems) the only undocumented one, so let's fix it up...
Also add a note about it to git-merge documentation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Signed-off-by: Christian Meder <chris@absolutegiganten.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
The replacement was performed automatically by these commands:
perl -pi -e 's/link:(git.+)\.html\[\1\]/gitlink:$1\[1\]/g' \
README Documentation/*.txt
perl -pi -e 's/link:git\.html\[git\]/gitlink:git\[7\]/g' \
README Documentation/*.txt
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
... and add link from git.txt, as usual.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
