What's cooking in git.git (topics)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The topics list the commits in reverse chronological order.

* sp/merge (Thu Dec 28 02:35:34 2006 -0500) 5 commits
 - Improve merge performance by avoiding in-index merges.
 - Avoid git-fetch in `git-pull .` when possible.
 + Use merge-recursive in git-am -3.
 + Allow merging bare trees in merge-recursive.
 + Move better_branch_name above get_ref in merge-recursive.

Good intentions, very attractive, somewhat disruptive and might be risky breaking existing users. I'd like at least the earlier parts to be in v1.5.0-rc1.

* jc/curl (Wed Dec 27 13:59:26 2006 -0800) 1 commit
 + Work around http-fetch built with cURL 7.16.0

Waiting for an Ack.

* sp/mmap (Wed Dec 27 02:46:23 2006 -0500) 22 commits
 - Fix random segfaults in pack-objects.
 - Cleanup read_cache_from error handling.
 - Replace mmap with xmmap, better handling MAP_FAILED.
 - Release pack windows before reporting out of memory.
 - Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
 - Test suite for sliding window mmap implementation.
 - Create pack_report() as a debugging aid.
 - Support unmapping windows on 'temporary' packfiles.
 - Improve error message when packfile mmap fails.
 - Ensure core.packedGitWindowSize cannot be less than 2 pages.
 - Load core configuration in git-verify-pack.
 - Fully activate the sliding window pack access.
 - Unmap individual windows rather than entire files.
 - Document why header parsing won't exceed a window.
 - Loop over pack_windows when inflating/accessing data.
 - Replace use_packed_git with window cursors.
 - Refactor how we open pack files to prepare for multiple windows.
 - Create read_or_die utility routine.
 - Use off_t for index and pack file lengths.
 - Refactor packed_git to prepare for sliding mmap windows.
 - Introduce new config option for mmap limit.
 - Replace unpack_entry_gently with unpack_entry.

Known breakage exists that this series is highly suspected. Will diagnose and merge to 'next' after fixing.

* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
 + git-diff/git-apply: make diff output a bit friendlier to GNU patch
   (part 2)

I promised this to wait until February. Most likely to be in v1.5.1.

* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
 - test-para: combined diff between HEAD, index and working tree.
 - para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
 - git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
 - gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
 - blame: --show-stats for easier optimization work.

These are on hold or will not be merged ever.

Hi,

On Thu, 28 Dec 2006, Junio C Hamano wrote:

I'd like this, but behind a command line switch. And in addition to saying "cannot merge, blabla needs update", git could spit out "if you want to risk a 3way merge, go ahead and add the --preserve-local flag to git-merge".

Comments?

Ciao, Dscho

Johannes Schindelin wrote:

Good idea.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I think what you propose is in line is what I originally wanted to do, but I backburnered it exactly because I did not like the "if you want to risk a 3-way" phrase. It's not the wording, but the fact that I have to say "risk" bothers me. No matter how you cut it, it _is_ risky, and indicates to me that we are somehow doing this in a wrong way. I have a nagging suspicion that there may be a better approach, but I haven't found one.

But you are welcome to take a crack at it.

On Fri, 29 Dec 2006, Johannes Schindelin wrote:

Is there really a point for not always doing it?

IOW, if you really want a command line switch, maybe it should be used to prevent the above not to allow it?

Nicolas

Hi,

On Fri, 29 Dec 2006, Nicolas Pitre wrote:

There is a drawback to enabling this all the time. If the merge screws up with gazillions of conflicts, because I pulled the wrong branch, I am so used to "git reset --hard". Bummer. All my changes lost.

That is why we encourage commit-before-pull, to have a saved state.

(Of course, the correct thing would not be "git reset --hard", but rather "git diff --ours | git apply -R; git reset", but that's a tad long, no?)

Ciao, Dscho

* Johannes Schindelin wrote, On 30.12.2006 12:22:

Then maybe introduce "git reset --ours" which does exactly that?

Hi,

On Sat, 30 Dec 2006, Raimund Bauer wrote:

That is possible.

But does it make sense? 

It is a volatile state, and errors are too easy. So I think it makes sense to have to _ask_ for such a state.

(Having said that, I think that it actually might make sense for bisecting an error where you _need_ a local patch to get it running to begin with.)

Ciao, Dscho