* Re: [RFC PATCH 0/6] Second round of committag series
From: Jakub Narebski @ 2009-11-20 23:24 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, Petr Baudis, Giuseppe Bilotta, Francis Galiegue
In-Reply-To: <1258525350-5528-1-git-send-email-marcel@oak.homeunix.org>
On Wed, 18 Nov 2009, Marcel M. Cary wrote:
> Thanks for the feedback. I've added four more patches to the end of
> the series and updated the first two. My replies are below.
>
> On Mon, 22 Jun 2009, Jakub Narebski wrote:
> > On Fri, 19 June 2009, Marcel M. Cary wrote:
Thanks for working on this. I'll try to reply soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: Junio C Hamano @ 2009-11-20 22:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258723430-31684-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> It seems this is the value most users set, so let's make it the default.
Maybe in 1.7.0, but I think using .gitignore will conflict with people who
put the entire $HOME under git (I think they are misguided, but that is
besides the point), so it should use some different name.
^ permalink raw reply
* Re: [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Junio C Hamano @ 2009-11-20 22:42 UTC (permalink / raw)
To: Phil Miller; +Cc: Git Mailing List
In-Reply-To: <81f018ac0911200805g55bd1607u651334c1ed7f1303@mail.gmail.com>
Phil Miller <mille121@illinois.edu> writes:
> The Gitosis single-account Git/ssh hosting system runs git commands
> through git-shell after confirming that the connecting user is
> authorized to access the requested repository. This works well for
> upload-pack and receive-pack, which take a repository argument through
> git-shell. This doesn't work so well for `cvs server', which is passed
> through literally, with no arguments. Allowing arguments risks
> sneaking in `--export-all', so that restriction should be maintained.
>
> Despite that, passing a list of repository roots is necessary for
> per-user access control by the hosting software, and passing a base
> path improves usability without weakening security. Thus,
> git-cvsserver needs to come up with these values at runtime by some
> other means. Since git-shell preserves the environment for other
> purposes, the environment can carry these arguments as well.
>
> Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
> the absence of equivalent command line arguments.
>
> Signed-off-by: Phil Miller <mille121@illinois.edu>
> ---
Thanks.
Any comments from cvsserver users?
> git-cvsserver.perl | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 6dc45f5..9e58d2a 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -104,6 +104,7 @@ $log->info("--------------- STARTING -----------------");
> my $usage =
> "Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
> " --base-path <path> : Prepend to requested CVSROOT\n".
> + " Can be read from GIT_CVSSERVER_BASE_PATH\n".
> " --strict-paths : Don't allow recursing into subdirectories\n".
> " --export-all : Don't check for gitcvs.enabled in config\n".
> " --version, -V : Print version information and exit\n".
> @@ -111,7 +112,8 @@ my $usage =
> "\n".
> "<directory> ... is a list of allowed directories. If no directories\n".
> "are given, all are allowed. This is an additional restriction, gitcvs\n".
> - "access still needs to be enabled by the gitcvs.enabled config option.\n";
> + "access still needs to be enabled by the gitcvs.enabled config option.\n".
> + "Alternately, these directories may be specified in
> GIT_CVSSERVER_ROOTS.\n";
When you introduce a single variable holding multiple values, you need to
document how to cram the values into it. Maybe such a detail isn't
necessary in this usage text, but definitely in the documentation.
Documentation/git-cvsserver.txt needs to be updated to describe the
features added by this patch.
By the way, this patch is line-wrapped. Here, and...
> my @opts = ( 'help|h|H', 'version|V',
> 'base-path=s', 'strict-paths', 'export-all' );
> @@ -148,6 +150,23 @@ if ($state->{'export-all'} &&
> !@{$state->{allowed_roots}}) {
... also here.
> die "--export-all can only be used together with an explicit whitelist\n";
> }
>
> +# Environment handling for running under git-shell
> +if ($ENV{GIT_CVSSERVER_BASE_PATH}) {
It probably is more kosher to say
if (exists $ENV{...})
as the base_path _could_ be '0' that evaluates to false. When the path
does not begin with a '/', what will it be relative to? Do we want to
document it (not a rhetorical question)?
> + if ($state->{'base-path'}) {
> + die "Cannot specify base path both ways.\n";
> + }
> + my $base_path = $ENV{GIT_CVSSERVER_BASE_PATH};
> + $state->{'base-path'} = $base_path;
> + $log->debug("Picked up base path '$base_path' from environment.\n");
> +}
> +if ($ENV{GIT_CVSSERVER_ROOTS}) {
> + if (@{$state->{allowed_roots}}) {
> + die "Cannot specify roots both ways: @ARGV\n";
> + }
> + my @allowed_root = split(',', $ENV{GIT_CVSSERVER_ROOTS});
> + $state->{allowed_roots} = [ @allowed_root ];
Even though a comma is probably rare in pathname components, I do not know
if this is good.
How much thought went into choosing comma for this purpose? Is there a
particular reason you chose ',' as the separator? That should be
documented in the commit log message.
Logical alternative choices are "split at whitespace" (mimics the way how
command line argument splitting works) and "colon" (mimics the way how
$PATH is split into component paths).
If a pathname component with whitespaces (Windows and Macs?) is not an
issue, I would imagine "split at whitespace" is much more natural way to
handle this, but probably many people have "My Programs" and such.
Especially because it is hard, if not impossible, to have a pathname
component that contains a colon on Windows, I suspect that a colon is much
rare compared to whitespaces and commas in the name of people's
directories and files. It might be better to split at colon like $PATH is
handled than using a comma, if you are not going to give any escape
mechanism to .
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Brandon Casey @ 2009-11-20 21:46 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T201341-834@post.gmane.org>
On Fri, Nov 20, 2009 at 07:15:40PM +0000, Derek wrote:
> Unfortunately I need 1.5.4.2 version specifically as I want it to work with
> gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
I didn't see anywhere on that page that says git version 1.5.4.2
specifically must be used. Did I miss it? or is it possible that a more
recent version of git would be compatible with that backup system?
The latest release is v1.6.5.3
-brandon
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 21:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <7v1vjsx6f5.fsf@alter.siamese.dyndns.org>
On vendredi 20 novembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> >> I wonder if this switch deserves run-time flippability, though...
> >
> > The following patch in master added run-time flippability to many
> > commands:
>
> What I meant was not that. I was wondering if the user wants to flip
> from the gitk GUI without restarting gitk.
Ah ok, yes this would be nice. But anyway I think the current patch is a
first good step.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 20:56 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Tarmigan, git, peff, jaysoffian, spearce
In-Reply-To: <20091120201116.GA19131@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Fri, Nov 20, 2009 at 11:03:13AM -0800, Tarmigan wrote:
>
>> Here's a patch (cut-n-paste so it will probably be munged) for
>> discussion of the port-fallback idea. If httpd cannot bind to 5541,
>> it tries 15541 etc.
>
> I would prefer if we skip the test right away.
Retrying is a different issue, and when tests are enabled I think it is Ok
to retry all you want.
But I don't want to see them enabled unless the user explicitly told us
to.
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Junio C Hamano @ 2009-11-20 20:55 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Michael J Gruber, Jakub Narebski,
Johannes Sixt, bill lam, Andreas Schwab, Paul Mackerras
In-Reply-To: <200911202142.39520.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> I wonder if this switch deserves run-time flippability, though...
>
> The following patch in master added run-time flippability to many commands:
What I meant was not that. I was wondering if the user wants to flip from
the gitk GUI without restarting gitk.
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 20:54 UTC (permalink / raw)
To: Tarmigan; +Cc: git, peff, jaysoffian, drizzd, spearce
In-Reply-To: <905315640911201103w6d1da86duf41a53537672be8e@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> On Fri, Nov 20, 2009 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Tarmigan <tarmigan+git@gmail.com> writes:
>>
>>> With smart http, git over http is likely to become much more common.
>>> To increase testing of smart http, enable the http tests by default.
>>
>> Sorry, but no test that listens to network ports should be enabled by
>> default; otherwise it will break automated, unattended tests people have
>> already set up randomly, depending on when the port happens to be
>> available for use by the tests.
>
> Is this the only concern or are there security or other issues as well?
I thought security was too obvious to mention.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-11-20 20:51 UTC (permalink / raw)
To: David Aguilar; +Cc: Paul Mackerras, peff, sam, git
In-Reply-To: <20091120185522.GC56351@gmail.com>
David Aguilar <davvid@gmail.com> writes:
>> > Also, I don't think we should remove the ability for the user to
>> > choose which external diff tool to use.
>>
>> This is a larger concern. Does "difftool" allow use of an arbitrary tool
>> like how gitk does (I have a suspicion that it is not as flexible)?
>
> difftool supports arbitrary tools through configuration.
> For arbitrary tools we set difftool.$name.cmd and
> diff.tool = $name.
So it is not as flexible as just giving a command line template for
one-shot invocation, but that is Ok.
Don't get me wrong. I think the longer term direction should be to reduce
code from gitk without making lifes harder to existing users, and just
like built-in "diff --cc" stripped the combined-diff implemented in Tcl
from gitk, use of "difftool" would be a good way to unify the "diffing"
experience for a user who uses both command line and gitk at the same
time.
I do not read Tcl very well but I am guessing that in gitk you specify
what tool to run (e.g. "frobanodiff -z"), gitk feeds you two temporary
files on the filesystem to compare (e.g. "frobanodiff -z $tmp1 $tmp2"),
and your command line is responsible for giving satisfying diff experience
to the end user.
I see three possible approaches:
* Teach "git-difftool" a mode to compare two arbitrary files on the
filesytem, and set that as "External Diff" command that takes the
filenames as extra two parameters, just like any other "External Diff"
programs given to gitk does. This is the least palatable, as it won't
solve the read-only repository issue at all (it only allows you the
logic to choose the configured difftool backend program).
* Instead of disabling the traditional "External Diff" and taking it over
like your patch did, add a new codepath for "Difftool" that feeds the
commit IDs and paths the way git-difftool expects. The user can use
both, and the issue of read-only repository is solved when "Difftool"
is used (but not "External Diff").
* Take over "External Diff" codepath exactly like your patch did, but
teach "git-difftool" a new command line option to name an unconfigured
external program that takes two filenames. When "External Diff"
program is *not* configured in gitk, the command line to invoke
difftool would be exactly as in your patch, i.e. "difftool --no-prompt
$from $to -- $path". Otherwise, when gitk is configured to use an
external program, e.g. "frobanodiff -z", for "External Diff", you pass
that command line to "git-difftool" via that new option, e.g.
difftool --no-prompt --extcmd="frobanodiff -z" $from $to -- $path
Then difftool is responsible for preparing the two necessary temporary
files out of the given information ($from/$to/$path) and feeding them
to "frobanodiff -z" command line.
Maybe such --extcmd support already exists in difftool, in which case
my earlier suspicion that difftool is not as flexible would be false.
I think the last one would be the way to go in the longer term.
^ permalink raw reply
* Re: git-svn of both trunk and tags while having no access to the 'parent' of those
From: Eric Wong @ 2009-11-20 20:47 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Michael J Gruber
In-Reply-To: <20091119095307.GA30423@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Michael J Gruber <git@drmicha.warpmail.net> wrote:
> > I tried also with two svn sections to circumvent this:
> >
> > [svn-remote "svn"]
> > url = http://domain.com:/project/trunk
> > fetch = :refs/remotes/trunk
> > [svn-remote "svnr"]
> > url = http://domain.com:/project/releases
> > tags = /*:refs/remotes/tags/*
Hi Yaroslav,
Weird, I'm a bit confused by this myself but I'm out of time
at the moment, but swapping '[svn-remote "svn"]' and "[svn-remote "svnr"]"
seems to work, so there's apparently a bug in our handling of
svn-remote != "svn" somewhere...
So the following config should work:
[svn-remote "svnt"]
url = http://domain.com:/project/trunk
fetch = :refs/remotes/trunk
[svn-remote "svn"]
url = http://domain.com:/project/releases
tags = /*:refs/remotes/tags/*
You should probably run "git svn fetch -R svnt" before running
"git svn fetch" to pick up the tagged releases.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 20:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <7vocmxvu7c.fsf@alter.siamese.dyndns.org>
On vendredi 20 novembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> > variable, and that is enough to make gitk ignore replace refs.
>
> This is a much less interesting implementation detail than everything
> else you should talk about the new feature you are adding; why is it the
> first sentence of the message?
This patch was previously the second patch in a 2 patch series so the
previous patch was already explaining some context. Perhaps I should have
sent the first patch again with this one.
> > The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> > safer on some platforms, thanks to Johannes Sixt and Michael J
> > Gruber.
>
> And this is even less interesting.
>
> > Replace refs are useful to change some git objects after they
> > have started to be shared between different repositories. One
> > might want to ignore them to see the original state.
>
> This is what the reader needs to see to understand why this patch is
> worthy of consideration. It is a minor offense that the paragraph does
> not end with "... original state, and --no-replace-objects option can be
> used from the command line to do so", but this could be excused if this
> is made the first paragraph in the message, close to the subject.
Ok, I will send the full series again with these changes.
> I wonder if this switch deserves run-time flippability, though...
The following patch in master added run-time flippability to many commands:
http://git.kernel.org/?p=git/git.git;a=commit;h=b0fa7ab51b29d34579d8f6bb4443dfbcb8278c7a
and Michael J Gruber wrote "we need a way to specify
--no-replace-objects for gitk" in this message:
http://article.gmane.org/gmane.comp.version-control.git/132576/
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Junio C Hamano @ 2009-11-20 20:19 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258732767-12741-3-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> We explain the user why uncommited changes can be problematic with merge,
> and point to "commit" and "stash" for the solution.
It is a shame that our existing documentation did not address this, and
the patch certainly takes us in the right direction.
I haven't seen a clear description of distinction between two vastly
different modes of failure from "git merge"---one that stops before even
touching anything, and one that results in conflicts to be resolved---and
how to tell them apart. As the course of action after these two modes are
quite different, it helps users to teach it early.
I attempted to summarize it some time ago:
http://gitster.livejournal.com/25801.html
(Completing a merge)
http://gitster.livejournal.com/29060.html
(Fun with keeping local changes around)
I am not very satisfied with them, but it might be a good start.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> Documentation/user-manual.txt | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 269ec47..6b4a037 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1176,14 +1176,22 @@ How to merge
> ------------
>
> You can rejoin two diverging branches of development using
> -linkgit:git-merge[1]:
> +linkgit:git-merge[1].
>
> -------------------------------------------------
> $ git merge branchname
> -------------------------------------------------
>
> merges the development in the branch "branchname" into the current
> -branch. If there are conflicts--for example, if the same file is
> +branch. Note that Git merges committed changes, but not the working
> +tree itself. Therefore, if you have uncommitted changes touching the
> +same files as the ones impacted by the merge, Git will refuse to
> +proceed.
"but not the working tree itself" is not incorrect per-se, but misses the
point. How about...
A merge is made by combining the changes made in "branchname" and
the changes made up to the latest commit in your current branch
since their histories forke. The work tree is overwritten by the
result of the merge when this combining is done cleanly, or
overwritten by a half-merged results when this combining results
in conflicts. Therefore, ...
> +proceed. Most of the time, you will want to commit your changes before
> +you can merge, and if you don't, then linkgit:git-stash[1] can take
> +these changes away while you're doing the merge, and reapply them
> +afterwards.
> +
> +If there are conflicts--for example, if the same file is
> modified in two different ways in the remote branch and the local
> branch--then you are warned; the output may look something like this:
>
> @@ -1679,7 +1687,7 @@ Sharing development with others
> Getting updates with git pull
> -----------------------------
>
> -After you clone a repository and make a few changes of your own, you
> +After you clone a repository and commit a few changes of your own, you
> may wish to check the original repository for updates and merge them
> into your own work.
>
> --
> 1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Clemens Buchacher @ 2009-11-20 20:11 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git, peff, jaysoffian, spearce
In-Reply-To: <905315640911201103w6d1da86duf41a53537672be8e@mail.gmail.com>
On Fri, Nov 20, 2009 at 11:03:13AM -0800, Tarmigan wrote:
> Here's a patch (cut-n-paste so it will probably be munged) for
> discussion of the port-fallback idea. If httpd cannot bind to 5541,
> it tries 15541 etc.
I would prefer if we skip the test right away. If we really want to try
different ports, we should first check that the port really is the problem.
Otherwise, the test will uselessly retry several times. Apache 2 writes
(98)Address already in use: make_sock: could not bind to address
127.0.0.1:5541
to stderr, which we could use to detect that error condition. But other web
servers are bound to behave differently.
Clemens
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Junio C Hamano @ 2009-11-20 20:04 UTC (permalink / raw)
To: Christian Couder
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <20091120194046.4469.53971.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> variable, and that is enough to make gitk ignore replace refs.
This is a much less interesting implementation detail than everything else
you should talk about the new feature you are adding; why is it the first
sentence of the message?
> The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> safer on some platforms, thanks to Johannes Sixt and Michael J
> Gruber.
And this is even less interesting.
> Replace refs are useful to change some git objects after they
> have started to be shared between different repositories. One
> might want to ignore them to see the original state.
This is what the reader needs to see to understand why this patch is
worthy of consideration. It is a minor offense that the paragraph does
not end with "... original state, and --no-replace-objects option can be
used from the command line to do so", but this could be excused if this is
made the first paragraph in the message, close to the subject.
I wonder if this switch deserves run-time flippability, though...
> Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> gitk-git/gitk | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index a0214b7..c586b93 100644
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -128,7 +128,7 @@ proc unmerged_files {files} {
> }
>
> proc parseviewargs {n arglist} {
> - global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
> + global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
>
> set vdatemode($n) 0
> set vmergeonly($n) 0
> @@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
> # git rev-parse doesn't understand --merge
> lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
> }
> + "--no-replace-objects" {
> + set env(GIT_NO_REPLACE_OBJECTS) "1"
> + }
> "-*" {
> # Other flag arguments including -<n>
> if {[string is digit -strict [string range $arg 1 end]]} {
> --
> 1.6.5.1.gaf97d
^ permalink raw reply
* [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 19:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
This option simply sets the GIT_NO_REPLACE_OBJECTS environment
variable, and that is enough to make gitk ignore replace refs.
The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
safer on some platforms, thanks to Johannes Sixt and Michael J
Gruber.
Replace refs are useful to change some git objects after they
have started to be shared between different repositories. One
might want to ignore them to see the original state.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
gitk-git/gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..c586b93 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -128,7 +128,7 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
+ global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
set vdatemode($n) 0
set vmergeonly($n) 0
@@ -208,6 +208,9 @@ proc parseviewargs {n arglist} {
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
+ "--no-replace-objects" {
+ set env(GIT_NO_REPLACE_OBJECTS) "1"
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:31 UTC (permalink / raw)
To: Derek, git
In-Reply-To: <1258744985-sup-932@ntdws12.chass.utoronto.ca>
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Excerpts from Ben Walton's message of Fri Nov 20 14:26:41 -0500 2009:
> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/git/trunk/Makefile
> [1] Basic docs, etc: http://sourceforge.net/apps/trac/gar/
Using svn is really painful, btw. I didn't think of the irony of
these links when hitting send.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:26 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T201341-834@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
Excerpts from Derek's message of Fri Nov 20 14:15:40 -0500 2009:
> Unfortunately I need 1.5.4.2 version specifically as I want it to work with
> gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
Ok, I can't help then. We have archival versions of older git
packages, but the first version I published was 1.6.0.5.
If you're willing to install the dependency packages, you could build
your own version using the recipe stored in our GAR[1] repository:
http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/git/trunk/Makefile
May help, may not.
-Ben
[1] Basic docs, etc: http://sourceforge.net/apps/trac/gar/
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Derek @ 2009-11-20 19:15 UTC (permalink / raw)
To: git
In-Reply-To: <1258743998-sup-86@ntdws12.chass.utoronto.ca>
Ben Walton <bwalton <at> artsci.utoronto.ca> writes:
> If you don't need that version specifically, have a look at:
>
> http://opencsw.org/packages/git
>
> It might save you some time.
>
> HTH.
> -Ben
>
Unfortunately I need 1.5.4.2 version specifically as I want it to work with
gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Ben Walton @ 2009-11-20 19:07 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T194807-826@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Excerpts from Derek's message of Fri Nov 20 13:50:13 -0500 2009:
> Any ideas?
If you don't need that version specifically, have a look at:
http://opencsw.org/packages/git
It might save you some time.
HTH.
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Tarmigan @ 2009-11-20 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff, jaysoffian, drizzd, spearce
In-Reply-To: <7vd43d7hdo.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
>
>> With smart http, git over http is likely to become much more common.
>> To increase testing of smart http, enable the http tests by default.
>
> Sorry, but no test that listens to network ports should be enabled by
> default; otherwise it will break automated, unattended tests people have
> already set up randomly, depending on when the port happens to be
> available for use by the tests.
Is this the only concern or are there security or other issues as well?
If that is the only concern, we could have the tests automatically
fall back to listening on a different port. Even if we didn't, if
httpd cannot startup because it can't bind to the port, the http tests
say
* skipping test, web server setup failed
and exit with test_done before any of the tests actually fail.
Here's a patch (cut-n-paste so it will probably be munged) for
discussion of the port-fallback idea. If httpd cannot bind to 5541,
it tries 15541 etc. You can test this by running "nc -l 5541 &"
before the test. If this approach might be acceptable, I can send a
properly formatted patch.
Comments?
Thanks,
Tarmigan
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index 797a2d6..a8eb6fa 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -77,7 +77,7 @@ prepare_httpd() {
if test -n "$LIB_HTTPD_SSL"
then
- HTTPD_URL=https://127.0.0.1:$LIB_HTTPD_PORT
+ HTTPD_URL=https://127.0.0.1
RANDFILE_PATH="$HTTPD_ROOT_PATH"/.rnd openssl req \
-config "$TEST_PATH/ssl.cnf" \
@@ -88,7 +88,7 @@ prepare_httpd() {
export GIT_SSL_NO_VERIFY
HTTPD_PARA="$HTTPD_PARA -DSSL"
else
- HTTPD_URL=http://127.0.0.1:$LIB_HTTPD_PORT
+ HTTPD_URL=http://127.0.0.1
fi
if test -n "$LIB_HTTPD_DAV" -o -n "$LIB_HTTPD_SVN"
@@ -109,16 +109,29 @@ start_httpd() {
trap 'code=$?; stop_httpd; (exit $code); die' EXIT
- "$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
- -f "$TEST_PATH/apache.conf" $HTTPD_PARA \
- -c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
- >&3 2>&4
- if test $? -ne 0
- then
- say "skipping test, web server setup failed"
- trap 'die' EXIT
- test_done
- fi
+ while true
+ do
+ "$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
+ -f "$TEST_PATH/apache.conf" $HTTPD_PARA \
+ -c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
+ >&3 2>&4
+ if test $? -ne 0
+ then
+ if test $LIB_HTTPD_PORT -gt 40000
+ then
+ say "skipping test, web server setup failed"
+ trap 'die' EXIT
+ test_done
+ fi
+ LIB_HTTPD_PORT=$(($LIB_HTTPD_PORT + 10000))
+ say "trying port $LIB_HTTPD_PORT"
+ continue
+ else
+ break
+ fi
+ done
+
+ HTTPD_URL="$HTTPD_URL:$LIB_HTTPD_PORT"
}
stop_httpd() {
^ permalink raw reply related
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: David Aguilar @ 2009-11-20 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, peff, sam, git
In-Reply-To: <7vhbsp7htq.fsf@alter.siamese.dyndns.org>
On Thu, Nov 19, 2009 at 11:53:37PM -0800, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > I have no problem with using git difftool if the underlying git is new
> > enough, I just don't want gitk to explode when it isn't.
>
> I somehow doubt there are many users who use pre 1.6.3 git but keep their
> gitk separately updated to very recent version, so personally I wouldn't
> worry too much about this.
>
> > Also, I don't think we should remove the ability for the user to
> > choose which external diff tool to use.
>
> This is a larger concern. Does "difftool" allow use of an arbitrary tool
> like how gitk does (I have a suspicion that it is not as flexible)?
difftool supports arbitrary tools through configuration.
For arbitrary tools we set difftool.$name.cmd and
diff.tool = $name.
If gitk were to have a difftool paradigm then it might
be nice to have a text field mapped to the diff.tool variable.
The patch didn't address the diff.tool configuration variable
so that's a concern if we are to pursue difftool further.
The argument in favor of difftool is one of user
expectations. From a user's POV it ~seems~ desirable for
gitk to honor difftool configurations. The easiest way for
gitk to do that is to use git-difftool and not worry about
the details of how arbitrary tools are setup.
Later work could be done to provide UI for setting up
arbitrary tools inside of gitk. My gut feeling
is that gitk isn't a git config editor.
This is why the difftool patch took the minimalist approach.
It trusts the user to have things configured to their
liking and trusts git-difftool to do the right thing
when no such configuration exists.
I think it's a question of whether this is something we'd
want to change. It certainly doesn't bother me either way.
I might be the only person who'd notice such small details
so my vote-in-code is with my v2 $TMPDIR patch until someone
else thinks that using difftool inside of gitk is a good idea.
At which point I would probably pursue it with the minimalist
approach first and then gradually add UI for the pertinent
git config variables.
Just my .02,
--
David
^ permalink raw reply
* GIT 1.5.4.2 installation on Solaris 8 problems
From: Derek @ 2009-11-20 18:50 UTC (permalink / raw)
To: git
I get the following error after make install:
install: git-fetch-pack was not found anywhere!
make: *** [install] Error 2
Any ideas?
^ permalink raw reply
* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: David Aguilar @ 2009-11-20 18:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: Matthieu Moy, git@vger.kernel.org, gitster@pobox.com
In-Reply-To: <4B06A7EE.2090801@atlas-elektronik.com>
On Fri, Nov 20, 2009 at 03:30:06PM +0100, Stefan Naewe wrote:
> On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> > It seems this is the value most users set, so let's make it the default.
>
> I like the idea but would suggest to use ~/.gitexcludes instead.
> That way it doesn't clash with .gitignore if your $HOME is
> under git-control.
>
> Regards
>
> Stefan
I second this. I also keep my $HOME in git.
--
David
^ permalink raw reply
* Re: [PATCH 1/2] merge-recursive: point the user to commit when file would be overwritten.
From: Junio C Hamano @ 2009-11-20 18:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258732767-12741-2-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The commit-before-pull is well accepted in the DVCS community, but is
> confusing some new users. This should get them back in the right way when
> the problem occurs.
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Don't these extra lines warrant "advice.*" option?
> ---
> merge-recursive.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/merge-recursive.c b/merge-recursive.c
> index f55b7eb..d5e0819 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -172,9 +172,11 @@ static int git_merge_trees(int index_only,
> struct unpack_trees_options opts;
> static const struct unpack_trees_error_msgs msgs = {
> /* would_overwrite */
> - "Your local changes to '%s' would be overwritten by merge. Aborting.",
> + "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
> + "Please, commit your changes or stash them before you can merge.",
> /* not_uptodate_file */
> - "Your local changes to '%s' would be overwritten by merge. Aborting.",
> + "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
> + "Please, commit your changes or stash them before you can merge.",
> /* not_uptodate_dir */
> "Updating '%s' would lose untracked files in it. Aborting.",
> /* would_lose_untracked */
> --
> 1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply
* Re: [PATCH 0/3] "log --stdin" updates
From: Junio C Hamano @ 2009-11-20 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091120144030.GB5419@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 20, 2009 at 03:25:12AM -0800, Junio C Hamano wrote:
>
>> These three come on top of 61ab67a (Teach --stdin option to "log" family,
>> 2009-11-03), which gave "--stdin" to the log family of commands (e.g. log,
>> rev-list). The earlier patch allowed you to feed only the revs (which was
>> what gitk originally wanted), but after zero or more revs (one rev per
>> line), you can now feed a line that consists of "--" and then pathspecs
>> (one path per line).
>
> This looks like a good API feature, though I am curious about the
> missing "4/3" that was the motivation (of course, with a feature
> like this, it may be for your out-of-git script, but as I said, I am
> curious :) ). Is it a response to
>
> http://article.gmane.org/gmane.comp.version-control.git/133268
>
> ?
No. This series is a follow-up to $gmane/131971; I was suspicious that I
missed something for the API feature to be complete back then (and the
patch was not signed-off partly for that reason), and I found one thing
that was lacking.
^ 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