# What's cooking in git.git (topics) 34 messages from 2007-05-13 to 2007-07-28. Participants: Junio C Hamano, Julian Phillips, Daniel Barkalow, Shawn O. Pearce, Johannes Schindelin, Nicolas Pitre, Dana How, Linus Torvalds, Matthias Lederhofer, Jeffrey C. Ollie. Thread: https://gitlist.dev/t/8139 ## Junio C Hamano, 2007-05-13 22:29 Subject: What's cooking in git.git (topics) Message-ID: <7v646wqrvm.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v646wqrvm.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/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit - Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file. This is waiting for Ack/Nack to make sure there is no unexpected side effects but I am hoping we can ship v1.5.2 with this. * dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits + Custom compression levels for objects and packs + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit + Add --aggressive option to 'git gc' * np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits + deprecate the new loose object header format + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit + git-update-ref: add --no-deref option for overwriting/detaching ref * jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit + Add colour support in rebase and merge tree diff stats output. New features, all deemed to be safe. To merge early after v1.5.2. * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits - Add handlers for fetch-side configuration of remotes. - Move refspec parser from connect.c and cache.h to remote.{c,h} - Move remote parsing into a library file out of builtin-push. Hopefully be in 'next' after v1.5.2; I haven't really played with it. The next step would probably be to add some stuff that use this series in fetch--tool, to further rewrite git-fetch itself in C, or maybe wholesale rewrite of git-fetch in C. * dh/repack (Tue May 8 13:05:04 2007 -0700) 5 commits - git-repack --max-pack-size: add option parsing to enable feature - git-repack --max-pack-size: split packs as asked by write_{object,one}() - git-repack --max-pack-size: write_{object,one}() respect pack limit - git-repack --max-pack-size: new file statics and code restructuring - Alter sha1close() 3rd argument to request flush only Hopefully will have a series rebased on top of 'master' after the first batch after v1.5.2 graduates. * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 Stalled. ``` ## Julian Phillips, 2007-05-13 22:58 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705132348290.4791%40beast.quantumfyre.co.uk In-Reply-To: <7v646wqrvm.fsf@assigned-by-dhcp.cox.net> ``` On Sun, 13 May 2007, Junio C Hamano wrote: > * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits > - Add handlers for fetch-side configuration of remotes. > - Move refspec parser from connect.c and cache.h to remote.{c,h} > - Move remote parsing into a library file out of builtin-push. > > Hopefully be in 'next' after v1.5.2; I haven't really played > with it. The next step would probably be to add some stuff that > use this series in fetch--tool, to further rewrite git-fetch > itself in C, or maybe wholesale rewrite of git-fetch in C. FWIW, I've got a largely functional C version of git-fetch ... the main functionality is there - but it's not complete yet. In addition to some of the non-core functionality being missing (e.g. --tags or --no-tags in tagopt), I haven't been keeping up with recent updates to fetch/fetch-tool. I was hoping to have it ready for post-1.5.2 - unfortunately I've been rather busy the last couple of weeks, and haven't managed to get as far as I'd hoped. -- Julian --- byob, v: Believing Your Own Bull ``` ## Junio C Hamano, 2007-05-13 23:33 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vzm48pacj.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzm48pacj.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Julian Phillips writes: > On Sun, 13 May 2007, Junio C Hamano wrote: > >> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits >> - Add handlers for fetch-side configuration of remotes. >> - Move refspec parser from connect.c and cache.h to remote.{c,h} >> - Move remote parsing into a library file out of builtin-push. >> >> Hopefully be in 'next' after v1.5.2; I haven't really played >> with it. The next step would probably be to add some stuff that >> use this series in fetch--tool, to further rewrite git-fetch >> itself in C, or maybe wholesale rewrite of git-fetch in C. > > FWIW, I've got a largely functional C version of git-fetch ... the > main functionality is there - but it's not complete yet. In addition > to some of the non-core functionality being missing (e.g. --tags or > --no-tags in tagopt), I haven't been keeping up with recent updates to > fetch/fetch-tool. I was hoping to have it ready for post-1.5.2 - > unfortunately I've been rather busy the last couple of weeks, and > haven't managed to get as far as I'd hoped. Thanks for the status updates. Although I do not recall Daniel saying it explicitly, I have been assuming that his series was aiming for the same all along. It might be a good idea for you two to compare notes sometime between now and v1.5.2? ``` ## Julian Phillips, 2007-05-14 00:38 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705140121030.5520%40beast.quantumfyre.co.uk In-Reply-To: <7vzm48pacj.fsf@assigned-by-dhcp.cox.net> ``` On Sun, 13 May 2007, Junio C Hamano wrote: > Julian Phillips writes: > >> On Sun, 13 May 2007, Junio C Hamano wrote: >> >>> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits >>> - Add handlers for fetch-side configuration of remotes. >>> - Move refspec parser from connect.c and cache.h to remote.{c,h} >>> - Move remote parsing into a library file out of builtin-push. >>> >>> Hopefully be in 'next' after v1.5.2; I haven't really played >>> with it. The next step would probably be to add some stuff that >>> use this series in fetch--tool, to further rewrite git-fetch >>> itself in C, or maybe wholesale rewrite of git-fetch in C. >> >> FWIW, I've got a largely functional C version of git-fetch ... the >> main functionality is there - but it's not complete yet. In addition >> to some of the non-core functionality being missing (e.g. --tags or >> --no-tags in tagopt), I haven't been keeping up with recent updates to >> fetch/fetch-tool. I was hoping to have it ready for post-1.5.2 - >> unfortunately I've been rather busy the last couple of weeks, and >> haven't managed to get as far as I'd hoped. > > Thanks for the status updates. Although I do not recall Daniel > saying it explicitly, I have been assuming that his series was > aiming for the same all along. It might be a good idea for you > two to compare notes sometime between now and v1.5.2? Well, it can't be a bad idea, can it? ;) Apart from the code itself (which can be found at http://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and since I haven't had a chance to work on it for a couple of weeks I'm not 100% sure of where I was at - due to lack of time I have tended to just spend a few hours adding some missing part when I found the time but I don't actually have a TODO list or similar (though I really should). I'm also out of town with work for the first half of the coming week ... but I'm certainly willing to talk about what I have and haven't done. (Daniel, hope you don't mind me adding you to CC ...) -- Julian --- The cable TV sex channels don't expand our horizons, don't make us better people, and don't come in clearly enough. -- Bill Maher ``` ## Daniel Barkalow, 2007-05-14 03:21 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705132234001.18541%40iabervon.org In-Reply-To: ``` On Mon, 14 May 2007, Julian Phillips wrote: > On Sun, 13 May 2007, Junio C Hamano wrote: > > > Thanks for the status updates. Although I do not recall Daniel > > saying it explicitly, I have been assuming that his series was > > aiming for the same all along. It might be a good idea for you > > two to compare notes sometime between now and v1.5.2? > > Well, it can't be a bad idea, can it? ;) > > Apart from the code itself (which can be found at > http://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and since I > haven't had a chance to work on it for a couple of weeks I'm not 100% sure of > where I was at - due to lack of time I have tended to just spend a few hours > adding some missing part when I found the time but I don't actually have a > TODO list or similar (though I really should). > > I'm also out of town with work for the first half of the coming week ... but > I'm certainly willing to talk about what I have and haven't done. I've actually been largely unsuccessful in figuring out how to do most of the fetch logic in C, but I was expecting that somebody would write it if the library were available. I've been working on various little things that are a lot easier if the parsing is centralized: * update tracking refs on push * handle refspec patterns in match_refs so that send-pack/http-push can take them and builtin-push doesn't need to do anything, and can also turn --tags into +refs/tags/*:refs/tags/*. I've also been looking at doing something like your remote_ops, but also including something for push, and doing it in another library file (so push, fetch, and ls-remote can all share the same dispatch on type of url). > (Daniel, hope you don't mind me adding you to CC ...) Not at all; I hadn't noticed this thread yet, and it's quite related to what I'm working on. -Daniel *This .sig left intentionally blank* ``` ## Junio C Hamano, 2007-05-17 00:21 Subject: What's cooking in git.git (topics) Message-ID: <7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfy5wcnbg.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v646wqrvm.fsf@assigned-by-dhcp.cox.net> ``` It probably would be more interesting to look at the earlier "What's not in 1.5.2" messages, but here is the current status of my tree on the 'next' and 'pu' front. 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. * mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit + connect: display connection progress * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits - Update local tracking refs when pushing - Add handlers for fetch-side configuration of remotes. - Move refspec parser from connect.c and cache.h to remote.{c,h} - Move remote parsing into a library file out of builtin-push. + git-update-ref: add --no-deref option for overwriting/detaching ref * dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits - git-repack --max-pack-size: add option parsing to enable feature - git-repack --max-pack-size: split packs as asked by write_{object,one}() - git-repack --max-pack-size: write_{object,one}() respect pack limit - git-repack --max-pack-size: new file statics and code restructuring - Alter sha1close() 3rd argument to request flush only + Custom compression levels for objects and packs + deprecate the new loose object header format + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit + Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file. * dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits + Custom compression levels for objects and packs + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit + Add --aggressive option to 'git gc' * np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits + deprecate the new loose object header format + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit + git-update-ref: add --no-deref option for overwriting/detaching ref * jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit + Add colour support in rebase and merge tree diff stats output. * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 ``` ## Daniel Barkalow, 2007-05-17 02:07 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705162057380.18541%40iabervon.org In-Reply-To: <7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net> ``` On Wed, 16 May 2007, Junio C Hamano wrote: > It probably would be more interesting to look at the earlier > "What's not in 1.5.2" messages, but here is the current status > of my tree on the 'next' and 'pu' front. > > 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. > > * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits > - Update local tracking refs when pushing > - Add handlers for fetch-side configuration of remotes. > - Move refspec parser from connect.c and cache.h to remote.{c,h} > - Move remote parsing into a library file out of builtin-push. > + git-update-ref: add --no-deref option for overwriting/detaching > ref AFAICT, this isn't really in my topic. Rebased too much, perhaps? I've also got one more patch ready, which moves refspec pattern matching into match_refs, for a net reduction of 50 lines and much simpler logic. I've also started making Julian Phillips' builtin-fetch use my parser, so I might have something ready before too long. -Daniel *This .sig left intentionally blank* ``` ## Junio C Hamano, 2007-05-17 04:13 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vzm44axzl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzm44axzl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Daniel Barkalow writes: > On Wed, 16 May 2007, Junio C Hamano wrote: > ... >> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits >> - Update local tracking refs when pushing >> - Add handlers for fetch-side configuration of remotes. >> - Move refspec parser from connect.c and cache.h to remote.{c,h} >> - Move remote parsing into a library file out of builtin-push. >> + git-update-ref: add --no-deref option for overwriting/detaching >> ref > > AFAICT, this isn't really in my topic. Rebased too much, perhaps? You have a new call to lock_any_ref_for_update() in the last patch in your series, whose function signature is changed by Sven's "add --no-deref". Because the latter is already scheduled for 'master' post 1.5.2, I rebased the remote series on top of it, to adjust to the change early (i.e. while my memory is still fresh). That's what This was rebased on to Sven's change to lock_any_ref_for_update(); comment was about in the earlier "[2/4] What's not in 1.5.2" message. ``` ## Daniel Barkalow, 2007-05-17 04:31 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0705170017050.18541%40iabervon.org In-Reply-To: <7vzm44axzl.fsf@assigned-by-dhcp.cox.net> ``` On Wed, 16 May 2007, Junio C Hamano wrote: > Daniel Barkalow writes: > > > On Wed, 16 May 2007, Junio C Hamano wrote: > > ... > >> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits > >> - Update local tracking refs when pushing > >> - Add handlers for fetch-side configuration of remotes. > >> - Move refspec parser from connect.c and cache.h to remote.{c,h} > >> - Move remote parsing into a library file out of builtin-push. > >> + git-update-ref: add --no-deref option for overwriting/detaching > >> ref > > > > AFAICT, this isn't really in my topic. Rebased too much, perhaps? > > You have a new call to lock_any_ref_for_update() in the last > patch in your series, whose function signature is changed by > Sven's "add --no-deref". > > Because the latter is already scheduled for 'master' post 1.5.2, > I rebased the remote series on top of it, to adjust to the > change early (i.e. while my memory is still fresh). > > That's what > > This was rebased on to Sven's change to lock_any_ref_for_update(); > > comment was about in the earlier "[2/4] What's not in 1.5.2" message. Oh, okay. I noticed the change, but missed that what it was rebased onto wasn't simply in the implicit base for the series, and also didn't realize that it was supposed to get listed that way. (I think it would be more clear to list merges of depended-on series rather than the contents of the series, when the depended-on series is also listed) -Daniel *This .sig left intentionally blank* ``` ## Junio C Hamano, 2007-05-19 05:48 Subject: What's cooking in git.git (topics) Message-ID: <7vd50xz7lq.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd50xz7lq.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vfy5wcnbg.fsf@assigned-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. ------------------------ To graduate immediately after 1.5.2, after 'maint' forks from it. * jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit + Add colour support in rebase and merge tree diff stats output. * tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit + Add --aggressive option to 'git gc' * np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits + deprecate the new loose object header format + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused * sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit + git-update-ref: add --no-deref option for overwriting/detaching ref * mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit + connect: display connection progress * dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits + Custom compression levels for objects and packs + make "repack -f" imply "pack-objects --no-reuse-object" + allow for undeltified objects not to be reused ------------------------ To be re-reviewed and then merged to 'next' after 1.5.2. * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits - Update local tracking refs when pushing - Add handlers for fetch-side configuration of remotes. - Move refspec parser from connect.c and cache.h to remote.{c,h} - Move remote parsing into a library file out of builtin-push. * dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits - git-repack --max-pack-size: add option parsing to enable feature - git-repack --max-pack-size: split packs as asked by write_{object,one}() - git-repack --max-pack-size: write_{object,one}() respect pack limit - git-repack --max-pack-size: new file statics and code restructuring - Alter sha1close() 3rd argument to request flush only ------------------------ I've queued this series only because I trust Pasky, not because I looked at the code deeply. I am not sure about this one's use of JavaScript is acceptable (I haven't looked at the code and do not even know if that is optional X-< Yes, I know, My Bad). * pb/web (Sat May 19 02:13:39 2007 +0200) 6 commits - gitweb: Clearly distinguish regexp / exact match searches - gitweb: Lift any characters restriction on searched strings - git-rev-list: Add regexp tuning options - gitweb: Remove git_blame (superseded by git_blame2) - gitweb: Extra columns in blame - gitweb: Incremental blame ------------------------ On hold. * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 ``` ## Junio C Hamano, 2007-05-23 21:46 Subject: What's cooking in git.git (topics) Message-ID: <7vodkb1adr.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vodkb1adr.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vd50xz7lq.fsf@assigned-by-dhcp.cox.net> ``` Nothing controversial has been queued since v1.5.2 yet. 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. * fl/cvsserver (Mon May 21 00:31:58 2007 +0200) 3 commits + t9400: Add some basic pserver tests + t9400: Add some more cvs update tests + t9400: Add test cases for config file handling Will push this out on 'master' by the end of this week. * dh/repack (Wed May 23 10:11:33 2007 -0700) 6 commits + pack-objects: clarification & option checks for --max-pack-size + git-repack --max-pack-size: add option parsing to enable feature + git-repack --max-pack-size: split packs as asked by write_{object,one}() + git-repack --max-pack-size: write_{object,one}() respect pack limit + git-repack --max-pack-size: new file statics and code restructuring + Alter sha1close() 3rd argument to request flush only I've commented on this series in a separate message. Looks quite clean modulo a few minor details, which was fixed up this morning. Will be in 'master' shortly. * db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits + Update local tracking refs when pushing + Add handlers for fetch-side configuration of remotes. + Move refspec parser from connect.c and cache.h to remote.{c,h} + Move remote parsing into a library file out of builtin-push. Will need to look at this once more; I do not expect too much problems with it. * jc/nodelta (Tue May 22 23:04:49 2007 -0700) 3 commits + builtin-pack-objects: remove unnecessary code for no-delta + Teach "delta" attribute to pack-objects. + pack-objects: pass fullname down to add_object_entry() I am a bit worried about potential performance penalty that can come from attribute look-up on big trees, which I've never measured so far. Independent measurement would be very much appreciated, and if it turns out to be too bad, we might want to discard this. The remainder is backburnered. * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits * jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits ``` ## Shawn O. Pearce, 2007-05-24 06:15 Subject: Re: What's cooking in git.git (topics) Message-ID: <20070524061521.GK28023@spearce.org> URL: https://gitlist.dev/e/20070524061521.GK28023%40spearce.org In-Reply-To: <7vodkb1adr.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > * db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits > + Update local tracking refs when pushing > + Add handlers for fetch-side configuration of remotes. > + Move refspec parser from connect.c and cache.h to remote.{c,h} > + Move remote parsing into a library file out of builtin-push. > > Will need to look at this once more; I do not expect too much > problems with it. I spent all day today working with this series. Lots of pushing new branches, deleting existing branches, updating existing branches across many repositories. Its an *awesome* change. I'm really happy with it. -- Shawn. ``` ## Junio C Hamano, 2007-05-29 10:11 Subject: What's cooking in git.git (topics) Message-ID: <7virac547s.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7virac547s.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vodkb1adr.fsf@assigned-by-dhcp.cox.net> ``` Tonight's 'next' is broken in that it does not seem to be able to do "git cat-file -t aba170cdb4874b72dd619e6f7bbc13c33295f83". If you add "1" to the end, it becomes the commit v1.5.2^0. Bisecting shows "Lazily open pack index files on demand" is the culprit, so I've reverted it locally (and made sure things starts working again), but I haven't got around to pushing out the results yet. I won't, until tomorrow evening. I'm a bit tired and it is getting late, so I won't comment on each of the series. I am seriously considering about merging Pasky's applypatch removal soon to 'master'. ---------------------------------------------------------------- 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/pack (Tue May 29 02:49:08 2007 -0700) 4 commits . Revert "Lazily open pack index files on demand" + Attempt to delay prepare_alt_odb during get_sha1 + Micro-optimize prepare_alt_odb + Lazily open pack index files on demand * pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits + Remove git-applypatch + git-applymbox: Remove command * mk/pack (Mon May 28 23:20:59 2007 +0200) 3 commits + builtin-pack-object: cache small deltas + git-pack-objects: cache small deltas between big objects + builtin-pack-objects: don't fail, if delta is not possible * lh/submodules (Sat May 26 15:56:40 2007 +0200) 1 commit + Add git-submodule command * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit - Enhance unpack-objects for live repo and large objects * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 ``` ## Junio C Hamano, 2007-06-02 21:09 Subject: What's cooking in git.git (topics) Message-ID: <7v6466oygl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v6466oygl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7virac547s.fsf@assigned-by-dhcp.cox.net> ``` Again, 'next' is getting quite lightweight compared to 'master'. Good time to do "war on whitespace" Marco suggested myself. 'pu' has Shawn's 'pu' from git-gui, to help people experiment with the proposed blame viewer improvements more easily. I personally like it quite a bit. ---------------------------------------------------------------- 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. * lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits + Add basic test-script for git-submodule + Add git-submodule command I find this a 'master' material already. Will merge soon. * gb/idx (Fri Jun 1 15:18:05 2007 -0400) 1 commit + Unify write_index_file functions Should graduate to 'master' by mid next week. * pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits + Remove git-applypatch + git-applymbox: Remove command Will push out to 'master' soon to see if anybody screams. * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit - Enhance unpack-objects for live repo and large objects I saw nobody other than Dana jump up and down and say we must have this, so I still parked this in 'pu' without merging it to 'next'. Maybe a time for a quick poll? * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 Backburnered. Further work on the latter, or something like that, or something based on (disused) git-merge-tree, is needed to exonerate Linus from having lied in the following part of his talk (there is a transcript at http://git.or.cz/gitwiki of his talk by the way): The source code may sometimes look complicated because we are very performance centric, I am. I really care, and sometimes to make things go really fast, you have to use more complicated algorithms than just checking one file at a time. When you are doing 22,000 file merges, you do not want to check one file at a time, you want to check the whole tree in one go and say, "Ah they are the same, I do not have to do anything". as we _DO_ currently merge one path at a time. You _could_ interpret "merge" in his message as applying millions of patches from Andrew, in which case it is true --- the cache-tree optimization in the index does help us skipping the unchanged tree recomputation. But that does not apply to a true merge, even when it is a trivial tree-level merge. ``` ## Johannes Schindelin, 2007-06-03 00:20 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0706030114540.4046%40racer.site In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sat, 2 Jun 2007, Junio C Hamano wrote: > * lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits > + Add basic test-script for git-submodule > + Add git-submodule command > > I find this a 'master' material already. Will merge soon. I agree. Even if I had not time to review it closely, from a cursory look it is clean enough. I don't expect any regressions from that. > * pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits > + Remove git-applypatch > + git-applymbox: Remove command > > Will push out to 'master' soon to see if anybody screams. Ack. > * 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 > > Backburnered. I actually like those two commits, and I always wanted to work on top of these, but my new boss keeps me away from Git :-( Will review, and try to work some more on them in the next three weeks. Don't drop them! As for the complicated source code: I cannot agree. If you have _any_ idea about what data structures are about, you will readily recognize what it is about. We _could_ be more explicit, but by a huge margin. (IMHO too many people try to chime in without _any_ clue about the difference of hash tables and binary search, and no notion of Landau's symbol. We should not necessarily try to accomodate people who are _that_ unwilling to work up their theory.) Ciao, Dscho ``` ## Shawn O. Pearce, 2007-06-03 01:10 Subject: Re: What's cooking in git.git (topics) Message-ID: <20070603011026.GB4507@spearce.org> URL: https://gitlist.dev/e/20070603011026.GB4507%40spearce.org In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > 'pu' has Shawn's 'pu' from git-gui, to help people experiment > with the proposed blame viewer improvements more easily. I > personally like it quite a bit. For what its worth, my 'pu' has the same policy as Junio's; it rebases freely and topics can come and go from it at any time. But that said, it is certainly suitable for Junio's 'pu'. :-) I just pushed an even newer version out a couple of minutes ago. Now I'm running two passes of git-blame: *) Pass 1: git-blame --incremental *) Pass 2: git-blame -M -C -C --incremental and the viewer shows them in two columns. This gives you pretty quick information about why a change exists, as you get both who moved the block to where it is, and who originally wrote it. ;-) Lots of things still to be worked on in blame, like having it keep track of what line(s) you are at or are trying to jump to. I'll try to get to that stuff tonight or tomorrow. -- Shawn. ``` ## Nicolas Pitre, 2007-06-03 21:06 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.99.0706031703140.12885%40xanadu.home In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net> ``` On Sat, 2 Jun 2007, Junio C Hamano wrote: > * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit > - Enhance unpack-objects for live repo and large objects > > I saw nobody other than Dana jump up and down and say we must > have this, so I still parked this in 'pu' without merging it to > 'next'. Maybe a time for a quick poll? I did provide a followup comment to this patch. If the concerns I raised are addressed then I won't be against such a patch. Nicolas ``` ## Dana How, 2007-06-03 21:20 Subject: Re: What's cooking in git.git (topics) Message-ID: <56b7f5510706031420j153f5f36v64e296b3f098f38@mail.gmail.com> URL: https://gitlist.dev/e/56b7f5510706031420j153f5f36v64e296b3f098f38%40mail.gmail.com In-Reply-To: ``` On 6/3/07, Nicolas Pitre wrote: > On Sat, 2 Jun 2007, Junio C Hamano wrote: > > * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit > > - Enhance unpack-objects for live repo and large objects > > > > I saw nobody other than Dana jump up and down and say we must > > have this, so I still parked this in 'pu' without merging it to > > 'next'. Maybe a time for a quick poll? > > I did provide a followup comment to this patch. If the concerns I > raised are addressed then I won't be against such a patch. Hmm, I thought only your comments about incoherency were still unaddressed and they applied only to the degunking patch, but in any case I was planning to improve both patches in similar ways. I won't be able to do this for a week or two (crunch time here). I will first review the discussion for each patch in case my memory is wrong. Thanks, -- Dana L. How danahow@gmail.com +1 650 804 5991 cell ``` ## Junio C Hamano, 2007-06-07 02:07 Subject: What's cooking in git.git (topics) Message-ID: <7vfy54tt3l.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfy54tt3l.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net> ``` Probably a few topics from the following will graduate to 'master' this weekend, but otherwise I expect that I'll be extremely slow and won't be doing much git next week. 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. "pu" also contains "pu" from git-gui as of tonight. * ar/clone (Wed Jun 6 16:39:05 2007 -0700) 1 commit - Fix clone to setup the origin if its name ends with .git This is meant to be merged to 'maint' as part of 1.5.2.2, but I am taking things slowly. * js/merge (Tue Jun 5 03:37:13 2007 +0100) 1 commit + git-merge-file: refuse to merge binary files This series needs to be cherry-picked to 'maint' at some point. * js/filter (Wed Jun 6 20:38:35 2007 +0200) 8 commits + filter-branch: also don't fail in map() if a commit cannot be mapped + filter-branch: Use rev-list arguments to specify revision ranges. + filter-branch: fix behaviour of '-k' + filter-branch: use $(($i+1)) instead of $((i+1)) + chmod +x git-filter-branch.sh + filter-branch: prevent filters from reading from stdin + t7003: make test repeatable + Add git-filter-branch Johannes & Johannes work well together ;-). Will push out to 'master' shortly. * lh/submodule (Wed Jun 6 11:13:02 2007 +0200) 2 commits + git-submodule: clone during update, not during init + git-submodule: move cloning into a separate function Will push out to 'master' shortly. * aj/pack (Sun Jun 3 20:21:41 2007 +0200) 1 commit + pack-check: Sort entries by pack offset before unpacking them. Makes "git fsck --full" go a lot faster. Will push out to 'master' shortly. * aw/cvs (Mon Jun 4 10:01:49 2007 +0100) 3 commits + cvsimport: add /HEAD reference in separate remotes more + cvsimport: update documentation to include separate remotes option + cvsimport: add support for new style remote layout Makes the ref layout consistent with git managed branches; git-svn already does this, I think. * ep/cvstag (Sun Jun 3 02:56:36 2007 -0400) 1 commit + Use git-tag in git-cvsimport Instead of handrolling a tag using lower-level mktag, this uses git-tag. * jh/tag (Mon Jun 4 02:54:56 2007 +0200) 6 commits + Add fsck_verify_ref_to_tag_object() to verify that refname matches name stored in tag object + git-mktag tests: Fix and expand the mktag tests according to the new tag object structure + Documentation/git-mktag: Document the changes in tag object structure + git-fsck: Do thorough verification of tag objects. + git-show: When showing tag objects with no tag name, show tag object's SHA1 instead of an empty string + Refactor git tag objects; make "tag" header optional; introduce new optional "keywords" header Tag refactoring. Looking good. * ml/worktree (Wed Jun 6 23:29:59 2007 +0200) 8 commits - setup_git_directory: fix segfault if repository is found in cwd - test GIT_WORK_TREE - extend rev-parse test for --is-inside-work-tree - Use new semantics of is_bare/inside_git_dir/inside_work_tree - introduce GIT_WORK_TREE to specify the work tree - test git rev-parse - rev-parse: introduce --is-bare-repository - rev-parse: document --is-inside-git-dir Allows you to have GIT_DIR environment that points at a repository at an unrelated location, and still lets you work in a working tree subdirectory by pointing its root with another environment variable. It is an intrusive set of changes. * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 1 commit - filter-branch: always export GIT_DIR if it is set This is "early integration" that depends on two other topics (GIT_WORK_TREE and filter-branch). This needs to be merged when both topics graduate to 'master'. * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit - Enhance unpack-objects for live repo and large objects * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 ``` ## Junio C Hamano, 2007-06-13 20:29 Subject: What's cooking in git.git (topics) Message-ID: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7vtztbbnsq.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <7vfy54tt3l.fsf@assigned-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. * lh/submodule (Tue Jun 12 09:05:21 2007 +0200) 5 commits + Add gitmodules(5) + git-submodule: give submodules proper names + Rename sections from "module" to "submodule" in .gitmodules + git-submodule: remember to checkout after clone + t7400: barf if git-submodule removes or replaces a file Soon to be merged to 'master' as 1.5.3 material, but still needs a trivial fix to the Documentation/gitmodules.txt, though. * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits + filter-branch: subdirectory filter needs --full-history + filter-branch: Simplify parent computation. + Teach filter-branch about subdirectory filtering + filter-branch: also don't fail in map() if a commit cannot be mapped + filter-branch: Use rev-list arguments to specify revision ranges. + filter-branch: fix behaviour of '-k' + filter-branch: use $(($i+1)) instead of $((i+1)) + chmod +x git-filter-branch.sh + filter-branch: prevent filters from reading from stdin + t7003: make test repeatable + Add git-filter-branch Soon to be merged to 'master' as 1.5.3 material, but still needs documentation, and culling of empty side branches. * fl/cvsserver (Thu Jun 7 16:57:01 2007 +0200) 1 commit + cvsserver: Add some useful commandline options To merge. * gp/branch (Sat Jun 9 12:40:35 2007 +0000) 1 commit + git-branch: cleanup config file when deleting branches To merge. * jc/remote (Sat Jun 9 11:01:23 2007 -0700) 6 commits + git-push: Update description of refspecs and add examples + remote.c: "git-push frotz" should update what matches at the source. + remote.c: fix "git push" weak match disambiguation + remote.c: minor clean-up of match_explicit() + remote.c: refactor creation of new dst ref + remote.c: refactor match_explicit_refs() To merge; this is an fix to fairly annoying breakage. * ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit + git-svn: allow dcommit to retain local merge information Hoping to be able to merge it to 'master', as it would be a big usability improvement for people who use "git to merge because SVN cannot" (without this, life ater such a merge will unfortunately be miserable). * jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits + builtin-add: simplify (and increase accuracy of) exclude handling + dir_struct: add collect_ignored option Hoping to be able to merge them to 'master', but haven't convinced myself that these changes are correct. Help is appreciated. * jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits + Extend --pretty=oneline to cover the first paragraph, + Lift 16kB limit of log message output Hoping to be able to merge them to 'master', but haven't convinced myself that these changes are correct. Help is appreciated. * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits - Quiet the output from git-init when cloning, if requested. - Add an option to quiet git-init. Undecided. I do not have anything against these two patches, as they are obviously correct. It's just the fact that nobody complained my keeping these packed on 'pu' suggests there is not much desire, and it is an extra option we need to maintain. * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) - filter-branch: always export GIT_DIR if it is set * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits - make git barf when an alias changes environment variables - setup_git_directory: fix segfault if repository is found in cwd - test GIT_WORK_TREE - extend rev-parse test for --is-inside-work-tree - Use new semantics of is_bare/inside_git_dir/inside_work_tree - introduce GIT_WORK_TREE to specify the work tree - test git rev-parse - rev-parse: introduce --is-bare-repository - rev-parse: document --is-inside-git-dir Undecided. Some people would want to have a way to have GIT_DIR point at somewhere unusual and still want to work from within a subdirectory, which is probably a valid thing to support. This is not something I would use myself, so I am mostly worried about the impact these changes may have on people who do not use this feature. ``` ## Johannes Schindelin, 2007-06-13 22:44 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0706132334060.4059%40racer.site In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com> ``` Hi, On Wed, 13 Jun 2007, Junio C Hamano wrote: > * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits Isn't that convenient? That's already the second project the two JS'es are working together... > * jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits > + Extend --pretty=oneline to cover the first paragraph, > + Lift 16kB limit of log message output > > Hoping to be able to merge them to 'master', but haven't > convinced myself that these changes are correct. Help is > appreciated. I haven't had a chance to look at the patch yet, but the intention is sound. > * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) > - filter-branch: always export GIT_DIR if it is set > * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits > - make git barf when an alias changes environment variables > - setup_git_directory: fix segfault if repository is found in cwd > - test GIT_WORK_TREE > - extend rev-parse test for --is-inside-work-tree > - Use new semantics of is_bare/inside_git_dir/inside_work_tree > - introduce GIT_WORK_TREE to specify the work tree > - test git rev-parse > - rev-parse: introduce --is-bare-repository > - rev-parse: document --is-inside-git-dir > > Undecided. Some people would want to have a way to have GIT_DIR > point at somewhere unusual and still want to work from within a > subdirectory, which is probably a valid thing to support. This > is not something I would use myself, so I am mostly worried > about the impact these changes may have on people who do not use > this feature. Yeah, it is something to worry about. As far as I am concerned, these changes are too deep for too obscure a feature. But then, I see that people need it. And I can't think of a better way to implement it. So unless somebody comes up with a nice solution, I think we should live with it, rather than let it simmer in pu. Ciao, Dscho ``` ## Linus Torvalds, 2007-06-14 03:18 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0706132013240.14121%40woody.linux-foundation.org In-Reply-To: ``` On Wed, 13 Jun 2007, Johannes Schindelin wrote: > > > * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits > > Isn't that convenient? Heh. I heard a perfect Dana Carvey "Isn't that conveeenient" in my head on that line (SNL "Church Lady" skits, in case people don't make the connection). Was that intentional, or is it just my brain that is fried? "Isn't that speecial?" > That's already the second project the two JS'es are working together... There's clearly something deeper to this notion of two-letter naming that Junio uses. I used to think it was obviously flawed, but Junio may really be onto something here.. Linus ``` ## Matthias Lederhofer, 2007-06-18 17:20 Subject: Re: What's cooking in git.git (topics) Message-ID: <20070618172044.GA1197@moooo.ath.cx> URL: https://gitlist.dev/e/20070618172044.GA1197%40moooo.ath.cx In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com> ``` Junio C Hamano wrote: > * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) > - filter-branch: always export GIT_DIR if it is set > * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits > - make git barf when an alias changes environment variables > - setup_git_directory: fix segfault if repository is found in cwd > - test GIT_WORK_TREE > - extend rev-parse test for --is-inside-work-tree > - Use new semantics of is_bare/inside_git_dir/inside_work_tree > - introduce GIT_WORK_TREE to specify the work tree > - test git rev-parse > - rev-parse: introduce --is-bare-repository > - rev-parse: document --is-inside-git-dir > > Undecided. Some people would want to have a way to have GIT_DIR > point at somewhere unusual and still want to work from within a > subdirectory, which is probably a valid thing to support. This > is not something I would use myself, so I am mostly worried > about the impact these changes may have on people who do not use > this feature. The only problem I know of up to now seems the one which happened with git-filter-branch: if GIT_DIR is set and GIT_WORK_TREE/core.worktree is set the specified working tree is used instead of cwd. So for users not using GIT_WORK_TREE/core.worktree there should be no problem. There might be problems if someone distributes scripts for git which expect the old behaviour and the user specified the worktree. OTOH the fix is to export GIT_WORK_TREE=. which does not break the script for older versions of git versions and is quite short (i.e. should not require any restructuring of the script). ``` ## Junio C Hamano, 2007-06-21 07:20 Subject: What's cooking in git.git (topics) Message-ID: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7v4pl1zsd7.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com> ``` 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. * lt/follow (Tue Jun 19 14:22:46 2007 -0700) 1 commit + Finally implement "git log --follow" Has leaks, and it won't graduate to 'master' without documentation. Also I am not convinced its handling of merges is sane. If you have an ancestry graph like this, and the commit A renames the followed path, it would show the file _before_ rename, which is very good. o-------B---A---o----o / o----C------' But the code changes pathspec globally, so when we are looking at C, it may or may not have that (before-renamed) path there. At least, the patch is small and would not affect codepath that does not use this option, so in that sense it is relatively safe change, though. * jc/oneline (Fri Jun 15 13:19:07 2007 +0100) 4 commits + pp_header(): work around possible memory corruption + Fix ALLOC_GROW off-by-one + Extend --pretty=oneline to cover the first paragraph, + Lift 16kB limit of log message output * jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits + builtin-add: simplify (and increase accuracy of) exclude handling + dir_struct: add collect_ignored option Will merge this weekend. * ns/clone (Sat Jun 16 15:26:08 2007 -0700) 1 commit + Cloning from a repo without "current branch" Will merge this weekend. * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits + filter-branch: subdirectory filter needs --full-history + filter-branch: Simplify parent computation. + Teach filter-branch about subdirectory filtering + filter-branch: also don't fail in map() if a commit cannot be mapped + filter-branch: Use rev-list arguments to specify revision ranges. + filter-branch: fix behaviour of '-k' + filter-branch: use $(($i+1)) instead of $((i+1)) + chmod +x git-filter-branch.sh + filter-branch: prevent filters from reading from stdin + t7003: make test repeatable + Add git-filter-branch Will merge this weekend. * ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit + git-svn: allow dcommit to retain local merge information Haven't heard major breakage report, so hopefully can merge by the end of the month. * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits + make git barf when an alias changes environment variables + setup_git_directory: fix segfault if repository is found in cwd + test GIT_WORK_TREE + extend rev-parse test for --is-inside-work-tree + Use new semantics of is_bare/inside_git_dir/inside_work_tree + introduce GIT_WORK_TREE to specify the work tree + test git rev-parse + rev-parse: introduce --is-bare-repository + rev-parse: document --is-inside-git-dir I've been resisting this but I think its definition of is-bare is a bit saner than what we have in 'master', and I think it is the right direction in the longer term. HOWEVER, I am not sure about the implementation and corner cases, e.g. what should it do in receive-pack? You cannot rely on user setting GIT_WORK_TREE environment -- rather, receive-pack is responsible for setting up a sane environment for other commands to work in. * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits - Quiet the output from git-init when cloning, if requested. - Add an option to quiet git-init. ``` ## Linus Torvalds, 2007-06-21 17:16 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0706211005520.3593%40woody.linux-foundation.org In-Reply-To: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com> ``` On Thu, 21 Jun 2007, Junio C Hamano wrote: > > Also I am not convinced its handling of merges is sane. If you > have an ancestry graph like this, and the commit A renames the > followed path, it would show the file _before_ rename, which is > very good. > > o-------B---A---o----o > / > o----C------' I agree. That's even what I tried to explain (but your graph is better) in my commit message, when I was talking about how it linearizes the history in "git log" order, and decides that renames happen "within that linearized" world. You can actually see an *example* of this by doing git log --stat --follow arch/i386/pci/common.c on the old historical Linux archive (the BK import one, not the bkcvs import - the latter has been linearized by bkcvs so won't show concurrent development anyway). What you get is: [ ... ] commit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad Author: Greg Kroah-Hartman Date: Mon May 6 20:18:16 2002 -0700 Move arch/i386/kernel/pci/ to arch/i386/pci/ arch/i386/{kernel => }/pci/common.c | 0 1 files changed, 0 insertions(+), 0 deletions(-) commit bbb283cca10b2d2c935ae35327620ebae07f7d80 Author: Patrick Mochel Date: Mon May 6 20:09:44 2002 -0700 Move arch/i386/kernel/pci/ to arch/i386/pci/ arch/i386/kernel/pci/common.c | 206 ----------------------------------------- 1 files changed, 0 insertions(+), 206 deletions(-) [ ... ] and this is an artifact of two _concurrent_ directory moves, and look at what "git log --follow" did: it actually found the rename (we looked at Greg's version first), but then *because* it found the rename, it is now starting to look at the *previous* name, which was arch/i386/kernel/pci/common.c and when it then sees the rename in Pat's commit, it's no longer finding that previous entry as a "new file that got created" (which triggers the rename logic), but now it finds that filename has being *removed* (because the _old_ filename really did go away - it got renamed!) This is 100% logical within that linearized history, but it's a bit surprising. But it's how "git log --follow" just works. If you want to see the real history, you need to do it with "git blame", which actually understands about merges, or with some graphical viewer that would be extended to follow renames when it notices that a filename goes away. But "git log" itself really fundamentally has no clue, and you really should see "git log" as a *linearization* thing. It linearizes the history by creating a one-dimensional streaming log. And within that linearized history, there can not be anything like "concurrent renames". Linus ``` ## Linus Torvalds, 2007-06-21 17:44 Subject: Re: What's cooking in git.git (topics) Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.98.0706211034500.3593%40woody.linux-foundation.org In-Reply-To: ``` On Thu, 21 Jun 2007, Linus Torvalds wrote: > > But "git log" itself really fundamentally has no clue, and you really > should see "git log" as a *linearization* thing. It linearizes the history > by creating a one-dimensional streaming log. And within that linearized > history, there can not be anything like "concurrent renames". Btw, just to clarify: This is absolutely not somethign unique to "--follow" and rename detection! when you do a simple "git log -p", you will very commonly see the issue of the same patch being applied twice, and if you think of the linearized "git log" output is somehow "the Truth" with a capital "T", then you'd obviously believe that the thing shows up twice in the end result. It doesn't even have to be the same patch: you can have a patch that shows up in one branch, and that *never* makes it into the end result, even though the other branch didn't "undo" it. A merge may have chosen just the one side (not necessarily due to "-s ours" or anythign like that: a merge conflict may have been resoled that way). So the individual logs of changes are not "meaningful" in that sense. Not with --follow, and not without. They are a locally linearized version of history, and as such you cannot put the world together just based on them. You need to have the bigger picture to get the end result. Does that mean that linearization is meaningless? No, obviously not. Does it mean that you *can* get confused by it? Yes, absolutely. Does rename detection add new _ways_ of getting confused? Oh, YES! The example from the kernel is a great one. I still think "git log --follow" is actually a really good thing. People will find places like this where they are confused, and maybe we'll have to teach them about the effects of linearizing their history, but especially if you come from the CVS/SVN world, your history has _always_ been linear, so git will always get that case right. And once you get used to merges, you'll start understanding why git does what git does more, and then the "git log --follow" behaviour will still perhaps not be what you might always want at any particular point in time, but it's something you can understand and deal with. And it's still hugely preferable to "file identities", which have their own (and much more fundamental) problems over merges. Linus ``` ## Junio C Hamano, 2007-06-25 09:43 Subject: What's cooking in git.git (topics) Message-ID: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7v645cz7vm.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com> ``` 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. * js/rebase (Mon Jun 25 01:11:14 2007 +0100) 2 commits + Teach rebase an interactive mode + Move the pick_author code to git-sh-setup Will merge. * rs/diff (Mon Jun 25 00:23:34 2007 +0200) 2 commits + diff: round down similarity index + diffcore-rename: don't change similarity index based on basename equality Will merge. * lt/run (Sun Jun 24 10:29:33 2007 -0700) 2 commits + Check for IO errors after running a command + Clean up internal command handling Will merge. * ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit + git-svn: allow dcommit to retain local merge information Haven't heard major breakage report, so hopefully can merge by the end of the month. * mk/svn (Fri Jun 22 11:15:03 2007 +0200) 1 commit - git-svn: honor ~/.subversion/ client cert file settings. Waiting for ACK from git-svn people. * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits + make git barf when an alias changes environment variables + setup_git_directory: fix segfault if repository is found in cwd + test GIT_WORK_TREE + extend rev-parse test for --is-inside-work-tree + Use new semantics of is_bare/inside_git_dir/inside_work_tree + introduce GIT_WORK_TREE to specify the work tree + test git rev-parse + rev-parse: introduce --is-bare-repository + rev-parse: document --is-inside-git-dir * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits + filter-branch: always export GIT_DIR if it is set I've been resisting these due to the size of the series, but I think the definition of is-bare is a bit saner than what we have in 'master', and I think it is the right direction in the longer term. HOWEVER, I am not sure about the implementation and corner cases, e.g. what should it do in receive-pack? You cannot rely on user setting GIT_WORK_TREE environment -- rather, receive-pack is responsible for setting up a sane environment for other commands to work in. * jc/quote (Sun Jun 24 15:11:24 2007 -0700) 1 commit + Add core.quotepath configuration variable. This will get rid of "Why is my UTF-8 pathnames are munged" complaints. Will wait for a while, maybe merge after 1.5.3. I believe the output from this is still readable by an unpatched git-apply, but I would want to be absolutely sure. * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits - Quiet the output from git-init when cloning, if requested. - Add an option to quiet git-init. I am not very much interested in this but I do not have any strong or otherwise feeling against it either. * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit - Enhance unpack-objects for live repo and large objects * jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits - blame: show log as it goes - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up * 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 Backburnered. ``` ## Jeffrey C. Ollie, 2007-06-25 15:47 Subject: Re: What's cooking in git.git (topics) Message-ID: <1182786420.3821.28.camel@lt21223.campus.dmacc.edu> URL: https://gitlist.dev/e/1182786420.3821.28.camel%40lt21223.campus.dmacc.edu In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com> ``` On Mon, 2007-06-25 at 02:43 -0700, Junio C Hamano wrote: > > * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits > - Quiet the output from git-init when cloning, if requested. > - Add an option to quiet git-init. > > I am not very much interested in this but I do not have any > strong or otherwise feeling against it either. It seems to me that this series is more about "DWIM" than anything. A naïve user would expect "git clone -q" to silcence _all_ non-error output. The output "Initialized empty Git repository in .git/" that you get from "git init" isn't an error... Jeff ``` ## Matthias Lederhofer, 2007-06-26 13:35 Subject: Re: What's cooking in git.git (topics) Message-ID: <20070626133548.GB11504@moooo.ath.cx> URL: https://gitlist.dev/e/20070626133548.GB11504%40moooo.ath.cx In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com> ``` Junio C Hamano wrote: > * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits > + make git barf when an alias changes environment variables > + setup_git_directory: fix segfault if repository is found in cwd > + test GIT_WORK_TREE > + extend rev-parse test for --is-inside-work-tree > + Use new semantics of is_bare/inside_git_dir/inside_work_tree > + introduce GIT_WORK_TREE to specify the work tree > + test git rev-parse > + rev-parse: introduce --is-bare-repository > + rev-parse: document --is-inside-git-dir > * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits > + filter-branch: always export GIT_DIR if it is set > > I've been resisting these due to the size of the series, but I > think the definition of is-bare is a bit saner than what we have > in 'master', and I think it is the right direction in the longer > term. HOWEVER, I am not sure about the implementation and > corner cases, e.g. what should it do in receive-pack? You > cannot rely on user setting GIT_WORK_TREE environment -- rather, > receive-pack is responsible for setting up a sane environment > for other commands to work in. Thanks. I'll have a look at receive-pack this week. Is there anything in receive-pack yet which helps to use a working tree in the hooks? Or is this something for which the behaviour of git still has to be defined? ``` ## Junio C Hamano, 2007-06-27 02:14 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7vtzsurvo1.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <20070626133548.GB11504@moooo.ath.cx> ``` Matthias Lederhofer writes: > Thanks. I'll have a look at receive-pack this week. Is there > anything in receive-pack yet which helps to use a working tree in the > hooks? Or is this something for which the behaviour of git still has > to be defined? I think the behaviour for receive-pack and the environment the hooks run in have been pretty well defined. You start in the repository (the directory $GIT_DIR), GIT_DIR is set and points at it. The issue is that the introduction of WORK_TREE enviornment and core.worktree mechanism might want to update the semantics. For example, some people seem to run checkout (or perhaps "merge") to update the associated working tree. Can they find out where the root of the working tree is (because they would want to chdir to it before saying "git checkout"), given the current environment receive-pack sets up for them? Earlier we said that people who use only GIT_DIR without GIT_WORK_TREE nor core.worktree should get exactly the same semantics with or without the WORK_TREE topic, so the above may not be an issue. ``` ## Matthias Lederhofer, 2007-06-28 20:23 Subject: Re: What's cooking in git.git (topics) Message-ID: <20070628202321.GA13263@moooo.ath.cx> URL: https://gitlist.dev/e/20070628202321.GA13263%40moooo.ath.cx In-Reply-To: <7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com> ``` Junio C Hamano wrote: > I think the behaviour for receive-pack and the environment the > hooks run in have been pretty well defined. You start in the > repository (the directory $GIT_DIR), GIT_DIR is set and points > at it. > > The issue is that the introduction of WORK_TREE enviornment and > core.worktree mechanism might want to update the semantics. For > example, some people seem to run checkout (or perhaps "merge") > to update the associated working tree. Can they find out where > the root of the working tree is (because they would want to > chdir to it before saying "git checkout"), given the current > environment receive-pack sets up for them? > > Earlier we said that people who use only GIT_DIR without > GIT_WORK_TREE nor core.worktree should get exactly the same > semantics with or without the WORK_TREE topic, so the above may > not be an issue. When GIT_WORK_TREE/core.worktree are not set the only difference with the patch series should be that cwd may be used as working tree in more cases than before. I think these are the ways git-receive-pack is executed (in normal setups): * local pushes: git_connect() unsets GIT_WORK_TREE. * ssh: the user might set GIT_WORK_TREE in his shell configuration, .ssh/environments, .ssh/authorized_keys etc. git-receive-pack is then executed with GIT_WORK_TREE set. * git-daemon: git-daemon with --enable=receive-pack allows pushing and does not unset GIT_WORK_TREE, so a git-daemon started with GIT_WORK_TREE exported will also have it exported when receive-pack is executed. I think it makes sense to unset GIT_WORK_TREE when receive-pack is started. In the first case GIT_WORK_TREE is unset already and in the latter two cases I don't think we really need to support that GIT_WORK_TREE stays exported in the hooks, it could rather happen accidentally. When doing more stuff in receive-pack old hooks might stop working break. For example receive-pack could set up GIT_WORK_TREE with a sane default value if a working tree can be found, i.e. $ export GIT_WORK_TREE=$(dirname $(pwd)) if the working tree is in the parent directory $ export GIT_WORK_TREE=$(git config core.worktree) if core.worktree is set and otherwise GIT_WORK_TREE is not exported. This way hooks can just use GIT_WORK_TREE for the working tree if they don't need anything special. ``` ## Junio C Hamano, 2007-06-29 00:02 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vmyyjmxv8.fsf@assigned-by-dhcp.pobox.com> URL: https://gitlist.dev/e/7vmyyjmxv8.fsf%40assigned-by-dhcp.pobox.com In-Reply-To: <20070628202321.GA13263@moooo.ath.cx> ``` Matthias Lederhofer writes: > When doing more stuff in receive-pack old hooks might stop working > break. > > For example receive-pack could set up GIT_WORK_TREE with a sane > default value if a working tree can be found, i.e. > $ export GIT_WORK_TREE=$(dirname $(pwd)) > if the working tree is in the parent directory > $ export GIT_WORK_TREE=$(git config core.worktree) > if core.worktree is set and otherwise GIT_WORK_TREE is not exported. > This way hooks can just use GIT_WORK_TREE for the working tree if > they don't need anything special. Your analysis looks good. Probably we can start without doing anything to see if anybody screams. ``` ## Junio C Hamano, 2007-07-02 00:16 Subject: What's cooking in git.git (topics) Message-ID: <7vd4zb3bid.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vd4zb3bid.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v645cz7vm.fsf@assigned-by-dhcp.pobox.com> ``` Here are the topics that have been cooking in 'next'. * ns/stash (Sun Jul 1 15:29:01 2007 -0700) 3 commits + git-stash: require "save" to be explicit and update documentation + Document git-stash + Add git-stash script I am hoping this would appear in 1.5.3; it would help what many people asked (and later we probably would want to invoke it in git-merge to have an option to automated the process further). * js/rebase (Mon Jun 25 18:59:43 2007 +0100) 6 commits + Teach rebase -i about --preserve-merges + rebase -i: provide reasonable reflog for the rebased branch + rebase -i: several cleanups + ignore git-rebase--interactive + Teach rebase an interactive mode + Move the pick_author code to git-sh-setup Will merge. * jc/diffcore (Thu Jun 28 23:14:13 2007 -0700) 4 commits + diffcore-delta.c: Ignore CR in CRLF for text files + diffcore-delta.c: update the comment on the algorithm. + diffcore_filespec: add is_binary + diffcore_count_changes: pass diffcore_filespec Will merge; although the CRLF stuff itself would probably not help anybody in real-life, the change in the interface to allow further enhancement would be a good thing. * ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit + git-svn: allow dcommit to retain local merge information Any negative feedback on this? Otherwise will merge. * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits + Quiet the output from git-init when cloning, if requested. + Add an option to quiet git-init. Opinions? ``` ## Junio C Hamano, 2007-07-28 08:47 Subject: Re: What's cooking in git.git (topics) Message-ID: <7vtzrosynb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vtzrosynb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7vd4zb3bid.fsf@assigned-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. * bs/lock (Thu Jul 26 22:13:12 2007 -0700) 3 commits + Add test for symlinked configuration file updates. + use lockfile.c routines in git_commit_set_multivar() + fully resolve symlinks when creating lockfiles I would like to have this in 1.5.3, as it appears to be obviously and trivially correct, and resolves real issues we saw reported on the list and #git channel. * js/worktree (Thu Jul 26 07:32:49 2007 +0100) 5 commits . With work-trees possibly inside git-dir, be more generous . Add test for sanitized work-tree behaviour . Clean up work-tree handling . Add functions get_relative_cwd() and is_inside_dir() . Add is_absolute_path(), make_absolute_path() and normalize_path() Dscho is dead set fixing broken WORK_TREE series that is already in 'master'. The series so far unfortunately has still been untestable state, but the basic approach of cleaning up seems sound, and knowing him I am reasonably confident that this will be at least 'next' quality soon enough. * cr/tag (Mon Jul 23 12:58:27 2007 +0100) 5 commits + Teach "git stripspace" the --strip-comments option + Make verify-tag a builtin. + builtin-tag.c: Fix two memory leaks and minor notation changes. + launch_editor(): Heed GIT_EDITOR and core.editor settings + Make git tag a builtin. Carlos did a good job at very carefully crafting this series, under Dscho's supervision. Judging from the quality of the series, I would personally love to have this in 1.5.3. But as a matter of principle, replacing an implementation with a totally different one post -rc is not something I'd want to make a precedent of. This will be merged early after 1.5.3. * mc/logsize (Fri Jul 20 20:15:13 2007 +0200) 1 commit - Add --log-size to git log to print message size This adds a new option --log-size that is to primarily help loading "git log --pretty=raw" output by qgit. It is probably not useful with any other combination of options, with "-p", "--stat", "--pretty={email,oneline}", etc., as the "length indicator" is at the wrong place (it should be the first line of each record, not on the second line), but it is good enough for helping qgit. This (or improvement of it if one comes up) will most likely to be in 'master' after 1.5.3. * js/recursive-fix (Tue Jul 17 18:14:48 2007 +0100) 2 commits . Add tests for cherry-pick d/f conflict which should be none . merge-recursive: sometimes, d/f conflict is not an issue This is to paper over a design bug in merge-recursive d/f conflict checking code. I'd expect we would want to rethink the whole merge datapath after 1.5.3 and prefer to leave this series out of 1.5.3. * jc/blame (Thu Jul 12 10:49:08 2007 -0700) 4 commits - git-log --follow? - git-blame: optimize get_origin() from linear search to hash- lookup. - git-blame: pass "struct scoreboard *" pointers around. - blame: lift structure definitions up The tip of this is Linus's "follow single file". I will cherry-pick and put it in 'next' after 1.5.3. * db/fetch-pack (Tue Jul 10 00:38:42 2007 -0400) 1 commit . Make fetch-pack a builtin with an internal API Daniel has a few more patches in this series we have already seen on the list; I'll ask him to rebase/repost after 1.5.3. * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits . rebase: allow starting from a dirty tree. . stash: implement "stash create" I did this just for fun, but come to think of it, the user can run git-stash himself when git-rebase complains the working tree is dirty anyway, so this may probably not so useful. * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit . Enhance unpack-objects for live repo and large objects This is to deliberately avoid placing large blob to packfile. Nico had objections on this type of special purpose hacks, and I agree with him. * 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 ```