# What's in git.git 6 messages from 2006-06-18 to 2006-06-19. Participants: Junio C Hamano, Johannes Schindelin, Petr Baudis. Thread: https://gitlist.dev/t/4548 ## Junio C Hamano, 2006-06-18 00:48 Subject: What's in git.git Message-ID: <7vpsh75lx1.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vpsh75lx1.fsf%40assigned-by-dhcp.cox.net ``` It's been a while since I've done v1.4.0, and I haven't fully caught up with the list traffic yet, but here is the current status. I'm planning to manage the v1.4.X series a bit differently during this round. So far, they were supposed to be fix-only on top of v1.4.0, but people who follow the maintenance series (including the binary packages) missed out on too many good stuff that happen on the "master" branch. Also presses like lwn.net tended to cover the maint series which gets stale pretty quickly. So I'll first merge only post-1.4.0 fixes and additions to the "master" branch until we are comfortable with its shape, tag it as 1.4.1, and continue. Essentially, "next" and "pu" will become the playpens (the first being "not proven but fixable" changes, the latter being "under consideration, but will not be missed if dropped" changes) their names originally implied, and "master" will be what "maint" was supposed to be -- fixes and good changes. The old fixes-only maintenance on "maint" branch will be halted for now -- except maybe when some urgent fixes are needed, I might do 1.4.X.Y like the kernel folks do. * The 'master' branch has these since v1.4.0 Dennis Stosberg: Make t4101-apply-nonl bring along its patches Eric W. Biederman: Don't parse any headers in the real body of an email message. Eric Wong: git-svn: t0000: add -f flag to checkout git-svn: fix handling of filenames with embedded '@' git-svn: eol_cp corner-case fixes git-svn: restore original LC_ALL setting (or unset) for commit git-svn: don't allow commit if svn tree is not current git-svn: support -C passing to git-diff-tree git-svn: --branch-all-refs / -B support git-svn: optimize --branch and --branch-all-ref git-svn: support manually placed initial trees from fetch git-svn: Move all git-svn-related paths into $GIT_DIR/svn git-svn: minor cleanups, extra error-checking git-svn: add --repack and --repack-flags= options git-svn: add --shared and --template= options to pass to init-db git-svn: add some functionality to better support branches in svn git-svn: add UTF-8 message test git-svn: add 'log' command, a facsimile of basic `svn log' git-svn: add support for Perl SVN::* libraries git-svn: make the $GIT_DIR/svn/*/revs directory obsolete git-svn: avoid creating some small files git-svn: fix several small bugs, enable branch optimization git-svn: Eliminate temp file usage in libsvn_get_file() git-svn: bugfix and optimize the 'log' command git-svn: tests no longer fail if LC_ALL is not a UTF-8 locale git-svn: svn (command-line) 1.0.x compatibility git-svn: rebuild convenience and bugfixes Florian Forster: gitweb: Adding a `blame' interface. gitweb: Make the `blame' interface in gitweb optional. Fredrik Kuivinen: blame: Add --time to produce raw timestamps Jakub Narebski: Update gitweb README: gitweb is now included with git Junio C Hamano: gitk: rereadrefs needs listrefs fix git alias t5100: mailinfo and mailsplit tests. mailinfo: ignore blanks after in-body headers. Linus Torvalds: gitweb.cgi history not shown Martin Langhoff: cvsimport: ignore CVSPS_NO_BRANCH and impossible branches cvsimport: complete the cvsps run before starting the import cvsimport: keep one index per branch during import Peter Eriksen: Implement safe_strncpy() as strlcpy() and use it more. Sean Estabrooks: Add a "--notags" option for git-p4import. Sven Verdoolaege: git-cvsexportcommit.perl: fix typo * The 'next' branch, in addition, has these. Johannes Schindelin: diff options: add --color I would say this would be fine as is -- diff being quite important part of the system, I just wanted to cook it for a while. Junio C Hamano: read-tree: --prefix=/ option. write-tree: --prefix= read-tree: reorganize bind_merge code. I'll have them graduate to "master" soon, as they do not seem to hurt anybody. fetch-pack: give up after getting too many "ack continue" Maybe merge to "master" and see what it breaks. shared repository: optionally allow reading to "others". This should be ready. I just want to do another round of check. Paul Eggert: date.c: improve guess between timezone offset and year. This is more for the entertainment value than for practical value ;-). * The 'pu' branch, in addition, has these. Johannes Schindelin: Read configuration also from ~/.gitconfig repo-config: learn the flag "--no-local" I see Pasky has proposed another config change (this time, not "also from" but "alternatively from") -- I am not sure which one is more appropriate. Waiting for Johannes's response to Pasky's message and hoping the list can agree on a single patch series to apply to "next". Teach diff about -b and -w flags Yakov Lerner: auto-detect changed prefix and/or changed build flags I think this is fine, except that test-prefix-change target is probably unneeded as Martin noticed. ``` ## Johannes Schindelin, 2006-06-18 12:26 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0606181417090.26803%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vpsh75lx1.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sat, 17 Jun 2006, Junio C Hamano wrote: > Read configuration also from ~/.gitconfig > repo-config: learn the flag "--no-local" > > I see Pasky has proposed another config change (this time, > not "also from" but "alternatively from") -- I am not sure > which one is more appropriate. Waiting for Johannes's > response to Pasky's message and hoping the list can agree on > a single patch series to apply to "next". There is one thing I don't like about Pasky's approach: You can change the config file name to whatever you like, even if no program will read it. That is why I decided to have a flag instead of an option: to prevent pilot-errors. But hey, that is just me. I cobbled together a patch, which turned out to be rather messy, introducing "--config-file " to git-repo-config. If people are interested, I'll clean it up and post it. But then, if you already know you want to use another config file, you are probably better of just exporting GIT_CONFIG_FILE and be done with it. Note that this issue is orthogonal to the need for a user-specific config file. I still think that this one should go in. Ciao, Dscho ``` ## Petr Baudis, 2006-06-18 13:08 Subject: Re: What's in git.git Message-ID: <20060618130837.GN2609@pasky.or.cz> URL: https://gitlist.dev/e/20060618130837.GN2609%40pasky.or.cz In-Reply-To: ``` Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter where Johannes Schindelin said that... > There is one thing I don't like about Pasky's approach: You can change the > config file name to whatever you like, even if no program will read it. > That is why I decided to have a flag instead of an option: to prevent > pilot-errors. I'm lost here, admittelly not getting your argument. :-( > I cobbled together a patch, which turned out to be rather messy, > introducing "--config-file " to git-repo-config. If people are > interested, I'll clean it up and post it. But then, if you already know > you want to use another config file, you are probably better of just > exporting GIT_CONFIG_FILE and be done with it. $GIT_CONFIG_FILE feels nicer since any other git tool can use it as well, it's not git-repo-config-specific. But the current intent indeed is to simply override the location for git-repo-config, thus for the current purposes if we will have --config-file instead of GIT_CONFIG_FILE, I will not weep; whatever does the job. > Note that this issue is orthogonal to the need for a user-specific config > file. I still think that this one should go in. I agree as well. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ A person is just about as big as the things that make them angry. ``` ## Johannes Schindelin, 2006-06-18 18:43 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0606182040410.26803%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <20060618130837.GN2609@pasky.or.cz> ``` Hi, On Sun, 18 Jun 2006, Petr Baudis wrote: > Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter > where Johannes Schindelin said that... > > There is one thing I don't like about Pasky's approach: You can change the > > config file name to whatever you like, even if no program will read it. > > That is why I decided to have a flag instead of an option: to prevent > > pilot-errors. > > I'm lost here, admittelly not getting your argument. :-( Okay, the point I was driving at: GIT_CONFIG_FILE=~/.gitrc git repo-config blabla.blibli bloblo _will_ succeed, but to the user it will be non-obvious that the git commands do not pick up on it (because ~/.gitconfig is read instead of ~/.gitrc), whereas git repo-config --user blabla.blibli bloblo is pretty obvious, and _has_ the intended effect. > > I cobbled together a patch, which turned out to be rather messy, > > introducing "--config-file " to git-repo-config. If people are > > interested, I'll clean it up and post it. But then, if you already know > > you want to use another config file, you are probably better of just > > exporting GIT_CONFIG_FILE and be done with it. > > $GIT_CONFIG_FILE feels nicer since any other git tool can use it as > well, it's not git-repo-config-specific. But the current intent indeed > is to simply override the location for git-repo-config, thus for the > current purposes if we will have --config-file instead of > GIT_CONFIG_FILE, I will not weep; whatever does the job. Yes, that is true. Forget about my --config-file patch, please. > > Note that this issue is orthogonal to the need for a user-specific config > > file. I still think that this one should go in. > > I agree as well. Ciao, Dscho ``` ## Junio C Hamano, 2006-06-19 07:34 Subject: Re: What's in git.git Message-ID: <7vy7vta9ae.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vy7vta9ae.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060618130837.GN2609@pasky.or.cz> ``` Petr Baudis writes: > Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter > where Johannes Schindelin said that... > >> Note that this issue is orthogonal to the need for a user-specific config >> file. I still think that this one should go in. > > I agree as well. OK, let's have it then. Johannes, this makes your earlier ~/.gitconfig and --no-local patches no longer applicable, so I'd drop them from "pu" for now. But I suspect we do want to have per user configuration that is used as a fallback for per repo configuration, right? I think we should mark what we have in "next" tonight, plus a few others, as v1.4.1 sometime this coming week and continue from there. ``` ## Johannes Schindelin, 2006-06-19 08:35 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0606191034350.26329%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vy7vta9ae.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Mon, 19 Jun 2006, Junio C Hamano wrote: > Petr Baudis writes: > > > Dear diary, on Sun, Jun 18, 2006 at 02:26:14PM CEST, I got a letter > > where Johannes Schindelin said that... > > > >> Note that this issue is orthogonal to the need for a user-specific config > >> file. I still think that this one should go in. > > > > I agree as well. > > OK, let's have it then. > > Johannes, this makes your earlier ~/.gitconfig and --no-local > patches no longer applicable, so I'd drop them from "pu" for > now. But I suspect we do want to have per user configuration > that is used as a fallback for per repo configuration, right? I'll redo the patches, then. Ciao, Dscho ```