Re: What's cooking in git.git (Jun 2011, #05; Thu, 30)

From: Elijah Newren <newren@gmail.com>
Date: Jul 1, 2011, 05:09 UTC
Message-ID: <BANLkTikeg+=QrxiRB7fxVByizDqy=qxNjQ@mail.gmail.com>
In-Reply-To: <7viprmq4sy.fsf@alter.siamese.dyndns.org>

Hi,

On Thu, Jun 30, 2011 at 5:26 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 52 quoted lines

> * en/merge-recursive (2011-06-13) 49 commits
>  - t3030: fix accidental success in symlink rename
>  - merge-recursive: Fix working copy handling for rename/rename/add/add
>  - merge-recursive: add handling for rename/rename/add-dest/add-dest
>  - merge-recursive: Have conflict_rename_delete reuse modify/delete code
>  - merge-recursive: Make modify/delete handling code reusable
>  - merge-recursive: Consider modifications in rename/rename(2to1) conflicts
>  - merge-recursive: Create function for merging with branchname:file markers
>  - merge-recursive: Record more data needed for merging with dual renames
>  - merge-recursive: Defer rename/rename(2to1) handling until process_entry
>  - merge-recursive: Small cleanups for conflict_rename_rename_1to2
>  - merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
>  - merge-recursive: Introduce a merge_file convenience function
>  - merge-recursive: Fix modify/delete resolution in the recursive case
>  - merge-recursive: Provide more info in conflict markers with file renames
>  - merge-recursive: Cleanup and consolidation of rename_conflict_info
>  - merge-recursive: Consolidate process_entry() and process_df_entry()
>  - merge-recursive: Improve handling of rename target vs. directory addition
>  - merge-recursive: Add comments about handling rename/add-source cases
>  - merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
>  - merge-recursive: Fix deletion of untracked file in rename/delete conflicts
>  - merge-recursive: When we detect we can skip an update, actually skip it
>  - merge-recursive: Split update_stages_and_entry; only update stages at end
>  - merge-recursive: Consolidate different update_stages functions
>  - merge-recursive: Allow make_room_for_path() to remove D/F entries
>  - merge-recursive: Split was_tracked() out of would_lose_untracked()
>  - merge-recursive: Save D/F conflict filenames instead of unlinking them
>  - merge-recursive: Fix code checking for D/F conflicts still being present
>  - merge-recursive: Fix sorting order and directory change assumptions
>  - merge-recursive: Fix recursive case with D/F conflict via add/add conflict
>  - merge-recursive: Avoid working directory changes during recursive case
>  - merge-recursive: Remember to free generated unique path names
>  - merge-recursive: Mark some diff_filespec struct arguments const
>  - merge-recursive: Correct a comment
>  - merge-recursive: Make BUG message more legible by adding a newline
>  - t6022: Add testcase for merging a renamed file with a simple change
>  - t6022: New tests checking for unnecessary updates of files
>  - t6022: Remove unnecessary untracked files to make test cleaner
>  - t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
>  - t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
>  - t6036: tests for criss-cross merges with various directory/file conflicts
>  - t6036: criss-cross with weird content can fool git into clean merge
>  - t6036: Add differently resolved modify/delete conflict in criss-cross test
>  - t6042: Ensure rename/rename conflicts leave index and workdir in sane state
>  - t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
>  - t6042: Add tests for content issues with modify/rename/directory conflicts
>  - t6042: Add a testcase where undetected rename causes silent file deletion
>  - t6042: Add a pair of cases where undetected renames cause issues
>  - t6042: Add failing testcase for rename/modify/add-source conflict
>  - t6042: Add a testcase where git deletes an untracked file
>
> Haven't looked at the whole series yet.

That's understandable; it's a pretty long series. I've got this worry, though, that you're going to read it all soon and have lots of questions and comments -- just after I leave on vacation for two weeks and am unplugged from email. Anyway, just thought I'd send a heads up to avoid any problems in reviewing/advancing this series. Let me know if there's anything in particular you'd like me to do (either the few days before I leave or when I get back). If you'd prefer to just wait a few weeks to look at it, or are okay with me not responding to reviews for a couple weeks or whatever, that's fine.

Thanks Elijah