* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-24 20:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901242049580.14855@racer>
On Sat, Jan 24, 2009 at 20:52, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Jan 2009, Lars Hjemli wrote:
>
>> $ git archive --submodules <tree-ish>: Create an archive which
>> includes the trees of all gitlink entries in <tree-ish>, fail unless
>> all the required objects are available.
>>
>> $ git archive --submodules=<group>: Same as above, but only traverse
>> submodules in the specified group (as defined in $GIT_CONFIG).
>
> How about having the former with --submodules='*' and let --submodules
> without argument include those submodules that are checked out (none in a
> bare repository)?
Yeah, that might make more sense (since you'd normally not have access
to the content of non-checked out submodules). I'm also considering
something like --submodules[=(all|checkedout|[group:]<name>)], i.e.
the 'group:'-part could be optional as long as <name> is unambiguous.
--
larsh
^ permalink raw reply
* Re: diff settings
From: Keith Cascio @ 2009-01-24 20:01 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87ocxwv6qg.fsf@iki.fi>
> It seems that the answer is "no", but aliases are a work-around:
>
> git config --global alias.dff "diff -w"
>
> Then "git dff" is your new "git diff -w". :-)
That feature is gonna come in handy. It doesn't 100% fulfill my needs here but
I like it! Thanks, I did not know about alias.*
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Johannes Schindelin @ 2009-01-24 19:52 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <8c5c35580901241126q2da83f50m1472ed017b92c982@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Lars Hjemli wrote:
> $ git archive --submodules <tree-ish>: Create an archive which
> includes the trees of all gitlink entries in <tree-ish>, fail unless
> all the required objects are available.
>
> $ git archive --submodules=<group>: Same as above, but only traverse
> submodules in the specified group (as defined in $GIT_CONFIG).
How about having the former with --submodules='*' and let --submodules
without argument include those submodules that are checked out (none in a
bare repository)?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Makefile: Use libc strlcpy on OSX >= 10.2
From: Junio C Hamano @ 2009-01-24 19:42 UTC (permalink / raw)
To: Benjamin Kramer; +Cc: git
In-Reply-To: <7f978c810901241101h227c5437p88ca7c9cc54abc9a@mail.gmail.com>
Benjamin Kramer <benny.kra@googlemail.com> writes:
> OSX supports strlcpy(3) since 10.2 so we don't need
> to use our own. This revised also patch checks the darwin
> version. 10.0 is darwin v1.3; 10.1 is darwin v1.4.
What does the output from "uname -r" and "uname -s" look like on your box
(and older OSX boxes)?
> @@ -643,7 +643,9 @@ ifeq ($(uname_S),Darwin)
> ifneq ($(shell expr "$(uname_R)" : '9\.'),2)
> OLD_ICONV = UnfortunatelyYes
> endif
This existing one says "If 'uname -r' output does not begin with two
characters '9.' (nine and dot), then set OLD_ICONV".
> - NO_STRLCPY = YesPlease
> + ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
And this new one says "If 'uname -r' output begins with two characters
'1.' (one and dot), then set NO_STRLCPY".
> + NO_STRLCPY = YesPlease
> + endif
I am guessing that 'uname -r' says 9.X in "Darwin 9.X" (which is OSX
10.5), and existing conditional says that versions before 9.X needs
OLD_ICONV but later ones do not need it.
Does 1.X stand for OSX 10.2? A quick googling finds a handful pages that
say that OSX 10.2 = Darwin 6.x and OSX 10.3 = Darwin 7.x, and I am not
sure where you are getting that "begins with one-and-dot" from....
> NO_MEMMEM = YesPlease
> THREADED_DELTA_SEARCH = YesPlease
> endif
> --
> 1.6.1.285.g3454
^ permalink raw reply
* Re: read-only working copies using links
From: Jeff King @ 2009-01-24 19:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Chad Dombrova, Tim 'Mithro' Ansell, git
In-Reply-To: <bd6139dc0901241043h7087316bgcbcb5d9085d603ef@mail.gmail.com>
On Sat, Jan 24, 2009 at 07:43:20PM +0100, Sverre Rabbelier wrote:
> On Sat, Jan 24, 2009 at 19:39, Chad Dombrova <chadrik@gmail.com> wrote:
> > what's the case against it, other than the obvious, that it will take more
> > work?
>
> Good question, I think it was mostly that, someone has to implement it
> (possibly as part of packv4). Backwards compatibility is of course
> always an concern, but I'm not too familiar with the subject, perhaps
> other people on the list (or even those were at the gittogether) can
> comment?
If I understand his proposal correctly, such objects must _not_ be part
of a pack. The whole idea is splitting them _more_, not less.
-Peff
^ permalink raw reply
* Re: read-only working copies using links
From: Jeff King @ 2009-01-24 19:34 UTC (permalink / raw)
To: Chad Dombrova; +Cc: Sverre Rabbelier, Tim 'Mithro' Ansell, git
In-Reply-To: <AE9781AD-0B63-4AEE-9B62-20F9720B5DC4@gmail.com>
On Sat, Jan 24, 2009 at 10:39:46AM -0800, Chad Dombrova wrote:
>> I think Tim Ansell (cced) was talking about this at the gittogether
>> (storing the metadata seperately), as it would benefit sparse/narrow
>> checkout, another advantage supporting his case?
>
> what's the case against it, other than the obvious, that it will take
> more work?
I'm not sure this is actually the same as Tim's proposal. Tim wanted to
store the commit and tree information separately from the blob
information (since his use case was that blobs are enormous, but the
rest is reasonable).
AIUI, Chad's proposal is about storing the actual blob data itself
separate from the blob object's metadata (i.e., its object type and
length headers). Which means that the normal loose object format is not
acceptable, and you would end up with something like (for example):
.git/objects/pack/pack-full-of-your-regular-stuff.{pack,idx}
.git/objects/[0-9a-f]{2}/[0-9a-f]{38}/header
.git/objects/[0-9a-f]{2}/[0-9a-f]{38}/data
or something similar. Then you could hardlink directly to the 'data'
portion. So you would need:
- to teach everything that ever looks for loose objects how to read
this new format. In theory, it's all nicely encapsulated in
sha1_file.c
- to teach checkout routines to hardlink such a case instead of
copying the file
The obvious downsides that I can think of are:
- it has the potential to make object reading, which is a core part of
git (read: very performance- and correctness- sensitive) a lot more
complex. But maybe the implementation would not be that painful;
somebody would have to look very closely to see.
- it interacts badly with smudge/clean filters and crlf conversion.
In those cases you can't hardlink. If you treat this like an
optimization, though, it's not so bad: we only do the optimization
when we _can_, and fall back to regular checkout if those other
options are in effect.
- it's somewhat dangerous to your repository's health. Git's model is
that object files are immutable (since they are, after all, named
after their contents). But now you are linking them into your
working tree, which makes them susceptible to some third party tool
munging them. So yes, most tools will probably behave, but any tool
that misbehaves will actually corrupt your repository.
-Peff
^ permalink raw reply
* Re: diff settings
From: Teemu Likonen @ 2009-01-24 19:33 UTC (permalink / raw)
To: Keith Cascio; +Cc: git
In-Reply-To: <alpine.GSO.2.00.0901240936080.23073@kiwi.cs.ucla.edu>
Keith Cascio (2009-01-24 09:38 -0800) wrote:
> How do I configure my local git so that diff always obeys a particular
> option, e.g. "-w", without needing to type it on the command line each
> time?
It seems that the answer is "no", but aliases are a work-around:
git config --global alias.dff "diff -w"
Then "git dff" is your new "git diff -w". :-)
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-24 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901241443270.13232@racer>
On Sat, Jan 24, 2009 at 14:51, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Now, there is still a problem when your submodule is missing the objects
> for the commit your superproject is referring to.
>
> IMO that is a serious issue, as it just asks for confused users.
This made me finally understand your concern (sorry for being slow):
you want the command to behave in a predictable/consistent way while
my implementation would end up making an archive with basically random
content.
>> > - presence of a specific commit in the supermodule is a _lousy_
>> > indicator that the user wants to include that submodule in the
>> > archive.
>>
>> This is the issue I tried to address with my
>> `--submodules=[a|c|r][g:<name>]` proposal in the commit message for
>> this patch.
>
> Nope, doing this "in the future" does not please me one bit.
>
> Besides, I find the semantics, uhm, "interesting". (The other word would
> be "unintuitive". Why do you have to be so cryptic that I have to read
> the proposal to understand what the heck "c" is about?)
I thought it would be nifty to be able to combine different flags
which would affect the behaviour/semantics of the command, but given
the comments from you and Junio, I think I'll end up with something
like this:
$ git archive --submodules <tree-ish>: Create an archive which
includes the trees of all gitlink entries in <tree-ish>, fail unless
all the required objects are available.
$ git archive --submodules=<group>: Same as above, but only traverse
submodules in the specified group (as defined in $GIT_CONFIG).
--
larsh
^ permalink raw reply
* Re: diff settings
From: Jeff King @ 2009-01-24 19:22 UTC (permalink / raw)
To: Keith Cascio; +Cc: git
In-Reply-To: <alpine.GSO.2.00.0901240936080.23073@kiwi.cs.ucla.edu>
On Sat, Jan 24, 2009 at 09:38:18AM -0800, Keith Cascio wrote:
> How do I configure my local git so that diff always obeys a particular
> option, e.g. "-w", without needing to type it on the command line each
> time?
AFAIK, there is not a way to do it in the general case (though there are
specific config options for things like rename support). When I
refactored the gitattributes diff=$foo code a few months back, I tried
to keep in mind the possibility of a "diff options" field. But I never
actually implemented anything, as I don't personally ever use diff
options in such a way.
If you're interested, it would probably not be too hard to implement
(see userdiff.[ch], and the external and textconv code in diff.c for a
start).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Jeff King @ 2009-01-24 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, René Scharfe, git
In-Reply-To: <7vk58ko8k7.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 24, 2009 at 10:36:24AM -0800, Junio C Hamano wrote:
> Why should format-patch need to even worry about protecting itself from
> "color.ui" to begin with?
Agreed. In the "should I use color" function I proposed, there should be
a big fat "are_we_a_porcelain_that_will_allow_any_color_at_all" flag
at the top, which will make it totally clear how to make sure color is
off.
> You did not find the breakage in format-patch either to begin with; so
> your not finding does not give us much confidence that there is no other
> breakage, does it?
>
> Grumble...
Sadly, this is an area that is not covered very well in the tests
(partially, I think, because it is "just" output which we tend to
neglect, and partially because the isatty() stuff is hard to test with
our harness). So I don't think it's _entirely_ Markus' fault.
-Peff
^ permalink raw reply
* [PATCH v2] Makefile: Use libc strlcpy on OSX >= 10.2
From: Benjamin Kramer @ 2009-01-24 19:01 UTC (permalink / raw)
To: gitster; +Cc: git
OSX supports strlcpy(3) since 10.2 so we don't need
to use our own. This revised also patch checks the darwin
version. 10.0 is darwin v1.3; 10.1 is darwin v1.4.
Signed-off-by: Benjamin Kramer <benny.kra@gmail.com>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..7dd5224 100644
--- a/Makefile
+++ b/Makefile
@@ -643,7 +643,9 @@ ifeq ($(uname_S),Darwin)
ifneq ($(shell expr "$(uname_R)" : '9\.'),2)
OLD_ICONV = UnfortunatelyYes
endif
- NO_STRLCPY = YesPlease
+ ifeq ($(shell expr "$(uname_R)" : '1\.'),2)
+ NO_STRLCPY = YesPlease
+ endif
NO_MEMMEM = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
--
1.6.1.285.g3454
^ permalink raw reply related
* Re: [PATCH] cygwin: Convert paths for html help from posix to windows
From: Ramsay Jones @ 2009-01-24 18:51 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, jaeckel, git
In-Reply-To: <20090122171605.GA16684@atjola.homenet>
Björn Steinbrink wrote:
> When using "git help --web" with cygwin, we used to pass the posix path
> to the browser, but a native windows browser will expect a windows path
> and is unable to make use of the given path.
>
> So the cygwin port gets its own open_html implementation that handles
> the path conversion.
>
> Reported-by: Steffen Jaeckel <jaeckel@stzedn.de>
> Tested-by: Steffen Jaeckel <jaeckel@stzedn.de>
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
> OK, I don't really know if this is the right way to do it. Maybe when
> the browser was built for cygwin this breaks? I have no clue, it's
> admittedly just the result of a quick glance at the code and some
> googling to find the "right" cygwin function... :-/
>
Hi Björn,
I had the same problem. However, rather than modifying git, I created a
firefox wrapper script (in ~/bin) which used the cygpath command line
tool to do the path conversion. Also, if you use "git instaweb", you
also need to filter out http URLs and pass them through un-molested
by cygpath (it turns http://localhost into http:\localhost).
My script is clearly a "quick hack" just to get something working for
me, but you may find it useful as a starting point for your own
("proper" ;-) script, so I've included it below.
HTH,
Ramsay Jones
-->8--
#!/bin/sh
#
while test $# != 0
do
case "$1" in
-version)
echo "firefox 1.5.0.2"
exit 0
;;
-new-tab)
echo "-new-tab not supported"
exit 1
;;
--)
shift
break
;;
-*)
echo "option '$1' not supported"
exit 1
;;
*)
break
;;
esac
shift
done
if test "$1" = ""
then
p=
else
case "$1" in
http*)
p="$1"
;;
*)
p="$(cygpath -w "$1")"
;;
esac
fi
"/cygdrive/c/Program Files/Mozilla Firefox/firefox.exe" "$p"
exit 0
^ permalink raw reply
* Re: [PATCH] Makefile: Use libc strlcpy on OSX
From: Benjamin Kramer @ 2009-01-24 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxj8o8fq.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 24, 2009 at 19:39, Junio C Hamano <gitster@pobox.com> wrote:
> How does your patch to Makefile refrain from kicking in for people with
> OSX older than 10.2, so that their builds are not broken?
I'm not even sure anyone uses <= 10.1 nowadays. But of course you're right,
I'll write a better patch.
-- Benjamin
^ permalink raw reply
* Re: problems with http://git-scm.com/
From: Teemu Likonen @ 2009-01-24 18:44 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git, Adam Cooke, Scott Chacon
In-Reply-To: <20090124173756.GU6683@cs-wsok.swansea.ac.uk>
[Adding some CCs.]
Oliver Kullmann (2009-01-24 17:37 +0000) wrote:
> since a few docs my (somewhat rusty) Konqueror can't load
> http://git-scm.com/
> anymore.
>
> Now checking at
> http://validator.w3.org/
> we get one error:
>
> Line 174, Column 14: there is no attribute "clear".
> <br clear="all"/>
>
> And that shouldn't be (since http://git-scm.com/ claims to be strict
> xhtml). Don't know whether this is the problem, but that attribute
> clearly should be removed anyway.
It seems that the attribute has already been changed to
style="clear:both;" in the web site's git repository[1]. It's the commit
cea494929e (2009-01-08). But www.git-scm.com is still serving an old
version.
---------------
1. git://github.com/schacon/gitscm.git
^ permalink raw reply
* Re: read-only working copies using links
From: Sverre Rabbelier @ 2009-01-24 18:43 UTC (permalink / raw)
To: Chad Dombrova; +Cc: Tim 'Mithro' Ansell, git
In-Reply-To: <AE9781AD-0B63-4AEE-9B62-20F9720B5DC4@gmail.com>
On Sat, Jan 24, 2009 at 19:39, Chad Dombrova <chadrik@gmail.com> wrote:
> what's the case against it, other than the obvious, that it will take more
> work?
Good question, I think it was mostly that, someone has to implement it
(possibly as part of packv4). Backwards compatibility is of course
always an concern, but I'm not too familiar with the subject, perhaps
other people on the list (or even those were at the gittogether) can
comment?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: read-only working copies using links
From: Chad Dombrova @ 2009-01-24 18:39 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Tim 'Mithro' Ansell, git
In-Reply-To: <bd6139dc0901240302q6b3c9a13p56fe39a976882133@mail.gmail.com>
>
> I think Tim Ansell (cced) was talking about this at the gittogether
> (storing the metadata seperately), as it would benefit sparse/narrow
> checkout, another advantage supporting his case?
>
what's the case against it, other than the obvious, that it will take
more work?
-chad
^ permalink raw reply
* Re: [PATCH] Makefile: Use libc strlcpy on OSX
From: Junio C Hamano @ 2009-01-24 18:39 UTC (permalink / raw)
To: Benjamin Kramer; +Cc: git
In-Reply-To: <7f978c810901240741k201f954dx1c0470186094ae24@mail.gmail.com>
Benjamin Kramer <benny.kra@googlemail.com> writes:
> OSX supports strlcpy(3) since 10.2 so we don't need
> to use our own.
How does your patch to Makefile refrain from kicking in for people with
OSX older than 10.2, so that their builds are not broken?
>
> Signed-off-by: Benjamin Kramer <benny.kra@gmail.com>
> ---
> Makefile | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b4d9cb4..4c9aab5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -643,7 +643,6 @@ ifeq ($(uname_S),Darwin)
> ifneq ($(shell expr "$(uname_R)" : '9\.'),2)
> OLD_ICONV = UnfortunatelyYes
> endif
> - NO_STRLCPY = YesPlease
> NO_MEMMEM = YesPlease
> THREADED_DELTA_SEARCH = YesPlease
> endif
^ permalink raw reply
* Re: [PATCH 1/2] handle color.ui at a central place
From: Junio C Hamano @ 2009-01-24 18:36 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Jeff King, René Scharfe, git
In-Reply-To: <200901241228.33690.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> I looked at the code and found this in git_format_config():
>
> if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
> return 0;
>
> Which of course didn't handle color.ui, but that wasn't necessary before
> the central color.ui handling from my patch.
Centralized handling is never a goal in itself. The goal should be to
make it easier for various codepaths to use color settings correctly,
without having to have many special case workarounds. Centralized
handling, if designed right, could be a good way to achieve that goal.
> So with the following diff it works:
>
> - if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")) {
> + if (!strcmp(var, "diff.color") || !strcmp(var, "color.diff")
> + || !strcmp(var, "color.ui")) {
Why should format-patch need to even worry about protecting itself from
"color.ui" to begin with?
If your patch is making color handling saner, I would expect that
format-patch can *lose* the existing "ignore diff.color or color.diff"
workaround as a result of that. If you need to add even *more* workaround
code like that, there's something wrong, don't you think?
> format-patch is perhaps the only place where the commit has broken
> things, because I didn't find other places,...
You did not find the breakage in format-patch either to begin with; so
your not finding does not give us much confidence that there is no other
breakage, does it?
Grumble...
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-24 18:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, git
In-Reply-To: <7vwscmue5z.fsf@gitster.siamese.dyndns.org>
> I do not use mergetool myself so I generally do not pay attention to
> patches on this tool, but I would want to pick up ones that people
> involved in mergetool discussion can agree to be good patches.
yeah I can see that.
> There are a few mergetool updates in flight from various authors. How
> does your submission compare with others' in both form/presentation and
> clarity of logic (remember, I am not keeping track)?
to be honest, a quick search of the past 2 months of patches didn't
show me any patches that do the same thing as mine, so I'm not sure
that comparing one feature to a different feature is good. I did try
to remain consistent and even improve consistency with existing UI,
and use the same/similar logic to existing. I'm not keeping track
either, just fixing my own problem.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* problems with http://git-scm.com/
From: Oliver Kullmann @ 2009-01-24 17:37 UTC (permalink / raw)
To: git
Hi,
since a few docs my (somewhat rusty) Konqueror can't load
http://git-scm.com/
anymore.
Now checking at
http://validator.w3.org/
we get one error:
Line 174, Column 14: there is no attribute "clear".
<br clear="all"/>
And that shouldn't be (since http://git-scm.com/ claims to
be strict xhtml).
Don't know whether this is the problem, but that attribute
clearly should be removed anyway.
Oliver
^ permalink raw reply
* [PATCH] git-svn: Don't fail `--help' if git directory not found.
From: Allan Caffee @ 2009-01-24 17:44 UTC (permalink / raw)
To: git
When called with the `--help' or `--version' from outside of a working tree
git-svn would fail with
fatal: Not a git repository
rev-parse --show-cdup: command returned error: 128
This happens because git-svn would check that it was running from the top of a
working directory before parsing options. Fix this by parsing options first.
Signed-off-by: Allan Caffee <allan.caffee@gmail.com>
---
git-svn.perl | 38 +++++++++++++++++++-------------------
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d4cb538..875a05b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -216,6 +216,25 @@ for (my $i = 0; $i < @ARGV; $i++) {
}
};
+my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
+
+read_repo_config(\%opts);
+if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
+ Getopt::Long::Configure('pass_through');
+}
+my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
+ 'minimize-connections' => \$Git::SVN::Migration::_minimize,
+ 'id|i=s' => \$Git::SVN::default_ref_id,
+ 'svn-remote|remote|R=s' => sub {
+ $Git::SVN::no_reuse_existing = 1;
+ $Git::SVN::default_repo_id = $_[1] });
+exit 1 if (!$rv && $cmd && $cmd ne 'log');
+
+usage(0) if $_help;
+version() if $_version;
+usage(1) unless defined $cmd;
+load_authors() if $_authors;
+
# make sure we're always running at the top-level working directory
unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
unless (-d $ENV{GIT_DIR}) {
@@ -241,25 +260,6 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
$_repository = Git->repository(Repository => $ENV{GIT_DIR});
}
-my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
-
-read_repo_config(\%opts);
-if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
- Getopt::Long::Configure('pass_through');
-}
-my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
- 'minimize-connections' => \$Git::SVN::Migration::_minimize,
- 'id|i=s' => \$Git::SVN::default_ref_id,
- 'svn-remote|remote|R=s' => sub {
- $Git::SVN::no_reuse_existing = 1;
- $Git::SVN::default_repo_id = $_[1] });
-exit 1 if (!$rv && $cmd && $cmd ne 'log');
-
-usage(0) if $_help;
-version() if $_version;
-usage(1) unless defined $cmd;
-load_authors() if $_authors;
-
unless ($cmd =~ /^(?:clone|init|multi-init|commit-diff)$/) {
Git::SVN::Migration::migration_check();
}
--
1.5.4.3
^ permalink raw reply related
* diff settings
From: Keith Cascio @ 2009-01-24 17:38 UTC (permalink / raw)
To: git
How do I configure my local git so that diff always obeys a particular option,
e.g. "-w", without needing to type it on the command line each time?
Thanks,
Keith
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Johannes Schindelin @ 2009-01-24 17:32 UTC (permalink / raw)
To: Tim Henigan; +Cc: git, pasky, gitster
In-Reply-To: <32c343770901240914n3fc76fe0vbe844e50cbc0bbf@mail.gmail.com>
Hi,
On Sat, 24 Jan 2009, Tim Henigan wrote:
> On Sat, Jan 24, 2009 at 11:58 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> >> Should I update the GitWiki page to remove this Janitor task or do
> >> you keep it as a test to see if people are properly searching the
> >> mail archives?
> >
> > Yes, please!
>
> I did some more digging and found this last comment on the subject by
> Linus: https://kerneltrap.org/mailarchive/git/2008/11/6/4014344
>
> Given this, should the janitor task simply be deleted (since using
> unsigned longs are safe until year 2038 is considered) or should it be
> updated to change all timestamps to 64-bit values?
>
> Also, there are still ~37 references to time_t in the code (e.g. the
> index_state struct in cache.h). Should these be phased out in favor of
> unsigned longs (or perhaps 64-bit types)?
Correct me if I am wrong: there are two different uses of times. One to
output dates (which is where we use unsigned long), and one where we
compare dates in file stats (where we use time_t).
I haven't looked at the code, though, so this might be incorrect.
If it is correct, though, I think that we should stay with time_t for the
cases where we have to compare to time_t anyway (as the stat() calls give
us the time in that datatype).
BTW the Janitor task was added by Pasky, so he should say something.
Pasky?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use time_t for timestamps returned by approxidate() instead of unsigned
From: Tim Henigan @ 2009-01-24 17:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901241757140.13232@racer>
On Sat, Jan 24, 2009 at 11:58 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> Should I update the GitWiki page to remove this Janitor task or do you
>> keep it as a test to see if people are properly searching the mail
>> archives?
>
> Yes, please!
I did some more digging and found this last comment on the subject by Linus:
https://kerneltrap.org/mailarchive/git/2008/11/6/4014344
Given this, should the janitor task simply be deleted (since using
unsigned longs are safe until year 2038 is considered) or should it be
updated to change all timestamps to 64-bit values?
Also, there are still ~37 references to time_t in the code (e.g. the
index_state struct in cache.h). Should these be phased out in favor
of unsigned longs (or perhaps 64-bit types)?
Perhaps the Janitor task should be changed to do this so that all the
code handles timestamps consistently? (btw, I will volunteer to do
this if desired).
Thanks,
Tim
^ permalink raw reply
* Re: PATCH] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-01-24 17:03 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901240816r25e6a9c9q2d437d413a524362@mail.gmail.com>
Hi,
On Sun, 25 Jan 2009, Ray Chuan wrote:
> Currently, functions that deal with objects on the remote repository
> have to allocate and do strcpys to generate the URL.
>
> This patch saves them this trouble, by providing a function that
> returns a URL: either the object's 2-digit hex directory (eg.
> /objects/a1/) or the complete object location (eg. /objects/a1/b2).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make that an Acked-by: okay?
> diff --git a/http-push.c b/http-push.c
> index cb5bf95..715954e 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -177,6 +177,16 @@ struct remote_ls_ctx
> struct remote_ls_ctx *parent;
> };
>
> +static char *get_remote_object_url(const char *url, const char *hex,
> int only_two_digit_postfix) {
It is actually a prefix.
Ciao,
Dscho
^ 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