* Re: Feature request: Allow extracting revisions into directories
From: Andrew Ardill @ 2013-02-04 12:58 UTC (permalink / raw)
To: Robert Clausecker; +Cc: Michael J Gruber, git@vger.kernel.org
In-Reply-To: <1359980045.24730.32.camel@t520>
On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> wrote:
> The specific workflow I am planning is this:
>
> I have a server that hosts a bare git repository. This git repository
> contains a branch production. Whenever somebody pushes to production a
> hook automatically puts a copy of the current production branch
> into /var/www/foo. I could of course use pull for that but it just does
> not feels right. Why should I have a repository twice on the server?
Maybe I'm missing something. How does the behaviour you need differ from
> GIT_WORKING_DIR=/var/www/foo git checkout -f <tree-ish>
??
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Matthieu Moy @ 2013-02-04 13:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Jonathan Niedier
In-Reply-To: <7v1ucx83fz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> --- a/t/t6030-bisect-porcelain.sh
>>> +++ b/t/t6030-bisect-porcelain.sh
>>> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
>>> cp .git/BISECT_START saved &&
>>> test_must_fail git bisect start $HASH4 foo -- &&
>>> git branch > branch.output &&
>>> - test_i18ngrep "* (no branch)" branch.output > /dev/null &&
>>> + test_i18ngrep "* (bisecting other)" branch.output > /dev/null &&
[...]
> What does "other" refer to when you start your bisection at a
> detached head?
If I read correctly, the branch name is shown only when the bisection
was not started on a detached HEAD:
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(bisecting)"));
+ else
+ strbuf_addf(&result, _("(bisecting %s)"), sb.buf);
> I personally think "other" has _no_ value in that message, because
> "(no branch, bisecting)" gives the same amount of information,
> especially because "other" does not say which branch it refers to at
> all.
Just to be sure: "other" here is not a hardcoded message "bisecting
other", but an instance of "bisecting <branch-name>" with the branch
being called "other".
I think this is very valuable information, and most likely the
information you'd be looking for when running "git branch". You're
technically on detached HEAD, but morally on some branch, the HEAD being
detached only because a bisect is in progress.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Getting started contributing.
From: Matthieu Moy @ 2013-02-04 13:19 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> Hi,
> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>
Just to make it clear: this page is not "the official TODO-list for
Git", but a list where we (essentially me) can throw ideas of things to
be implemented.
As you did, the first thing to do is to discuss ideas on the list, to
make sure they are actually wanted.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Getting started contributing.
From: Matthieu Moy @ 2013-02-04 13:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: adamfraser, git
In-Reply-To: <7vhaltalre.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> adamfraser <adamfraser0@gmail.com> writes:
>
>> I would like to start contributing to git and am looking for a small project
>> idea to get started with. On the Small Project Ideas wiki
>> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
>> suggestion for adding a 'git rebase --status' command that sounds like it
>> would be good for someone who has little knowledge of the code base.
>
> I think the two patches Duy just posted tonight overlap with that
> topic, and I suspect it would give the end users a better experience
> to put the information in "git status" output rather than a separate
> "git rebase" subcommand.
(I'm the one who wrote the idea on the wiki)
"git status" already shows a lot of valuable information about rebase,
but my idea was that there's still room for a much more verbose command
(hence too verbose to appear in the output of "git branch" or "git
status"), saying eg.
* Which patch is being applied (we can imagine giving just the subject
line by default, but showing the complete patch with an additional
--patch option). I often miss that when trying to understand the
origin of a conflict. I can manually look at file
.git/rebase-merge/patch (I seem to remember a patch that shows the
path to this file when rebase stops, but I can't find it anymore), but
a nice porcelain would be nice.
* What's still on the todo-list
Also, perhaps this could gather the advices "(run git rebase <something>
to <do something>)" currently in the output of "git status", and "git
status may just say "(run git rebase --status for more information)"
instead of 2 or 3 lines of advices.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-02-04 13:58 UTC (permalink / raw)
To: Sébastien Boisvert
Cc: Thomas Rast, Brian J. Murrell, git, kusmabite,
Pyeron, Jason J CTR (US), Maxime Boissonneault, Philippe Vaucher
In-Reply-To: <51002D18.4080201@calculquebec.ca>
Hi,
On 01/23/2013 01:34 PM, Sébastien Boisvert wrote:
> Hello,
>
> Here is a patch (with git format-patch) that removes any timer if
> NO_SETITIMER is set.
>
Even with the patch, I finally got an error... :-/
Here are the log (strace -f) of a clean execution and one with the error:
http://www.giref.ulaval.ca/~ericc/NO_SETITIMER-patch_bin_git_noerror.txt.gz
http://www.giref.ulaval.ca/~ericc/NO_SETITIMER-patch_bin_git_with_error.txt.gz
Eric
^ permalink raw reply
* [WIP/RFH/RFD/PATCH] grep: allow to use textconv filters
From: Michael J Gruber @ 2013-02-04 15:27 UTC (permalink / raw)
To: git; +Cc: Jeff King
Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:
ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)
"git grep" currently does not use textconv filters at all, that is
neither for displaying the match and context nor for the actual grepping.
Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
which makes git grep use any configured textconv filters for grepping
and output purposes.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Notes:
I'm somehow stuck in textconv/filespec/... hell, so I'm sending this out
in request for help. I'm sure there are people for whom it's a breeze to
get this right.
The difficulty is in getting the different cases (blob/sha1 vs.
worktree) right, and in making the changes minimally invasive. It seems
that some more refactoring could help: "git show --textconv" does not
use textconv filters when used on blobs either. (It does for diffs, of
course.) Most existing helper functions are tailored for diffs.
Nota bene: --textconv does not affect "diff --stat" either...
builtin/grep.c | 5 ++++-
grep.c | 47 +++++++++++++++++++++++++++++------------------
grep.h | 3 ++-
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 8025964..2181c22 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -96,7 +96,7 @@ static void add_work(struct grep_opt *opt, enum grep_source_type type,
grep_source_init(&todo[todo_end].source, type, name, path, id);
if (opt->binary != GREP_BINARY_TEXT)
- grep_source_load_driver(&todo[todo_end].source);
+ grep_source_load_driver(&todo[todo_end].source, opt);
todo[todo_end].done = 0;
strbuf_reset(&todo[todo_end].out);
todo_end = (todo_end + 1) % ARRAY_SIZE(todo);
@@ -659,6 +659,9 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_SET_INT('I', NULL, &opt.binary,
N_("don't match patterns in binary files"),
GREP_BINARY_NOMATCH),
+ OPT_SET_INT(0, "textconv", &opt.binary,
+ N_("process binary files with textconv filters"),
+ GREP_BINARY_TEXTCONV),
{ OPTION_INTEGER, 0, "max-depth", &opt.max_depth, N_("depth"),
N_("descend at most <depth> levels"), PARSE_OPT_NONEG,
NULL, 1 },
diff --git a/grep.c b/grep.c
index 4bd1b8b..410b7b8 100644
--- a/grep.c
+++ b/grep.c
@@ -1,10 +1,12 @@
#include "cache.h"
+#include "diff.h"
+#include "diffcore.h"
#include "grep.h"
#include "userdiff.h"
#include "xdiff-interface.h"
-static int grep_source_load(struct grep_source *gs);
-static int grep_source_is_binary(struct grep_source *gs);
+static int grep_source_load(struct grep_source *gs, struct grep_opt *opt);
+static int grep_source_is_binary(struct grep_source *gs, struct grep_opt *opt);
static struct grep_opt grep_defaults;
@@ -1174,7 +1176,7 @@ static int match_funcname(struct grep_opt *opt, struct grep_source *gs, char *bo
{
xdemitconf_t *xecfg = opt->priv;
if (xecfg && !xecfg->find_func) {
- grep_source_load_driver(gs);
+ grep_source_load_driver(gs, opt);
if (gs->driver->funcname.pattern) {
const struct userdiff_funcname *pe = &gs->driver->funcname;
xdiff_set_find_func(xecfg, pe->pattern, pe->cflags);
@@ -1354,14 +1356,15 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle
switch (opt->binary) {
case GREP_BINARY_DEFAULT:
- if (grep_source_is_binary(gs))
+ if (grep_source_is_binary(gs, opt))
binary_match_only = 1;
break;
case GREP_BINARY_NOMATCH:
- if (grep_source_is_binary(gs))
+ if (grep_source_is_binary(gs, opt))
return 0; /* Assume unmatch */
break;
case GREP_BINARY_TEXT:
+ case GREP_BINARY_TEXTCONV:
break;
default:
die("bug: unknown binary handling mode");
@@ -1372,7 +1375,7 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle
try_lookahead = should_lookahead(opt);
- if (grep_source_load(gs) < 0)
+ if (grep_source_load(gs, opt) < 0)
return 0;
bol = gs->buf;
@@ -1610,12 +1613,17 @@ void grep_source_clear_data(struct grep_source *gs)
}
}
-static int grep_source_load_sha1(struct grep_source *gs)
+static int grep_source_load_sha1(struct grep_source *gs, struct grep_opt *opt)
{
enum object_type type;
-
grep_read_lock();
- gs->buf = read_sha1_file(gs->identifier, &type, &gs->size);
+ if (opt->binary == GREP_BINARY_TEXTCONV) {
+ struct diff_filespec *df = alloc_filespec(gs->name);
+ gs->size = fill_textconv(gs->driver, df, &gs->buf);
+ free_filespec(df);
+ } else {
+ gs->buf = read_sha1_file(gs->identifier, &type, &gs->size);
+ }
grep_read_unlock();
if (!gs->buf)
@@ -1625,7 +1633,7 @@ static int grep_source_load_sha1(struct grep_source *gs)
return 0;
}
-static int grep_source_load_file(struct grep_source *gs)
+static int grep_source_load_file(struct grep_source *gs, struct grep_opt *opt)
{
const char *filename = gs->identifier;
struct stat st;
@@ -1660,42 +1668,45 @@ static int grep_source_load_file(struct grep_source *gs)
return 0;
}
-static int grep_source_load(struct grep_source *gs)
+static int grep_source_load(struct grep_source *gs, struct grep_opt *opt)
{
if (gs->buf)
return 0;
switch (gs->type) {
case GREP_SOURCE_FILE:
- return grep_source_load_file(gs);
+ return grep_source_load_file(gs, opt);
case GREP_SOURCE_SHA1:
- return grep_source_load_sha1(gs);
+ return grep_source_load_sha1(gs, opt);
case GREP_SOURCE_BUF:
return gs->buf ? 0 : -1;
}
die("BUG: invalid grep_source type");
}
-void grep_source_load_driver(struct grep_source *gs)
+void grep_source_load_driver(struct grep_source *gs, struct grep_opt *opt)
{
if (gs->driver)
return;
- grep_attr_lock();
+ grep_attr_lock(); //TODO
+ printf("Looking up userdiff driver for: %s", gs->path);
if (gs->path)
gs->driver = userdiff_find_by_path(gs->path);
if (!gs->driver)
gs->driver = userdiff_find_by_name("default");
+ if (opt->binary == GREP_BINARY_TEXTCONV)
+ gs->driver = userdiff_get_textconv(gs->driver);
grep_attr_unlock();
}
-static int grep_source_is_binary(struct grep_source *gs)
+static int grep_source_is_binary(struct grep_source *gs, struct grep_opt *opt)
{
- grep_source_load_driver(gs);
+ grep_source_load_driver(gs, opt);
if (gs->driver->binary != -1)
return gs->driver->binary;
- if (!grep_source_load(gs))
+ if (!grep_source_load(gs, opt))
return buffer_is_binary(gs->buf, gs->size);
return 0;
diff --git a/grep.h b/grep.h
index 8fc854f..d272d25 100644
--- a/grep.h
+++ b/grep.h
@@ -105,6 +105,7 @@ struct grep_opt {
#define GREP_BINARY_DEFAULT 0
#define GREP_BINARY_NOMATCH 1
#define GREP_BINARY_TEXT 2
+#define GREP_BINARY_TEXTCONV 3
int binary;
int extended;
int use_reflog_filter;
@@ -173,7 +174,7 @@ void grep_source_init(struct grep_source *gs, enum grep_source_type type,
const void *identifier);
void grep_source_clear_data(struct grep_source *gs);
void grep_source_clear(struct grep_source *gs);
-void grep_source_load_driver(struct grep_source *gs);
+void grep_source_load_driver(struct grep_source *gs, struct grep_opt *opt);
int grep_source(struct grep_opt *opt, struct grep_source *gs);
--
1.8.1.2.718.g9d378fc
^ permalink raw reply related
* Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Junio C Hamano @ 2013-02-04 16:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Nguyễn Thái Ngọc Duy, git, Jonathan Niedier
In-Reply-To: <vpqr4kwmdcs.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Just to be sure: "other" here is not a hardcoded message "bisecting
> other", but an instance of "bisecting <branch-name>" with the branch
> being called "other".
OK, then I do not have any objection. Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Michal Nazarewicz @ 2013-02-04 16:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Krzysztof Mazur
In-Reply-To: <20130130074306.GA17868@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
On Wed, Jan 30 2013, Jeff King wrote:
> I do not mind a .netrc or .authinfo parser, because while those formats
> do have security problems, they are standard files that may already be
> in use. So as long as we are not encouraging their use, I do not see a
> problem in supporting them (and we already do the same with curl's netrc
> support).
>
> But it would probably make sense for send-email to support the existing
> git-credential subsystem, so that it can take advantage of secure
> system-specific storage. And that is where we should be pointing new
> users. I think contrib/mw-to-git even has credential support written in
> perl, so it would just need to be factored out to Git.pm.
As far as I understand, there could be a git-credential helper that
reads ~/.authinfo and than git-send-email would just call “git
credential fill”, right?
I've noticed though, that git-credential does not support port argument,
which makes it slightly incompatible with ~/.authinfo.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2.2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: [RFC] Should "log --cc" imply "log --cc -p"?
From: Junio C Hamano @ 2013-02-04 16:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <510F95D7.6010107@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> But diffs are on here ("-p"), it's just that the default diff option for
> merges is to not display them. Well, I admit there's two different ways
> of thinking here:
>
> A) "git log -p" turns on diffs for all commits, and the default diff
> options is the (non-existing) "--no-show" diff-option for merges.
>
> B) "git log -p" applies "-p" to all commits except merge commits.
>
> I'm strongly in the A camp,...
I can personally be trained to think either way, but I suspect that
we already came halfway to
C) "-p" asks for two-way patches, and "-c/--cc" ask for n-way
patches (including but not limited to n==2); it is not that -p
asks for patch generation and others modify the finer behaviour
of patch generation.
"git log/diff-files -U8" do not need "-p" to enable textual patches,
for example. It is "I already told you that I want 8-line context.
For what else, other than showing textual diff, do you think I told
you that for?" and replacing "8-line context" with various other
options that affect patch generation will give us a variety of end
user complaints that would tell us that C) is more intuitive to
them.
But I do not feel very strongly that I am *right* on this issue, so
I won't do anything about it hastily right now.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-04 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
On Sun, 3 Feb 2013 14:41:49 -0500 Jeff King <peff@peff.net> wrote:
JK> On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
>> If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
>> use the output. So non-interactively, that could hang if GPG was
>> waiting for input. Does Git handle that, or should I check for a TTY?
JK> No, git does not do anything special with respect to credential helpers
JK> and ttys (nor should it, since one use of helpers is to get credentials
JK> when there is no tty). I think it is GPG's problem to deal with, though.
JK> We will invoke it, and it is up to it to decide whether it can acquire
JK> the passphrase or not (either through the tty, or possibly from
JK> gpg-agent). So it would be wrong to do the tty check yourself.
JK> I haven't tested GPG, but I assume it properly tries to read from
JK> /dev/tty and not stdin. Your helper's stdio is connected to git and
JK> speaking the credential-helper protocol, so GPG reading from stdin would
JK> either steal your input (if run before you read it), or just get EOF (if
JK> you have read all of the pipe content already). If GPG isn't well
JK> behaved, it may be worth redirecting its stdin from /dev/null as a
JK> safety measure.
In my testing GPG did the right thing, so I think this is OK.
>> Take a look at the proposed patch and let me know if it's usable, if you
>> need a formal copyright assignment, etc.
JK> Overall looks sane to me, though my knowledge of .netrc is not
JK> especially good. Usually we try to send patches inline in the email
JK> (i.e., as generated by git-format-patch), and include a "Signed-off-by"
JK> line indicating that content is released to the project; see
JK> Documentation/SubmittingPatches.
OK, thanks. I will fire that off.
>> +use Data::Dumper;
JK> I don't see it used here. Leftover from debugging?
It's part of my Perl new script skeleton, sorry.
>> + print <<EOHIPPUS;
JK> Cute, I haven't seen that one before.
Heh heh. I've had to explain that one in code review many times. "See,
it's the precursor to the modern horse..."
>> +$0 [-f AUTHFILE] [-d] get
>> +
>> +Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
JK> I don't know if we have a particular policy for items in contrib/, but
JK> this license may be too vague. In particular, it does not explicitly
JK> allow redistribution, which would make Junio shipping a release with it
JK> a copyright violation.
JK> Any objection to just putting it under some well-known simple license
JK> (GPL, BSD, or whatever)?
No, I didn't know what Git requires, and I'd like it to be the least
restrictive, so BSD is OK. Stated in -h now.
>> +if ($file =~ m/\.gpg$/)
>> +{
>> + $file = "gpg --decrypt $file|";
>> +}
JK> Does this need to quote $file, since the result will get passed to the
JK> shell? It might be easier to just use the list form of open(), like:
JK> my @data = $file =~ /\.gpg$/ ?
JK> load('-|', qw(gpg --decrypt), $file) :
JK> load('<', $file);
JK> (and then obviously update load to just dump all of @_ to open()).
Yes, thanks. Done.
>> +die "Sorry, we could not load data from [$file]"
>> + unless (scalar @data);
JK> Probably not that interesting a corner case, but this means we die on an
JK> empty .netrc, whereas it might be more sensible for it to behave as "no
JK> match".
JK> For the same reason, it might be worth silently exiting when we don't
JK> find a .netrc (or any of its variants). That lets people who share their
JK> dot-files across machines configure git globally, even if they don't
JK> necessarily have a netrc on every machine.
OK; done.
>> +# the query
>> +my %q;
>> +
>> +foreach my $v (values %{$options{tmap}})
>> +{
>> + undef $q{$v};
>> +}
JK> Just my personal style, but I find the intent more obvious with "map" (I
JK> know some people find it unreadable, though):
JK> my %q = map { $_ => undef } values(%{$options{tmap}});
Yes, changed.
>> +while (<STDIN>)
>> +{
>> + next unless m/([a-z]+)=(.+)/;
JK> We don't currently have any exotic tokens that this would not match, nor
JK> do I plan to add them, but the credential documentation defines a valid
JK> line as /^([^=]+)=(.+)/.
JK> It's also possible for the value to be empty, but I do not think
JK> off-hand that current git will ever send such an empty value.
Yes, changed.
JK> The rest of it looks fine to me. I don't think any of my comments are
JK> show-stoppers. Tests would be nice, but integrating contrib/ stuff with
JK> the test harness is kind of a pain.
"I tested it on AIX, it works great!" :)
It's pretty easy to write a local Makefile with a test target, if you
think it worthwhile.
Ted
^ permalink raw reply
* [PATCH 1/3] Add contrib/credentials/netrc with GPG support
From: Ted Zlatanov @ 2013-02-04 16:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 242 +++++++++++++++++++++++++
1 files changed, 242 insertions(+), 0 deletions(-)
create mode 100755 contrib/credential/netrc/git-credential-netrc
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 0000000..92fc306
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,242 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Data::Dumper;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = "0.1";
+
+my %options = (
+ help => 0,
+ debug => 0,
+
+ # identical token maps, e.g. host -> host, will be inserted later
+ tmap => {
+ port => 'protocol',
+ machine => 'host',
+ path => 'path',
+ login => 'username',
+ user => 'username',
+ password => 'password',
+ }
+ );
+
+foreach my $v (values %{$options{tmap}})
+{
+ $options{tmap}->{$v} = $v;
+}
+
+foreach my $suffix ('.gpg', '')
+{
+ foreach my $base (qw/authinfo netrc/)
+ {
+ my $file = glob("~/.$base$suffix");
+ next unless (defined $file && -f $file);
+ $options{file} = $file ;
+ }
+}
+
+Getopt::Long::Configure("bundling");
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ "help|h",
+ "debug|d",
+ "file|f=s",
+ );
+
+if ($options{help})
+{
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print <<EOHIPPUS;
+
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+
+Options:
+ -f AUTHFILE: specify a netrc-style file
+ -d: turn on debugging
+
+To enable (note that Git will prepend "git-credential-" to the helper
+name and look for it in the path):
+
+ git config credential.helper '$shortname -f AUTHFILE'
+
+And if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+Only "get" mode is supported by this credential helper. It opens
+AUTHFILE and looks for entries that match the requested search
+criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get "protocol=https\nusername=tzz", this credential
+helper will look for lines in AUTHFILE that match
+
+port https login tzz
+
+OR
+
+protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the line,
+including "password" tokens, mapping e.g. "port" back to "protocol".
+
+The first matching line is used. Tokens can be quoted as 'STRING' or
+"STRING".
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit;
+}
+
+my $mode = shift @ARGV;
+
+# credentials may get 'get', 'store', or 'erase' as parameters but
+# only acknowledge 'get'
+die "Syntax: $0 [-f AUTHFILE] [-d] get" unless defined $mode;
+
+# only support 'get' mode
+exit unless $mode eq 'get';
+
+my $debug = $options{debug};
+my $file = $options{file};
+
+die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
+ unless defined $file;
+
+die "Sorry, the specified netrc $file is not accessible"
+ unless -f $file;
+
+if ($file =~ m/\.gpg$/)
+{
+ $file = "gpg --decrypt $file|";
+}
+
+my @data = load($file);
+chomp @data;
+
+die "Sorry, we could not load data from [$file]"
+ unless (scalar @data);
+
+# the query
+my %q;
+
+foreach my $v (values %{$options{tmap}})
+{
+ undef $q{$v};
+}
+
+while (<STDIN>)
+{
+ next unless m/([a-z]+)=(.+)/;
+
+ my ($token, $value) = ($1, $2);
+ die "Unknown search token $1" unless exists $q{$token};
+ $q{$token} = $value;
+}
+
+# build reverse token map
+my %rmap;
+foreach my $k (keys %{$options{tmap}})
+{
+ push @{$rmap{$options{tmap}->{$k}}}, $k;
+}
+
+# there are CPAN modules to do this better, but we want to avoid
+# dependencies and generally, complex netrc-style files are rare
+
+if ($debug)
+{
+ foreach (sort keys %q)
+ {
+ printf STDERR "searching for %s = %s\n",
+ $_, $q{$_} || '(any value)';
+ }
+}
+
+LINE: foreach my $line (@data)
+{
+
+ print STDERR "line [$line]\n" if $debug;
+ my @tok;
+ # gratefully stolen from Net::Netrc
+ while (length $line &&
+ $line =~ s/^("((?:[^"]+|\\.)*)"|((?:[^\\\s]+|\\.)*))\s*//)
+ {
+ (my $tok = $+) =~ s/\\(.)/$1/g;
+ push(@tok, $tok);
+ }
+
+ my %tokens;
+ while (@tok)
+ {
+ my ($k, $v) = (shift @tok, shift @tok);
+ next unless defined $v;
+ next unless exists $options{tmap}->{$k};
+ $tokens{$options{tmap}->{$k}} = $v;
+ }
+
+ foreach my $check (sort keys %q)
+ {
+ if (exists $tokens{$check} && defined $q{$check})
+ {
+ print STDERR "comparing [$tokens{$check}] to [$q{$check}] in line [$line]\n" if $debug;
+ next LINE unless $tokens{$check} eq $q{$check};
+ }
+ else
+ {
+ print STDERR "we could not find [$check] but it's OK\n" if $debug;
+ }
+ }
+
+ print STDERR "line has passed all the search checks\n" if $debug;
+ foreach my $token (sort keys %rmap)
+ {
+ print STDERR "looking for useful token $token\n" if $debug;
+ next unless exists $tokens{$token}; # did we match?
+
+ foreach my $rctoken (@{$rmap{$token}})
+ {
+ next if defined $q{$rctoken}; # don't re-print given tokens
+ }
+
+ print STDERR "FOUND: $token=$tokens{$token}\n" if $debug;
+ printf "%s=%s\n", $token, $tokens{$token};
+ }
+
+ last;
+}
+
+sub load
+{
+ my $file = shift;
+ # this supports pipes too
+ my $io = new IO::File($file) or die "Could not open $file: $!\n";
+
+ return <$io>; # whole file
+}
--
1.7.9.rc2
^ permalink raw reply related
* [PATCH 2/3] Skip blank and commented lines in contrib/credentials/netrc
From: Ted Zlatanov @ 2013-02-04 16:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
index 92fc306..a47a223 100755
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -192,6 +192,9 @@ LINE: foreach my $line (@data)
push(@tok, $tok);
}
+ # skip blank lines, comments, etc.
+ next LINE unless scalar @tok;
+
my %tokens;
while (@tok)
{
--
1.7.9.rc2
^ permalink raw reply related
* [PATCH 3/3] Fix contrib/credentials/netrc minor issues: exit quietly; use 3-parameter open; etc.
From: Ted Zlatanov @ 2013-02-04 16:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 38 +++++++++++++------------
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
index a47a223..0e35918 100755
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -3,8 +3,6 @@
use strict;
use warnings;
-use Data::Dumper;
-
use Getopt::Long;
use File::Basename;
@@ -58,7 +56,7 @@ if ($options{help})
$0 [-f AUTHFILE] [-d] get
-Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+Version $VERSION by tzz\@lifelogs.com. License: BSD.
Options:
-f AUTHFILE: specify a netrc-style file
@@ -129,31 +127,36 @@ my $file = $options{file};
die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
unless defined $file;
-die "Sorry, the specified netrc $file is not accessible"
- unless -f $file;
+unless (-f $file)
+{
+ print STDERR "Sorry, the specified netrc $file is not accessible\n" if $debug;
+ exit 0;
+}
+my @data;
if ($file =~ m/\.gpg$/)
{
- $file = "gpg --decrypt $file|";
+ @data = load('-|', qw(gpg --decrypt), $file)
+}
+else
+{
+ @data = load('<', $file);
}
-my @data = load($file);
chomp @data;
-die "Sorry, we could not load data from [$file]"
- unless (scalar @data);
-
-# the query
-my %q;
-
-foreach my $v (values %{$options{tmap}})
+unless (scalar @data)
{
- undef $q{$v};
+ print STDERR "Sorry, we could not load data from [$file]\n" if $debug;
+ exit;
}
+# the query: start with every token with no value
+my %q = map { $_ => undef } values(%{$options{tmap}});
+
while (<STDIN>)
{
- next unless m/([a-z]+)=(.+)/;
+ next unless m/([^=]+)=(.+)/;
my ($token, $value) = ($1, $2);
die "Unknown search token $1" unless exists $q{$token};
@@ -237,9 +240,8 @@ LINE: foreach my $line (@data)
sub load
{
- my $file = shift;
# this supports pipes too
- my $io = new IO::File($file) or die "Could not open $file: $!\n";
+ my $io = new IO::File(@_) or die "Could not open [@_]: $!\n";
return <$io>; # whole file
}
--
1.7.9.rc2
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Junio C Hamano @ 2013-02-04 16:46 UTC (permalink / raw)
To: Jeff King; +Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <20130204093821.GA32095@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:
>
>> I think this really boils down to where we draw the "this is good
>> enough" line. I am not sure if losing the file as in $gmane/215211
>> is common enough to be special cased to buy us much, while leaving
>> other ".depend/foo.o.d was updated to contain a wrong info" cases
>> still broken.
>
> Hmm. Yeah, I was thinking it might be more common than ordinary munging
> due to something like an interrupted "git clean -x". But given that:
>
> 1. As far as I can tell, it is not a situation that can happen through
> regular use of checkout/make/etc, and...
>
> 2. We have zero reports of it happening in practice (I only discovered
> it while explicitly trying to break the Makefile), and...
>
> 3. It is just one of many possible breakages, all of which can be
> fixed by "git clean -dx" if you suspect issues...
>
> let's just leave it. Thanks for a sanity check.
The only case that worries me is when make or cc gets interrupted.
As long as make removes the ultimate target *.o in such a case, it
is fine to leave a half-written .depend/foo.o.d (or getting it
removed) behind.
How expensive to generate the dependency for a single foo.c file
into a temporary without compiling it into foo.o, and comparing the
resulting dependency with existing .depend/foo.o.d? If it is very
cheap, it might be worth doing it before linking the final build
product and error the build out when we see discrepancies. I dunno.
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-04 16:52 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Robert Clausecker, Michael J Gruber, git
In-Reply-To: <1359982065-ner-9588@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> That's what `git checkout` is for. And I would even argue that it's the better
> choice in your situation because it would delete files from /var/www/foo which
> you have deleted in your repo. git archive|tar wouldn't do that.
The point about removal is an interesting one. From that /var/www
location I guess that you are discussing some webapp, but if you let
it _write_ into it, you may also have to worry about how to handle
the case where an update from the source end that comes from the
checkout and an update by the webapp collide with each other.
You also need to maintain the .git/index file that corresponds to
what should be in /var/www/foo/ if you go that route.
Just to be sure, I am not saying "checkout" is an inappropriate
solution to whatever problem you are trying to solve. I am just
pointing out things you need to be aware of if you take that
approach.
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-04 16:55 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Robert Clausecker, Michael J Gruber, git@vger.kernel.org
In-Reply-To: <CAH5451mp6fRU25LWE+8gk1h6Mz=y_XQHaU-iE0k4=bP0RfzLAA@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> wrote:
>> The specific workflow I am planning is this:
>>
>> I have a server that hosts a bare git repository. This git repository
>> contains a branch production. Whenever somebody pushes to production a
>> hook automatically puts a copy of the current production branch
>> into /var/www/foo. I could of course use pull for that but it just does
>> not feels right. Why should I have a repository twice on the server?
>
> Maybe I'm missing something. How does the behaviour you need differ from
>
>> GIT_WORKING_DIR=/var/www/foo git checkout -f <tree-ish>
>
> ??
In addition to the fact that your misspellt environment variable
name will not cause it to write there, you will also be overwriting
the index for your working tree, which presumably you meant is a
location different from the /var/www/foo, with the contents of
<tree-ish>.
^ permalink raw reply
* Re: [PATCH 1/3] Add contrib/credentials/netrc with GPG support
From: Ted Zlatanov @ 2013-02-04 16:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <87sj5cvxnf.fsf_-_@lifelogs.com>
Grr, sorry for the bad formatting. First time doing format-patch.
Ted
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-04 17:00 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: Jeff King, Junio C Hamano, git, Krzysztof Mazur
In-Reply-To: <xa1tmwvk9gy1.fsf@mina86.com>
On Mon, 04 Feb 2013 17:33:58 +0100 Michal Nazarewicz <mina86@mina86.com> wrote:
MN> As far as I understand, there could be a git-credential helper that
MN> reads ~/.authinfo and than git-send-email would just call “git
MN> credential fill”, right?
MN> I've noticed though, that git-credential does not support port argument,
MN> which makes it slightly incompatible with ~/.authinfo.
My proposed netrc credential helper does this :)
The token mapping I use:
port, protocol => protocol
machine, host => host
path => path
login, username, user => username
password => password
I think that's sensible.
Ted
^ permalink raw reply
* Re: [PATCH 2/2] count-objects: report garbage files in .git/objects/pack directory too
From: Junio C Hamano @ 2013-02-04 17:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1359982145-10792-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The hook in prepare_packed_git_one is ugly, but I don't want to
> duplicate the search file logic there in count-objects. Maybe I'm
> wrong.
In this particular case I do not think you are completely wrong;
you are probably only two thirds wrong ;-)
The idea to use a customizable function pointer to allow it do extra
work is probably fine, but adding three identical calls and continue
is a bad taste. Just have one callsite for the error path and do
not hesitate to jump to it with 'goto'.
I do not think failure to add_packed_git() should be treated the
same way as other cases where the files readdir() found are truly
garbage, by the way.
I also wonder, especially because you are enumerating the temporary
pack files in .git/objects/pack/, if it make more sense to account
for their sizes as well. After all, you would end up doing stat()
for a common case of files with ".pack" suffix---doing so for all of
them shouldn't be too bad.
^ permalink raw reply
* Re: [WIP/RFH/RFD/PATCH] grep: allow to use textconv filters
From: Junio C Hamano @ 2013-02-04 17:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King
In-Reply-To: <2c0641ea4df6a872a4466efe0c0124f304f44c3e.1359991521.git.git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Recently and not so recently, we made sure that log/grep type operations
> use textconv filters when a userfacing diff would do the same:
>
> ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
> b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
> 0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)
>
> "git grep" currently does not use textconv filters at all, that is
> neither for displaying the match and context nor for the actual grepping.
>
> Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
> which makes git grep use any configured textconv filters for grepping
> and output purposes.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>
> Notes:
> I'm somehow stuck in textconv/filespec/... hell, so I'm sending this out
> in request for help. I'm sure there are people for whom it's a breeze to
> get this right.
Looks like the patch touches the right places in the codepaths that
need to be updated from a quick read.
> The difficulty is in getting the different cases (blob/sha1 vs.
> worktree) right, and in making the changes minimally invasive.
I think grep_source abstraction was intended to be a way for that,
and if what it gives you is not sufficient for your needs, extending
it should not be seen as "invasive" at all.
^ permalink raw reply
* Re: [PATCH 1/3] Add contrib/credentials/netrc with GPG support
From: Junio C Hamano @ 2013-02-04 17:24 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: git, Jeff King
In-Reply-To: <87sj5cvxnf.fsf_-_@lifelogs.com>
[administrivia: I would really wish you didn't put "Mail-copies-to:
never" above].
Ted Zlatanov <tzz@lifelogs.com> writes:
> +foreach my $v (values %{$options{tmap}})
> +{
> + $options{tmap}->{$v} = $v;
> +}
Please follow the styles of existing Perl scripts, e.g. indent with
tab, etc. Style requests are not optional; it is a prerequisite to
make the patch readable and reviewable.
> + print <<EOHIPPUS;
> + ...
> +EOHIPPUS
Do we really need to refer readers to Wikipedia or something to
learn about extinct equid ungulates ;-)?
^ permalink raw reply
* Re: [PATCH 3/3] Fix contrib/credentials/netrc minor issues: exit quietly; use 3-parameter open; etc.
From: Junio C Hamano @ 2013-02-04 17:27 UTC (permalink / raw)
To: Ted Zlatanov; +Cc: git, Jeff King
In-Reply-To: <87k3qovxlp.fsf_-_@lifelogs.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
> ---
> contrib/credential/netrc/git-credential-netrc | 38 +++++++++++++------------
> 1 files changed, 20 insertions(+), 18 deletions(-)
Especially because this is an initial submission, please equash
three patches into one, instead of sending three "here is my first
attempt with many problems I know I do not want to be there", "one
small improvement", "another one to fix remaining issues".
Otherwise you will waste reviewers' time, getting distracted by
undesirable details they find in an earlier patch while reviewing,
without realizing that some of them are fixed in a later one.
Thanks.
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Junio C Hamano @ 2013-02-04 17:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Thomas Rast, Rene Moser, git
In-Reply-To: <20130128204140.GA7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
>> need to read blob from the standard input, 2012-06-27), which is
>> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
>> upgrade.
>
> Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
> is currently in the release candidate stage) take this fix? Do you
> happen to know of any other fixes such people would want?
I've been wondering if we can help automating this for backporters.
Because of the way my integration branches are managed, if you run
git log --first-parent v1.8.0..maint-1.8.0
git log --first-parent v1.8.1..maint
the output should give us a birds-eye view (because most are merges
of one or more patches on a topic) of the changes that are fixes,
excluding any feature enhancements.
You can then iterate over the single patches applied directly on top
of maint (or maint-1.8.0) and tips of the topics merged to maint (or
maint-1.8.0) and see if each of them is applicable to maint-1.7.10
codebase. I think you can mechanically reject the ones that are on
'maint' that merge topics that were forked from v1.8.1 as too new.
That hopefully culls the topics that needs manual review and
assessment (some may be too minor to be worth backproting, for
example).
You should be able to do the same for
git log --first-parent v1.8.1..master
There will be fixes and features mixed in the output, but if you
can mechanically narrow down the ones that may be relevant to your
old maintenance track, eyeballing the rest to judge if each of them
is worth backporting will become a manageable task.
^ permalink raw reply
* Re: [PATCH 2/2] count-objects: report garbage files in .git/objects/pack directory too
From: Junio C Hamano @ 2013-02-04 18:16 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1359982145-10792-2-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -1024,11 +1035,15 @@ static void prepare_packed_git_one(char *objdir, int local)
> int namelen = strlen(de->d_name);
> struct packed_git *p;
>
> - if (!has_extension(de->d_name, ".idx"))
> + if (!has_extension(de->d_name, ".idx")) {
> + report_pack_garbage(path, len - 1, de->d_name);
> continue;
> + }
>
> - if (len + namelen + 1 > sizeof(path))
> + if (len + namelen + 1 > sizeof(path)) {
> + report_pack_garbage(path, len - 1, de->d_name);
> continue;
> + }
>
> /* Don't reopen a pack we already have. */
> strcpy(path + len, de->d_name);
> @@ -1042,8 +1057,10 @@ static void prepare_packed_git_one(char *objdir, int local)
> * .pack file that we can map.
> */
> p = add_packed_git(path, len + namelen, local);
> - if (!p)
> + if (!p) {
> + report_pack_garbage(path, len - 1, de->d_name);
> continue;
> + }
> install_packed_git(p);
> }
> closedir(dir);
I forgot to mention one more thing. Your report_pack_garbage()
special cases ".pack" to see if it is a regular file, but this loop
structure causes a regular file whose name ends with ".pack" but
without corresponding ".idx" file to go unreported.
I think the loop should be restructured to iterate over all known
file types and report unknown ones, if you want to repurpose it for
the reporting, something along this line, perhaps:
for (each name) {
if (does it end with ".idx") {
if (is it unusable ".idx") {
report garbage;
}
continue;
}
if (! we are in report mode)
continue;
if (does it end with ".pack") {
if (!have we seen corresponding ".idx")
remember it;
continue;
}
report garbage;
}
for (remembered pack) {
if (does it have corresponding ".idx" &&
is it really usable ".pack")
continue;
report garbage;
}
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Andreas Schwab @ 2013-02-04 18:21 UTC (permalink / raw)
To: Robert Clausecker; +Cc: Michael J Gruber, git
In-Reply-To: <1359980045.24730.32.camel@t520>
Robert Clausecker <fuzxxl@gmail.com> writes:
> I have a server that hosts a bare git repository. This git repository
> contains a branch production. Whenever somebody pushes to production a
> hook automatically puts a copy of the current production branch
> into /var/www/foo. I could of course use pull for that but it just does
> not feels right. Why should I have a repository twice on the server?
You can avoid the separate repo copy by using git new-workdir.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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