* Re: (class=ham score=-4.96032) memmem.c improvement
From: Christian Thaeter @ 2007-12-01 2:30 UTC (permalink / raw)
To: Tor Myklebust; +Cc: libc-alpha, git
In-Reply-To: <Pine.LNX.4.64.0711301954370.9426@caffeine.csclub.uwaterloo.ca>
Tor Myklebust wrote:
> On Sat, 1 Dec 2007, Christian Thaeter wrote:
>
>> Short story, 'memmem()' is a gnuish, nonstandard function. I wanted to
>> provide a generic fallback in some code. So, lets borrow it somewhere
>> else:
>>
>> First looking at git's compat/memmem.c which I found was suboptimal
>> with roughly O(M*N) performance (albeit ok for that case since it was
>> just a generic fallback).
>>
>> Well, second taking a look at glibc's source surprised me, there is
>> the same code as in git. I somewhat expected a faster implementation
>> from a generic C library.
>
> I don't think anybody involved with glibc really feels like having
> strstr() (or memmem(), for that matter) go fast. (The grounds I heard
> were that "applications requiring large searches are more likely to have
> own fast string search implementations.')
>
>> That thought and done, the code is attached to this mail. The
>> algorithm is similar to the Rabin/Karp method for string searches but
>> uses a weaker and simpler additive rolling hash.
>
> There are rolling hashes based on arithmetic in fields of order 2^k.
> These can typically be computed using a bunch of bit-shifts and
> additions; have you tried using one? There are lots of irreducible
> polynomials over Z_2 of degree k, so you can even fall back to a
> different one every few false positives.
>
>> The result is still somewhat like O(M+N) for most cases
>
> I don't think you get linear performance in the average case. (But I do
> think you shave a factor of 256 off of the quadratic term. The same
> algorithm, where your hash function is the population count, gives a
> collision between two random strings of length m with probability
> sum_(i=0)^m (m choose i)^2 / 4^m, which grows like sqrt(m). Your
> algorithm helps this by a factor of 256.)
...
>
>> (There may be corner cases where it not that good, but its really hard
>> to imagine those).
>
> The needle "1100110011001100...1100" and the haystack
> "10101010101010...10" will produce quite a few false matches with your
> hash function (simply because every substring of the haystack of the
> appropriate length has the same hash as your needle). (Making the
> needle "1010101010...101100" makes it even worse.)
I am fully aware that this is not the best possible search algorithm. It
is considerably better than the actual one for 'common' data. Having a
string with few symbols or other corner cases needs an algorithm better
suited for that task. But well, this was just reaching a low hanging
fruit. I just wanted to share it because it is better than the algorithm
which is in git and glibc, feel free to submit a even better one or keep
the old one, whatever. For me it suffices and I won't put more efforts
into improving or lobbying it, its just not worth it.
Christian
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Shawn O. Pearce @ 2007-12-01 2:35 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20071130175018.GB30048@efreet.light.src>
Jan Hudec <bulb@ucw.cz> wrote:
> Nevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting
> it in python nor any other language would probably help it in any way.
UNIX (really X11) users think git-gui looks like cr*p on their
systems as Tk draws with 1980s widgets, not 2007 style widgets.
They have every right to complain about the look and feel of the
application, its utter crap. Tk 8.5's tiles extension may help
that, but I haven't tried.
On Windows 2000/XP and Mac OS X I think I've gotten git-gui to
(almost) fit into the rest of the desktop. It fits into the Windows
UI better than it does Mac OS X, there are still some rough edges
where it is really obvious its not a native Mac OS X application.
On all platforms Tk has some "features" that are less than desirable.
For example it has been an absolute nightmare to get split pane
divider things to work on all systems. I can't tell you how many
days I spent just getting the main window to not react stupidly
on each system. And it *still* doesn't act right everywhere.
Sometimes if you resize the window the status bar on the bottom
disappears and Tk just clips it right out of the UI (no, I didn't
ask it to do that, Tk has bugs).
Building context sensitive menus isn't fun. Managing some data
structures in Tcl isn't fun. The list of why I'm currently unhappy
with Tcl/Tk for git-gui is actually pretty long.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0711281810410.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:
>
>> The comment is clearly not clear enough. Maybe this?
>>
>> + if (!work_tree_env) {
>> + retval = set_work_tree(gitdirenv);
>> + /* config may override worktree (see
>> set_work_tree comment) */
>> + check_repository_format();
>> + return retval;
>> + }
>
> Perfect. Please make it so, and add my ACK.
Looks sensible, but can this be accompanied with a trivial test to
demonstrate the existing breakage?
^ permalink raw reply
* Re: [PATCH] Mention that git-rm can be an appropriate resolution as well as git-add.
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <11958251302874-git-send-email-dsymonds@gmail.com>
David Symonds <dsymonds@gmail.com> writes:
> Especially when using git-cherry-pick, removing files that are unmerged can be
> a logical action. This patch merely changes the informative text to be less
> confusing.
>
> Signed-off-by: David Symonds <dsymonds@gmail.com>
This would be a good wording change; I'll munge this for 'next'.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: the commitdiff is very commonly used, it's needed on search page, too
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Denis Cheng; +Cc: git, dengxw, jnareb, pasky
In-Reply-To: <1196080926-5962-1-git-send-email-crquan@gmail.com>
I'll queue this to my tree but will drop if I hear objections from
gitweb people CC'ed over the weekend.
^ permalink raw reply
* Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Eyvind Bernhardsen, Nicolas Pitre, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0711301207020.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Since we plan to move the dash-form (git-<whatever>) into an execdir, it
> make sense to prepare our git protocol users for it.
>
> Noticed by Eyvind Bernhardsen.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Fri, 30 Nov 2007, Eyvind Bernhardsen wrote:
>
> > - When pushing to my system over ssh, git-receive-pack and
> > git-upload-pack are expected to be in $PATH. I resolved the
> > problem by putting symlinks in /usr/local/bin.
>
> How about this? (I only compile-tested it...)
I only eyeball-tested it and looks Okay, but that does not assure us
much ;-). Is this change easy to test using local transport?
^ permalink raw reply
* [PATCH] Run the specified perl in Documentation/
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863auuoy96.fsf@blue.stonehenge.com>
Makefile uses $(PERL_PATH) but Documentation/Makefile uses "perl"; that
means the two Makefiles can use two different Perl installations.
Teach Documentation/Makefile to use PERL_PATH that is exported from the
toplevel Makefile, and give a sane fallback for people who run "make"
from Documentation directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Haven't tested this at all; please Ack or report breakage.
Documentation/Makefile | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index d886641..8b19130 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -45,6 +45,9 @@ infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
INSTALL_INFO=install-info
DOCBOOK2X_TEXI=docbook2x-texi
+ifndef PERL_PATH
+ PERL_PATH = /usr/bin/perl
+endif
-include ../config.mak.autogen
-include ../config.mak
@@ -105,7 +108,7 @@ install-info: info
#
doc.dep : $(wildcard *.txt) build-docdep.perl
$(RM) $@+ $@
- perl ./build-docdep.perl >$@+
+ $(PERL_PATH) ./build-docdep.perl >$@+
mv $@+ $@
-include doc.dep
@@ -124,7 +127,7 @@ $(cmds_txt): cmd-list.made
cmd-list.made: cmd-list.perl $(MAN1_TXT)
$(RM) $@
- perl ./cmd-list.perl
+ $(PERL_PATH) ./cmd-list.perl
date >$@
git.7 git.html: git.txt
@@ -161,7 +164,7 @@ user-manual.html: user-manual.xml
git.info: user-manual.xml
$(RM) $@ $*.texi $*.texi+
$(DOCBOOK2X_TEXI) user-manual.xml --to-stdout >$*.texi+
- perl fix-texi.perl <$*.texi+ >$*.texi
+ $(PERL_PATH) fix-texi.perl <$*.texi+ >$*.texi
$(MAKEINFO) --no-split $*.texi
$(RM) $*.texi $*.texi+
^ permalink raw reply related
* Re: [PATCH] cvsimport: fix usage of cvsimport.module
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Jeff King; +Cc: Emanuele Giaquinta, git
In-Reply-To: <20071130222212.GA30037@coredump.intra.peff.net>
Thanks; will apply to 'maint' along with your earlier fixes.
^ permalink raw reply
* Re: [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Jeff King; +Cc: git list
In-Reply-To: <20071128190439.GA11396@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It would be nice to have a "git config --colorbool" option, but it has
> the unfortunate problem that the stdout of "git config" is piped back to
> the caller, so the isatty check is meaningless (and the "pager in use"
> is similarly tricky). Perhaps it should go in Git.pm, so it at least
> only needs to be written once.
About the isatty(3) check, you do not have to use the stdout to report
the result, though. IOW, you could use the exit code from the command.
^ permalink raw reply
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, dzwell, peff, Matthieu.Moy
In-Reply-To: <1196337638-45972-1-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> A "hidden" feature is that any string can be entered, and an anchored
> regex search is used to find the first matching option.
I'd run s/the first/the uniquely/ here.
When list_and_choose() function is letting you choose more than one
items, its prompt becomes ">> ", instead of "> " that is used for a
singleton choice. To that prompt, you can say "3-7" (Add these 5 items
to the choice), "*" (I want all of them), "-2-4" (exclude 2 and 3 and 4
from the set I have chosen so far). These are also "hidden", and need
to be documented, but that would be a separate patch.
> +# given a prefix/remainder tuple return a string with the prefix highlighted
> +# for now use square brackets; later might use ANSI colors (underline, bold)
> +sub highlight_prefix {
> + my $prefix = shift;
> + my $remainder = shift;
> + $prefix ? "[$prefix]$remainder" : $remainder;
> +}
I'd rewrite the last line to:
return (defined $prefix) ? "[$prefix]$remainder" : $remainder;
just in case the unique prefix is "0". Otherwise you would lose the
first letter from "00ReadMe" and show remainder "0ReadMe" alone.
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-12-01 2:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071130015716.GA15224@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I have always been a bit confused about diffcore-break, so I am probably
> misunderstanding what you mean. But are you saying that
> diffcore-break.c:should_break should return 1 for typechanges?
What I had in mind was to do something like that in spirit, but instead
break such a filepair inside diffcore-rename (iow, even when the user
did not say -B) early on.
But after re-reading your patch and the surrounding code, that is
more or less what you are doing (without actually recording the extra
broken pair to be merged back later).
If we did the "automatic break of typechange" early, instead of your
patch, when we come to the register_rename_src() loop, one half of the
broken pair (i.e. "create a new symlink here") will be processed
in this part of the loop:
if (!DIFF_FILE_VALID(p->one)) {
if (!DIFF_FILE_VALID(p->two))
continue; /* unmerged */
else if (options->single_follow &&
strcmp(options->single_follow, p->two->path))
continue; /* not interested */
else
locate_rename_dst(p->two, 1);
}
and rename_dst is registered here. The other half (i.e. "remove the
regular file") will be caught by this part in the loop:
else if (!DIFF_FILE_VALID(p->two)) {
/*
* If the source is a broken "delete", and
* they did not really want to get broken,
* that means the source actually stays.
* So we increment the "rename_used" score
* by one, to indicate ourselves as a user
*/
if (p->broken_pair && !p->score)
p->one->rename_used++;
register_rename_src(p->one, p->score);
}
to register a source candidate.
Instead your patch does that with a single:
+ else if (DIFF_PAIR_TYPE_CHANGED(p)) {
+ p->one->rename_used++;
+ register_rename_src(p->one, p->score);
+ }
which is essentially doing the same thing but only for the "remove the
regular file" half. One has to wonder how the lack of handling the
other half affects the outcome and still produce a result more intuitive
than the current code.
In your test case, the "new" symlink won't have any similar symlink that
is removed from the preimage, so registering it as a rename destination
would not make a difference (it will say "no match found, so create this
as usual"), but I am not convinced if that would work well in general.
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Junio C Hamano @ 2007-12-01 2:37 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <7F81126E-5A76-40CA-94BF-82B46C57AFF6@mit.edu>
Michael Witten <mfwitten@MIT.EDU> writes:
>> I gave only a very cursory look; looks Ok to me. This makes me wonder
>> if post-update wants to run as well.
>
> Seems like post-receive is supposed to supersede post-update anyhow,
> so might as well leave post-update out at this point?
I'll queue your patch, but I think it should be enhanced to support
post-update for consistency. I do not think anybody said anything about
deprecating let alone dropping support for post-update so far.
When we talk about deprecation and later removal of post-update hook, we
should drop that additional support from cvsserver and receive-pack at
the same time, but not before that.
^ permalink raw reply
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Junio C Hamano @ 2007-12-01 2:37 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, francois
In-Reply-To: <47464A90.4030509@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Junio C Hamano wrote:
>>> The http_proxy / HTTPS_PROXY variables used by curl to control
>>> proxying may not be suitable for git. Allow the user to override them
>>> in the configuration file.
>>> ---
>>> In particular, privoxy will block directories called /ad/ ... d'oh!
>>> +++ b/Documentation/config.txt
>>> +http.proxy::
>>> + Override the HTTP proxy, normally configured using the 'http_proxy'
>>> + environment variable (see gitlink:curl[1]).
>>
>> This may work around the issue you cited, but it makes me wonder
>> if it is a road to insanity. Does the curl library expect that
>> (1) each and every HTTP talking application that uses the
>> library offer this kind of knob for its users to tweak, and (2)
>> users set the knob for each and every one of such application?
>
> This is true. However I still think that it is a useful feature for
> many users, with few side effects. If nothing else the bit on the man
> page will prompt them to think, "oh, I should set that in the environment".
>
>> I would say if privoxy cannot be tweaked to allow /ad/ in chosen
>> context (e.g. /ad/ in general is rejected but /objects/ad/ is
>> Ok), that is what needs to be fixed.
>> Or it would be the use of such a broken proxy by the user. That
>> can be fixed and much easily.
>
> Yes - but consider the dilemma of the user. They've apt-get installed
> this privoxy thing and figured out how to set their applications to use
> it. Now, it doesn't work and they think it is the proxy in the way, and
> they've no idea that they might be able to reconfigure it. This way
> they can tell git to bypass it.
>
> I don't know, I see your point and pretty much agree with it. It just
> seems like something that might come in handy (as well as be another
> vector for something you need to check when you get HTTP fetch issues -
> so maybe a command-line option would be better).
>
> Actually something that would really have helped is more documentation
> of the various GIT_CURL_* environment variables available for debugging.
Having thought about this a bit more, I changed my mind. From the
beginning, I did not mind adding a dozen or so lines if the change helps
the user. I was not _fundamentally_ opposed to your patch.
However.
There may be other environment variables that the users may want to set
differently when running git from the settings they use in their
interactive sessions. We have precedentsto support such situations in
the form of git-specific environment variables (e.g. GIT_EDITOR and
GIT_PAGER). These might have been a road to insanity already, and what
we should have done may be to introduce multivalued core.environment
variables in $HOME/.gitconfig, like so:
[core.environment]
EDITOR = vim
PAGER = less
without introducing GIT_foo environment variables. We can then change
the git potty[*1*] start-up sequence to add them to the enviornment. But
this is a bit like water under the bridge now.
While that approach could work for environment variables that apply
globally to any and all git sessions the user may run, I suspect it
would not work well for things like http_proxy. If we really wanted to
help users, I think it should be tied to which remote we are going to,
just like we made git-send-email to use different mailpath depending on
which project you are communicating with.
In that sense, I think http.proxy configuration variable does not go far
enough, even though it might be a step in the right direction. Perhaps
use your configuration variable http.proxy (or "core.environment") to
define the global default, with remote.$name.httpproxy to override it?
[Footnote]
*1* git(7) calls "git" itself as "git potty". Is this word still used?
I also notice that Andreas's name is misspelled there.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-12-01 2:37 UTC (permalink / raw)
To: Jeff King
Cc: Andreas Ericsson, Nicolas Pitre, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130212500.GB25946@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I can, of course, always make my own hardlinks (which is really the same
> thing, except the "trick" is slightly harder to perform and perhaps less
> socially acceptable; OTOH, if such a trick is common, perhaps it means
> taking away the dash forms wasn't such a good idea after all).
>
>> Newbie: Stupid inconsistency. Who suggested that?
>
> Jeff [runs git-blame]: It must have been Junio! :)
You found a bug in git-blame, then ;-). I think it should report Jeff.
As Windows ports need to have their own difference _anyway_, I
personally do not think it is a big deal if the Makefile I ship
continues to install the dashed form in gitexecdir, and Windows ports
omit the hardlinks if they feel copies are wasteful.
However, that would introduce hard-to-track platform dependent bugs
(e.g. "git-receive-pack" is asked for by "git-send-pack", but the other
side does not have such a program anywhere). So my preference at this
point is to move things out of PATH first (without removing the
hardlinks), deal with possible fallout from that move.
And after things stablize, discuss to either remove the hardlinks from
all installations, or to keep them in all installations. I do not think
"it's this way here but that way there" is a good thing in general.
We do have "git-foo.exe" vs "git-foo" difference and there are some
existing code (most notably, help.c::list_commands_in_dir()) that need
to be aware of it. Let's try not to make things any worse.
^ permalink raw reply
* Re: To push into a non-bare repository, or not to push into it...
From: Junio C Hamano @ 2007-12-01 2:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711290122440.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> how about resolving this recurring subject of discussion by introducing a
> config variable, say "branch.allowPushingIntoHEAD". We'd teach git-init
> to set it to "false", and receive-pack would refuse to update HEAD if it
> is "false", _unless_ core.bare = true.
>
> Of course, we would default the value to "false" to leave existing setups
> functional.
Perhaps that could be a reasonable compromise, except that it does not
feel right to assume that new repositories are used by new users.
People who have been been trained to expect "git push" to checked out
branches always work (and they know "git reset --hard" or have
equivalent post-update hook) will wonder why their push into a new clone
does not work while their push into existing ones does.
But with a good diagnosis to pushers when receive-pack refuses a push
for this reason, I do not think that should be too much of a problem.
Upon REF_STATUS_REMOTE_REJECT, the message on "ng " line will be given
by send-pack to the pusher, so the infrastructure to do so is already
there, I think. We need to utilize it when we implement your
suggestion.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-12-01 2:37 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pfakr4j.fsf@gitster.siamese.dyndns.org>
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.
----------------------------------------------------------------
[Graduated to 'master']
* jk/maint-cvsimport-fix (Wed Nov 28 13:56:28 2007 -0500)
----------------------------------------------------------------
[New Topics]
* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
- Start preparing the API documents.
The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability. Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.
This currently consists of mostly stubs, although I wrote about a few
topics as examples.
* js/fast-export (Sun Nov 25 22:37:20 2007 +0100) 1 commit
- Add 'git fast-export', the sister of 'git fast-import'
This needs something like 9e42d6a1c53dadd409fab11cc76e0eba9ec15365
(sha1_file.c: Fix size_t related printf format warnings) to compile, I
think, but I haven't tried to fix it (parked in pu)
* js/pull-rebase (Wed Nov 28 13:11:07 2007 +0000) 1 commit
+ Teach 'git pull' about --rebase
Resurrected from an old thread (thanks, Dscho and Nana for reminding).
* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
+ Support builtin aliases
Cute hack. I'd like to have "git less" here.
* wc/rebase-insn (Sat Nov 24 00:38:50 2007 +1100) 2 commits
+ Mention that git-rm can be an appropriate resolution as well as
git-add.
+ revert/cherry-pick: Allow overriding the help text by the calling
Porcelain
Patches from Wincent and David Symonds. They both improve the help
message upon conflicts.
* js/prune-expire (Thu Nov 29 20:59:55 2007 +0000) 1 commit
+ Add "--expire <time>" option to 'git prune'
This would help making unmonitored pruning jobs safer. The expiration
does not kick in unless you explicitly ask, which is a suitable default
for interactive session where the users who run "git prune" knows what
they are doing.
* ew/svn (Thu Nov 22 13:44:42 2007 +0000) 4 commits
- git-svn: add support for pulling author from From: and Signed-off-
by:
- git-svn: add a show-externals command.
- git-svn now reads settings even if called in subdirectory
- git-svn: Remove unnecessary Git::SVN::Util package
Picked up from the list with Eric's Acks, but haven't merged, as my next
pull from Eric would hopefully bring them in anyway.
* mw/cvsserver (Fri Nov 23 04:12:54 2007 -0500) 1 commit
- git-cvsserver runs hooks/post-receive
Queue in 'pu', but lacks a corresponding support for hooks/post-update,
which we haven't declared deprecation.
* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
- Move all dashed-form commands to libexecdir
I think this is a sane thing to do in the longer term. Will be in
'next' after v1.5.4. I think "leave porcelain on PATH" might be also a
good thing as a transition measure, but not strictly necessary. If we
were to do so, I'd like to see a patch that consolidates the knowledge
of what's Porcelain and what's common in one place before that.
Currently:
(1) generate-cmdlist.sh has its own built-in list for common command
names to be used in "git help";
(2) Documentation/cmd-list.perl has more comprehensive classification to
generate git(7) manpage and git.html. It needs to also know what's
deprecated.
(3) contrib/completion/git-completion.bash has a list of "uncommon
commands", commands not to be shown to the user.
which is a mess. I think a good approach would be to separate the
command list part from Documentation/cmd-list.perl script and move it to
the toplevel, and have these three read from it. Maybe git-help command
can learn "--classify" option to show that command list with
classification, so that git-completion.bash and other scripts can use it
without hardcoding the command list in.
Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them. I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir. This may
need to happen anyway as mingw fallouts, though ;-).
* jc/color (Tue Nov 27 22:41:05 2007 -0800) 2 commits
+ git-config --get-color: get configured color
+ "color.diff = true" is not "always" anymore.
Hopefully Dan's colored "git add -i" can rebuild on top of these.
* js/dashless (Fri Nov 30 12:08:20 2007 +0000) 1 commit
- transport.c: call dash-less form of receive-pack and upload-pack
on remote
Not field tested by anybody nor came with any tests, but this is an
important component to move git-foo commands out of user's PATH.
* dc/gitweb (Mon Nov 26 20:42:06 2007 +0800) 1 commit
- gitweb: the commitdiff is very commonly used, it's needed on
search page, too
Queue in 'pu', waiting for Acks from gitweb guys.
* jc/docmake-perl (Fri Nov 30 15:48:17 2007 -0800) 1 commit
- Run the specified perl in Documentation/
Queue in 'pu', waiting for Ack from Merlyn.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* cr/tag-options (Sun Nov 25 23:50:58 2007 -0500) 4 commits
+ git-tag: test that -s implies an annotated tag
+ "git-tag -s" should create a signed annotated tag
+ builtin-tag: accept and process multiple -m just like git-commit
+ Make builtin-tag.c use parse_options.
Will merge to 'master' over the weekend.
* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
+ git-branch --contains: doc and test
+ git-branch --contains=commit
+ parse-options: Allow to hide options from the default usage.
Contains Pierre's "hidable options with --help-all" patch.
Will merge to 'master' over the weekend.
* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
+ Move gitk to its own subdirectory
I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.
Will merge to 'master' over the weekend.
* js/rebase-i-rerere (Thu Nov 22 11:18:10 2007 +0000) 1 commit
+ rebase -i: give rerere a chance
I haven't seen rerere kick in since I merged this to 'next' (which I
almost always run). Success stories?
* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
+ Remove hint to use "git help -a"
+ Make the list of common commands more exclusive
Some people on the list may find the exact list of commands
somewhat debatable.
* kh/commit (Wed Nov 28 22:13:08 2007 +0100) 27 commits
+ Do not generate full commit log message if it is not going to be
used
+ Remove git-status from list of scripts as it is builtin
+ Fix off-by-one error when truncating the diff out of the commit
message.
+ builtin-commit.c: export GIT_INDEX_FILE for launch_editor as well.
+ Add a few more tests for git-commit
+ builtin-commit: Include the diff in the commit message when
verbose.
+ builtin-commit: fix partial-commit support
+ Fix add_files_to_cache() to take pathspec, not user specified list
of files
+ Export three helper functions from ls-files
+ builtin-commit: run commit-msg hook with correct message file
+ builtin-commit: do not color status output shown in the message
template
+ file_exists(): dangling symlinks do exist
+ Replace "runstatus" with "status" in the tests
+ t7501-commit: Add test for git commit <file> with dirty index.
+ builtin-commit: Clean up an unused variable and a debug fprintf().
+ Call refresh_cache() when updating the user index for --only
commits.
+ builtin-commit: Add newline when showing which commit was created
+ builtin-commit: resurrect behavior for multiple -m options
+ builtin-commit --s: add a newline if the last line was not a S-o-b
+ builtin-commit: fix --signoff
+ git status: show relative paths when run in a subdirectory
+ builtin-commit: Refresh cache after adding files.
+ builtin-commit: fix reflog message generation
+ launch_editor(): read the file, even when EDITOR=:
+ Port git commit to C.
+ Export launch_editor() and make it accept ':' as a no-op editor.
+ Add testcase for amending and fixing author in git commit.
Now comes with a few more fixes since the last issue of "What's in".
This should be production ready, but commit is so central, so let's wait
a bit longer until the bugfixes completely stop flowing in. The
earliest will be next Wednesday.
* js/export-with-assignment (Wed Nov 28 15:56:11 2007 +0000) 1 commit
+ Replace instances of export VAR=VAL with VAR=VAL; export VAR
This will make scripts easier to read for traditionalists (that's me), at
the same time working around a bug in BSD ash where VAL is word split if
you write "export VAR=VAL".
----------------------------------------------------------------
[Actively cooking]
* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits
+ core.whitespace: documentation updates.
+ builtin-apply: teach whitespace_rules
+ builtin-apply: rename "whitespace" variables and fix styles
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
Now apply also knows about the customizable definition of what
whitespace breakages are, and I was reasonably happy. But Bruce kicked
it back from "scheduled to merge" to "still cooking" status, reminding
that we would want to have this not a tree-wide configuration but
per-path attribute. And I agree with him.
* wc/add-i (Thu Nov 29 13:00:38 2007 +0100) 32 commits
+ Highlight keyboard shortcuts in git-add--interactive
+ Document all help keys in "git add -i" patch mode.
+ Add "--patch" option to git-add--interactive
+ add -i: Fix running from a subdirectory
+ builtin-add: fix command line building to call interactive
+ Merge branch 'kh/commit' into wc/add-i
+ Add a few more tests for git-commit
+ git-add -i: allow multiple selection in patch subcommand
+ builtin-commit: Include the diff in the commit message when
verbose.
+ builtin-commit: fix partial-commit support
+ Fix add_files_to_cache() to take pathspec, not user specified list
of files
+ Export three helper functions from ls-files
+ builtin-commit: run commit-msg hook with correct message file
+ builtin-commit: do not color status output shown in the message
template
+ file_exists(): dangling symlinks do exist
+ Replace "runstatus" with "status" in the tests
+ t7501-commit: Add test for git commit <file> with dirty index.
+ builtin-commit: Clean up an unused variable and a debug fprintf().
+ Call refresh_cache() when updating the user index for --only
commits.
+ builtin-commit: Add newline when showing which commit was created
+ builtin-commit: resurrect behavior for multiple -m options
+ builtin-commit --s: add a newline if the last line was not a S-o-b
+ builtin-commit: fix --signoff
+ git status: show relative paths when run in a subdirectory
+ builtin-commit: Refresh cache after adding files.
+ builtin-commit: fix reflog message generation
+ launch_editor(): read the file, even when EDITOR=:
+ Port git commit to C.
+ Export launch_editor() and make it accept ':' as a no-op editor.
+ Add testcase for amending and fixing author in git commit.
+ Add path-limiting to git-add--interactive
+ Teach builtin-add to pass multiple paths to git-add--interactive
This looks larger than it really is, as I merged in the builtin commit
series near the tip (they interact with each other somewhat, and it is
very likely that builtin commit series will graduate to 'master' before
this series).
* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
+ refactor fetch's ref matching to use refname_match()
+ push: use same rules as git-rev-parse to resolve refspecs
+ add refname_match()
+ push: support pushing HEAD to real branch name
I think the "git push HEAD" is a good change, and also using the same
short refname resolving as rev-parse does for matching the destination
of push. I am having second thoughts on the last one. The changed
semantics is somewhat less safe:
* We did not allow fetching outside refs/ (except HEAD), but now we
allow any random string.
* We used to restrict fetching names that do not begin with refs/ to
heads, tags and remotes, but now the code grabs anything underneath
refs/.
which could invite mistakes by letting typos slip through.
Having said that, I probably "fetch" much less often than other people
do and these may be non issues in the real-world usecases. It could be
that I am worried too much needlessly. If anybody who is following
'next' has been bitten by the change, please speak up.
* nd/maint-work-tree-fix (Thu Nov 29 19:21:39 2007 +0700) 2 commits
+ Do check_repository_format() early
+ Add missing inside_work_tree setting in setup_git_directory_gently
The tip one needs test script.
----------------------------------------------------------------
[Stalled]
I've dropped a few topics that did not see actions recently.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
- Added diff hunk coloring to git-add--interactive
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
There were many good suggestions by Jeff to the updated series;
hopefully we can have replacements of these three that incorporate
Jeff's suggestions, and build on the "git-config --get-color" series.
* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
- Making ce_path_match() more useful by accepting globs
This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex. I tend to agree with him.
^ permalink raw reply
* Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Marco Costalba @ 2007-12-01 2:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jan Hudec, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20071201023520.GQ14735@spearce.org>
On Dec 1, 2007 3:35 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> Building context sensitive menus isn't fun. Managing some data
> structures in Tcl isn't fun. The list of why I'm currently unhappy
> with Tcl/Tk for git-gui is actually pretty long.
>
Not to advertise, just my two cents, but Qt with whatever language
binding you want to use, it's really powerful, easy to learn,
documentation is great, easy to create GUI forms, actually you don't
even need to program because Qt Designer let you create a form
graphically, the result is a XML like file that a Qt tool called UIC
transforms in a compilable file.
Qt library is consistent and complete and very portable, especially
Qt4 works and installs under different OS with no hassles. And the Qt
community (http://www.qtcentre.org/forum/) is very helpful and
supportive.
I really don't want to advertise, but after reading your list of
Tcl/Tk cons I was not able to stay quiet.
Marco
^ permalink raw reply
* Re: [PATCH] gitweb: the commitdiff is very commonly used, it's needed on search page, too
From: Jakub Narebski @ 2007-12-01 3:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsrz9m5j.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I'll queue this to my tree but will drop if I hear objections from
> gitweb people CC'ed over the weekend.
This just ads link to 'search' view to 'commitdiff'; looks very nice.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Try harder in parse_tag; perhaps it was given ambiguous name
From: Jakub Narebski @ 2007-12-01 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <200712010247.25107.jnareb@gmail.com>
This patch should be RFC.
Sorry for missing that.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: memmem.c improvement
From: Tor Myklebust @ 2007-12-01 3:07 UTC (permalink / raw)
To: Christian Thaeter; +Cc: libc-alpha, git
In-Reply-To: <4750C74B.8060308@pipapo.org>
On Sat, 1 Dec 2007, Christian Thaeter wrote:
> I am fully aware that this is not the best possible search algorithm.
> It is considerably better than the actual one for 'common' data.
And not considerably worse in the worst case I could think of. (Which was
my point, not that it was slow or sucked in some other way.)
> Having a string with few symbols or other corner cases needs an
> algorithm better suited for that task.
Yes, if it's actually worth anyone's time making strstr() fast in the case
where the haystack has length three and the needle length two.
Amusingly enough, I haven't ever seen strstr() used to do any nontrivial
string matching in any free software I've bothered to grep.
> But well, this was just reaching a low hanging fruit.
Suitably hacked, your code looks clearly correct. But there are valid
reasons not to mess with the strstr() in libc (fewer for memmem()); chief
among them is that *if* there is an undetected bug in the code, *then*
lots of stuff can break.
> For me it suffices and I won't put more efforts into improving or
> lobbying it, its just not worth it.
Clearly, the tone of my email did not help convey my message. (Perhaps I
should just stop trying to write words of encouragement altogether --- it
never goes according to plan and always seems to end in disaster.) I do
commend you for submitting improvements (and this is clearly an
improvement); I was merely trying to point out that it will likely be an
uphill battle, and that certain things are either wrong or can be done
better than you have done. Do go on, please! (And I'm sorry if my
previous email caused you particular dismay.)
Tor Myklebust
^ permalink raw reply
* Re: [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Jeff King @ 2007-12-01 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v4pf39m4j.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 06:36:44PM -0800, Junio C Hamano wrote:
> > It would be nice to have a "git config --colorbool" option, but it has
> > the unfortunate problem that the stdout of "git config" is piped back to
> > the caller, so the isatty check is meaningless (and the "pager in use"
> > is similarly tricky). Perhaps it should go in Git.pm, so it at least
> > only needs to be written once.
>
> About the isatty(3) check, you do not have to use the stdout to report
> the result, though. IOW, you could use the exit code from the command.
I thought about that, but it feels a little wrong since it is so unlike
all of the other interfaces to git-config. Still, I would consider doing
it if there weren't other issues (like knowing when a pager is in use).
At some point it becomes more complex than simply having the 5-10 lines
necessary to do the check in perl.
-Peff
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jeff King @ 2007-12-01 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Ericsson, Nicolas Pitre, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <7vbq9b87jb.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 06:37:12PM -0800, Junio C Hamano wrote:
> side does not have such a program anywhere). So my preference at this
> point is to move things out of PATH first (without removing the
> hardlinks), deal with possible fallout from that move.
>
> And after things stablize, discuss to either remove the hardlinks from
> all installations, or to keep them in all installations. I do not think
> "it's this way here but that way there" is a good thing in general.
I think that it is a sensible course of action.
-Peff
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Jeff King @ 2007-12-01 4:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl2n87jr.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 30, 2007 at 06:36:56PM -0800, Junio C Hamano wrote:
> > I have always been a bit confused about diffcore-break, so I am probably
> > misunderstanding what you mean. But are you saying that
> > diffcore-break.c:should_break should return 1 for typechanges?
>
> What I had in mind was to do something like that in spirit, but instead
> break such a filepair inside diffcore-rename (iow, even when the user
> did not say -B) early on.
Ah, I see. BTW, I totally screwed up the tests I did earlier. Returning
1 from should_break _does_ produce the same results for my simple case
(copy + typechange).
> But after re-reading your patch and the surrounding code, that is
> more or less what you are doing (without actually recording the extra
> broken pair to be merged back later).
I don't think we need to, because they are never actually "broken"; we
simply consider the source a candidate for renaming, but keep the pair
together to note the typechange.
> which is essentially doing the same thing but only for the "remove the
> regular file" half. One has to wonder how the lack of handling the
> other half affects the outcome and still produce a result more intuitive
> than the current code.
AIUI, because we never broke the pair in the first place, we don't need
to look for a source for that dest (the "add a new symlink" half). It's
already part of the same filepair.
Whether this is by design or simply a happy accident that we record both
renames and typechanges in diff_filepairs, I'm not sure. Or perhaps I'm
totally misunderstanding how the breaking works.
> In your test case, the "new" symlink won't have any similar symlink that
> is removed from the preimage, so registering it as a rename destination
> would not make a difference (it will say "no match found, so create this
> as usual"), but I am not convinced if that would work well in general.
I don't know that it makes a difference. We are impacting only a
'typechange', which implies that we have a filepair in which both p->one
and p->two are valid; thus, the current code doesn't use it as a rename
dst at all.
-Peff
^ permalink raw reply
* Re: [RFC] use typechange as rename source
From: Junio C Hamano @ 2007-12-01 6:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071201043407.GD30725@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> In your test case, the "new" symlink won't have any similar symlink that
>> is removed from the preimage, so registering it as a rename destination
>> would not make a difference (it will say "no match found, so create this
>> as usual"), but I am not convinced if that would work well in general.
>
> I don't know that it makes a difference. We are impacting only a
> 'typechange', which implies that we have a filepair in which both p->one
> and p->two are valid; thus, the current code doesn't use it as a rename
> dst at all.
I think it does make a difference, if you have a cross rename that
swaps:
$ ls -F foo bar
bar foo@
$ mv foo tmp; mv bar foo; mv tmp bar
$ ls -F foo bar
bar@ foo
The attached patch does not automatically break a filepair that is a
typechange, so the new t4023 test asks for diffcore-break with -B
explicitly.
I suspect your patch alone would not pass t4023 (with or without -B).
We may want to do the autobreak in diffcore-rename even when -B is not
in effect on top of this patch, but that is a separate topic.
-- >8 --
Subject: [PATCH] rename: Break filepairs with different types.
When we consider if a path has been totally rewritten, we did not
touch changes from symlinks to files or vice versa. But a change
that modifies even the type of a blob surely should count as a
complete rewrite.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 7 +++
diffcore-break.c | 7 ++-
t/t4023-diff-rename-typechange.sh | 86 +++++++++++++++++++++++++++++++++++++
tree-walk.h | 7 ---
4 files changed, 97 insertions(+), 10 deletions(-)
create mode 100755 t/t4023-diff-rename-typechange.sh
diff --git a/cache.h b/cache.h
index aaa135b..d0e7a71 100644
--- a/cache.h
+++ b/cache.h
@@ -192,6 +192,13 @@ enum object_type {
OBJ_MAX,
};
+static inline enum object_type object_type(unsigned int mode)
+{
+ return S_ISDIR(mode) ? OBJ_TREE :
+ S_ISGITLINK(mode) ? OBJ_COMMIT :
+ OBJ_BLOB;
+}
+
#define GIT_DIR_ENVIRONMENT "GIT_DIR"
#define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TREE"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
diff --git a/diffcore-break.c b/diffcore-break.c
index c71a226..69afc07 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -52,8 +52,8 @@ static int should_break(struct diff_filespec *src,
* is the default.
*/
- if (!S_ISREG(src->mode) || !S_ISREG(dst->mode))
- return 0; /* leave symlink rename alone */
+ if (object_type(src->mode) != object_type(dst->mode))
+ return 1; /* even their types are different */
if (src->sha1_valid && dst->sha1_valid &&
!hashcmp(src->sha1, dst->sha1))
diff --git a/t/t4023-diff-rename-typechange.sh b/t/t4023-diff-rename-typechange.sh
new file mode 100755
index 0000000..255604e
--- /dev/null
+++ b/t/t4023-diff-rename-typechange.sh
@@ -0,0 +1,86 @@
+#!/bin/sh
+
+test_description='typechange rename detection'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ rm -f foo bar &&
+ cat ../../COPYING >foo &&
+ ln -s linklink bar &&
+ git add foo bar &&
+ git commit -a -m Initial &&
+ git tag one &&
+
+ rm -f foo bar &&
+ cat ../../COPYING >bar &&
+ ln -s linklink foo &&
+ git add foo bar &&
+ git commit -a -m Second &&
+ git tag two &&
+
+ rm -f foo bar &&
+ cat ../../COPYING >foo &&
+ git add foo &&
+ git commit -a -m Third &&
+ git tag three &&
+
+ mv foo bar &&
+ ln -s linklink foo &&
+ git add foo bar &&
+ git commit -a -m Fourth &&
+ git tag four &&
+
+ # This is purely for sanity check
+
+ rm -f foo bar &&
+ cat ../../COPYING >foo &&
+ cat ../../Makefile >bar &&
+ git add foo bar &&
+ git commit -a -m Fifth &&
+ git tag five &&
+
+ rm -f foo bar &&
+ cat ../../Makefile >foo &&
+ cat ../../COPYING >bar &&
+ git add foo bar &&
+ git commit -a -m Sixth &&
+ git tag six
+
+'
+
+test_expect_success 'cross renames to be detected for regular files' '
+
+ git diff-tree five six -r --name-status -B -M | sort >actual &&
+ {
+ echo "R100 foo bar"
+ echo "R100 bar foo"
+ } | sort >expect &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cross renames to be detected for typechange' '
+
+ git diff-tree one two -r --name-status -B -M | sort >actual &&
+ {
+ echo "R100 foo bar"
+ echo "R100 bar foo"
+ } | sort >expect &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'moves and renames' '
+
+ git diff-tree three four -r --name-status -B -M | sort >actual &&
+ {
+ echo "R100 foo bar"
+ echo "T100 foo"
+ } | sort >expect &&
+ diff -u expect actual
+
+'
+
+test_done
diff --git a/tree-walk.h b/tree-walk.h
index 903a7b0..db0fbdc 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -7,13 +7,6 @@ struct name_entry {
unsigned int mode;
};
-static inline enum object_type object_type(unsigned int mode)
-{
- return S_ISDIR(mode) ? OBJ_TREE :
- S_ISGITLINK(mode) ? OBJ_COMMIT :
- OBJ_BLOB;
-}
-
struct tree_desc {
const void *buffer;
struct name_entry entry;
--
1.5.3.6.2090.g4ece0
^ permalink raw reply related
* Re: [PATCH/RFC] "color.diff = true" is not "always" anymore.
From: Junio C Hamano @ 2007-12-01 6:10 UTC (permalink / raw)
To: Jeff King; +Cc: git list
In-Reply-To: <20071201041549.GB30725@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 30, 2007 at 06:36:44PM -0800, Junio C Hamano wrote:
>
>> > It would be nice to have a "git config --colorbool" option, but it has
>> > the unfortunate problem that the stdout of "git config" is piped back to
>> > the caller, so the isatty check is meaningless (and the "pager in use"
>> > is similarly tricky). Perhaps it should go in Git.pm, so it at least
>> > only needs to be written once.
>>
>> About the isatty(3) check, you do not have to use the stdout to report
>> the result, though. IOW, you could use the exit code from the command.
>
> I thought about that, but it feels a little wrong since it is so unlike
> all of the other interfaces to git-config.
Yeah, that is why I did not seriously suggest it. The message you were
responding to was sitting in my "I do not know if this should go out"
box for a few days and was sent out purely by accident ;-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox