* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-11-27 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vws1cwnu0.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.11.2009 06:15:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> * Should I rename wt-status.c's color() into something more unique when
>> I export it?
>
> Is it an option to instead move short_unmerged(), short_status() and
> friends to wt-status.c from builtin-commit.c? It's been quite a while
> since I worked on the code, so I don't recall why it needs such cross
> references at low level between two files.
I didn't notice, but I'll look into it during the rewrite.
>> * Is there any policy regarding use of putchar/puts vs. printf?
>
> J6t addressed it. You have mixture of putchar(' ') and printf(" ") which
> looks somewhat funny ;-)
;) I'm happy with printf("c"), I just thought someone would find printf
overkill for a format less char.
>> * The way it is done now I "color" a space, otherwise one would need to
>> break down the print statements even more. Since we always color the
>> foreground only it is no problem, is it?
>
> Some people do configure to use "reverse". For example, I have:
>
> [diff.color]
> old = red reverse
> whitespace = blue reverse
>
> [status.color]
> updated = green
> changed = red
> untracked = blue reverse
>
> The output should be consistent between long and short format (I do not
> offhand recall what we do for the long format, though).
Oh, I didn't know about reverse. In this case I have to change the code
and leave the space alone. (The one between ?? and the filename.) Will do.
In the long format, only the file name is colored. Note that in the
short format, it does not make sense to color the file name because one
line may represent two pieces of status information. That is why I color
the two status letters and not the file name.
Michael
^ permalink raw reply
* Re: [PATCH] Add a notice that only certain functions can print color escape codes
From: Michael J Gruber @ 2009-11-27 9:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4B0F82E1.80402@viscovery.net>
Johannes Sixt venit, vidit, dixit 27.11.2009 08:42:
> Junio C Hamano schrieb:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Like this?
>>
>> Yeah, and in addition to "puts", "write(2)" is also not supported, right?
>
> Correct, good catch!
>
> --- 8< ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] Add a notice that only certain functions can print color escape codes
>
> We emulate color escape codes on Windows by overriding printf, fprintf,
> and fputs. Warn users that these are the only functions that can be used
> to print them.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> color.h | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/color.h b/color.h
> index 7d8da6f..3cb4b7f 100644
> --- a/color.h
> +++ b/color.h
> @@ -4,6 +4,11 @@
> /* "\033[1;38;5;2xx;48;5;2xxm\0" is 23 bytes */
> #define COLOR_MAXLEN 24
>
> +/*
> + * IMPORTANT: Due to the way these color codes are emulated on Windows,
> + * write them only using printf(), fprintf(), and fputs(). In particular,
> + * do not use puts() or write().
Nor putchar nor putc... but they're part of the puts family, of course.
More worthwhile then listing those negatives could be a hint on another
positive: color_fprintf and friends which are declared at the end of
color.h.
> + */
> #define GIT_COLOR_NORMAL ""
> #define GIT_COLOR_RESET "\033[m"
> #define GIT_COLOR_BOLD "\033[1m"
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 9:31 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127062013.GA20844@coredump.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:
>
> > On Wed, Nov 25, 2009 at 3:20 PM, Jeff King <peff@peff.net> wrote:
> > > Sure, there are all those downsides. But what is the other option?
> > > Making me use the command line option (or pathspec magic) every
> > > single time I invoke git grep?
> >
> > Yes, but only when you want non-default behavior, not every single
> > time.
>
> Did you miss the part of the thread where I explained that in certain
> repos, I want it one way every single time, and in others, I want it the
> other way?
Guess what. I have a similar problem, only it is that my "git status"
output is _always_ too long, so I always have to page it.
Once upon a time, Junio applied a patch that implied -p with status. I
was overjoyed. He reverted that patch later. Yes, exactly.
So I end up doing "git config --global ps '-p status'" on every new
account (I usually even forget to curse!), and I really cannot see why you
do not do the equivalent "git config fullgrep grep --full-tree" in your
repositories (or even the global thing).
The further benefit is that we stop talking about breaking backwards
compatibility, and we stop talking about making it hard for Git experts to
help newbies.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Johannes Schindelin @ 2009-11-27 9:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4B0F8825.3040107@viscovery.net>
Hi,
On Fri, 27 Nov 2009, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> The list of header files was incomplete because a number of header files
> were added to the code base, but were not added to the list LIB_H that we
> have in the Makefile. This meant that no rebuild was triggered if one of
> the missing headers was changed because we do not have automatic
> dependency tracking, either.
>
> Sidestep the issue by computing the list using $(wildcard).
Funny; I thought that not all header files are library header files, i.e.
not all header changes should trigger a full new build of libgit.a.
Am I wrong?
Ciao,
Dscho
P.S.: Something that comes to mind is the http.h header, which should
really be independent of libgit.a. Which reminds me: do we _still_ tell
libgit.a at _compile time_ whether git-remote-http is compiled with cURL?
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-27 9:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302>
On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:
> Guess what. I have a similar problem, only it is that my "git status"
> output is _always_ too long, so I always have to page it.
>
> Once upon a time, Junio applied a patch that implied -p with status. I
> was overjoyed. He reverted that patch later. Yes, exactly.
>
> So I end up doing "git config --global ps '-p status'" on every new
If only somebody had written a "pager.status" configuration variable,
you could use that. Oh wait. I did. And it shipped in v1.6.0.
> account (I usually even forget to curse!), and I really cannot see why you
> do not do the equivalent "git config fullgrep grep --full-tree" in your
> repositories (or even the global thing).
>
> The further benefit is that we stop talking about breaking backwards
> compatibility, and we stop talking about making it hard for Git experts to
> help newbies.
I guess you missed the part of the thread where I already discussed
this. It was here:
http://article.gmane.org/gmane.comp.version-control.git/133672
-Peff
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-27 10:01 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Barkalow, git
In-Reply-To: <76718490911260927h9ff796bgbebcccab7e52ffbe@mail.gmail.com>
Jay Soffian wrote:
>> toms-mac-mini:git-umlauts tom$ git status
>> # On branch master
>> #
>> # Initial commit
>> #
>> # Changes to be committed:
>> # (use "git rm --cached <file>..." to unstage)
>> #
>> # new file: "U\314\210berla\314\210nge.txt"
>> #
>
> Wait, what's the problem here? It's staged according to the above,
> just commit it.
You are completely right and I feel quite foolish.
What about this one:
toms-mac-mini:git-umlauts tom$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: "U\314\210berla\314\210nge.txt"
#
toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
--
Thanks in advance,
Tom
^ permalink raw reply
* change URL
From: Rakotomandimby Mihamina @ 2009-11-27 9:56 UTC (permalink / raw)
To: git
Hi all,
When I first cloned a project, I used the non fully qualified hostname
if the repo:
$ git clone ssh://git/git/Mailaka
When pushing, it was OK:
$ git push
mihamina@git's password:
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 825 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git/git/Mailaka
1e91a44..8af5c57 master -> master
Now, I am on a slow network, with a different search domain in resolv.conf.
What should I edit to make "git push" uses "git.rktmb.org" rather than "git.domainsearch-in-resolv.conf"?
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 33 11 207 36
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-27 10:20 UTC (permalink / raw)
To: Jay Soffian; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0FA388.4030507@syntevo.com>
Thomas Singer wrote:
> Jay Soffian wrote:
>>> toms-mac-mini:git-umlauts tom$ git status
>>> # On branch master
>>> #
>>> # Initial commit
>>> #
>>> # Changes to be committed:
>>> # (use "git rm --cached <file>..." to unstage)
>>> #
>>> # new file: "U\314\210berla\314\210nge.txt"
>>> #
>> Wait, what's the problem here? It's staged according to the above,
>> just commit it.
>
> You are completely right and I feel quite foolish.
>
> What about this one:
>
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
> toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
OK, I've found it. This works (I have to complete the file name after having
typed an U):
toms-mac-mini:git-umlauts tom$ git rm --cached Überlänge.txt
--
Tom
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Matthieu Moy @ 2009-11-27 10:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Guess what. I have a similar problem, only it is that my "git status"
> output is _always_ too long, so I always have to page it.
>
> Once upon a time, Junio applied a patch that implied -p with status. I
> was overjoyed. He reverted that patch later. Yes, exactly.
In this particular example, a config variable was added (pager.status
= true). But one big difference is that while pager.status = true can
be /annoying/ for some users, it can never really harm (since the
pager will automatically disable itself in the cases where you'd
really don't want it).
OTOH, a config variable that actually changes the beahvior of the
command can indeed harm. Those who ever tried doing portable
programming in PHP, where the apache config can actually change the
semantics of the language probably understand what I mean ;-).
> So I end up doing "git config --global ps '-p status'" on every new
> account (I usually even forget to curse!), and I really cannot see why you
> do not do the equivalent "git config fullgrep grep --full-tree" in your
> repositories (or even the global thing).
(I guess you meant alias.fullgrep)
Maybe "mygrep" or "dwimgrep" would be a better name, except for the
difficulty to type it: the same alias can be defined to different
things on different machines.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 10:53 UTC (permalink / raw)
To: Jeff King; +Cc: James Pickens, Junio C Hamano, git
In-Reply-To: <20091127095914.GA4865@sigill.intra.peff.net>
Hi,
On Fri, 27 Nov 2009, Jeff King wrote:
> On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:
>
> > Guess what. I have a similar problem, only it is that my "git status"
> > output is _always_ too long, so I always have to page it.
> >
> > Once upon a time, Junio applied a patch that implied -p with status.
> > I was overjoyed. He reverted that patch later. Yes, exactly.
> >
> > So I end up doing "git config --global ps '-p status'" on every new
>
> If only somebody had written a "pager.status" configuration variable,
> you could use that. Oh wait. I did. And it shipped in v1.6.0.
And it makes things inconsistent. That is why I do not use it. Do you
work on 10 different computers? I do. And nothing is more unnerving than
the same command producing something different on the different computers.
Sure, after a few minutes of fiddling I find out that it was my fault to
begin with, but dammit! if the tool makes it that hard already for an
expert, it is outright unusable for new users.
I, for one, do not like Git's reputation, but I am tired of trying to
fight for the users. BTW quick question: how many Git _users_ were at the
GitTogether at MV? 0?
> > account (I usually even forget to curse!), and I really cannot see why
> > you do not do the equivalent "git config fullgrep grep --full-tree" in
> > your repositories (or even the global thing).
> >
> > The further benefit is that we stop talking about breaking backwards
> > compatibility, and we stop talking about making it hard for Git
> > experts to help newbies.
>
> I guess you missed the part of the thread where I already discussed
> this. It was here:
>
> http://article.gmane.org/gmane.comp.version-control.git/133672
I only skimmed it, yes. And I did not plan to participate in this thread.
But it seems that my views are not represented enough, even if gitzilla
chimed in with the very valid, under-acknowledged and over-ignored
message: consistency is good. Corollary: inconsistency is bad.
Ciao,
Dscho
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Martin Langhoff @ 2009-11-27 10:56 UTC (permalink / raw)
To: Thomas Singer; +Cc: Jay Soffian, Daniel Barkalow, git
In-Reply-To: <4B0FA7D7.1050302@syntevo.com>
On Fri, Nov 27, 2009 at 11:20 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
>> toms-mac-mini:git-umlauts tom$ git rm --cached "U\314\210berla\314\210nge.txt"
>> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
>
> OK, I've found it. This works (I have to complete the file name after having
> typed an U):
>
> toms-mac-mini:git-umlauts tom$ git rm --cached Überlänge.txt
Tom,
have you tried calling git-update-index --add
--stdin -z? Your original email stated
> we've got a problem report regarding our SmartGit GUI client
so it sounds like you are building a porcelain. In that case, the
sanest approach is to invoke git-update-index and write to its stdin.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-27 10:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, James Pickens, Junio C Hamano, git
In-Reply-To: <vpq8wdsqmm4.fsf@bauges.imag.fr>
Hi,
On Fri, 27 Nov 2009, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Guess what. I have a similar problem, only it is that my "git status"
> > output is _always_ too long, so I always have to page it.
> >
> > Once upon a time, Junio applied a patch that implied -p with status.
> > I was overjoyed. He reverted that patch later. Yes, exactly.
>
> In this particular example, a config variable was added (pager.status =
> true). But one big difference is that while pager.status = true can be
> /annoying/ for some users, it can never really harm (since the pager
> will automatically disable itself in the cases where you'd really don't
> want it).
It changes behavior. And worse: it changes behavior _in a different
manner_ in different repositories. I have too many of them to remember
what I set where.
So it is harmful in a very real sense.
> > So I end up doing "git config --global ps '-p status'" on every new
> > account (I usually even forget to curse!), and I really cannot see why you
> > do not do the equivalent "git config fullgrep grep --full-tree" in your
> > repositories (or even the global thing).
>
> (I guess you meant alias.fullgrep)
You guessed right, and likewise alias.ps.
Ciao,
Dscho
^ permalink raw reply
* Re: change URL
From: Jan Krüger @ 2009-11-27 11:22 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B0FA253.6060804@gulfsat.mg>
Hi,
Rakotomandimby Mihamina <mihamina@gulfsat.mg> wrote:
> When I first cloned a project, I used the non fully qualified hostname
> if the repo:
> $ git clone ssh://git/git/Mailaka
> [...]
> What should I edit to make "git push" uses "git.rktmb.org" rather
> than "git.domainsearch-in-resolv.conf"?
it's in .git/config, and it's rather easy to find there.
Jan
^ permalink raw reply
* [PATCH] pull: clarify advice for the unconfigured error case
From: Jonathan Nieder @ 2009-11-27 14:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jan Krüger, Jeff King, Jan Nieuwenhuizen, Tomas Carnecky,
git list
In-Reply-To: <20091113040754.GA3255@progeny.tock>
From: Jan Krüger <jk@jk.gs>
When pull --rebase fails because it cannot find what branch to
merge against, the error message implies we are trying to merge.
Say "rebase against" instead of "merge with" to avoid confusion.
The configuration suggested to remedy the situation uses a
confusing syntax, with variables specified in the dotted form
accepted by 'git config' but separated from their values by the
'=' delimiter used by config files. Since the user will have to
edit this output anyway, it is more helpful to provide a config
file snippet to paste into an editor and modify.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> Jan Krüger wrote:
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -91,45 +91,56 @@ error_on_no_merge_candidates () {
>[...]
>> if [ $# -gt 1 ]; then
>> - echo "There are no candidates for merging in the refs that you just fetched."
>> + echo "There are no candidates for using the refs that you just fetched."
>> echo "Generally this means that you provided a wildcard refspec which had no"
>> echo "matches on the remote end."
>
> This sounds a little awkward to me, maybe because all the remote refs
> are being used to populate the remotes/<remote>/* hierarchy.
Scratch that --- I was confused.
I still find pull pretty confusing. In its three forms, it does
different things:
- 'git pull' fetches from the current branch’s remote (both its
standard fetch refspec and the current branch’s), then merges any
branches that match the current branch’s refspec.
- 'git pull foo' fetches from the specified remote. If it is
the current branch’s remote, this is just a synonym for
'git pull'; otherwise, it first fetches and then complains.
- 'git pull foo refspec' does a fetch according to the specified
refspec, and if any branches match, merges them into the
current branch.
I was worried about the first form before (but who uses wildcards
in their branches’ refspecs?), but as Peff explains in commit
a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) the third one should be much more common.
In the --rebase case, exactly one branch would have to match for
this to make any sense (there is no such thing as an octopus
rebase), so I reworded the message accordingly.
git-pull.sh | 48 +++++++++++++++++++++++++++++++++---------------
1 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 37f3d93..2c384c4 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -91,45 +91,63 @@ error_on_no_merge_candidates () {
esac
done
+ if test true = "$rebase"
+ then
+ op_type=rebase
+ op_prep=against
+ else
+ op_type=merge
+ op_prep=with
+ fi
+
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
remote=$(git config "branch.$curr_branch.remote")
if [ $# -gt 1 ]; then
- echo "There are no candidates for merging in the refs that you just fetched."
+ if [ "$rebase" = true ]; then
+ printf "There is no candidate for rebasing against "
+ else
+ printf "There are no candidates for merging "
+ fi
+ echo "among the refs that you just fetched."
echo "Generally this means that you provided a wildcard refspec which had no"
echo "matches on the remote end."
elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
echo "You asked to pull from the remote '$1', but did not specify"
- echo "a branch to merge. Because this is not the default configured remote"
+ echo "a branch. Because this is not the default configured remote"
echo "for your current branch, you must specify a branch on the command line."
elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
- echo "Please specify which branch you want to merge on the command"
+ echo "Please specify which remote branch you want to use on the command"
echo "line and try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
elif [ -z "$upstream" ]; then
echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "specify which branch you want to merge on the command line and"
+ echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me, either. Please"
+ echo "specify which branch you want to use on the command line and"
echo "try again (e.g. 'git pull <repository> <refspec>')."
echo "See git-pull(1) for details."
echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
+ echo "If you often $op_type $op_prep the same branch, you may want to"
+ echo "use something like the following in your configuration file:"
+ echo
+ echo " [branch \"${curr_branch}\"]"
+ echo " remote = <nickname>"
+ echo " merge = <remote-ref>"
+ test rebase = "$op_type" &&
+ echo " rebase = true"
echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
+ echo " [remote \"<nickname>\"]"
+ echo " url = <url>"
+ echo " fetch = <refspec>"
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
- echo "remote, but no such ref was fetched."
+ echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
+ echo "from the remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.3
^ permalink raw reply related
* Re: [msysGit] [PATCH/RFC 08/11] daemon: use explicit file descriptor
From: Erik Faye-Lund @ 2009-11-27 14:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911262303.57228.j6t@kdbg.org>
Sorry for the long delay in the reply, but I'm a little low on time
these days (and I've already spent some time trying to figure out what
I was thinking - I wrote these patches a while ago).
On Thu, Nov 26, 2009 at 11:03 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> @@ -372,37 +372,35 @@ static int run_service_command(const char **argv)
>> cld.argv = argv;
>> cld.git_cmd = 1;
>> cld.err = -1;
>> + cld.in = cld.out = fd;
>
> You shouldn't do that. In fact, the next patch 9 has a hunk that correctly
> calls dup() once.
>
OK, as long as it works as expected, sure. But perhaps this needs a
little change (see discussion later)
>> - close(0);
>> - close(1);
>
> Here, stdin and stdout were closed and start_command() used both. But these
> two new calls
>
>> + exit(execute(0, addr));
>> ...
>> + return execute(0, peer);
>
> are the only places where a value is assigned to fd. Now it is always only
> stdin. Where does the old code initialize stdout? Shouldn't this place need a
> change, too?
The "dup2(incoming, 0)"-call in handle() is AFAICT what makes it work
to use the forked process' stdin as both stdin and stdout for the
service-process pipe (since fd 0 now becomes a pipe that is both
readable and writable). This isn't exactly a pretty mechanism, and I
guess I should rework it. At the very least, I should remove the
"dup2(incoming, 1)"-call, but I'm open to other suggestions. Perhaps I
can change this patch to do the entire socket-passing (which is
currently in the next patch)?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Jonathan Nieder @ 2009-11-27 14:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091127065904.GE20844@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 05:03:33PM -0800, Junio C Hamano wrote:
>> * jc/grep-full-tree (2009-11-24) 1 commit.
>> - grep: --full-tree
>>
>> We probably would want test, doc and a configuration variable to make it
>> default (or non-default) before we can merge it to 'master'.
>
> I can try to pick this up. But did we reach a decision on having a
> configuration variable?
I am not sure, but I will say I would prefer not to have one. Surely
we can come up with a UI that does not require searching through
git-config(1) to be made convenient.
Couldn’t we just add the option (with test and documentation) first,
to get some experience with how we end up using the two forms?
If --full-tree does become the default, I think it should be in 1.7.0,
when it is expected for some habits to break (with a configuration
variable for the transition, I guess). This might be okay, since
constructions like 'git grep foo -- "./*.h"' should still work.
^ permalink raw reply
* Breaking expectations in 1.7.0, was Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Johannes Schindelin @ 2009-11-27 14:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091127144553.GA24366@progeny.tock>
Hi,
On Fri, 27 Nov 2009, Jonathan Nieder wrote:
> If --full-tree does become the default, I think it should be in 1.7.0,
> when it is expected for some habits to break (with a configuration
> variable for the transition, I guess).
I recently read more and more about 1.7.0 being expected to break
expectations, and more and more expectations about more and more being
expected to be broken there.
This is a very slippery slope. You have been warned.
Ciao,
Dscho
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 07/11] run-command: support input-fd
From: Erik Faye-Lund @ 2009-11-27 14:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911262253.59641.j6t@kdbg.org>
On Thu, Nov 26, 2009 at 10:53 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> @@ -327,7 +327,10 @@ int start_async(struct async *async)
>> {
>> int pipe_out[2];
>>
>> - if (pipe(pipe_out) < 0)
>> + if (async->out) {
>> + pipe_out[0] = dup(async->out);
>> + pipe_out[1] = dup(async->out);
>> + } else if (pipe(pipe_out) < 0)
>> return error("cannot create pipe: %s", strerror(errno));
>> async->out = pipe_out[0];
>
> Hm. If async->out != 0:
>
> pipe_out[0] = dup(async->out);
> async->out = pipe_out[0];
>
> This is confusing.
What do you find confusing about it? The idea is to use a provided
bi-directional fd instead of a pipe if async->out is non-zero. The
currently defined rules for async is that async->out must be zero
(since the structure should be zero-initialized).
> Moreover, you are assigning (a dup of) the same fd to the writable end. This
> assumes a bi-directional channel. I don't yet know what I should think about
> this (haven't studied the later patches, yet).
>
Indeed it does. Do we want to extend it to support a set of
unidirectional channels instead?
> It would be great if you could add a few words to
> Documentation/technical/api-runcommand.txt.
>
Ah, yes. I know I should update the documentation and all, I'm just
usually really bad (*cough* lazy *cough*) at documenting stuff. But
I'll give it a go and if people hate what I write, they can suggest
changes.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: change URL
From: Michael J Gruber @ 2009-11-27 15:09 UTC (permalink / raw)
To: Jan Krüger; +Cc: Rakotomandimby Mihamina, git
In-Reply-To: <20091127122228.660131af@perceptron>
Jan Krüger venit, vidit, dixit 27.11.2009 12:22:
> Hi,
>
> Rakotomandimby Mihamina <mihamina@gulfsat.mg> wrote:
>
>> When I first cloned a project, I used the non fully qualified hostname
>> if the repo:
>> $ git clone ssh://git/git/Mailaka
>> [...]
>> What should I edit to make "git push" uses "git.rktmb.org" rather
>> than "git.domainsearch-in-resolv.conf"?
>
> it's in .git/config, and it's rather easy to find there.
>
> Jan
:)
git config remote.origin.url ssh://git.rktmb.org/git/Mailaka
Cheers,
Michael
^ permalink raw reply
* Re: qgit question: tagged commits not on a branch
From: Michael J Gruber @ 2009-11-27 15:15 UTC (permalink / raw)
To: Chris.Cheney; +Cc: git
In-Reply-To: <Xns9CCFDEF02D061ChrisCheneytesconet@80.91.229.13>
Chris.Cheney venit, vidit, dixit 26.11.2009 22:54:
> My commit graph has a number of forks (I can't use the word "branches"
> here) that are referenced only by a tag. Whereas gitk --all displays this
> graph including those forks, qgit does not display those forks - I don't
> see a way to make it do so, other than by adding branches to those tagged
> commits.
>
> Have I overlooked something?
>
qgit --all does it for me. It may not be the newest qgit, though.
I use tags like that to mark a version of a topic branch before
rebasing, so that on old version won't be gc'ed away and the branch name
space is not too crowded. Poor man's topgit, so to say. I guess it's a
common use case.
Michael
^ permalink raw reply
* Re: Breaking expectations in 1.7.0, was Re: What's cooking in git.git (Nov 2009, #06; Wed, 25)
From: Jonathan Nieder @ 2009-11-27 15:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0911271536100.4521@intel-tinevez-2-302>
Johannes Schindelin wrote:
> I recently read more and more about 1.7.0 being expected to break
> expectations, and more and more expectations about more and more being
> expected to be broken there.
>
> This is a very slippery slope. You have been warned.
I was trained by 1.6.0 and 1.5.0, I guess. I think it would be hard to
argue that 1.5.0 breaking compatibility in some places (the behavior of
'git add', for example) was a bad thing. I also liked the major 1.6.0
change, but I did have the benefit of being warned far in advance.
Of course, the best break with compatibility is the one that does not
break expectations.
I’m on the fence about the default git grep behavior for that reason.
I think --full-tree really would be a better default. Every once in a
while, I really do find myself wondering why git grep has not given me
the results I expected; it can take a moment to remember that this is
because I am in a subdirectory. But it is not clear it is worth the
change.
Am I right to infer you are less conflicted about this, or was it just
a good opportunity to bring to mind that important principle?
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-11-27 15:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git, Martin Koegler
In-Reply-To: <7vy6lsy9mi.fsf@alter.siamese.dyndns.org>
On Fri, 27 Nov 2009, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > It might be however good *interim* solution, so people would be able
> > to test 'blame_incremental' view without having to edit gitweb links.
>
> Exactly. I thought you were responding to my earlier "ship it as a new
> feature with known breakage so that people can choose to enable to help
> debugging and fixing". If flipping on the new implementation makes an
> alternative working implementation unavailable, that would be one reason
> the site owners might consider _not_ enabling it. By making them both
> available, the result will have one less reason not to try for site
> owners.
Actually "addLinks" would be a bit harder, I guess, than current "fixLinks"
because "fixLinks" just adds ';js=1' to URL to denote that gitweb can use
JavaScript-requiring actions equivalents. For "addLinks" selecting where
to add links would have to be in gitweb.js
I can "borrow" some code from Martin Koegler patch from April 2007
"[PATCH 5/7] gitweb: Prototyp for selecting diffs in JavaScript"
Message-Id: <1176669971921-git-send-email-mkoegler@auto.tuwien.ac.at>
$gmane/44517/focus=44523.
Would turning
"blame"
link ito pair of links
"blame (incremental)"
be a good solution? I'm trying to come up with good naming for extra link
to 'blame_incremental' action...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 0/2] http: allow multi-pass authentication
From: Tay Ray Chuan @ 2009-11-27 15:41 UTC (permalink / raw)
To: git
Cc: Martin Storsjö, Nicholas Miell, gsky51, Clemens Buchacher,
Mark Lodato, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0904150054470.7479@localhost.localdomain>
This patch series applies on top of master. It enables fetching and
pushing over http with the most suitable authentication scheme chosen
by curl when the http.authAny or GIT_HTTP_AUTH_ANY is set.
Authorization headers can also be preserved across requests, with at
least 1 curl session being preserved by default. This is especially
useful for the smart http protocol, where it is hard to rewind and re-
send a request.
Nicholas, Martin's patch should lead to similar functionality as your
patch (dated Oct 3rd) would. However, unlike your patch,
CURLOPT_HTTPAUTH is set even if the user name is not specified
explicitly in the remote url, since it's conditional on
http.c::user_name being set.
I've tested this with Digest, and I believe this should work with NTLM
too.
gsky, could you try this out with NTLM?
=?ISO-8859-15?Q?Martin_Storsj=F6?= (1):
Add an option for using any HTTP authentication scheme, not only
basic
Tay Ray Chuan (1):
http: maintain curl sessions
Documentation/config.txt | 13 +++++++++++++
http.c | 41 +++++++++++++++++++++++++++++++++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH 1/2] http: maintain curl sessions
From: Tay Ray Chuan @ 2009-11-27 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <20091127234110.7b7e9993.rctay89@gmail.com>
Allow curl sessions to be kept alive (ie. not ended with
curl_easy_cleanup()) even after the request is completed, the number of
which is determined by the configuration setting http.minSessions.
Add a count for curl sessions, and update it, across slots, when
starting and ending curl sessions.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Documentation/config.txt | 6 ++++++
http.c | 19 +++++++++++++++++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a8e0876..b77d66d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1132,6 +1132,12 @@ http.maxRequests::
How many HTTP requests to launch in parallel. Can be overridden
by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
+http.minSessions::
+ The number of curl sessions (counted across slots) to be kept across
+ requests. They will not be ended with curl_easy_cleanup() until
+ http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
+ value will be capped at 1. Defaults to 1.
+
http.postBuffer::
Maximum size in bytes of the buffer used by smart HTTP
transports when POSTing data to the remote system.
diff --git a/http.c b/http.c
index ed6414a..fb0a97b 100644
--- a/http.c
+++ b/http.c
@@ -7,6 +7,8 @@ int active_requests;
int http_is_verbose;
size_t http_post_buffer = 16 * LARGE_PACKET_MAX;
+static int min_curl_sessions = 1;
+static int curl_session_count;
#ifdef USE_CURL_MULTI
static int max_requests = -1;
static CURLM *curlm;
@@ -152,6 +154,14 @@ static int http_options(const char *var, const char *value, void *cb)
ssl_cert_password_required = 1;
return 0;
}
+ if (!strcmp("http.minsessions", var)) {
+ min_curl_sessions = git_config_int(var, value);
+#ifndef USE_CURL_MULTI
+ if (min_curl_sessions > 1)
+ min_curl_sessions = 1;
+#endif
+ return 0;
+ }
#ifdef USE_CURL_MULTI
if (!strcmp("http.maxrequests", var)) {
max_requests = git_config_int(var, value);
@@ -372,6 +382,7 @@ void http_init(struct remote *remote)
if (curl_ssl_verify == -1)
curl_ssl_verify = 1;
+ curl_session_count = 0;
#ifdef USE_CURL_MULTI
if (max_requests < 1)
max_requests = DEFAULT_MAX_REQUESTS;
@@ -480,6 +491,7 @@ struct active_request_slot *get_active_slot(void)
#else
slot->curl = curl_easy_duphandle(curl_default);
#endif
+ curl_session_count++;
}
active_requests++;
@@ -558,9 +570,11 @@ void fill_active_slots(void)
}
while (slot != NULL) {
- if (!slot->in_use && slot->curl != NULL) {
+ if (!slot->in_use && slot->curl != NULL
+ && curl_session_count > min_curl_sessions) {
curl_easy_cleanup(slot->curl);
slot->curl = NULL;
+ curl_session_count--;
}
slot = slot->next;
}
@@ -633,12 +647,13 @@ static void closedown_active_slot(struct active_request_slot *slot)
void release_active_slot(struct active_request_slot *slot)
{
closedown_active_slot(slot);
- if (slot->curl) {
+ if (slot->curl && curl_session_count > min_curl_sessions) {
#ifdef USE_CURL_MULTI
curl_multi_remove_handle(curlm, slot->curl);
#endif
curl_easy_cleanup(slot->curl);
slot->curl = NULL;
+ curl_session_count--;
}
#ifdef USE_CURL_MULTI
fill_active_slots();
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/2] Add an option for using any HTTP authentication scheme, not only basic
From: Tay Ray Chuan @ 2009-11-27 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <20091127234226.8b158336.rctay89@gmail.com>
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@martin.st>
This adds the configuration option http.authAny (overridable with
the environment variable GIT_HTTP_AUTH_ANY), for instructing curl
to allow any HTTP authentication scheme, not only basic (which
sends the password in plaintext).
When this is enabled, curl has to do double requests most of the time,
in order to discover which HTTP authentication method to use, which
lowers the performance slightly. Therefore this isn't enabled by default.
One example of another authentication scheme to use is digest, which
doesn't send the password in plaintext, but uses a challenge-response
mechanism instead. Using digest authentication in practice requires
at least curl 7.18.1, due to bugs in the digest handling in earlier
versions of curl.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Martin, I've not made any changes, except to make it apply cleanly.
Documentation/config.txt | 7 +++++++
http.c | 22 ++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b77d66d..a54ede3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1158,6 +1158,13 @@ http.noEPSV::
support EPSV mode. Can be overridden by the 'GIT_CURL_FTP_NO_EPSV'
environment variable. Default is false (curl will use EPSV).
+http.authAny::
+ Allow any HTTP authentication method, not only basic. Enabling
+ this lowers the performance slightly, by having to do requests
+ without any authentication to discover the authentication method
+ to use. Can be overridden by the 'GIT_HTTP_AUTH_ANY'
+ environment variable. Default is false.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index fb0a97b..aeb69b3 100644
--- a/http.c
+++ b/http.c
@@ -7,6 +7,10 @@ int active_requests;
int http_is_verbose;
size_t http_post_buffer = 16 * LARGE_PACKET_MAX;
+#if LIBCURL_VERSION_NUM >= 0x070a06
+#define LIBCURL_CAN_HANDLE_AUTH_ANY
+#endif
+
static int min_curl_sessions = 1;
static int curl_session_count;
#ifdef USE_CURL_MULTI
@@ -36,6 +40,9 @@ static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv;
static const char *curl_http_proxy;
static char *user_name, *user_pass;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+static int curl_http_auth_any = 0;
+#endif
#if LIBCURL_VERSION_NUM >= 0x071700
/* Use CURLOPT_KEYPASSWD as is */
@@ -190,6 +197,12 @@ static int http_options(const char *var, const char *value, void *cb)
http_post_buffer = LARGE_PACKET_MAX;
return 0;
}
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (!strcmp("http.authany", var)) {
+ curl_http_auth_any = git_config_bool(var, value);
+ return 0;
+ }
+#endif
/* Fall back on the default ones */
return git_default_config(var, value, cb);
@@ -240,6 +253,10 @@ static CURL *get_curl_handle(void)
#if LIBCURL_VERSION_NUM >= 0x070907
curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (curl_http_auth_any)
+ curl_easy_setopt(result, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
+#endif
init_curl_http_auth(result);
@@ -391,6 +408,11 @@ void http_init(struct remote *remote)
if (getenv("GIT_CURL_FTP_NO_EPSV"))
curl_ftp_no_epsv = 1;
+#ifdef LIBCURL_CAN_HANDLE_AUTH_ANY
+ if (getenv("GIT_HTTP_AUTH_ANY"))
+ curl_http_auth_any = 1;
+#endif
+
if (remote && remote->url && remote->url[0]) {
http_auth_init(remote->url[0]);
if (!ssl_cert_password_required &&
--
1.6.4.4
^ permalink raw reply related
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