Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: git/git
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 83232e3
Choose a base ref
...
head repository: git/git
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 8c8e5bd
Choose a head ref
  • 15 commits
  • 19 files changed
  • 1 contributor

Commits on Apr 8, 2019

  1. Use 'unsigned short' for mode, like diff_filespec does 

    struct diff_filespec defines mode to be an 'unsigned short'.  Several
other places in the API which we'd like to interact with using a
diff_filespec used a plain unsigned (or unsigned int).  This caused
problems when taking addresses, so switch to unsigned short.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    5ec1e72 View commit details
    Browse the repository at this point in the history

  2. merge-recursive: rename merge_options argument from 'o' to 'opt' 

    The name 'o' was used for the merge_options struct pointer taken by many
functions, but in a few places it was named 'opt'.  Several functions
that didn't need merge_options instead used 'o' for a diff_filespec
argument or local.  Some functions needed both an inconsistently either
renamed the merge_options to 'opt' or the diff_filespec to 'one'.  I
want to remove the weird split in the codebase between using a
diff_filespec and a pair of (oid,mode) values in favor of using a
diff_filespec everywhere, but that dramatically increases the number of
cases where we want to use 'o' as a diff_filespec.  Rename the
merge_options argument to 'opt' to make room.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    259ccb6 View commit details
    Browse the repository at this point in the history

  3. merge-recursive: rename diff_filespec 'one' to 'o' 

    In the previous commit, we noted that several places throughout merge
recursive both had a reason to use 'o'; some for a merge_options struct,
and others for a diff_filespec struct.  Some places had both, forcing
one of the two to be renamed, though the choice was inconsistent.  Now
that the merge_options struct has been renamed to 'opt' everywhere, we
can replace the few places that used 'one' for the diff_filespec to 'o'.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    e3de888 View commit details
    Browse the repository at this point in the history

  4. merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf' 

    Since we want to replace oid,mode pairs with a single diff_filespec,
we will soon want to be able to use the names 'o', 'a', and 'b' for
the three different file versions.  Rename some local variables in
blob_unchanged() that would otherwise conflict.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    93a02c5 View commit details
    Browse the repository at this point in the history

  5. merge-recursive: use 'ci' for rename_conflict_info variable name 

    We used a couple different names, but used 'ci' the most.  Use the same
variable name throughout for a little extra consistency.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    043622b View commit details
    Browse the repository at this point in the history

  6. merge-recursive: move some struct declarations together 

    These structs are related and reference each other, so move them
together to make it easier for folks to determine what they hold and
what their purpose is.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    967d6be View commit details
    Browse the repository at this point in the history

  7. merge-recursive: shrink rename_conflict_info 

    The rename_conflict_info struct used both a pair and a stage_data which
were taken from a rename struct.  Just use the original rename struct.
This will also allow us to start making other simplifications to the
code.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    e9cd1b5 View commit details
    Browse the repository at this point in the history

  8. merge-recursive: remove ren[12]_other fields from rename_conflict_info 

    The ren1_other and ren2_other fields were synthesized from information
in ren1->src_entry and ren2->src_entry.  Since we already have the
necessary information in ren1 and ren2, just use those.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    3f9c92e View commit details
    Browse the repository at this point in the history

  9. merge-recursive: track branch where rename occurred in rename struct 

    We previously tracked the branch associated with a rename in a separate
field in rename_conflict_info, but since it is directly associated with
the rename it makes more sense to move it into the rename struct.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    c336ab8 View commit details
    Browse the repository at this point in the history

  10. merge-recursive: cleanup handle_rename_* function signatures 

    Instead of passing various bits and pieces of 'ci', just pass it
directly.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    e2d563d View commit details
    Browse the repository at this point in the history

  11. merge-recursive: switch from (oid,mode) pairs to a diff_filespec 

    There was a significant inconsistency in the various parts of the API
used in merge-recursive; many places used a pair of (oid, mode) to track
file version/contents, while other parts used a diff_filespec (which
have an oid and mode embedded in it).  This inconsistency caused lots of
places to need to pack and unpack data to call into other functions.
This has been the subject of some past cleanups (see e.g. commit
0270a07 ("merge-recursive: remove final remaining caller of
merge_file_one()", 2018-09-19)), but let's just remove the underlying
mess altogether by switching to use diff_filespec.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    8daec1d View commit details
    Browse the repository at this point in the history

  12. t6043: fix copied test description to match its purpose 

    Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    e0612a1 View commit details
    Browse the repository at this point in the history

  13. merge-recursive: track information associated with directory renames 

    Directory rename detection previously silently applied.  In order to
allow printing information about paths that changed or printing a
conflict notification (and only doing so near other potential conflict
messages associated with the paths), save this information inside the
rename struct for later use.  A subsequent patch will make use of the
additional information.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    6d169fd View commit details
    Browse the repository at this point in the history

  14. merge-recursive: give callers of handle_content_merge() access to con… 

    …tents

Pass a merge_file_info struct to handle_content_merge() so that the
callers can access the oid and mode of the result afterward.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    e62d112 View commit details
    Browse the repository at this point in the history

  15. merge-recursive: switch directory rename detection default 

    When all of x/a, x/b, and x/c have moved to z/a, z/b, and z/c on one
branch, there is a question about whether x/d added on a different
branch should remain at x/d or appear at z/d when the two branches are
merged.  There are different possible viewpoints here:

  A) The file was placed at x/d; it's unrelated to the other files in
     x/ so it doesn't matter that all the files from x/ moved to z/ on
     one branch; x/d should still remain at x/d.

  B) x/d is related to the other files in x/, and x/ was renamed to z/;
     therefore x/d should be moved to z/d.

Since there was no ability to detect directory renames prior to
git-2.18, users experienced (A) regardless of context.  Choice (B) was
implemented in git-2.18, with no option to go back to (A), and has been
in use since.  However, one user reported that the merge results did not
match their expectations, making the change of default problematic,
especially since there was no notice printed when directory rename
detection moved files.

Note that there is also a third possibility here:

  C) There are different answers depending on the context and content
     that cannot be determined by git, so this is a conflict.  Use a
     higher stage in the index to record the conflict and notify the
     user of the potential issue instead of silently selecting a
     resolution for them.

Add an option for users to specify their preference for whether to use
directory rename detection, and default to (C).  Even when directory
rename detection is on, add notice messages about files moved into new
directories.

As a sidenote, x/d did not have to be a new file here; it could have
already existed at some other path and been renamed to x/d, with
directory rename detection just renaming it again to z/d.  Thus, it's
not just new files, but also a modification to all rename types (normal
renames, rename/add, rename/delete, rename/rename(1to1),
rename/rename(1to2), and rename/rename(2to1)).

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
    @newren @gitster
    newren authored and gitster committed Apr 8, 2019
    Configuration menu
    Copy the full SHA
    8c8e5bd View commit details
    Browse the repository at this point in the history
Loading