summaryrefslogtreecommitdiff
path: root/Documentation/git-merge.txt
AgeCommit message (Collapse)AuthorFilesLines
2010-01-24Merge branch 'doc-style/for-next' of git://repo.or.cz/git/trastLibravatar Junio C Hamano1-78/+100
* '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
2010-01-24Documentation: merge: use MERGE_HEAD to refer to the remote branchLibravatar Jonathan Nieder1-6/+8
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>
2010-01-24Documentation: simplify How Merge WorksLibravatar Jonathan Nieder1-36/+16
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>
2010-01-24Documentation: merge: add a section about fast-forwardLibravatar Jonathan Nieder1-13/+18
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>
2010-01-24Documentation: emphasize when git merge terminates earlyLibravatar Jonathan Nieder1-10/+21
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>
2010-01-24Documentation: merge: add an overviewLibravatar Jonathan Nieder1-2/+26
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>
2010-01-24Documentation: merge: move merge strategy list to endLibravatar Jonathan Nieder1-2/+2
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>
2010-01-24Documentation: suggest `reset --merge` in How Merge Works sectionLibravatar Jonathan Nieder1-3/+3
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>
2010-01-24Documentation: merge: move configuration section to endLibravatar Jonathan Nieder1-9/+9
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>
2010-01-20Merge remote branch 'remotes/trast-doc/for-next'Libravatar Junio C Hamano1-25/+29
* 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-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.
2010-01-10Documentation: format full commands in typewriter fontLibravatar Thomas Rast1-7/+7
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>
2010-01-09Documentation: warn prominently against merging with dirty treesLibravatar Thomas Rast1-0/+4
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>
2010-01-09Documentation/git-merge: reword references to "remote" and "pull"Libravatar Thomas Rast1-17/+17
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>
2009-12-04Teach --[no-]rerere-autoupdate option to merge, revert and friendsLibravatar Junio C Hamano1-1/+6
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>
2009-10-21modernize fetch/merge/pull examplesLibravatar Clemens Buchacher1-0/+33
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>
2009-10-09Documentation: clarify mergeoptions descriptionLibravatar Jonathan Nieder1-2/+2
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>
2009-10-09Documentation: git fmt-merge-msg does not have to be a scriptLibravatar Jonathan Nieder1-3/+4
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>
2009-08-12Documentation: merge: one <remote> is requiredLibravatar Paul Bolle1-1/+1
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>
2009-03-26Grammar fix for "git merge" man pageLibravatar Wincent Colaiuta1-1/+1
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>
2009-03-25Grammar fixes to "merge" and "patch-id" docsLibravatar Wincent Colaiuta1-1/+1
Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-17Documentation: remove extra quoting/emphasis around literal textsLibravatar Chris Johnsen1-3/+3
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>
2008-12-09Improve language in git-merge.txt and related docsLibravatar Ralf Wildenhues1-17/+17
Improve some minor language and format issues like hyphenation, phrases, spacing, word order, comma, attributes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-29Merge branch 'jc/better-conflict-resolution'Libravatar Shawn O. Pearce1-0/+65
* 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
2008-09-04Fix AsciiDoc errors in merge documentationLibravatar Johan Herland1-4/+4
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>
2008-08-31git-merge documentation: describe how conflict is presentedLibravatar Junio C Hamano1-0/+65
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>
2008-08-22git-merge documentation: more details about resolving conflictsLibravatar Dan Hensgen1-6/+18
Signed-off-by: Dan Hensgen <dan@methodhead.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-30Make the DESCRIPTION match <x>... items in the SYNOPSISLibravatar Abhijit Menon-Sen1-2/+2
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>
2008-07-21Update my e-mail addressLibravatar Junio C Hamano1-1/+1
The old cox.net address is still getting mails from gitters. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-19Documentation/git-merge.txt: Partial rewrite of How Merge WorksLibravatar Petr Baudis1-47/+29
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>
2008-07-08Documentation: mention ORIG_HEAD in am, merge, and rebaseLibravatar Brian Gernhardt1-1/+3
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>
2008-07-05manpages: italicize git command names (which were in teletype font)Libravatar Jonathan Nieder1-8/+8
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>
2008-07-01Documentation formatting and cleanupLibravatar Jonathan Nieder1-6/+8
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>
2008-07-01Documentation: be consistent about "git-" versus "git "Libravatar Jonathan Nieder1-5/+5
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>
2008-06-06documentation: move git(7) to git(1)Libravatar Christian Couder1-1/+1
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>
2008-04-12merge, pull: introduce '--(no-)stat' optionLibravatar SZEDER Gábor1-1/+1
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>
2008-04-12doc: moved merge.* config variables into separate merge-config.txtLibravatar SZEDER Gábor1-12/+1
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>
2008-03-03Fix incorrect wording in git-merge.txt.Libravatar Matthieu Moy1-1/+2
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>
2008-01-16Documentation: fix and clarify grammar in git-merge docs.Libravatar Dave Peticolas1-6/+6
Signed-off-by: Dave Peticolas <dave@krondo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-06Documentation: rename gitlink macro to linkgitLibravatar Dan McGee1-4/+4
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>
2007-12-22Documentation: describe 'union' low-level merge driverLibravatar Junio C Hamano1-1/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-30Merge branch 'maint' into HEADLibravatar Junio C Hamano1-5/+6
* 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
2007-10-30git-merge: document but discourage the historical syntaxLibravatar Junio C Hamano1-5/+6
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>
2007-10-03Merge branch 'lh/merge'Libravatar Junio C Hamano1-0/+4
* 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
2007-09-25Fix spelling of overridden in documentationLibravatar Shawn Bohrer1-1/+1
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-23git-merge: add support for branch.<name>.mergeoptionsLibravatar Lars Hjemli1-0/+4
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>
2007-08-01Try to be consistent with capitalization in the documentationLibravatar Steve Hoelzer1-5/+5
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-12Update git-merge documentation.Libravatar Jakub Narebski1-0/+15
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>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+1
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>
2007-05-24Add a configuration option to control diffstat after mergeLibravatar Alex Riesen1-1/+1
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>