* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 6:59 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Johannes Schindelin, Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <200901192145.21115.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> When diff is invoked with --color-words (w/o =regex), use the regular
> expression the user has configured as diff.color-words.
>
> diff drivers configured via attributes take precedence over the
> diff.color-words setting. If the user wants to change them, they have
> their own configuration variables.
This needs an entry in Documentation/config.txt
None of the existing configuration variables defined use hyphens in
multi-word variable names.
Other than that, I think this is a welcome addition to the suite.
Thanks.
^ permalink raw reply
* Re: [PATCH] commit: more compact summary and without extra quotes
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <1232405116-2359-1-git-send-email-santi@agolina.net>
I've updated the log message, so there is no need to resend. I suspect
that documentation/tutorial needs updating after this one.
Will apply to 'master'. Thanks.
^ permalink raw reply
* Re: [PATCH/RFC v2 1/1] bug fix, diff whitespace ignore options
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Keith Cascio; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.GSO.2.00.0901191000520.25883@kiwi.cs.ucla.edu>
Keith Cascio <keith@CS.UCLA.EDU> writes:
> Fixed bug in diff whitespace ignore options. It is now
> OK to specify more than one whitespace ignore option
> on the command line.
>
> Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
> ---
> Dscho,
> You are right. The code and the patch are more readable this way.
Thanks; I've fixed it up so there is no need to resend but your patch was
whitespace mangled (format=flowed), by the way.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Junio C Hamano @ 2009-01-20 7:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090120044021.GE30714@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 19, 2009 at 01:13:30AM -0800, Junio C Hamano wrote:
>
>> * jk/signal-cleanup (Sun Jan 11 06:36:49 2009 -0500) 3 commits
>> - pager: do wait_for_pager on signal death
>> - refactor signal handling for cleanup functions
>> - chain kill signals for cleanup functions
>>
>> Sorry, I lost track. What is the status of this one?
>
> I need to clean up and re-send. The three improvements needed are:
> ...
Thanks.
^ permalink raw reply
* Re: [PATCH] Provide pessimistic defaults for cross compilation tests.
From: Ralf Wildenhues @ 2009-01-20 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Julius Naperkowski, git
In-Reply-To: <7v63kampwz.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:50:52AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> > --- a/configure.ac
> > +++ b/configure.ac
> > + [ac_cv_c_c99_format=no],
> > if test $ac_cv_c_c99_format = no; then
>
> This one probably is Ok, but...
>
> > @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
> > FILE *f = fopen(".", "r");
> > return f && fread(&c, 1, 1, f)]])],
> > [ac_cv_fread_reads_directories=no],
> > + [ac_cv_fread_reads_directories=yes],
> > [ac_cv_fread_reads_directories=yes])
> > ])
> > if test $ac_cv_fread_reads_directories = yes; then
>
> I am not quite sure if this is an improvement ...
>
> > @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
> > if (snprintf(buf, 3, "%s", "12345") != 5
> > || strcmp(buf, "12")) return 1]])],
> > [ac_cv_snprintf_returns_bogus=no],
> > + [ac_cv_snprintf_returns_bogus=yes],
> > [ac_cv_snprintf_returns_bogus=yes])
> > ])
> > if test $ac_cv_snprintf_returns_bogus = yes; then
>
> ... nor this one.
I can see why you're cautious here, but AFAICS the actual code that will
be enabled by these defaults is portable to systems that have no bogus
snprintf and whose fread does not read directories. IOW, all you lose
is a bit of performance at most.
> Is there a way to say something like "I'll autodetect as much as I can
> without running tests, but please tell me these characteristics of the
> target system manually" and leave the resulting config.mak.autogen in a
> shape that will guarantee compilation failure until the missing ones are
> supplied by config.mak?
Well, without my patch, each of these three tests will get configure to
error out. Instead of setting a variable, these added arguments can
also output a more helpful error, in the sense of
"please find out whether the return value of snprintf is ok,
and set $ac_cv_snprintf_returns_bogus accordingly when rerunning
configure"
> The thing is, I am not convinced that it is desirable to be able to build
> a possibly suboptimal binary in a cross compilation environment, without
> being told in what aspect of the resulting binary is suboptimal. I'd
> rather see a build system that honestly tells me what information it needs
> but couldn't find, so that I would know I have a chance to help it.
Sure.
> Of course, suggesting a pessimistic default that can result in suboptimal
> but correct result would be a good thing to help the user help the build.
> I just think it is a good idea to tell the user we are giving such hint a
> bit more loudly to draw attention.
Agreed, too. Would you prefer a hard erroring out of configure, for
each of the tests, or would it suffice to see a warning fly by?
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Ralf Wildenhues @ 2009-01-20 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljt6mqv0.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:30:27AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
>
> > In order to be cached, configure variables need to contain the
> > string '_cv_', and they should begin with a package-specific
> > prefix in order to avoid interfering with third-party macros.
> > Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
> We require every patch we accept to be accompanied with a sign-off.
>
> Can you certify that ... [see Documentation/SubmittingPatches and look for
> (4) Sign your work] ... please?
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Sorry about that.
Cheers,
Ralf
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Ciprian Dorin, Craciun @ 2009-01-20 7:29 UTC (permalink / raw)
To: Greg KH; +Cc: david, Bryan Donlan, git
In-Reply-To: <20090120033402.GC8754@kroah.com>
On Tue, Jan 20, 2009 at 5:34 AM, Greg KH <greg@kroah.com> wrote:
> On Mon, Jan 19, 2009 at 09:52:16AM +0200, Ciprian Dorin, Craciun wrote:
>> I use something even simpler, please see the attached .git/config
>> file that I use. It also uses remote branches, and rewrites the refs
>> to something like: stable/v2.6.25/master or torvalds/v2.6/master. Also
>> in order to fetch them I use git fetch stable/v2.6.25
>
> You all do know that all of the -stable trees are automatically kept in
> one repo on kernel.org, so you don't have to jump through all of these
> hoops, right?
>
> confused,
>
> greg k-h
:) This is something that escaped me... Could you give me the
exact git url for this repository? (on kernel.org I'm not able to find
it, just the current one...)
Thanks,
Ciprian Craciun.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Sixt @ 2009-01-20 7:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120044021.GE30714@sigill.intra.peff.net>
Jeff King schrieb:
> - the test needs a few tweaks to be portable to Windows
While this is true, the workaround I have in my tree is so ugly that its
discussion would hold back this series unnecessarily. So, please don't
wait for the fixup of the test.
[My intention is to send test suite fixups for Windows as a separate
series, which would include the fixup for this case, too.]
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-svn: fix SVN 1.1.x compatibility
From: Tom G. Christensen @ 2009-01-20 8:11 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090120012301.GA30236@dcvr.yhbt.net>
Eric Wong wrote:
> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>> Eric Wong wrote:
>>> The get_log() function in the Perl SVN API introduced the limit
>>> parameter in 1.2.0. However, this got discarded in our SVN::Ra
>>> compatibility layer when used with SVN 1.1.x. We now emulate
>>> the limit functionality in older SVN versions by preventing the
>>> original callback from being called if the given limit has been
>>> reached. This emulation is less bandwidth efficient, but SVN
>>> 1.1.x is becoming rarer now.
>>>
>>> Additionally, the --limit parameter in svn(1) uses the
>>> aforementioned get_log() functionality change in SVN 1.2.x.
>>> t9129 no longer depends on --limit to work and instead uses
>>> Perl to parse out the commit message.
>>>
>>> Thanks to Tom G. Christensen for the bug report.
>>>
>>> Signed-off-by: Eric Wong <normalperson@yhbt.net>
>> I applied this to 1.6.1 and the testsuite now passes using SVN 1.1.4 on
>> RHEL 4/i386 (t9106 still fails on RHEL 4/x86_64).
>
> Any chance I could have access to that RHEL4/x86_64 environment?
Unfortunately I can't offer that.
It is really just a mock buildroot, and it should be possible to
recreate the problem with CentOS 4/x86_64.
On Fedora Linux the default mock install has a suitable config (epel-4).
If you're not a Fedora/CentOS person then I could possibly prepare a
VMware image for you.
> I'll
> try to work around bugs in older SVN as best I can, but can't guarantee
> anything.
>
I don't expect more than that.
-tgc
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Brian Foster @ 2009-01-20 8:12 UTC (permalink / raw)
To: Dilip M; +Cc: Reece Dunn, git list
In-Reply-To: <c94f8e120901190637i294d379dke3a07a90da5076f8@mail.gmail.com>
On Monday 19 January 2009 15:37:06 Dilip M wrote:
> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> >> not found'
> >
> > Who is the owner of the repository directory (and the .git directory)
> > and what are the permissions on the directory? [ ... ]
>
> dm-laptop:~/repos/atria> id -a
> uid=1000(dm) gid=1000(dm) [ ... ]
> dm-laptop:~/repos/atria> ls -lh .git/
>[... all looks Ok ...]
repeating Reece's question, what is the permissions/owner
_of_the_directory_which_contains_ the ‘.git/’ directory?
I can reproduce this behaviour (git 1.6.0.4) simply by
denying myself search (née execute) permission on that
directory, for entirely obvious reasons.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): avoid traversing the reflogs twice
From: Junio C Hamano @ 2009-01-20 8:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <alpine.DEB.1.00.0901191331590.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This, together with a removal of the hard-coded limit of 16 could be
> squashed with this patch:
Yeah, I think that makes very much sense, not because 16 is too small, but
because it does not make sense to keep track of all 16 when you asked for
the last (or the second from the last) event.
Thanks for a free sanity ;-)
^ permalink raw reply
* Re: [PATCH v2 2/2] bash completion: refactor diff options
From: Junio C Hamano @ 2009-01-20 8:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Shawn O. Pearce
In-Reply-To: <1232399880-22036-2-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff, log and show all take the same diff options. Refactor them from
> __git_diff and __git_log into a variable, and complete them in
> __git_show too.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
>
> ---
> contrib/completion/git-completion.bash | 36 ++++++++++++++++++-------------
> 1 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 096603b..bfae953 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -773,14 +773,7 @@ _git_describe ()
> __gitcomp "$(__git_refs)"
> }
>
> -_git_diff ()
> -{
> - __git_has_doubledash && return
> -
> - local cur="${COMP_WORDS[COMP_CWORD]}"
> - case "$cur" in
> - --*)
> - __gitcomp "--cached --stat --numstat --shortstat --summary
> +__git_diff_common_options="--stat --numstat --shortstat --summary
> --patch-with-stat --name-only --name-status --color
> --no-color --color-words --no-renames --check
> --full-index --binary --abbrev --diff-filter=
> @@ -789,9 +782,21 @@ _git_diff ()
> --ignore-all-space --exit-code --quiet --ext-diff
> --no-ext-diff
> --no-prefix --src-prefix= --dst-prefix=
> - --base --ours --theirs
> --inter-hunk-context=
> --patience
> + --raw
> +"
> +
> +_git_diff ()
> +{
> + __git_has_doubledash && return
> +
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "--cached --pickaxe-all --pickaxe-regex
> + --base --ours --theirs
> + $__git_diff_common_options
> "
> return
> ;;
> @@ -977,17 +982,16 @@ _git_log ()
> --relative-date --date=
> --author= --committer= --grep=
> --all-match
> - --pretty= --name-status --name-only --raw
> + --pretty=
> --not --all
> --left-right --cherry-pick
> --graph
> - --stat --numstat --shortstat
> - --decorate --diff-filter=
> - --color-words --walk-reflogs
> + --decorate
> + --walk-reflogs
> --parents --children --full-history
> --merge
> --inter-hunk-context=
> - --patience
> + $__git_diff_common_options
> --pickaxe-all --pickaxe-regex
> "
I'll tweak this part to drop duplicated --ihc; other than that it looked
good. Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Thomas Rast @ 2009-01-20 8:57 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Junio C Hamano, git
In-Reply-To: <200901192317.23079.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 635 bytes --]
Boyd Stephen Smith Jr. wrote:
> Is there anywhere you are publishing these refs? Of course, I see the
> commits in 'pu', but sometimes I would like to merge something you have
> in 'next'/'pu' into a branch based on 'master' or one of my local
> branches, and I have to go hunting for the commit SHA.
[...]
> $ git pull origin jk/color-parse
> fatal: Couldn't find remote ref jk/color-parse
You could try the script I posted here:
http://article.gmane.org/gmane.comp.version-control.git/106129
Just 'git resurrect -m jk/color-parse' and you should be good to go.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-20 9:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Boyd Stephen Smith Jr.
In-Reply-To: <alpine.DEB.1.00.0901181718370.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
[Sorry for missing this message, it seems KMail4 does have some rather
annoying filtering bugs...]
Johannes Schindelin wrote:
> On Sun, 18 Jan 2009, Thomas Rast wrote:
>
> > Makefile | 1 +
> > git-resurrect.sh | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Maybe have it in contrib/ instead?
It was really intended as a toy patch, but if people find it useful
(Boyd?) I can add the rest of the options so that all searches can be
chosen independently, and shape it as a "real" contrib patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add tests for diff.color-words configuration option.
From: Johannes Schindelin @ 2009-01-20 9:58 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901192017.54163.bss@iguanasuicide.net>
Hi,
On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
> I'm not sure why the diff is crazy long.
Because you changed things that need no changing, such as "cat > expect"
-> "cat > expect.blabla", and because you inserted your test instead of
adding it at the end.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 10:02 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Santi Béjar, Thomas Rast, git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901192145.21115.bss@iguanasuicide.net>
Hi,
On Mon, 19 Jan 2009, Boyd Stephen Smith Jr. wrote:
> diff --git a/diff.c b/diff.c
> index 9fcde96..c53e1d1 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -23,6 +23,7 @@ static int diff_detect_rename_default;
> static int diff_rename_limit_default = 200;
> static int diff_suppress_blank_empty;
> int diff_use_color_default = -1;
> +static const char *diff_color_words_cfg = NULL;
> static const char *external_diff_cmd_cfg;
Guess why external_diff_cmd_cfg is not set to NULL? All variables
defined outside a function are set to all-zero anyway.
> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
> }
> if (!strcmp(var, "diff.external"))
> return git_config_string(&external_diff_cmd_cfg, var, value);
> + if (!strcmp(var, "diff.color-words"))
I'd call it diff.wordregex, because that's what it is.
> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
> o->word_regex = userdiff_word_regex(one);
> if (!o->word_regex)
> o->word_regex = userdiff_word_regex(two);
> + if (!o->word_regex)
> + o->word_regex = diff_color_words_cfg;
IMHO this is the wrong order. config should not override attributes,
which are by definition more specific.
> diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
> index 6ebce9d..a207d9e 100755
> --- a/t/t4034-diff-words.sh
> +++ b/t/t4034-diff-words.sh
> @@ -105,7 +105,7 @@ a = b + c<RESET>
> EOF
> cp expect.non-whitespace-is-word expect
>
> -test_expect_failure 'use default supplied by config' '
> +test_expect_success 'use default supplied by config' '
Let's squash the two, okay?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH,v4] git-checkout(1): mention fate of extraneous files
From: Johannes Schindelin @ 2009-01-20 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Boyd Stephen Smith Jr., git, jidanni
In-Reply-To: <7vy6x6odiw.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> [...] the more I think about it, I do not think it is natural at all to
> expect "checkout" to behave as if you did "rm -fr" everything and then
> "tar xf" over the void. What other SCM implements branch switching that
> way, and what workflow would such a behaviour help?
>
> We need to draw a line somewhere to avoid cluttering the documentation
> too much, and I do not think this is something even a person with CVS
> braindamage would get confused about, which is where I think is a
> reasonable place to draw that line.
IIRC both CVS and Subversion allow you to say "$SCM co" with an existing
working directory, which is then updated (and untracked files are left
alone, as "$SCM up" always did and should do).
So no, not even people with CVS/SVN braindamage would get confused thusly.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] commit: more compact summary and without extra quotes
From: Johannes Schindelin @ 2009-01-20 10:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <7vocy2ocw0.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 364 bytes --]
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> Santi Béjar <santi@agolina.net> writes:
>
> > OK, less work for me :-)
>
> A summary of discussion in addition to URL would save everybody's time.
As Santi pointed out, not his time. And I almost feared that he was
comfortable with the overall time-balance weighing dramatically in his
favor.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce for_each_recent_reflog_ent().
From: Johannes Schindelin @ 2009-01-20 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vpriimr93.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> This can be used to scan only the last few kilobytes of a reflog, as a
> cheap optimization when the data you are looking for is likely to be
> found near the end of it. The caller is expected to fall back to the
> full scan if that is not the case.
FWIW I really like it, as it works around mmap() nicely.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] interpret_nth_last_branch(): plug small memleak
From: Johannes Schindelin @ 2009-01-20 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vvdsamrai.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Mon, 19 Jan 2009, Junio C Hamano wrote:
> The error return path leaked both cb.buf[] strbuf array itself, and the
> strings contained in its elements.
Oops. Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Johannes Schindelin @ 2009-01-20 10:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <20090120040617.GB30714@sigill.intra.peff.net>
Hi,
On Mon, 19 Jan 2009, Jeff King wrote:
> On Mon, Jan 19, 2009 at 03:10:56PM -0800, Junio C Hamano wrote:
>
> > > Hrm. OK, it doesn't actually work always. It does for git-log, but
> > > not for rev-list, which leaves diff_use_color_default as -1. I don't
> > > know if there are any other ways you can get to this code path
> > > without having set diff_use_color_default.
> >
> > Yuck, no matter what you do please don't contaminate plumbing with the
> > UI color options.
>
> Of course. But the problem is that rev-list is _already_ contaminated by
> --pretty=format:%Cred. Or do you mean, you really want rev-list to
> unconditionally output color in such a case?
No, rev-list is not contaminated with UI color options. %Cred _always_
outputs the color, even when the user turned off color explicitely, using
--no-color.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] commit: more compact summary and without extra quotes
From: Santi Béjar @ 2009-01-20 10:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201109430.3586@pacific.mpi-cbg.de>
2009/1/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 19 Jan 2009, Junio C Hamano wrote:
>
>> Santi Béjar <santi@agolina.net> writes:
>>
>> > OK, less work for me :-)
>>
>> A summary of discussion in addition to URL would save everybody's time.
>
> As Santi pointed out, not his time. And I almost feared that he was
> comfortable with the overall time-balance weighing dramatically in his
> favor.
No, I'm not comfortable. I don't like wasting other's time. It was an
unfortunate comment from my part (I thought you were saying just
remove or put it after the ---).
Santi
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Johannes Schindelin @ 2009-01-20 10:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <alpine.DEB.1.00.0901201126500.3586@pacific.mpi-cbg.de>
Hi,
On Tue, 20 Jan 2009, Johannes Schindelin wrote:
> On Mon, 19 Jan 2009, Jeff King wrote:
>
> > On Mon, Jan 19, 2009 at 03:10:56PM -0800, Junio C Hamano wrote:
> >
> > > > Hrm. OK, it doesn't actually work always. It does for git-log, but
> > > > not for rev-list, which leaves diff_use_color_default as -1. I
> > > > don't know if there are any other ways you can get to this code
> > > > path without having set diff_use_color_default.
> > >
> > > Yuck, no matter what you do please don't contaminate plumbing with
> > > the UI color options.
> >
> > Of course. But the problem is that rev-list is _already_ contaminated
> > by --pretty=format:%Cred. Or do you mean, you really want rev-list to
> > unconditionally output color in such a case?
>
> No, rev-list is not contaminated with UI color options. %Cred _always_
> outputs the color, even when the user turned off color explicitely,
> using --no-color.
BTW I would find it very logical for rev-list not to output any color at
all when %C(yellow) is specified, as your code respects the diff UI
options, which are implicitly turned off for rev-list (as rev-list is no
UI), just like the coloring of "commit <name>" is implicitly turned off
for rev-list.
Ciao,
Dscho
^ permalink raw reply
* Few Questions
From: Arya, Manish Kumar @ 2009-01-20 10:38 UTC (permalink / raw)
To: git
Hi,
I am new to Git. Earlier I have configured svn with LDAP auth and svnwebclient.
I want to have following with Git
- LDAP and ssh authentication.
- checkin and checkout using web interface and ssh
- when ever someone checkin something then a email should be send to a email address (a mailing list)
please let me know how to do this with Git
-Manish
^ permalink raw reply
* Re: Few Questions
From: Matthieu Moy @ 2009-01-20 11:04 UTC (permalink / raw)
To: m.arya; +Cc: git
In-Reply-To: <726600.29783.qm@web35708.mail.mud.yahoo.com>
"Arya, Manish Kumar" <m.arya@yahoo.com> writes:
> Hi,
>
> I am new to Git. Earlier I have configured svn with LDAP auth and svnwebclient.
>
> I want to have following with Git
>
> - LDAP and ssh authentication.
AFAIK, there isn't any authentication mechanism built into Git.
Instead, Git relies on existing (proven, reliable, ...) mechanisms.
SSH authentication is what you get when accessing a repository with
e.g. git clone ssh://host.com/path/to/repo (either you have a full
ssh shell access on the server, or you can restrict the access with
git-shell to allow only basic git operations on the server).
There's probably a way to let your server use LDAP for authentication
when using SSH, but that's independant from Git (and I'm helpless
here).
> - checkin and checkout using web interface and ssh
Gitweb for the web interface. "checkin" and "checkout" have different
meanings depending on the tool, so I'm not sure I understand the
question correctly.
In Git, the equivalent of "checkout" for centralized VCS would be
"clone" (i.e. get a local working tree for a remote repository, but
Git also duplicates the history), see above, it works straigtforwardly
through SSH. I don't think you can do it from a web interface, but I
don't understand what would be the point in doing it.
> - when ever someone checkin something then a email should be send to
> a email address (a mailing list)
With a hook. You probably don't want to have this as the commit hook,
since the advantage of Git is to make "commit" a local, somehow
private operation, and to distinguish it from "push" (which somehow
means "publish", "show to the rest of the world"). So sending email
when some server receives the new revisions is sensible, this is the
post-receive hook.
These can help:
http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/hooks/post-receive-email;h=28a3c0e46ecf9951f3f42a025a288a65c70e0424;hb=HEAD
http://source.winehq.org/git/tools.git/?a=blob;f=git-notify;hb=HEAD
--
Matthieu
^ 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