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:

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

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:

Hi,

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

quoted

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

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?

Good idea.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Fri, 29 Dec 2006, Johannes Schindelin wrote:

Hi,

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

quoted

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

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?

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:

On Fri, 29 Dec 2006, Johannes Schindelin wrote:

quoted

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

quoted

* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
 + git-merge: preserve and merge local changes when doing fast
   forward

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?

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?

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:

(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?)

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

-- 
best regards

  Ray

Hi,

On Sat, 30 Dec 2006, Raimund Bauer wrote:

* Johannes Schindelin wrote, On 30.12.2006 12:22:

quoted

(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?)

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

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