* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Jeff King @ 2007-11-22 22:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dan Zwell, Git Mailing List, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <7v63zu3r7h.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 22, 2007 at 01:28:34PM -0800, Junio C Hamano wrote:
> I think the "config_bool with default" also makes sense but it
> needs to be coded a bit carefully. Issues to consider:
Yes. It is not strictly necessary for this patch series, but I think it
is nice to stake out a claim on the third argument of config_* functions
for consistency sake. But perhaps in the name of avoiding regression, it
should come later, when somebody actually wants to use it.
> (1) Non default form "$r->config_bool('key')" should keep the
> original semantics; missing key in the configuration is the
> same as false (i.e. "undef" in scalar, () in list context).
Yes, this is obviously the most important thing.
> (2) What should be the second parameter in the form to default
> to true? '1'? 'true'? Any kind of "true" value in Perl
> should be accepted?
>
> (3) Same question as (2) but for defaulting to false. Any kind
> of "false"?
Hmm. I am tempted to say "yes, any true or any false value" in that the
point of config_* is to convert git config values to native perl
representations. OTOH, the moral equivalent of
config_color('my.key', 'bold red');
is probably more appropriately
config_bool('my.key', 'true');
so I am fine doing it that way, as well (though I think it makes us
duplicate the "translate these strings into bools" code into perl).
-Peff
^ permalink raw reply
* Re: [PATCH 5/5] Added diff hunk coloring to git-add--interactive
From: Junio C Hamano @ 2007-11-22 22:35 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Git Mailing List, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071122122540.GH12913@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 22, 2007 at 04:56:24AM -0600, Dan Zwell wrote:
>
>> - else { # set up colors
>> - # Grab the 3 main colors in git color string format, with sane
>> - # (visible) defaults:
>> - $prompt_color = Git::color_to_ansi_code(
>> - scalar $repo->config_default('color.interactive.prompt',
>> - 'bold blue'));
>
> These were just added in the last patch. I know sometimes it is worth
> showing the progression of work as the patches go, but in this case, I
> think it is simpler for the reviewers if the first patch which adds a
> chunk of code does it in the final way (even if you need to just say "I
> did it this way because there will be reasons later on.").
If you are suggesting to reorganize the series like this:
1/5 Fix to Git.pm for list context;
2/5 Enhance Git.pm to allow config() methods to take default values;
3/5 Enhance Git.pm with get_color() method;
4/5 Teach git-add--interactive to read color settings from the
config;
5/5 Paint output from git-add--interactive in colors, including
prompt, help and diff hunks.
I think that makes a very good sense. The earlier part of the
series would be independent from colorization of "add -i" and
can go in before everything else to allow other potential users,
e.g. "git remote --color" ;-). I do not see a strong reason to
have the separate "Basic color support with hardcoded color" at
the beginning, either.
I think it is a matter of taste to either:
(1) Squash 4 and 5 in the above list into one; or
(2) Split 5 into separate commits to color different parts.
Perhaps the former would be simpler and more appropriate for
this series.
^ permalink raw reply
* Re: [PATCH] Tweak git-quiltimport to allow more flexible series format
From: Junio C Hamano @ 2007-11-22 23:43 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git, adobriyan
In-Reply-To: <20071122134849.GB6240@localhost.sw.ru>
Alexey Dobriyan <adobriyan@sw.ru> writes:
> Make quiltimport also understand comments following patch name.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
> ---
>
> git-quiltimport.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/git-quiltimport.sh
> +++ b/git-quiltimport.sh
> @@ -63,7 +63,7 @@ tmp_info="$tmp_dir/info"
> commit=$(git rev-parse HEAD)
>
> mkdir $tmp_dir || exit 2
> -for patch_name in $(grep -v '^#' < "$QUILT_PATCHES/series" ); do
> +for patch_name in $(sed -e 's/#.*//' < "$QUILT_PATCHES/series" ); do
> if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
> echo "$patch_name doesn't exist. Skipping."
> continue
Is this consistent with the way quilt groks the series file?
IOW, does quilt forbid patchfile whose name contains a hash, and
anything after a hash on the line is taken as comment?
Can a line in a quilt series file name more than one patchfile?
If so, are they whitespace separated?
^ permalink raw reply
* [PATCH] Allow HTTP proxy to be overridden in config
From: Sam Vilain @ 2007-11-23 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, francois, Sam Vilain
The http_proxy / HTTPS_PROXY variables used by curl to control
proxying may not be suitable for git. Allow the user to override them
in the configuration file.
---
In particular, privoxy will block directories called /ad/ ... d'oh!
Documentation/config.txt | 4 ++++
http.c | 11 +++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ee97df..859a7f3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -515,6 +515,10 @@ specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
is one of "ext" and "pserver") to make them apply only for the given
access method.
+http.proxy::
+ Override the HTTP proxy, normally configured using the 'http_proxy'
+ environment variable (see gitlink:curl[1]).
+
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
diff --git a/http.c b/http.c
index c6fb8ac..8f60d89 100644
--- a/http.c
+++ b/http.c
@@ -24,6 +24,7 @@ char *ssl_cainfo = NULL;
long curl_low_speed_limit = -1;
long curl_low_speed_time = -1;
int curl_ftp_no_epsv = 0;
+char *curl_http_proxy = NULL;
struct curl_slist *pragma_header;
@@ -160,6 +161,13 @@ static int http_options(const char *var, const char *value)
curl_ftp_no_epsv = git_config_bool(var, value);
return 0;
}
+ if (!strcmp("http.proxy", var)) {
+ if (curl_http_proxy == NULL) {
+ curl_http_proxy = xmalloc(strlen(value)+1);
+ strcpy(curl_http_proxy, value);
+ }
+ return 0;
+ }
/* Fall back on the default ones */
return git_default_config(var, value);
@@ -205,6 +213,9 @@ static CURL* get_curl_handle(void)
if (curl_ftp_no_epsv)
curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
+ if (curl_http_proxy)
+ curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
+
return result;
}
--
1.5.3.5
^ permalink raw reply related
* [PATCH] git checkout's reflog: even when detaching the HEAD, say from where
From: Johannes Schindelin @ 2007-11-23 0:20 UTC (permalink / raw)
To: git, gitster
When checking out another ref, the reflogs already record from which
branch you switched. Do that also when switching to a detached HEAD.
While at it, record also when coming _from_ a detached HEAD.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Yeah, took me a long time to take care of this issue.
git-checkout.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index aa724ac..5dc8ddb 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -266,7 +266,7 @@ if [ "$?" -eq 0 ]; then
if test -n "$branch"
then
old_branch_name=`expr "z$oldbranch" : 'zrefs/heads/\(.*\)'`
- GIT_DIR="$GIT_DIR" git symbolic-ref -m "checkout: moving from $old_branch_name to $branch" HEAD "refs/heads/$branch"
+ GIT_DIR="$GIT_DIR" git symbolic-ref -m "checkout: moving from ${old_branch_name:-$old} to $branch" HEAD "refs/heads/$branch"
if test -n "$quiet"
then
true # nothing
@@ -278,7 +278,8 @@ if [ "$?" -eq 0 ]; then
fi
elif test -n "$detached"
then
- git update-ref --no-deref -m "checkout: moving to $arg" HEAD "$detached" ||
+ old_branch_name=`expr "z$oldbranch" : 'zrefs/heads/\(.*\)'`
+ git update-ref --no-deref -m "checkout: moving from ${old_branch_name:-$old} to $arg" HEAD "$detached" ||
die "Cannot detach HEAD"
if test -n "$detach_warn"
then
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Junio C Hamano @ 2007-11-23 0:28 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, francois
In-Reply-To: <1195776420-22075-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> The http_proxy / HTTPS_PROXY variables used by curl to control
> proxying may not be suitable for git. Allow the user to override them
> in the configuration file.
> ---
> In particular, privoxy will block directories called /ad/ ... d'oh!
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 7ee97df..859a7f3 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -515,6 +515,10 @@ specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
> is one of "ext" and "pserver") to make them apply only for the given
> access method.
>
> +http.proxy::
> + Override the HTTP proxy, normally configured using the 'http_proxy'
> + environment variable (see gitlink:curl[1]).
> +
This may work around the issue you cited, but it makes me wonder
if it is a road to insanity. Does the curl library expect that
(1) each and every HTTP talking application that uses the
library offer this kind of knob for its users to tweak, and (2)
users set the knob for each and every one of such application?
I would say if privoxy cannot be tweaked to allow /ad/ in chosen
context (e.g. /ad/ in general is rejected but /objects/ad/ is
Ok), that is what needs to be fixed.
Or it would be the use of such a broken proxy by the user. That
can be fixed and much easily.
^ permalink raw reply
* how to change/fake the time for next commit ?
From: Christian MICHON @ 2007-11-23 0:29 UTC (permalink / raw)
To: git
Hi Git list,
I'd like to recreate a git repo with kernel version, using exclusively
tar.bz2 files.
I already did such approach in the past by script, but usually the
dates of commit are the timestamps of current tar imports. I'd like
the date of commit to match any date I would give (without changing
the time on my linux system): the date I would give would be (of
course) the date of the released version.
example: date of 2.6.23.8 release was 2007-11-16 18:16 UTC, so if I
import linux-2.6.23.8.tar.bz2 into a dedicated "2.6.23.8" branch, I'd
like the commit to have "2007-11-16 18:16 UTC" as date.
Is there a way to do this, by plumbing or porcelain ?
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: how to change/fake the time for next commit ?
From: Johannes Schindelin @ 2007-11-23 0:34 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660711221629j5d294a5dp4771778e38b14962@mail.gmail.com>
Hi,
On Fri, 23 Nov 2007, Christian MICHON wrote:
> I already did such approach in the past by script, but usually the
> dates of commit are the timestamps of current tar imports.
Have you tried setting the environment variables GIT_COMMITTER_DATE and
GIT_AUTHOR_DATE before committing?
Hth,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Han-Wen Nienhuys @ 2007-11-23 0:27 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711210336210.27959@racer.site>
Johannes Schindelin escreveu:
> [WIP: this does not handle tags yet, and it lacks a test script
> as well as documentation.]
>
> This program dumps (parts of) a git repository in the format that
> fast-import understands.
>
> For clarity's sake, it does not use the 'inline' method of specifying
> blobs in the commits, but builds the blobs before building the commits.B
>
> ---
> I am way too tired now to continue, but maybe someone else wants
> to pick up the ball.
>
> Oh, and it relies on "int" being castable to void * and vice
> versa. Is anybody aware of a platform where this can lead to
> problems?
>
> And yes, I will add a copyright when I woke up again.
This one seems to setup a dump of a single branch from the command
line, which then follows the commit structure. Am I missing
something?
The cool thing about git-fast-import is that it reads from stdin, has
a very easy to use programmatic interface, and does not impose any
order on how you enter the information.
This doesn't seem to be mirrored by this script?
I am working on a script for [company] which uses git. Git is a pain
to script for: for every query I need to invoke another git process,
with another command (log, show-ref, cat-file, show, etc.), parse
another output format and/or specify another --pretty=format:%blah
format.
Besides being a nuisance, I actually run git on NFS, and every git
process has to go to NFS a couple times to retrieve the same
information. This has a noticeable performance impact.
It would make my life a lot easier if I could simply open a pipe to a
single process for the duration of the script, and do all my queries
to this one process. Of course, if the repository is changed by
another process, I would have to restart it, but that's manageable. I
could even write a nice Python class that runs both fast-import and
fast-export. I could then have an efficient Python interface to a
git-repository, without needing any library wrapping.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: how to change/fake the time for next commit ?
From: Christian MICHON @ 2007-11-23 0:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711230032320.27959@racer.site>
On Nov 23, 2007 1:34 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Have you tried setting the environment variables GIT_COMMITTER_DATE and
> GIT_AUTHOR_DATE before committing?
cool! yes indeed it helped. ;-)
Thanks Dscho!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-23 1:01 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <fi5743$32p$1@ger.gmane.org>
Hi,
[please Cc me when you reply to my message]
On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:
> This one seems to setup a dump of a single branch from the command line,
> which then follows the commit structure. Am I missing something?
Yes. It should work with "--all", too. In fact, with every rev-list
parameters, even a..b (which would cut off the history up to -- and
including -- a).
> The cool thing about git-fast-import is that it reads from stdin, has a
> very easy to use programmatic interface, and does not impose any order
> on how you enter the information.
>
> This doesn't seem to be mirrored by this script?
Umm. What exactly do you want to reorder? I mean, this program is meant
to dump the complete contents to stdout (whether you redirect it to a file
or edit it with sed does not concern this program). It does that.
Maybe you want to specify if all blobs should be output first, and then
the commits? Or files should be used? But all of these things seem to be
useless to me.
So I am puzzled what you ask for.
> I am working on a script for [company] which uses git. Git is a pain to
> script for: for every query I need to invoke another git process, with
> another command (log, show-ref, cat-file, show, etc.), parse another
> output format and/or specify another --pretty=format:%blah format.
Now I am really puzzled. Git is one of the most easily scriptable
programs I ever saw.
It does not even force you to use certain combinations of scripting
languages, such as Python, Scheme, C++ and PostScript, separated by which
part of the program you want to script.
> Besides being a nuisance, I actually run git on NFS, and every git
> process has to go to NFS a couple times to retrieve the same
> information. This has a noticeable performance impact.
Why don't you just work on a local clone? If it is really performance
critical, and I/O is an issue, you are better off working in a tmpfs.
Once you're done, you push back to the NFS repository (which is
lock-challenged AFAIR, but I guess you know that).
> It would make my life a lot easier if I could simply open a pipe to a
> single process for the duration of the script, and do all my queries to
> this one process. Of course, if the repository is changed by another
> process, I would have to restart it, but that's manageable. I could
> even write a nice Python class that runs both fast-import and
> fast-export. I could then have an efficient Python interface to a
> git-repository, without needing any library wrapping.
There is a minimal python wrapper to libgit-thin, which was one of our
GSoC projects. You might want to look at this if you are really that
unhappy with the existing framework.
As to the niceness of Python classes; this lies definitely in the eyes of
the beholder. For example, I have given up on understanding any part of
your GUB framework.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] bash completion: add diff options
From: Johannes Schindelin @ 2007-11-23 1:11 UTC (permalink / raw)
To: git, gitster
I use "git diff" (the porcelain) really often, and am almost as often
annoyed that the completions do not know how to complete something simple
as --cached. Now they do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
contrib/completion/git-completion.bash | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 599b2fc..58e0e53 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -551,6 +551,20 @@ _git_describe ()
_git_diff ()
{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --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
+ --find-copies-harder --pickaxe-all --pickaxe-regex
+ --text --ignore-space-at-eol --ignore-space-change
+ --ignore-all-space --exit-code --quiet --ext-diff
+ --no-ext-diff"
+ return
+ ;;
+ esac
__git_complete_file
}
--
1.5.3.6.1977.g54d30
^ permalink raw reply related
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Han-Wen Nienhuys @ 2007-11-23 1:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711230050270.27959@racer.site>
2007/11/22, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > The cool thing about git-fast-import is that it reads from stdin, has a
> > very easy to use programmatic interface, and does not impose any order
> > on how you enter the information.
> >
> > This doesn't seem to be mirrored by this script?
>
> Umm. What exactly do you want to reorder? I mean, this program is meant
> to dump the complete contents to stdout (whether you redirect it to a file
> or edit it with sed does not concern this program). It does that.
fast-import does not need to take a complete repository as input, but
can also update lots of branches incrementally, all from one process.
Likewise, it would be nice to have a program that can also dump small
bits of information.
Maybe I'm misunderstanding you, but fast-export just does not seem a
mirror of fast-import; perhaps you can name it 'dump-all' or
something?
> Maybe you want to specify if all blobs should be output first, and then
> the commits? Or files should be used? But all of these things seem to be
> useless to me.
No, I want the program to wait for me to tell it what
blobs/commits/trees I want. The commit I want to see secondly may
depend on the output I read in the first request blob. Right now, for
each data dependency I have to start a new git process.
> > Besides being a nuisance, I actually run git on NFS, and every git
> > process has to go to NFS a couple times to retrieve the same
> > information. This has a noticeable performance impact.
>
> Why don't you just work on a local clone? If it is really performance
> critical, and I/O is an issue, you are better off working in a tmpfs.
In a company setting, NFS is the easiest way to share information with
colleagues without breaking access control and making our security
staff nervous. It's also snapshotted and backed up automatically.
> > It would make my life a lot easier if I could simply open a pipe to a
> > single process for the duration of the script, and do all my queries to
> > this one process. Of course, if the repository is changed by another
> > process, I would have to restart it, but that's manageable. I could
> > even write a nice Python class that runs both fast-import and
> > fast-export. I could then have an efficient Python interface to a
> > git-repository, without needing any library wrapping.
>
> There is a minimal python wrapper to libgit-thin, which was one of our
> GSoC projects. You might want to look at this if you are really that
> unhappy with the existing framework.
What's the status of this? I prefer not to diverge from mainline too much.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: Git Screencast ?
From: Michael Donaghy @ 2007-11-23 1:47 UTC (permalink / raw)
To: git
In-Reply-To: <47453C6D.1080403@op5.se>
Andreas Ericsson wrote:
> Michael Donaghy wrote:
>> I am a new user of git and SCMs in general , I have learned a lot from
>> the docs , irc and just using it , but there are just some concepts
>> that hare hard to grasp , I am a very visual persion (probably like a
>> lot of you :) ) , is there a screencast of git somewhere (for free)
>> that can demonstrate some of the advanced features of git...
>> (Also...I have seen both Randal (Schwartz) and Linus' (you better know
>> his last name) presentations at google on git , in which they explain
>> the ideas behind git more than the actual usage,
>>
>
> The thing that helped me and my co-workers the most was running through
> the steps of the tutorial, but stopping every time something wasn't
> absolutely crystal clear and doing gitk or qgit (I prefer qgit, since
> it seems to display things more consistently and also loads faster).
>
> That primarily helped us get branches under control. We came from a
> CVS world and never had any branches, as none of us had time or energy
> to figure out how to merge them back together using those crippled scm's.
>
> I noticed Johannes Gilger already sent you the link to git-for-scientists
> thing which is also a really good aid, especially when you've read the
> tutorial and some of the less tech-oriented docs.
>
Yes thank you , although a screen cast would still be ideal , the
documentation is very good,
also , what do you think of git-gui ? , I think it is the best one
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-23 2:11 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <f329bf540711221723g2754ce03r4da6d429c45668c@mail.gmail.com>
Hi,
On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:
> Maybe I'm misunderstanding you, but fast-export just does not seem a
> mirror of fast-import; perhaps you can name it 'dump-all' or something?
It is a mirror. It does not necessarily dump all.
> > Maybe you want to specify if all blobs should be output first, and
> > then the commits? Or files should be used? But all of these things
> > seem to be useless to me.
>
> No, I want the program to wait for me to tell it what
> blobs/commits/trees I want. The commit I want to see secondly may depend
> on the output I read in the first request blob. Right now, for each data
> dependency I have to start a new git process.
It does not seem like you want a mirror of fast-import, but rather a
driver. You might be happy to hear that you can do that already. Today.
However, you probably want to query different programs about certain
states of the repository. This will not change.
> > > Besides being a nuisance, I actually run git on NFS, and every git
> > > process has to go to NFS a couple times to retrieve the same
> > > information. This has a noticeable performance impact.
> >
> > Why don't you just work on a local clone? If it is really performance
> > critical, and I/O is an issue, you are better off working in a tmpfs.
>
> In a company setting, NFS is the easiest way to share information with
> colleagues without breaking access control and making our security staff
> nervous. It's also snapshotted and backed up automatically.
So?
How does that prevent you from following my suggestion to do the intensive
tasks locally, and push when you finished?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Sam Vilain @ 2007-11-23 3:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, francois
In-Reply-To: <7voddl24b7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> The http_proxy / HTTPS_PROXY variables used by curl to control
>> proxying may not be suitable for git. Allow the user to override them
>> in the configuration file.
>> ---
>> In particular, privoxy will block directories called /ad/ ... d'oh!
>> +++ b/Documentation/config.txt
>> +http.proxy::
>> + Override the HTTP proxy, normally configured using the 'http_proxy'
>> + environment variable (see gitlink:curl[1]).
>
> This may work around the issue you cited, but it makes me wonder
> if it is a road to insanity. Does the curl library expect that
> (1) each and every HTTP talking application that uses the
> library offer this kind of knob for its users to tweak, and (2)
> users set the knob for each and every one of such application?
This is true. However I still think that it is a useful feature for
many users, with few side effects. If nothing else the bit on the man
page will prompt them to think, "oh, I should set that in the environment".
> I would say if privoxy cannot be tweaked to allow /ad/ in chosen
> context (e.g. /ad/ in general is rejected but /objects/ad/ is
> Ok), that is what needs to be fixed.
> Or it would be the use of such a broken proxy by the user. That
> can be fixed and much easily.
Yes - but consider the dilemma of the user. They've apt-get installed
this privoxy thing and figured out how to set their applications to use
it. Now, it doesn't work and they think it is the proxy in the way, and
they've no idea that they might be able to reconfigure it. This way
they can tell git to bypass it.
I don't know, I see your point and pretty much agree with it. It just
seems like something that might come in handy (as well as be another
vector for something you need to check when you get HTTP fetch issues -
so maybe a command-line option would be better).
Actually something that would really have helped is more documentation
of the various GIT_CURL_* environment variables available for debugging.
--
Sam Vilain, Chief Yak Shaver, Catalyst IT (NZ) Ltd.
phone: +64 4 499 2267 PGP ID: 0x66B25843
^ permalink raw reply
* Re: [PATCH 2/5] Don't return 'undef' in case called in a vector context.
From: Dan Zwell @ 2007-11-23 4:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Jeff King, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <7vd4u23rpg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Dan Zwell <dzwell@zwell.net> writes:
>
>> diff --git a/perl/Git.pm b/perl/Git.pm
>> index dca92c8..6603762 100644
>> --- a/perl/Git.pm
>> +++ b/perl/Git.pm
>> @@ -508,7 +508,7 @@ sub config {
>> my $E = shift;
>> if ($E->value() == 1) {
>> # Key not found.
>> - return undef;
>> + return;
>> } else {
>> throw $E;
>> }
>
> Shouldn't the same fix made to config_bool as well?
>
I didn't realize it at the time, but yes, config_bool needs this (though
the only time config_bool is evaluated in a list context should be when
it is evaluated as an argument to another function). I'll make the change.
Dan
^ permalink raw reply
* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Dan Zwell @ 2007-11-23 5:32 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <20071122223050.GC3620@sigill.intra.peff.net>
Jeff King wrote:
>> (2) What should be the second parameter in the form to default
>> to true? '1'? 'true'? Any kind of "true" value in Perl
>> should be accepted?
>>
>> (3) Same question as (2) but for defaulting to false. Any kind
>> of "false"?
>
> Hmm. I am tempted to say "yes, any true or any false value" in that the
> point of config_* is to convert git config values to native perl
> representations. OTOH, the moral equivalent of
>
> config_color('my.key', 'bold red');
>
> is probably more appropriately
>
> config_bool('my.key', 'true');
>
> so I am fine doing it that way, as well (though I think it makes us
> duplicate the "translate these strings into bools" code into perl).
>
As you said, config_* converts git values to perl values. However, that
conversion needs only be done for strings in .gitconfig. Is there any
reason why the caller of the function would need to pass a string
"false"? I just don't see the need for conversion of any kind.
Further, I think that we could return the default variable directly,
without parsing it at all. It would be much simpler, and there would
need to be no special cases for dealing with undef or 'false'. It's a
perl function, being called with perl arguments, so a user should not be
that surprised when 'false' does what perl says it should do.
Dan
^ permalink raw reply
* Re: how to change/fake the time for next commit ?
From: Johannes Sixt @ 2007-11-23 7:20 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660711221629j5d294a5dp4771778e38b14962@mail.gmail.com>
Christian MICHON schrieb:
> I'd like to recreate a git repo with kernel version, using exclusively
> tar.bz2 files.
There's contrib/fast-import/import-tars.perl.
-- Hannes
^ permalink raw reply
* Re: Temporary directories getting errantly added into trees
From: Karl Hasselström @ 2007-11-23 8:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711221052280.27959@racer.site>
On 2007-11-22 10:55:00 +0000, Johannes Schindelin wrote:
> But I don't know about QGit, StGit, etc...
I don't think StGit relies on the name of any file outside .git. (It
does pollute the root of the worktree with some temp files of its own,
though -- but not across invocations.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-23 8:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vsl30eyuk.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
I ran out of time while re-reviewing the stalled topics to
decide what to do with them, and many of them are left out of
'pu' branch for tonight, even though I haven't dropped them
entirely from my repository yet.
A funny thing is, 'pu' passes most of the testsuite thanks to
this temporary droppage. The tip of 'pu' hasn't passed the
tests for quite some time.
New tests for svn-info seem to be failing in my private
repository at k.org; I haven't tried to look into it yet.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
+ Move gitk to its own subdirectory
I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.
* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits
+ Bisect reset: do nothing when not bisecting.
+ Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
+ Bisect visualize: use "for-each-ref" to list all good refs.
+ git-bisect: modernize branch shuffling hack
+ git-bisect: use update-ref to mark good/bad commits
+ git-bisect: war on "sed"
+ Bisect reset: remove bisect refs that may have been packed.
Will merge by the weekend (if I can find time, that is).
* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
+ Do git reset --hard HEAD when using git rebase --skip
After seeing a conflicted rebase, you may decide to skip that
patch but then you would need "git reset --hard" before saying
"git rebase --skip". This teaches "git rebase --skip" to
automatically discard the conflicted rebase for you.
Will merge by the weekend.
* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
+ Remove hint to use "git help -a"
+ Make the list of common commands more exclusive
Some people on the list may find the exact list of commands
somewhat debatable. We can fine-tune that in-tree ('pu' does
not count as "in-tree").
* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits
+ fetch-pack: Prepare for a side-band demultiplexer in a thread.
+ rehabilitate some t5302 tests on 32-bit off_t machines
+ Allow ETC_GITCONFIG to be a relative path.
+ Introduce git_etc_gitconfig() that encapsulates access of
ETC_GITCONFIG.
+ Allow a relative builtin template directory.
+ Close files opened by lock_file() before unlinking.
+ builtin run_command: do not exit with -1.
+ Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
util.h.
+ Use is_absolute_path() in sha1_file.c.
+ Skip t3902-quoted.sh if the file system does not support funny
names.
+ t5302-pack-index: Skip tests of 64-bit offsets if necessary.
+ t7501-commit.sh: Not all seds understand option -i
+ t5300-pack-object.sh: Split the big verify-pack test into smaller
parts.
A set of good general clean-up patches.
* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
+ Teach git clean to use setup_standard_excludes()
+ git-clean: Fix error message if clean.requireForce is not set.
+ Make git-clean a builtin
* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.
* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
+ send-pack: cluster ref status reporting
+ send-pack: fix "everything up-to-date" message
+ send-pack: tighten remote error reporting
+ make "find_ref_by_name" a public function
+ Fix warning about bitfield in struct ref
+ send-pack: assign remote errors to each ref
+ send-pack: check ref->status before updating tracking refs
+ send-pack: track errors for each ref
+ Merge branch 'aw/mirror-push' into jk/send-pack
+ Merge branch 'ar/send-pack-remote-track' into jk/send-pack
+ Merge branch 'db/remote-builtin' into jk/send-pack
+ git-push: add documentation for the newly added --mirror mode
+ Add tests for git push'es mirror mode
+ Update the tracking references only if they were succesfully
updated on remote
+ Add a test checking if send-pack updated local tracking branches
correctly
+ git-push: plumb in --mirror mode
+ Teach send-pack a mirror mode
+ Merge master into aw/mirror-push
+ Merge branch 'jk/terse-push' into aw/mirror-push
+ send-pack: segfault fix on forced push
+ Reteach builtin-ls-remote to understand remotes
+ send-pack: require --verbose to show update of tracking refs
+ receive-pack: don't mention successful updates
+ more terse push output
+ Build in ls-remote
+ Build-in send-pack, with an API for other programs to call.
+ Use built-in send-pack.
+ Build-in peek-remote, using transport infrastructure.
+ Miscellaneous const changes and utilities
Various improvements on status reporting and error handling by
send-pack, and implementation of "mirror" pushing.
----------------------------------------------------------------
[Actively cooking]
* kh/commit (Thu Nov 22 16:21:49 2007 -0800) 23 commits
+ Add a few more tests for git-commit
+ builtin-commit: Include the diff in the commit message when
verbose.
+ builtin-commit: fix partial-commit support
+ Fix add_files_to_cache() to take pathspec, not user specified list
of files
+ Export three helper functions from ls-files
+ builtin-commit: run commit-msg hook with correct message file
+ builtin-commit: do not color status output shown in the message
template
+ file_exists(): dangling symlinks do exist
+ Replace "runstatus" with "status" in the tests
+ t7501-commit: Add test for git commit <file> with dirty index.
+ builtin-commit: Clean up an unused variable and a debug fprintf().
+ Call refresh_cache() when updating the user index for --only
commits.
+ builtin-commit: Add newline when showing which commit was created
+ builtin-commit: resurrect behavior for multiple -m options
+ builtin-commit --s: add a newline if the last line was not a S-o-b
+ builtin-commit: fix --signoff
+ git status: show relative paths when run in a subdirectory
+ builtin-commit: Refresh cache after adding files.
+ builtin-commit: fix reflog message generation
+ launch_editor(): read the file, even when EDITOR=:
+ Port git commit to C.
+ Export launch_editor() and make it accept ':' as a no-op editor.
+ Add testcase for amending and fixing author in git commit.
Although I found the fd shuffling somewhat distasteful, overall
the series seems reasonably stable so it is in 'next'.
* cr/tag-options (Thu Nov 22 23:16:51 2007 -0800) 2 commits
+ builtin-tag: accept and process multiple -m just like git-commit
+ Make builtin-tag.c use parse_options.
The handling of multiple -m options are made consistent with
what git-commit does; i.e. they are concatenated as separate
paragraphs.
* wc/add-i (Thu Nov 22 01:47:13 2007 -0800) 3 commits
+ git-add -i: allow multiple selection in patch subcommand
+ Add path-limiting to git-add--interactive
+ Teach builtin-add to pass multiple paths to git-add--interactive
This still does not have the "directly invoke 'patch' subcommand
and exit after the interaction without coming back to the menu"
part.
* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
+ refactor fetch's ref matching to use refname_match()
+ push: use same rules as git-rev-parse to resolve refspecs
+ add refname_match()
+ push: support pushing HEAD to real branch name
These are the uncontroversial bits from the series.
The "--matching" patch was dropped; I do not know what will
happen to the "--current" thing. I'd prefer to postpone the
discussion until jk/send-pack topic stabilizes and graduates.
* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
+ git-branch --contains: doc and test
+ git-branch --contains=commit
+ parse-options: Allow to hide options from the default usage.
Contains Pierre's "hidable options with --help-all" patch.
----------------------------------------------------------------
[Approaching 'next']
----------------------------------------------------------------
[Others]
* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
- test format-patch -s: make sure MIME content type is shown as
needed
- format-patch -s: add MIME encoding header if signer's name
requires so
This is to apply to 'maint' later; the equivalent fix is already
in 'master'.
* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
- Fix rev-list when showing objects involving submodules
This is to apply to 'maint' later; the equivalent fix is already
in 'next' and will be merged to 'master' soon.
----------------------------------------------------------------
[Stalled]
* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
- revert/cherry-pick: start refactoring call to merge_recursive
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
The second one could probably be used to replace the use of
path-list in the tip commit on the kh/commit series.
* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
- Added diff hunk coloring to git-add--interactive
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
There were many good suggestions by Jeff to the updated series;
hopefully we can replace these three with it.
* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
+ Add missing inside_work_tree setting in setup_git_directory_gently
There was an additional patch, which still had issues Dscho
pointed out. Waiting for refinements.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
. Make git-svn rebase --dirty pass along --dirty to git-rebase.
. Implement --dirty for git-rebase--interactive.
. Introduce --dirty option to git-rebase, allowing you to start from
a dirty state.
This seems to be optimized for the --dirty case too much. I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
. handle renames using similarity engine
. introduce generic similarity library
. change hash table calling conventions
This was an attempt to use different strategy to speed up
similarity computation, but does not work quite well as is.
^ permalink raw reply
* Re: [PATCH] Converted git-merge-ours.sh -> builtin-merge-ours.c
From: Junio C Hamano @ 2007-11-23 8:49 UTC (permalink / raw)
To: Thomas Harning; +Cc: git, thomas.harning
In-Reply-To: <4745E45C.7@gmail.com>
Thomas Harning <harningt@gmail.com> writes:
> Here's a simple patch to make git-merge-ours.sh into a builtin.
>
> I figure this would be a simple way of getting in the git-development flow.
>
> Signed-off-by: Thomas Harning Jr <harningt@gmail.com>
Have you tried to read this proposed commit log message in the
context of "git log", after applying it on top of 'master'?
"Here's a simple patch to" and "I figure ..." are of not much
use.
The patch looks good except for minor style nits.
> diff --git a/builtin-merge-ours.c b/builtin-merge-ours.c
> new file mode 100644
> index 0000000..fbfe183
> --- /dev/null
> +++ b/builtin-merge-ours.c
> @@ -0,0 +1,32 @@
> +/*
> + * Implementation of git-merge-ours.sh as builtin
> + *
Traling whitespace.
> +int cmd_merge_ours(int argc, const char **argv, const char *prefix)
> +{
> + const char *nargv[] = {
> + "diff-index",
> + "--quiet",
> + "--cached",
> + "HEAD",
> + NULL
> + };
> + int i;
> +
> + int ret = cmd_diff_index(4, nargv, prefix);
> + printf("GOT: %i\n", ret);
Unused variable "i".
An unwanted blank line still in the sequence of variable
definitions, and a missing blank line after the definitions.
A leftover debug printf() is not very welcomed.
[Not a nit but a comment]
The call to cmd_diff_index() here raised my eyebrow a
bit. I would have skipped all the parameter parsing and
arranged it to directly call into run_diff_index()
instead.
As the result of literally translating the scripted
version of git-merge-ours, the code inherits a
corner-case bug. Can you spot it?
> + /* We need to exit with 2 if the index does not match our HEAD tree,
> + * because the current index is what we will be committing as the
> + * merge result.
> + */
We tend to format a multi-line comment block as:
/*
* We need to ...
* ... merge result.
*/
> + if(ret) ret = 2;
A SP between "if" and "("; put the body of the "if" on a
separate line.
Thanks. No need to resend; all these minor nits can be fixed
here easily.
^ permalink raw reply
* Re: Reordering lines in "git-rebase -i" task sheet
From: Andy Parkins @ 2007-11-23 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vlk8q7hzg.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Could we please reorder the lines so that list of initial
> "pick"s come first and have the help comment lines at the very
> end?
I'm not convinced that this is a great idea.
Mostly with git-rebase -i one is reordering the most recent commits, which
are at the bottom. Personally, I am often reordering commits that are as
yet unpushed, so for ease-of-thinking I type
git rebase -i origin/master
again and again. Hence the early lines are probably already sorted into a
nice order and it's commits at the bottom of the list that need a bit of
massaging.
At present it's easy to get to them because a shift-G or ctrl-end, or
$END_OF_FILE takes you there. With the above change it's now more steps
to move to the interesting part.
Now if you were suggesting flipping the sort direction at the same time, I
could get on board - but that is perhaps one confusing step too far.
> That is the reason why git commit leaves the first line empty in
> its initial template. It is to allow the user to immediately
> start typing.
That's different, for a commit message, the first line is exactly where one
would want to be.
Not a strong objection.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Jeff King @ 2007-11-23 9:09 UTC (permalink / raw)
To: Dan Zwell
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce,
Wincent Colaiuta, Jonathan del Strother, Johannes Schindelin,
Frank Lichtenheld, Jakub Narebski
In-Reply-To: <474665E0.1010104@zwell.net>
On Thu, Nov 22, 2007 at 11:32:16PM -0600, Dan Zwell wrote:
> Further, I think that we could return the default variable directly, without
> parsing it at all. It would be much simpler, and there would need to be no
> special cases for dealing with undef or 'false'. It's a perl function, being
> called with perl arguments, so a user should not be that surprised when
> 'false' does what perl says it should do.
I think that is more elegant for config_bool, but it means that
config_bool and config_color have slightly different behaviors (the
difference being that it is easy to feed a native perl value as the
default to config_bool, but to get the same behavior for config_color,
you would call Git::color_to_ansi_code manually, which is a pain).
In this instance, I am inclined to sacrifice consistency for convenience
and make it:
my $bool = config_bool('my.key', 0);
my $color = config_color('my.key', 'bold red');
Note that there is one tricky part of config_bool, which is what
config_bool('my.key', undef) should do (is it "default false" or "no
default"?).
-Peff
^ permalink raw reply
* Re: [PATCH 4/5] Let git-add--interactive read colors from configuration
From: Junio C Hamano @ 2007-11-23 9:17 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Git Mailing List, Shawn O. Pearce, Wincent Colaiuta,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld,
Jakub Narebski
In-Reply-To: <20071123090918.GC5196@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Note that there is one tricky part of config_bool, which is what
> config_bool('my.key', undef) should do (is it "default false" or "no
> default"?).
I am glad somebody finally got to the trick question I posed
earlier ;-)
But config_bool('key') and config_bool('key', undef) would both
return undef to say "The value is false" when key does not
exist, so it was not much of a trick. It does not make a
difference if the undef came because the default parameter was
undef, or because there was no default parameter given and the
built-in behaviour of config_bool() was to return undef for a
missing key.
^ 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