summaryrefslogtreecommitdiff
path: root/Documentation/git-push.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-07-22remote.c: add command line option parser for "--force-with-lease"Libravatar Junio C Hamano1-11/+66
Update "git push" and "git send-pack" to parse this commnd line option. The intended sematics is: * "--force-with-lease" alone, without specifying the details, will protect _all_ remote refs that are going to be updated by requiring their current value to be the same as some reasonable default, unless otherwise specified; * "--force-with-lease=refname", without specifying the expected value, will protect that refname, if it is going to be updated, by requiring its current value to be the same as some reasonable default. * "--force-with-lease=refname:value" will protect that refname, if it is going to be updated, by requiring its current value to be the same as the specified value; and * "--no-force-with-lease" will cancel all the previous --force-with-lease on the command line. For now, "some reasonable default" is tentatively defined as "the value of the remote-tracking branch we have for the ref of the remote being updated", and it is an error if we do not have such a remote-tracking branch. But this is known to be fragile, its use is not yet recommended, and hopefully we will find more reasonable default as we gain experience with this feature. The manual marks the feature as experimental unless the expected value is specified explicitly for this reason. Because the command line options are parsed _before_ we know which remote we are pushing to, there needs further processing to the parsed data after we instantiate the transport object to: * expand "refname" given by the user to a full refname to be matched with the list of "struct ref" used in match_push_refs() and set_ref_status_for_push(); and * learning the actual local ref that is the remote-tracking branch for the specified remote ref. Further, some processing need to be deferred until we find the set of remote refs and match_push_refs() returns in order to find the ones that need to be checked after explicit ones have been processed for "--force-with-lease" (no specific details). These post-processing will be the topic of the next patch. This option was originally called "cas" (for "compare and swap"), the name which nobody liked because it was too technical. The second attempt called it "lockref" (because it is conceptually like pushing after taking a lock) but the word "lock" was hated because it implied that it may reject push by others, which is not the way this option works. This round calls it "force-with-lease". You assume you took the lease on the ref when you fetched to decide what the rebased history should be, and you can push back only if the lease has not been broken. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26Merge branch 'mm/push-force-is-dangerous'Libravatar Junio C Hamano1-0/+9
* mm/push-force-is-dangerous: Documentation/git-push.txt: explain better cases where --force is dangerous
2013-06-18Documentation/git-push.txt: explain better cases where --force is dangerousLibravatar Matthieu Moy1-0/+9
The behavior of "git push --force" is rather clear when it updates only one remote ref, but running it when pushing several branches can really be dangerous. Warn the users a bit more and give them the alternative to push only one branch. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-05Merge branch 'tr/push-no-verify-doc'Libravatar Junio C Hamano1-1/+6
"git push --[no-]verify" was not documented. * tr/push-no-verify-doc: Document push --no-verify
2013-05-23Document push --no-verifyLibravatar Thomas Rast1-1/+6
ec55559 (push: Add support for pre-push hooks, 2013-01-13) forgot to add a note to git-push(1) about the new --no-verify option. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-17documentation: trivial style cleanupsLibravatar Felipe Contreras1-2/+1
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>
2013-03-26Merge branch 'jc/maint-push-refspec-default-doc' into maintLibravatar Junio C Hamano1-9/+14
* jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-25Merge branch 'jc/push-follow-tag'Libravatar Junio C Hamano1-1/+7
The new "--follow-tags" option tells "git push" to push relevant annotated tags when pushing branches out. * jc/push-follow-tag: push: --follow-tags commit.c: use clear_commit_marks_many() in in_merge_bases_many() commit.c: add in_merge_bases_many() commit.c: add clear_commit_marks_many()
2013-03-21Merge branch 'jc/maint-push-refspec-default-doc'Libravatar Junio C Hamano1-9/+14
Clarify in the documentation "what" gets pushed to "where" when the command line to "git push" does not say these explicitly. * jc/maint-push-refspec-default-doc: Documentation/git-push: clarify the description of defaults
2013-03-08Documentation/git-push: clarify the description of defaultsLibravatar Junio C Hamano1-9/+14
We describe what gets pushed by default when the command line does not give any <refspec> under the bullet point of <refspec>. It is a bit unfriendly to expect users to read on <refspec> when they are not giving any in the first place. "What gets pushed" is determined by taking many factors (<refspec> argument being only one of them) into account, and is a property of the entire command, not an individual argument. Also we do not describe "Where the push goes" when the command line does not say. Give the description on "what gets pushed to where" upfront before explaining individual arguments and options. Also update the description of <refspec> to say what it is, what it is used for, before explaining what shape it takes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05push: --follow-tagsLibravatar Junio C Hamano1-1/+7
The new option "--follow-tags" tells "git push" to push annotated tags that are missing from the other side and that can be reached by the history that is otherwise pushed out. For example, if you are using the "simple", "current", or "upstream" push, you would ordinarily push the history leading to the commit at your current HEAD and nothing else. With this option, you would also push all annotated tags that can be reached from that commit to the other side. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-4/+4
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05Merge branch 'cr/push-force-tag-update'Libravatar Junio C Hamano1-4/+5
Require "-f" for push to update a tag, even if it is a fast-forward. * cr/push-force-tag-update: push: allow already-exists advice to be disabled push: rename config variable for more general use push: cleanup push rules comment push: clarify rejection of update to non-commit-ish push: require force for annotated tags push: require force for refs under refs/tags/ push: flag updates that require force push: keep track of "update" state separately push: add advice for rejected tag reference push: return reject reasons as a bitset
2012-12-02push: require force for annotated tagsLibravatar Chris Rorvick1-5/+5
Do not allow fast-forwarding of references that point to a tag object. Updating from a tag is potentially destructive since it would likely leave the tag dangling. Disallowing updates to a tag also makes sense semantically and is consistent with the behavior of lightweight tags. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-02push: require force for refs under refs/tags/Libravatar Chris Rorvick1-5/+6
References are allowed to update from one commit-ish to another if the former is an ancestor of the latter. This behavior is oriented to branches which are expected to move with commits. Tag references are expected to be static in a repository, though, thus an update to something under refs/tags/ should be rejected unless the update is forced. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-27Documentation/git-push.txt: clarify the "push from satellite" workflowLibravatar Junio C Hamano1-2/+14
The context of the example to push into refs/remotes/satellite/ hierarchy of the other repository needs to be spelled out explicitly for the value of this example to be fully appreciated. Make it so. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-27Documentation: improve phrasing in git-push.txtLibravatar Mark Szepieniec1-1/+2
The current version contains the sentence: Further suppose that the other person already pushed changes leading to A back to the original repository you two obtained the original commit X. which doesn't parse for me; I've changed it to Further suppose that the other person already pushed changes leading to A back to the original repository from which you two obtained the original commit X. Signed-off-by: Mark Szepieniec <mszepien@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-18Merge branch 'mm/maint-doc-remote-tracking' into maintLibravatar Junio C Hamano1-1/+1
Update "remote tracking branch" in the documentation to "remote-tracking branch". * mm/maint-doc-remote-tracking: Documentation: remote tracking branch -> remote-tracking branch
2012-11-04Merge branch 'mm/maint-doc-remote-tracking'Libravatar Jeff King1-1/+1
We long ago hyphenated "remote-tracking branch"; this catches some new instances added since then. * mm/maint-doc-remote-tracking: Documentation: remote tracking branch -> remote-tracking branch
2012-10-25Documentation: remote tracking branch -> remote-tracking branchLibravatar Matthieu Moy1-1/+1
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>
2012-10-02Documentation: mention `push.default` in git-push.txtLibravatar Ramkumar Ramachandra1-3/+7
It already is listed in the "git config" documentation, but people interested in pushing would first look at "git push" documentation. Noticed-by: David Glasser Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Fixed-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-02Merge branch 'jk/doc-asciidoc-inline-literal'Libravatar Junio C Hamano1-7/+7
Our documentation was written for an ancient version of AsciiDoc, making the source not very readable. By Jeff King * jk/doc-asciidoc-inline-literal: docs: stop using asciidoc no-inline-literal
2012-04-26docs: stop using asciidoc no-inline-literalLibravatar Jeff King1-7/+7
In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24Merge branch 'hv/submodule-recurse-push'Libravatar Junio C Hamano1-4/+10
"git push --recurse-submodules" learns to optionally look into the histories of submodules bound to the superproject and push them out. By Heiko Voigt * hv/submodule-recurse-push: push: teach --recurse-submodules the on-demand option Refactor submodule push check to use string list instead of integer Teach revision walking machinery to walk multiple times sequencially
2012-03-30push: teach --recurse-submodules the on-demand optionLibravatar Heiko Voigt1-4/+10
When using this option git will search for all submodules that have changed in the revisions to be send. It will then try to push the currently checked out branch of each submodule. This helps when a user has finished working on a change which involves submodules and just wants to push everything in one go. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-22push: add '--prune' optionLibravatar Felipe Contreras1-1/+9
When pushing groups of refs to a remote, there is no simple way to remove old refs that still exist at the remote that is no longer updated from us. This will allow us to remove such refs from the remote. With this change, running this command $ git push --prune remote refs/heads/*:refs/remotes/laptop/* removes refs/remotes/laptop/foo from the remote if we do not have branch "foo" locally anymore. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-02Merge branch 'fg/submodule-ff-check-before-push'Libravatar Junio C Hamano1-0/+6
* fg/submodule-ff-check-before-push: push: Don't push a repository with unpushed submodules
2011-08-20push: Don't push a repository with unpushed submodulesLibravatar Fredrik Gustafsson1-0/+6
When working with submodules it is easy to forget to push a submodule to the server but pushing a super-project that contains a commit for that submodule. The result is that the superproject points at a submodule commit that is not available on the server. This adds the option --recurse-submodules=check to push. When using this option git will check that all submodule commits that are about to be pushed are present on a remote of the submodule. To be able to use a combined diff, disabling a diff callback has been removed from combined-diff.c. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04docs: put listed example commands in backticksLibravatar Jeff King1-10/+10
Many examples of git command invocation are given in asciidoc listing blocks, which makes them monospaced and avoids further interpretation of special characters. Some manpages make a list of examples, like: git foo:: Run git foo. git foo -q:: Use the "-q" option. to quickly show many variants. However, they can sometimes be hard to read, because they are shown in a proportional-width font (so, for example, seeing the difference between "-- foo" and "--foo" can be difficult). This patch puts all such examples into backticks, which gives the equivalent formatting to a listing block (i.e., monospaced and without character interpretation). As a bonus, this also fixes an example in the git-push manpage, in which "git push origin :::" was accidentally considered a newly-indented list, and not a list item with "git push origin :" in it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-10/+0
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.
2010-10-13Documentation: gitrevisions is in section 7Libravatar Jonathan Nieder1-1/+1
Fix references to gitrevisions(1) in the manual pages and HTML documentation. In practice, this will not matter much unless someone tries to use a hard copy of the git reference manual. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-20Documentation: do not convert ... operator to ellipsesLibravatar Jonathan Nieder1-1/+1
The symmetric difference or merge-base operator ... as used by rev-list and diff is actually three period characters. If it gets replaced by an ellipsis glyph in the manual, that would stop readers from copying and pasting it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-25Documentation/git-push: Explain status output in more detailLibravatar Thomas Rast1-10/+23
Mention the effects of the receive.deny* family of options for the "remote rejected" case. While there, also split up the explanation into an easier-to-parse list format. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05Documentation: link to gitrevisions rather than git-rev-parseLibravatar Michael J Gruber1-1/+1
Currently, whenever we need documentation for revisions and ranges, we link to the git-rev-parse man page, i.e. a plumbing man page, which has this along with the documentation of all rev-parse modes. Link to the new gitrevisions man page instead in all cases except - when the actual git-rev-parse command is referred to or - in very technical context (git-send-pack). Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-09Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: Let check_preimage() use memset() to initialize "struct checkout" fetch/push: fix usage strings
2010-04-09fetch/push: fix usage stringsLibravatar Tay Ray Chuan1-1/+1
- use "<options>" instead of just "options". - use "[<repository> [<refspec>...]]" to indicate that <repository> and <refspec> are optional, and that <refspec> cannot be specified without specifying <repository>. Note that when called without specifying <repository> (eg. "git fetch -f"), it is accurate to say that the "git fetch [<options>] [<repository> ...]" case takes precedence over "git fetch [<options>] <group>". Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-15Merge branch 'tc/transport-verbosity'Libravatar Junio C Hamano1-4/+11
* tc/transport-verbosity: transport: update flags to be in running order fetch and pull: learn --progress push: learn --progress transport->progress: use flag authoritatively clone: support multiple levels of verbosity push: support multiple levels of verbosity fetch: refactor verbosity option handling into transport.[ch] Documentation/git-push: put --quiet before --verbose Documentation/git-pull: put verbosity options before merge/fetch ones Documentation/git-clone: mention progress in -v Conflicts: transport.h
2010-02-24push: learn --progressLibravatar Tay Ray Chuan1-1/+8
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-24Documentation/git-push: put --quiet before --verboseLibravatar Tay Ray Chuan1-4/+4
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-18Documentation: describe --thin more accuratelyLibravatar Stephen Boyd1-3/+4
The description for --thin was misleading and downright wrong. Correct it with some inspiration from the description of index-pack's --fix-thin and some background information from Nicolas Pitre <nico@fluxnic.net>. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17docs: don't talk about $GIT_DIR/refs/ everywhereLibravatar Jeff King1-3/+3
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we may also consult the packed refs mechanism. These days we tend to treat the "refs hierarchy" as more of an abstract namespace that happens to be represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at worst it can confuse users who then look in $GIT_DIR/refs and find that it is missing some of the refs they expected to see. This patch drops most uses of "$GIT_DIR/refs/*", changing them into just "refs/*", under the assumption that users can handle the concept of an abstract refs namespace. There are a few things to note: - most cases just dropped the $GIT_DIR/ portion. But for cases where that left _just_ the word "refs", I changed it to "refs/" to help indicate that it was a hierarchy. I didn't do the same for longer paths (e.g., "refs/heads" remained, instead of becoming "refs/heads/"). - in some cases, no change was made, as the text was explicitly about unpacked refs (e.g., the discussion in git-pack-refs). - In some cases it made sense instead to note the existence of packed refs (e.g., in check-ref-format and rev-parse). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-08Merge branch 'maint'Libravatar Junio C Hamano1-5/+10
* maint: blame: prevent a segv when -L given start > EOF git-push: document all the status flags used in the output Fix parsing of imap.preformattedHTML and imap.sslverify git-add documentation: Fix shell quoting example
2010-02-08Merge branch 'jc/maint-push-doc-status' into maintLibravatar Junio C Hamano1-5/+10
* jc/maint-push-doc-status: git-push: document all the status flags used in the output
2010-02-08git-push: document all the status flags used in the outputLibravatar Junio C Hamano1-5/+10
We didn't talk about '-' (deletion), '*' (addition), nor '+' (forced). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-24Documentation: move away misplaced 'push --upstream' descriptionLibravatar Thomas Rast1-7/+7
e9fcd1e (Add push --set-upstream, 2010-01-16) inadvertently patched the description of --upstream in the middle of that of --repo. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-3/+3
* 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
2010-01-16Add push --set-upstreamLibravatar Ilari Liusvaara1-1/+8
Frequent complaint is lack of easy way to set up upstream (tracking) references for git pull to work as part of push command. So add switch --set-upstream (-u) to do just that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-10Documentation: spell 'git cmd' without dash throughoutLibravatar Thomas Rast1-3/+3
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.
2009-12-30builtin-push: add --delete as syntactic sugar for :fooLibravatar Jan Krüger1-0/+4
Refspecs without a source side have been reported as confusing by many. As an alternative, this adds support for commands like: git push origin --delete somebranch git push origin --delete tag sometag Specifically, --delete will prepend a colon to all colon-less refspecs given on the command line, and will refuse to accept refspecs with colons to prevent undue confusion. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-15Merge branch 'fc/doc-fast-forward'Libravatar Junio C Hamano1-7/+7
* fc/doc-fast-forward: Use 'fast-forward' all over the place Conflicts: builtin-merge.c