Re: [PATCH v6 8/8] checkout & worktree: introduce checkout.defaultRemote

On Sat, Jun 2, 2018 at 7:50 AM, Ævar Arnfjörð Bjarmason wrote: > Introduce a checkout.defaultRemote setting which can be used to > designate a remote to prefer (via checkout.defaultRemote=origin) when > running e.g. "git checkout master" to mean origin/master, even though > there's other remotes

[RFC PATCH 7/7] merge: fix misleading pre-merge check documentation

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

[RFC PATCH 5/7] t6044: add more testcases with staged changes before a merge is invoked

According to Documentation/git-merge.txt, ...[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.) Add some tests showing that

[RFC PATCH 1/7] t6044: verify that merges expected to abort actually abort

t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted,

[RFC PATCH 3/7] merge-recursive: make sure when we say we abort that we actually abort

In commit 65170c07d4 ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21), it was noted that there was a special case when merge-recursive didn't rely on unpack_trees() to enforce the index == HEAD requirement, and thus that it needed to do that enforcement itself.

[RFC PATCH 6/7] merge-recursive: enforce rule that index matches head before merging

builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to

[RFC PATCH 0/7] merge requirement: index matches head

Between working on some other things, I happened to be reading Documentation/git-merge.txt and ran across the part that 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

[RFC PATCH 2/7] t6044: add a testcase for index matching head, when head doesn't match HEAD

The `git merge-recursive` command allows the user to directly specify three commits to merge -- base, head, and remote. (More than three can be specified in the case of multiple merge bases.) Note that since the user is allowed to specify head, it need not match HEAD. Virtually every test and

[RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD

`git merge-recursive` does a three-way merge between user-specified trees base, head, and remote. Since the user is allowed to specify head, we can not necesarily assume that head == HEAD. We modify index_has_changes() to take an extra argument specifying the tree to compare the index to. If

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Hi, Junio On 05/29, Eduardo Habkost wrote: >Hi, > >I'm trying to use git-format-patch --base to generate the list of >prerequisite patches for a series, but the behavior of git >doesn't seem to match the documentation: > >When using a commit count (e.g.: "-2"), git-format-patch generates the

<    1   2