# What's cooking in git.git (topics) 8 messages from 2006-12-29 to 2006-12-30. Participants: Junio C Hamano, Johannes Schindelin, Jakub Narebski, Nicolas Pitre, Raimund Bauer. Thread: https://gitlist.dev/t/6148 ## Junio C Hamano, 2006-12-29 05:44 Subject: What's cooking in git.git (topics) Message-ID: <7vtzzfp86x.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vtzzfp86x.fsf%40assigned-by-dhcp.cox.net ``` 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. ``` ## Johannes Schindelin, 2006-12-29 17:55 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612291853210.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vtzzfp86x.fsf@assigned-by-dhcp.cox.net> ``` 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 ``` ## Jakub Narebski, 2006-12-29 18:06 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/en3la8%245t7%241%40sea.gmane.org In-Reply-To: ``` Johannes Schindelin wrote: > 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? Good idea. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Junio C Hamano, 2006-12-29 18:25 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vhcveo8yl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vhcveo8yl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > 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? 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. ``` ## Nicolas Pitre, 2006-12-30 03:21 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0612292219280.18171%40xanadu.home In-Reply-To: ``` On Fri, 29 Dec 2006, Johannes Schindelin wrote: > 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? 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 ``` ## Johannes Schindelin, 2006-12-30 11:22 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612301217010.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: ``` Hi, On Fri, 29 Dec 2006, Nicolas Pitre wrote: > On Fri, 29 Dec 2006, Johannes Schindelin wrote: > > > 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? > > 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 ``` ## Raimund Bauer, 2006-12-30 12:24 Subject: Re: What's cooking in git.git (topics) Message-ID: <45965A82.8030903@gmx.net> URL: https://gitlist.dev/e/45965A82.8030903%40gmx.net In-Reply-To: ``` * 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 ``` ## Johannes Schindelin, 2006-12-30 12:54 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0612301350580.19693%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <45965A82.8030903@gmx.net> ``` Hi, On Sat, 30 Dec 2006, Raimund Bauer wrote: > * 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? 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 ```