* Re: Few Questions
From: Jakub Narebski @ 2009-01-20 15:44 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.
>
Instead of inventing (and failing) its own protocol and its own
authentication git uses established solutions for authentication: SSH
for "smart" server, and WebDAV for push via (currently only "dumb")
HTTPS protocol.
There exist solutions that help with setting up SSH for git:
git-shell, ssh_acl, and I think most commonly used Gitosis (see
seminal reference about Gitosis on http://git.or.cz/gitwiki/BlogPosts).
> - checkin and checkout using web interface and ssh
>
Git is distributed version control system: checkin (named 'commit' in
git) and checkout are _local_ operations. Fetch (getting new changes
from remote repository) and clone (creating new local repository
following or forking specified remote repository) can be done via
local filesystem, via git:// protocol, via "dumb" HTTP, and via SSH.
Push (sending changes to remote repository) needs autheticated
channel: most common used is SSH, but you can also use WebDAV with
HTTPS.
There are web interfaces for Git, something like SVN::Web or ViewVC,
like gitweb (in Perl, developed in git.git repository) and cgit (in C).
See also "Web interfaces" section on InterfacesFrontendsAndTools page
on git wiki.
> - when ever someone checkin something then a email should be send to
> a email address (a mailing list)
If by 'checkin' you mean publishing changes to a server (i.e. push in
git terminology), see for example contrib/hooks/post-receive-email
hook.
> please let me know how to do this with Git
Please learn that Git is _different_ from Subversion, and not try to
follow your SVN workflow and expectations blindly.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 2/2] valgrind: ignore ldso errors
From: Johannes Schindelin @ 2009-01-20 15:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201602410.5159@intel-tinevez-2-302>
From: Jeff King <peff@peff.net>
On some Linux systems, we get a host of Cond and Addr errors
from calls to dlopen that are caused by nss modules. We
should be able to safely ignore anything happening in
ld-*.so as "not our problem."
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
This is Peff's patch, unchanged.
t/valgrind/default.supp | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
index 2482b3b..1013847 100644
--- a/t/valgrind/default.supp
+++ b/t/valgrind/default.supp
@@ -11,6 +11,18 @@
}
{
+ ignore-ldso-cond
+ Memcheck:Cond
+ obj:*ld-*.so
+}
+
+{
+ ignore-ldso-addr8
+ Memcheck:Addr8
+ obj:*ld-*.so
+}
+
+{
writing-data-from-zlib-triggers-errors
Memcheck:Param
write(buf)
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* [PATCH 1/2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-20 15:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201545570.5159@intel-tinevez-2-302>
This patch adds the ability to use valgrind's memcheck tool to
diagnose memory problems in git while running the test scripts. It
works by placing a "fake" git in the front of the test script's PATH;
this fake git runs the real git under valgrind. It also points the
exec-path such that any stand-alone dashed git programs are run using
the same script. In this way we avoid having to modify the actual git
code in any way.
To be certain that every call to any git executable is intercepted,
the PATH is searched for executables beginning with "git-"; Scripts
are excluded however.
Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the
make invocation. Any invocation of git that finds any errors under
valgrind will exit with failure code 126. Any valgrind output will go
to the usual stderr channel for tests (i.e., /dev/null, unless -v has
been specified).
If you need to pass options to valgrind -- you might want to run
another tool than memcheck, for example -- you can set the environment
variable GIT_VALGRIND_OPTIONS.
A few default suppressions are included, since libz seems to
trigger quite a few false positives. We'll assume that libz
works and that we can ignore any errors which are reported
there.
Initial patch and all the hard work by Jeff King.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
AFAIR libz reserves only aligned memory, and does all operations
in an aligned manner, but it is safe (even if it accesses
uninitialized memory, it does not use the results anyway).
t/test-lib.sh | 39 +++++++++++++++++++++++++++++++++++++--
t/valgrind/.gitignore | 2 ++
t/valgrind/default.supp | 21 +++++++++++++++++++++
t/valgrind/valgrind.sh | 12 ++++++++++++
4 files changed, 72 insertions(+), 2 deletions(-)
create mode 100644 t/valgrind/.gitignore
create mode 100644 t/valgrind/default.supp
create mode 100755 t/valgrind/valgrind.sh
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 41d5a59..1daae9b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -94,6 +94,8 @@ do
--no-python)
# noop now...
shift ;;
+ --va|--val|--valg|--valgr|--valgri|--valgrin|--valgrind)
+ valgrind=t; shift ;;
*)
break ;;
esac
@@ -467,8 +469,41 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-PATH=$TEST_DIRECTORY/..:$PATH
-GIT_EXEC_PATH=$(pwd)/..
+if test -z "$valgrind"
+then
+ PATH=$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+else
+ # override all git executables in PATH and TEST_DIRECTORY/..
+ GIT_VALGRIND=$TEST_DIRECTORY/valgrind
+ mkdir -p "$GIT_VALGRIND"
+ OLDIFS=$IFS
+ IFS=:
+ for path in $PATH:$TEST_DIRECTORY/..
+ do
+ ls "$TEST_DIRECTORY"/../git "$path"/git-* 2> /dev/null |
+ while read file
+ do
+ # handle only executables
+ test -x "$file" || continue
+
+ base=$(basename "$file")
+ test ! -h "$GIT_VALGRIND"/"$base" || continue
+
+ if test "#!" = "$(head -c 2 < "$file")"
+ then
+ # do not override scripts
+ ln -s ../../"$base" "$GIT_VALGRIND"/"$base"
+ else
+ ln -s valgrind.sh "$GIT_VALGRIND"/"$base"
+ fi
+ done
+ done
+ IFS=$OLDIFS
+ PATH=$GIT_VALGRIND:$PATH
+ GIT_EXEC_PATH=$GIT_VALGRIND
+ export GIT_VALGRIND
+fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
GIT_CONFIG_NOSYSTEM=1
diff --git a/t/valgrind/.gitignore b/t/valgrind/.gitignore
new file mode 100644
index 0000000..d781a63
--- /dev/null
+++ b/t/valgrind/.gitignore
@@ -0,0 +1,2 @@
+/git
+/git-*
diff --git a/t/valgrind/default.supp b/t/valgrind/default.supp
new file mode 100644
index 0000000..2482b3b
--- /dev/null
+++ b/t/valgrind/default.supp
@@ -0,0 +1,21 @@
+{
+ ignore-zlib-errors-cond
+ Memcheck:Cond
+ obj:*libz.so*
+}
+
+{
+ ignore-zlib-errors-value4
+ Memcheck:Value4
+ obj:*libz.so*
+}
+
+{
+ writing-data-from-zlib-triggers-errors
+ Memcheck:Param
+ write(buf)
+ obj:/lib/ld-*.so
+ fun:write_in_full
+ fun:write_buffer
+ fun:write_loose_object
+}
diff --git a/t/valgrind/valgrind.sh b/t/valgrind/valgrind.sh
new file mode 100755
index 0000000..24f3a4e
--- /dev/null
+++ b/t/valgrind/valgrind.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+base=$(basename "$0")
+
+exec valgrind -q --error-exitcode=126 \
+ --leak-check=no \
+ --suppressions="$GIT_VALGRIND/default.supp" \
+ --gen-suppressions=all \
+ --log-fd=4 \
+ --input-fd=4 \
+ $GIT_VALGRIND_OPTIONS \
+ "$GIT_VALGRIND"/../../"$base" "$@"
--
1.6.1.243.g6c8bb35
^ permalink raw reply related
* Re: [PATCH 2/2] expand --pretty=format color options
From: Johannes Schindelin @ 2009-01-20 14:58 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <20090120142301.GC10688@sigill.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 11:36:08AM +0100, Johannes Schindelin wrote:
>
> > > > 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.
>
> Now I'm confused. Should color in --pretty=format always be on, or
> should it respect color settings? You seem to be advocating both sides
> in the two paragraphs.
No, I am just very bad at relating my thoughts.
What I tried to say is "plumbing does not, and should not, change behavior
depending on diff.color".
With %Cred, I was just lazy, and did not make a check if diff.color is
true, which I regret now.
But then, its behavior still does not depend on diff.color when using
plumbing.
It does not even depend on it when using porcelain :-)
> The behavior I would propose it along the lines of:
>
> - plumbing _always_ has color off
>
> - porcelain respects color.* config, --color, etc
Right, that'd be the sane behavior, even for %Cred.
Ciao,
Dscho
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-20 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120141932.GB10688@sigill.intra.peff.net>
Hi,
On Tue, 20 Jan 2009, Jeff King wrote:
> On Tue, Jan 20, 2009 at 02:51:49PM +0100, Johannes Schindelin wrote:
>
> > > I think creating it inside the trash directory for each test run
> > > that wants to use valgrind makes more sense (probably as
> > > .git/valgrind, which is unlikely to hurt anything but will stay out
> > > of the way of most of the tests).
> >
> > Here I disagree. But I think that test-lib.sh should create it
> > on-demand, and it should traverse all executables in all paths listed
> > in $PATH, replacing the ones that start with "git-" ("git" itself
> > should be the first one) that are no scripts by symlinks to the
> > valgrind script (which should therefore live in t/), and those that
> > _are_ scripts by symlinks to $GIT_ROOT/$NAME.
>
> How will you deal with race conditions between two simultaneously
> running scripts? I.e., where are you going to put it?
There are no race conditions, as for every git executable, a symbolic link
is created, pointing to the valgrind.sh script [*1*].
Besides, what with valgrind being a memory hog, you'd be nuts to call
valgrinded scripts simultaneously.
Ciao,
Dscho
[*1*] Before anybody complains about symbolic links not being available on
Windows, or $GIT_SHELL not being heeded by the valgrind.sh script: get
valgrind to compile on those platforms, and _then_ we'll talk again.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Jakub Narebski @ 2009-01-20 14:38 UTC (permalink / raw)
To: git
In-Reply-To: <200901192145.21115.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. wrote:
> Nawiązania: 1 2 3
> 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.
Just a nit: all other configuration variables use camelCase or runwords;
this would be first configuration variable with '-' as words separator,
I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] expand --pretty=format color options
From: Jeff King @ 2009-01-20 14:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <alpine.DEB.1.00.0901201133280.3586@pacific.mpi-cbg.de>
On Tue, Jan 20, 2009 at 11:36:08AM +0100, Johannes Schindelin wrote:
> > > 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.
Now I'm confused. Should color in --pretty=format always be on, or
should it respect color settings? You seem to be advocating both sides
in the two paragraphs.
The behavior I would propose it along the lines of:
- plumbing _always_ has color off
- porcelain respects color.* config, --color, etc
-Peff
^ permalink raw reply
* Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 14:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901201447290.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 02:51:49PM +0100, Johannes Schindelin wrote:
> > I think creating it inside the trash directory for each test run that
> > wants to use valgrind makes more sense (probably as .git/valgrind, which
> > is unlikely to hurt anything but will stay out of the way of most of the
> > tests).
>
> Here I disagree. But I think that test-lib.sh should create it on-demand,
> and it should traverse all executables in all paths listed in $PATH,
> replacing the ones that start with "git-" ("git" itself should be the
> first one) that are no scripts by symlinks to the valgrind script (which
> should therefore live in t/), and those that _are_ scripts by symlinks to
> $GIT_ROOT/$NAME.
How will you deal with race conditions between two simultaneously
running scripts? I.e., where are you going to put it?
> I'll work on it.
Great.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Jeff King @ 2009-01-20 14:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <49758367.7040706@viscovery.net>
On Tue, Jan 20, 2009 at 08:55:19AM +0100, Johannes Sixt wrote:
> > - 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 goal was to just accept multiple exit codes in the test. I'll cc you
when I send out the new one, and you can comment.
-Peff
^ permalink raw reply
* valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)
From: Johannes Schindelin @ 2009-01-20 13:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090120044447.GF30714@sigill.intra.peff.net>
Hi,
On Mon, 19 Jan 2009, Jeff King wrote:
> One of the things I didn't like about it was that the valgrind wrapper
> directory was created in the Makefile.
I agree.
> I think creating it inside the trash directory for each test run that
> wants to use valgrind makes more sense (probably as .git/valgrind, which
> is unlikely to hurt anything but will stay out of the way of most of the
> tests).
Here I disagree. But I think that test-lib.sh should create it on-demand,
and it should traverse all executables in all paths listed in $PATH,
replacing the ones that start with "git-" ("git" itself should be the
first one) that are no scripts by symlinks to the valgrind script (which
should therefore live in t/), and those that _are_ scripts by symlinks to
$GIT_ROOT/$NAME.
I'll work on it.
Ciao,
Dscho
^ permalink raw reply
* Re: how to track multiple upstreams in one repository
From: Miklos Vajna @ 2009-01-20 12:03 UTC (permalink / raw)
To: Ciprian Dorin, Craciun; +Cc: Greg KH, david, Bryan Donlan, git
In-Reply-To: <8e04b5820901192329pf44431coce4423e6a8d43198@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Tue, Jan 20, 2009 at 09:29:13AM +0200, "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com> wrote:
> :) 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...)
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git
Have you tried this one?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] tutorial-2: Update with the new "git commit" ouput
From: Santi Béjar @ 2009-01-20 11:29 UTC (permalink / raw)
To: git
Commit
c5ee71f (commit: more compact summary and without extra quotes, 2009-01-19)
changed the "git commit" output when creating a commit.
This patch updates the example session in the tutorial.
Signed-off-by: Santi Béjar <santi@agolina.net>
---
Documentation/gittutorial-2.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index a057b50..dc8fc3a 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -32,12 +32,12 @@ Initialized empty Git repository in .git/
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
-[master (root-commit)] created 54196cc: "initial commit"
+[master (root-commit) 54196cc] initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
-[master] created c4d59f3: "add emphasis"
+[master c4d59f3] add emphasis
1 files changed, 1 insertions(+), 1 deletions(-)
------------------------------------------------
--
1.6.1.258.g7ff14
^ permalink raw reply related
* 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
* 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: [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
* 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: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] 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] 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] 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,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] 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] 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: [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: 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
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