summaryrefslogtreecommitdiff
path: root/builtin/merge.c
AgeCommit message (Collapse)AuthorFilesLines
2014-09-19Merge branch 'ah/grammofix'Libravatar Junio C Hamano1-2/+2
* ah/grammofix: grammofix in user-facing messages
2014-09-02grammofix in user-facing messagesLibravatar Alex Henrie1-2/+2
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-20run-command: introduce CHILD_PROCESS_INITLibravatar René Scharfe1-2/+1
Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16Merge branch 'rs/code-cleaning'Libravatar Junio C Hamano1-6/+4
* rs/code-cleaning: fsck: simplify fsck_commit_buffer() by using commit_list_count() commit: use commit_list_append() instead of duplicating its code merge: simplify merge_trivial() by using commit_list_append() use strbuf_addch for adding single characters use strbuf_addbuf for adding strbufs
2014-07-16Merge branch 'nd/split-index'Libravatar Junio C Hamano1-8/+4
An experiment to use two files (the base file and incremental changes relative to it) to represent the index to reduce I/O cost of rewriting a large index when only small part of the working tree changes. * nd/split-index: (32 commits) t1700: new tests for split-index mode t2104: make sure split index mode is off for the version test read-cache: force split index mode with GIT_TEST_SPLIT_INDEX read-tree: note about dropping split-index mode or index version read-tree: force split-index mode off on --index-output rev-parse: add --shared-index-path to get shared index path update-index --split-index: do not split if $GIT_DIR is read only update-index: new options to enable/disable split index mode split-index: strip pathname of on-disk replaced entries split-index: do not invalidate cache-tree at read time split-index: the reading part split-index: the writing part read-cache: mark updated entries for split index read-cache: save deleted entries in split index read-cache: mark new entries for split index read-cache: split-index mode read-cache: save index SHA-1 after reading entry.c: update cache_changed if refresh_cache is set in checkout_entry() cache-tree: mark istate->cache_changed on prime_cache_tree() cache-tree: mark istate->cache_changed on cache tree update ...
2014-07-10merge: simplify merge_trivial() by using commit_list_append()Libravatar René Scharfe1-6/+4
Build the commit_list of parents by calling commit_list_append() twice instead of allocating and linking the items by hand. This makes the code shorter and simpler. Rename the commit_list from parent to parents (plural) while at it because there are two of them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-10Merge branch 'mg/verify-commit'Libravatar Junio C Hamano1-4/+1
Add 'verify-commit' to be used in a way similar to 'verify-tag' is used. Further work on verifying the mergetags might be needed. * mg/verify-commit: t7510: test verify-commit t7510: exit for loop with test result verify-commit: scriptable commit signature verification gpg-interface: provide access to the payload gpg-interface: provide clear helper for struct signature_check
2014-07-02Merge branch 'jk/commit-buffer-length'Libravatar Junio C Hamano1-4/+4
Move "commit->buffer" out of the in-core commit object and keep track of their lengths. Use this to optimize the code paths to validate GPG signatures in commit objects. * jk/commit-buffer-length: reuse cached commit buffer when parsing signatures commit: record buffer length in cache commit: convert commit->buffer to a slab commit-slab: provide a static initializer use get_commit_buffer everywhere convert logmsg_reencode to get_commit_buffer use get_commit_buffer to avoid duplicate code use get_cached_commit_buffer where appropriate provide helpers to access the commit buffer provide a helper to set the commit buffer provide a helper to free commit buffer sequencer: use logmsg_reencode in get_message logmsg_reencode: return const buffer do not create "struct commit" with xcalloc commit: push commit_index update into alloc_commit_node alloc: include any-object allocations in alloc_report replace dangerous uses of strbuf_attach commit_tree: take a pointer/len pair rather than a const strbuf
2014-06-23gpg-interface: provide clear helper for struct signature_checkLibravatar Michael J Gruber1-4/+1
The struct has been growing members whose malloced memory needs to be freed. Do this with one helper function so that no malloced memory shall be left unfreed. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13read-cache: new API write_locked_index instead of write_index/write_cacheLibravatar Nguyễn Thái Ngọc Duy1-8/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12commit_tree: take a pointer/len pair rather than a const strbufLibravatar Jeff King1-4/+4
While strbufs are pretty common throughout our code, it is more flexible for functions to take a pointer/len pair than a strbuf. It's easy to turn a strbuf into such a pair (by dereferencing its members), but less easy to go the other way (you can strbuf_attach, but that has implications about memory ownership). This patch teaches commit_tree (and its associated callers and sub-functions) to take such a pair for the commit message rather than a strbuf. This makes passing the buffer around slightly more verbose, but means we can get rid of some dangerous strbuf_attach calls in the next patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03Merge branch 'fc/merge-default-to-upstream'Libravatar Junio C Hamano1-1/+1
"git merge" without argument, even when there is an upstream defined for the current branch, refused to run until merge.defaultToUpstream is set to true. Flip the default of that configuration variable to true. * fc/merge-default-to-upstream: merge: enable defaulttoupstream by default
2014-06-03Merge branch 'mh/ref-transaction'Libravatar Junio C Hamano1-3/+3
Update "update-ref --stdin [-z]" and then introduce a transactional support for (multi-)reference updates. * mh/ref-transaction: (27 commits) ref_transaction_commit(): work with transaction->updates in place struct ref_update: add a type field struct ref_update: add a lock field ref_transaction_commit(): simplify code using temporary variables struct ref_update: store refname as a FLEX_ARRAY struct ref_update: rename field "ref_name" to "refname" refs: remove API function update_refs() update-ref --stdin: reimplement using reference transactions refs: add a concept of a reference transaction update-ref --stdin: harmonize error messages update-ref --stdin: improve the error message for unexpected EOF t1400: test one mistake at a time update-ref --stdin -z: deprecate interpreting the empty string as zeros update-ref.c: extract a new function, parse_next_sha1() t1400: test that stdin -z update treats empty <newvalue> as zeros update-ref --stdin: simplify error messages for missing oldvalues update-ref --stdin: make error messages more consistent update-ref --stdin: improve error messages for invalid values update-ref.c: extract a new function, parse_refname() parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice ...
2014-04-22merge: enable defaulttoupstream by defaultLibravatar Felipe Contreras1-1/+1
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>
2014-04-08Merge branch 'jc/rev-parse-argh-dashed-multi-words'Libravatar Junio C Hamano1-1/+1
Make sure that the help text given to describe the "<param>" part of the "git cmd --option=<param>" does not contain SP or _, e.g. "--gpg-sign=<key-id>" option for "git commit" is not spelled as "--gpg-sign=<key id>". * jc/rev-parse-argh-dashed-multi-words: parse-options: make sure argh string does not have SP or _ update-index: teach --cacheinfo a new syntax "mode,sha1,path" parse-options: multi-word argh should use dash to separate words
2014-04-07refs.h: rename the action_on_err constantsLibravatar Michael Haggerty1-3/+3
Given that these constants are only being used when updating references, it is inappropriate to give them such generic names as "DIE_ON_ERR". So prefix their names with "UPDATE_REFS_". Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-28Merge branch 'bp/commit-p-editor'Libravatar Junio C Hamano1-3/+3
When it is not necessary to edit a commit log message (e.g. "git commit -m" is given a message without specifying "-e"), we used to disable the spawning of the editor by overriding GIT_EDITOR, but this means all the uses of the editor, other than to edit the commit log message, are also affected. * bp/commit-p-editor: run-command: mark run_hook_with_custom_index as deprecated merge hook tests: fix and update tests merge: fix GIT_EDITOR override for commit hook commit: fix patch hunk editing with "commit -p -m" test patch hunk editing with "commit -p -m" merge hook tests: use 'test_must_fail' instead of '!' merge hook tests: fix missing '&&' in test
2014-03-24parse-options: multi-word argh should use dash to separate wordsLibravatar Junio C Hamano1-1/+1
"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>
2014-03-18merge: fix GIT_EDITOR override for commit hookLibravatar Benoit Pierre1-1/+1
Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the editor is going to be called (e.g. with "merge -e"). Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18commit: fix patch hunk editing with "commit -p -m"Libravatar Benoit Pierre1-3/+3
Don't change git environment: move the GIT_EDITOR=":" override to the hook command subprocess, like it's already done for GIT_INDEX_FILE. Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-27Merge branch 'nv/commit-gpgsign-config'Libravatar Junio C Hamano1-0/+3
Introduce commit.gpgsign configuration variable to force every commit to be GPG signed. The variable cannot be overriden from the command line of some of the commands that create commits except for "git commit" and "git commit-tree", but I am not convinced that it is a good idea to sprinkle support for --no-gpg-sign everywhere, which in turn means that this configuration variable may not be such a good idea. * nv/commit-gpgsign-config: test the commit.gpgsign config option commit-tree: add and document --no-gpg-sign commit-tree: add the commit.gpgsign option to sign all commits
2014-02-24commit-tree: add the commit.gpgsign option to sign all commitsLibravatar Nicolas Vigier1-0/+3
If you want to GPG sign all your commits, you have to add the -S option all the time. The commit.gpgsign config option allows to sign all commits automatically. Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-27Merge branch 'ef/mingw-write'Libravatar Junio C Hamano1-1/+1
* ef/mingw-write: mingw: remove mingw_write prefer xwrite instead of write
2014-01-17prefer xwrite instead of writeLibravatar Erik Faye-Lund1-1/+1
Our xwrite wrapper already deals with a few potential hazards, and are as such more robust. Prefer it instead of write to get the robustness benefits everywhere. Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Reviewed-and-improved-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Libravatar Christian Couder1-6/+6
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-31merge: simplify ff-only optionLibravatar Felipe Contreras1-9/+2
No functional changes. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-17Merge branch 'rh/ishes-doc'Libravatar Junio C Hamano1-1/+1
We liberally use "committish" and "commit-ish" (and "treeish" and "tree-ish"); as these are non-words, let's unify these terms to their dashed form. More importantly, clarify the documentation on object peeling using these terms. * rh/ishes-doc: glossary: fix and clarify the definition of 'ref' revisions.txt: fix and clarify <rev>^{<type>} glossary: more precise definition of tree-ish (a.k.a. treeish) use 'commit-ish' instead of 'committish' use 'tree-ish' instead of 'treeish' glossary: define commit-ish (a.k.a. committish) glossary: mention 'treeish' as an alternative to 'tree-ish'
2013-09-04use 'commit-ish' instead of 'committish'Libravatar Richard Hansen1-1/+1
Replace 'committish' in documentation and comments with 'commit-ish' to match gitglossary(7) and to be consistent with 'tree-ish'. The only remaining instances of 'committish' are: * variable, function, and macro names * "(also committish)" in the definition of commit-ish in gitglossary[7] Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLLibravatar Stefan Beller1-6/+6
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-22Merge branch 'nd/const-struct-cache-entry'Libravatar Junio C Hamano1-1/+1
* nd/const-struct-cache-entry: Convert "struct cache_entry *" to "const ..." wherever possible
2013-07-15Merge branch 'mv/merge-ff-tristate'Libravatar Junio C Hamano1-22/+33
The configuration variable "merge.ff" was cleary a tri-state to choose one from "favor fast-forward when possible", "always create a merge even when the history could fast-forward" and "do not create any merge, only update when the history fast-forwards", but the command line parser did not implement the usual convention of "last one wins, and command line overrides the configuration" correctly. * mv/merge-ff-tristate: merge: handle --ff/--no-ff/--ff-only as a tri-state option
2013-07-12Merge branch 'ms/remote-tracking-branches-in-doc'Libravatar Junio C Hamano1-2/+2
* ms/remote-tracking-branches-in-doc: Change "remote tracking" to "remote-tracking"
2013-07-09Convert "struct cache_entry *" to "const ..." wherever possibleLibravatar Nguyễn Thái Ngọc Duy1-1/+1
I attempted to make index_state->cache[] a "const struct cache_entry **" to find out how existing entries in index are modified and where. The question I have is what do we do if we really need to keep track of on-disk changes in the index. The result is - diff-lib.c: setting CE_UPTODATE - name-hash.c: setting CE_HASHED - preload-index.c, read-cache.c, unpack-trees.c and builtin/update-index: obvious - entry.c: write_entry() may refresh the checked out entry via fill_stat_cache_info(). This causes "non-const struct cache_entry *" in builtin/apply.c, builtin/checkout-index.c and builtin/checkout.c - builtin/ls-files.c: --with-tree changes stagemask and may set CE_UPDATE Of these, write_entry() and its call sites are probably most interesting because it modifies on-disk info. But this is stat info and can be retrieved via refresh, at least for porcelain commands. Other just uses ce_flags for local purposes. So, keeping track of "dirty" entries is just a matter of setting a flag in index modification functions exposed by read-cache.c. Except unpack-trees, the rest of the code base does not do anything funny behind read-cache's back. The actual patch is less valueable than the summary above. But if anyone wants to re-identify the above sites. Applying this patch, then this: diff --git a/cache.h b/cache.h index 430d021..1692891 100644 --- a/cache.h +++ b/cache.h @@ -267,7 +267,7 @@ static inline unsigned int canon_mode(unsigned int mode) #define cache_entry_size(len) (offsetof(struct cache_entry,name) + (len) + 1) struct index_state { - struct cache_entry **cache; + const struct cache_entry **cache; unsigned int version; unsigned int cache_nr, cache_alloc, cache_changed; struct string_list *resolve_undo; will help quickly identify them without bogus warnings. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03Change "remote tracking" to "remote-tracking"Libravatar Michael Schubert1-2/+2
Fix a typo ("remote remote-tracking") going back to the big cleanup in 2010 (8b3f3f84 etc). Also, remove some more occurrences of "tracking" and "remote tracking" in favor of "remote-tracking". Signed-off-by: Michael Schubert <mschub@elegosoft.com> Reviewed-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-02merge: handle --ff/--no-ff/--ff-only as a tri-state optionLibravatar Miklos Vajna1-22/+33
These three options mean "favor fast-forwarding when possible, without creating an unnecessary merge", "never fast-forward and always create a merge commit even when the commit being merged is a strict descendant", and "we do not want to create any merge commit; update only when the merged commit is a strict descendant". They are "pick one out of these three possibilities" options, and correspond to "merge.ff" configuration that is tri-state (yes, no and only). However, the implementation did not follow the usual convention for the command line options (later one wins, and command line overrides what is in the configuration). Fix this by consolidating two variables (fast_forward_only and allow_fast_forward) used in the implementation into one enum that can take one of the three possible values. Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08merge: use help_unknown_ref()Libravatar Vikrant Varma1-1/+2
Use help.c:help_unknown_ref() instead of die() to provide a friendlier error message before exiting, when one of the refs specified in a merge is unknown. Signed-off-by: Vikrant Varma <vikrant.varma94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'sg/gpg-sig'Libravatar Junio C Hamano1-1/+36
Teach "merge/pull" to optionally verify and reject commits that are not signed properly. * sg/gpg-sig: pretty printing: extend %G? to include 'N' and 'U' merge/pull Check for untrusted good GPG signatures merge/pull: verify GPG signatures of commits being merged commit.c/GPG signature verification: Also look at the first GPG status line Move commit GPG signature verification to commit.c
2013-04-05Merge branch 'jc/merge-tag-object'Libravatar Junio C Hamano1-0/+13
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2" as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. This makes the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-03-31merge/pull Check for untrusted good GPG signaturesLibravatar Sebastian Götte1-0/+3
When --verify-signatures is specified, abort the merge in case a good GPG signature from an untrusted key is encountered. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-31merge/pull: verify GPG signatures of commits being mergedLibravatar Sebastian Götte1-1/+33
When --verify-signatures is specified on the command-line of git-merge or git-pull, check whether the commits being merged have good gpg signatures and abort the merge in case they do not. This allows e.g. auto-deployment from untrusted repo hosts. Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-19merge: a random object may not necssarily be a commitLibravatar Junio C Hamano1-0/+13
The user could have said "git merge $(git rev-parse v1.0.0)"; we shouldn't mark it as "Merge commit '15999998fb...'" as the merge name, even though such an invocation might be crazy. We could even read the "tag " header from the tag object and replace the object name the user gave us, but let's not lose the information by doing so, at least not yet. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-04Merge branch 'jc/custom-comment-char'Libravatar Junio C Hamano1-3/+2
Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
2013-01-16Allow custom "comment char"Libravatar Junio C Hamano1-3/+2
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10Merge branch 'jc/maint-fmt-merge-msg-no-edit-lose-credit'Libravatar Junio C Hamano1-0/+1
Stop spending cycles to compute information to be placed on commented lines in "merge --no-edit", which will be discarded anyway. * jc/maint-fmt-merge-msg-no-edit-lose-credit: merge --no-edit: do not credit people involved in the side branch
2013-01-09Merge branch 'ap/merge-stop-at-prepare-commit-msg-failure'Libravatar Junio C Hamano1-2/+3
"git merge" started calling prepare-commit-msg hook like "git commit" does some time ago, but forgot to pay attention to the exit status of the hook. t7505 may want a general clean-up but that is a different topic. * ap/merge-stop-at-prepare-commit-msg-failure: merge: Honor prepare-commit-msg return code
2013-01-03merge: Honor prepare-commit-msg return codeLibravatar Antoine Pelisse1-2/+3
65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to make "git commit" and "git merge" consistent, because a merge that required user assistance has to be concluded with "git commit", but back then only "git commit" triggered prepare-commit-msg hook. When it added a call to run the prepare-commit-msg hook, however, it forgot to check the exit code from the hook like "git commit" does, and ended up replacing one inconsistency with another. When prepare-commit-msg hook that is run from "git merge" exits with a non-zero status, abort the commit. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-28merge --no-edit: do not credit people involved in the side branchLibravatar Junio C Hamano1-0/+1
The credit lines "By" and "Via" to credit authors and committers for their contributions on the side branch are meant as a hint to the integrator to decide whom to mention in the log message text. After the integrator saves the message in the editor, they are meant to go away and that is why they are commented out. When a merge is recorded without editing the generated message, however, its contents do not go through the normal stripspace() and these lines are left in the merge. Stop producing them when we know the merge is going to be recorded without editing, i.e. when --no-edit is given. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29Move try_merge_command and checkout_fast_forward to libgit.aLibravatar Nguyễn Thái Ngọc Duy1-104/+2
These functions are called in sequencer.c, which is part of libgit.a. This makes libgit.a potentially require builtin/merge.c for external git commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2012-09-11Merge branch 'tr/void-diff-setup-done' into maint-1.7.11Libravatar Junio C Hamano1-2/+1
* tr/void-diff-setup-done: diff_setup_done(): return void
2012-09-07Merge branch 'nd/i18n-parseopt-help'Libravatar Junio C Hamano1-24/+24
A lot of i18n mark-up for the help text from "git <cmd> -h". * nd/i18n-parseopt-help: (66 commits) Use imperative form in help usage to describe an action Reduce translations by using same terminologies i18n: write-tree: mark parseopt strings for translation i18n: verify-tag: mark parseopt strings for translation i18n: verify-pack: mark parseopt strings for translation i18n: update-server-info: mark parseopt strings for translation i18n: update-ref: mark parseopt strings for translation i18n: update-index: mark parseopt strings for translation i18n: tag: mark parseopt strings for translation i18n: symbolic-ref: mark parseopt strings for translation i18n: show-ref: mark parseopt strings for translation i18n: show-branch: mark parseopt strings for translation i18n: shortlog: mark parseopt strings for translation i18n: rm: mark parseopt strings for translation i18n: revert, cherry-pick: mark parseopt strings for translation i18n: rev-parse: mark parseopt strings for translation i18n: reset: mark parseopt strings for translation i18n: rerere: mark parseopt strings for translation i18n: status: mark parseopt strings for translation i18n: replace: mark parseopt strings for translation ...