* Re: [PATCH] rename dirlink to gitlink.
From: Junio C Hamano @ 2007-05-21 23:32 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Martin Waitz, Junio C Hamano, git
In-Reply-To: <e7bda7770705211612w3ce1b7dew8d48f1ddeb7d100e@mail.gmail.com>
"Torgil Svensson" <torgil.svensson@gmail.com> writes:
> On 5/21/07, Martin Waitz <tali@admingilde.org> wrote:
>> Unify naming of plumbing dirlink/gitlink concept:
>>
>> perl -pi -e 's/dirlink/gitlink/g' -e 's/DIRLNK/GITLINK/g'
>> ---
>
> Does this mean that the link doesn't necessarily has to be represented
> as a directory (even though current code does it) ?
I do not think the patch has that much deep meaning.
Personally I think the patch is similar to renaming "cache" used
in the code to "index" --- needless code shuffling that does not
buy you anything.
As an internal symbol, S_IFDIRLNK makes _much_ more sense than
S_IFGITLINK, exactly because it is a mixture of S_IFDIR and
S_IFLNK.
The only excuse that we _might_ want to consider the patch is
that S_IFDIRLNK has not lived that long, compared to the use of
word "cache" in our codebase. It's only two weeks old -- so if
we were to apply this patch, we would need to do that right
away, or it will be never.
But I am not _so_ enthused about the renaming in the code.
^ permalink raw reply
* Re: [PATCH] Allow user to specify mailbox format for mailsplit
From: Junio C Hamano @ 2007-05-21 23:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: Fernando J. Pereda, Git Mailing List
In-Reply-To: <20070521230524.GC10890@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> If the argument ends with a slash - assume it is a Maildir and try to
> create it. Otherwise - it is an mbox.
Sorry, I am lost here. git-mailsplit is to read an existing
mbox and split the pieces of e-mail into the specified output
directory. The recent Maildir support is to make it read pieces
of e-mails from an existing Maildir (which presumably have bunch
of files that store e-mail), isn't it?
If the patch were about creating a new _output_ directory (that
is, "dir" in cmd_mailsplit), I would understand what you are
trying to do, but why would you even want to create the input
Maildir in that loop (I take that your patch is on top of
Fernando's patch)?
^ permalink raw reply
* Re: [PATCH] rename dirlink to gitlink.
From: Torgil Svensson @ 2007-05-21 23:12 UTC (permalink / raw)
To: Martin Waitz; +Cc: Junio C Hamano, git
In-Reply-To: <20070521200828.GC5412@admingilde.org>
On 5/21/07, Martin Waitz <tali@admingilde.org> wrote:
> Unify naming of plumbing dirlink/gitlink concept:
>
> perl -pi -e 's/dirlink/gitlink/g' -e 's/DIRLNK/GITLINK/g'
> ---
Does this mean that the link doesn't necessarily has to be represented
as a directory (even though current code does it) ?
//Torgil
^ permalink raw reply
* [PATCH] Allow user to specify mailbox format for mailsplit
From: Alex Riesen @ 2007-05-21 23:05 UTC (permalink / raw)
To: Fernando J. Pereda, Junio C Hamano, Git Mailing List
In-Reply-To: <20070521182052.GB4696@ferdyx.org>
If the argument ends with a slash - assume it is a Maildir and try to
create it. Otherwise - it is an mbox.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Documentation/git-mailsplit.txt | 4 +++-
builtin-mailsplit.c | 10 ++++++++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-mailsplit.txt b/Documentation/git-mailsplit.txt
index abb0903..2c58e09 100644
--- a/Documentation/git-mailsplit.txt
+++ b/Documentation/git-mailsplit.txt
@@ -25,7 +25,9 @@ OPTIONS
<Maildir>::
Root of the Maildir to split. This directory should contain the cur, tmp
- and new subdirectories.
+ and new subdirectories. If the argument ends with a slash '/'
+ the directory and new, cur and tmp subdirectories will be
+ created automatically.
<directory>::
Directory in which to place the individual messages.
diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
index 454f943..370f7fa 100644
--- a/builtin-mailsplit.c
+++ b/builtin-mailsplit.c
@@ -253,6 +253,7 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
const char *arg = *argp++;
struct stat argstat;
int ret = 0;
+ size_t arglen = strlen(arg);
if (arg[0] == '-' && arg[1] == 0) {
ret = split_mbox(arg, dir, allow_bare, nr_prec, nr);
@@ -264,6 +265,15 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
continue;
}
+ if (arglen && arg[arglen-1] == '/') {
+ char *dir = malloc(arglen + 5);
+ memcpy(dir, arg, arglen);
+ mkdir(arg, 0777);
+ mkdir(strcpy(dir + arglen, "new"), 0777);
+ mkdir(strcpy(dir + arglen, "cur"), 0777);
+ mkdir(strcpy(dir + arglen, "tmp"), 0777);
+ free(dir);
+ }
if (stat(arg, &argstat) == -1) {
error("cannot stat %s (%s)", arg, strerror(errno));
return 1;
--
1.5.2.rc3.112.gc1e43
^ permalink raw reply related
* Re: [PATCH] git-status: respect core.excludesFile
From: Junio C Hamano @ 2007-05-21 23:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705212251300.6410@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> git-add reads this variable, and honours the contents of that file if that
> exists. Match this behaviour in git-status, too.
>
> Noticed by Evan Carroll on IRC.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Sounds good, and probably is a 'maint' material.
Don't we need a documentation update and additional test for it,
though?
^ permalink raw reply
* Re: [PATCH] Add ability to specify environment extension to run_command
From: Junio C Hamano @ 2007-05-21 23:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Sven Verdoolaege
In-Reply-To: <20070521224828.GA10890@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> There is no way to specify and override for the environment: there is
> no visible user for it (yet, something in git-daemon could need it).
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Sven Verdoolaege, Mon, May 21, 2007 11:03:39 +0200:
>> Could you sign-off on this for me so I can use it my patch set?
>>
>
> So here it is. On top of the previos patch regarding chdir before
> exec. Junio, if needed, I can resend that first patch about chdir.
Both of them in a row would be good, so yes, resend is
appreciated.
> @@ -76,6 +76,10 @@ int start_command(struct child_process *cmd)
> if (cmd->dir && chdir(cmd->dir))
> die("exec %s: cd to %s failed (%s)", cmd->argv[0],
> cmd->dir, strerror(errno));
> + if (cmd->env) {
> + for (; *cmd->env; cmd->env++)
> + putenv((char*)*cmd->env);
> + }
> if (cmd->git_cmd) {
> execv_git_cmd(cmd->argv);
> } else {
I had a feeling that some callers needed to be able to unsetenv
some. How would this patch help them, or are they outside of
the scope?
^ permalink raw reply
* [PATCH] Add ability to specify environment extension to run_command
From: Alex Riesen @ 2007-05-21 22:48 UTC (permalink / raw)
To: git, Sven Verdoolaege; +Cc: Junio C Hamano
In-Reply-To: <20070521090339.GH942MdfPADPa@greensroom.kotnet.org>
There is no way to specify and override for the environment: there is
no visible user for it (yet, something in git-daemon could need it).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Sven Verdoolaege, Mon, May 21, 2007 11:03:39 +0200:
> Could you sign-off on this for me so I can use it my patch set?
>
So here it is. On top of the previos patch regarding chdir before
exec. Junio, if needed, I can resend that first patch about chdir.
run-command.c | 17 ++++++++++++++++-
run-command.h | 2 ++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/run-command.c b/run-command.c
index 043b570..605aa1e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -76,6 +76,10 @@ int start_command(struct child_process *cmd)
if (cmd->dir && chdir(cmd->dir))
die("exec %s: cd to %s failed (%s)", cmd->argv[0],
cmd->dir, strerror(errno));
+ if (cmd->env) {
+ for (; *cmd->env; cmd->env++)
+ putenv((char*)*cmd->env);
+ }
if (cmd->git_cmd) {
execv_git_cmd(cmd->argv);
} else {
@@ -137,7 +141,8 @@ int run_command(struct child_process *cmd)
}
static void prepare_run_command_v_opt(struct child_process *cmd,
- const char **argv, int opt)
+ const char **argv,
+ int opt)
{
memset(cmd, 0, sizeof(*cmd));
cmd->argv = argv;
@@ -160,3 +165,13 @@ int run_command_v_opt_cd(const char **argv, int opt, const char *dir)
cmd.dir = dir;
return run_command(&cmd);
}
+
+int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env)
+{
+ struct child_process cmd;
+ prepare_run_command_v_opt(&cmd, argv, opt);
+ cmd.dir = dir;
+ cmd.env = env;
+ return run_command(&cmd);
+}
+
diff --git a/run-command.h b/run-command.h
index cbd7484..af1e0bf 100644
--- a/run-command.h
+++ b/run-command.h
@@ -17,6 +17,7 @@ struct child_process {
int in;
int out;
const char *dir;
+ const char *const *env;
unsigned close_in:1;
unsigned close_out:1;
unsigned no_stdin:1;
@@ -34,5 +35,6 @@ int run_command(struct child_process *);
#define RUN_COMMAND_STDOUT_TO_STDERR 4
int run_command_v_opt(const char **argv, int opt);
int run_command_v_opt_cd(const char **argv, int opt, const char *dir);
+int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env);
#endif
--
1.5.2.rc3.112.gc1e43
^ permalink raw reply related
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Jakub Narebski @ 2007-05-21 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <20070521205812.GO4085@planck.djpig.de>
Frank Lichtenheld wrote:
> On Mon, May 21, 2007 at 09:54:23PM +0200, Jan Hudec wrote:
>> On Mon, May 21, 2007 at 19:46:59 +0200, Frank Lichtenheld wrote:
>> > This option will enclose key names in quotes (") if they
>> > contain a subsection and then escape " and \. It will also
>> > escape line breaks in values. Together this should produce
>> > an easily parsable output.
>>
>> That will lead to either eval (which runs perl parser and probably won't win
>> anything) or regexps (which is not big win over parsing the .ini directly
>> with them) on the perl side. IMHO only thing that would actually be faster is
>> NUL-separated entries.
>
>> Either:
>> KEY <NUL> VALUE <NUL>
>>
>> or:
>> KEY <TAB> VALUE <NUL>
>
> Both subsection names and values can contain <TAB> characters, so the
> latter isn't possible.
But neither subsection names (even [section "subsection"] style) not key
names cannot contain newline <LF>. I.e.
KEY <LF> VALUE <NUL>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Johannes Schindelin @ 2007-05-21 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Lichtenheld, Git Mailing List
In-Reply-To: <7vbqgddgff.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 21 May 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Git.pm could simply do:
> >>
> >> my $eval = `git config --perl --get-regexp 'gitcvs\..*'`;
> >> my $cfg = eval "$eval";
> >>
> >> if you code your "perl" notation to produce:
> >>
> >> +{
> >> 'gitcvs.ext.enabled' => 'false',
> >> 'gitcvs.logfile' => '/var/log/gitcvs.log',
> >> }
> >>
> >> in order to read things in.
> >>
> >> Hmm?
> >
> > IOW, something like
> > http://article.gmane.org/gmane.comp.version-control.git/36922
>
> Indeed (perhaps except fixing minor details like not hijacking
> the variable name). Care to resubmit with docs and tests?
Well, my version was not good, as Eric pointed out.
Do you want me to clean up Eric's version (according to my own comments,
that is)?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-status: respect core.excludesFile
From: Johannes Schindelin @ 2007-05-21 21:51 UTC (permalink / raw)
To: git, junkio
git-add reads this variable, and honours the contents of that file if that
exists. Match this behaviour in git-status, too.
Noticed by Evan Carroll on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
wt-status.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index a055990..4bfe8f1 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -22,6 +22,7 @@ static const char use_add_rm_msg[] =
"use \"git add/rm <file>...\" to update what will be committed";
static const char use_add_to_include_msg[] =
"use \"git add <file>...\" to include in what will be committed";
+static const char *excludes_file;
static int parse_status_slot(const char *var, int offset)
{
@@ -259,6 +260,8 @@ static void wt_status_print_untracked(struct wt_status *s)
x = git_path("info/exclude");
if (file_exists(x))
add_excludes_from_file(&dir, x);
+ if (excludes_file && file_exists(excludes_file))
+ add_excludes_from_file(&dir, excludes_file);
read_directory(&dir, ".", "", 0, NULL);
for(i = 0; i < dir.nr; i++) {
@@ -356,5 +359,11 @@ int git_status_config(const char *k, const char *v)
int slot = parse_status_slot(k, 13);
color_parse(v, k, wt_status_colors[slot]);
}
+ if (!strcmp(k, "core.excludesfile")) {
+ if (!v)
+ die("core.excludesfile without value");
+ excludes_file = xstrdup(v);
+ return 0;
+ }
return git_default_config(k, v);
}
--
1.5.2.GIT
^ permalink raw reply related
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Junio C Hamano @ 2007-05-21 21:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Frank Lichtenheld, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705211945470.6410@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Git.pm could simply do:
>>
>> my $eval = `git config --perl --get-regexp 'gitcvs\..*'`;
>> my $cfg = eval "$eval";
>>
>> if you code your "perl" notation to produce:
>>
>> +{
>> 'gitcvs.ext.enabled' => 'false',
>> 'gitcvs.logfile' => '/var/log/gitcvs.log',
>> }
>>
>> in order to read things in.
>>
>> Hmm?
>
> IOW, something like
> http://article.gmane.org/gmane.comp.version-control.git/36922
Indeed (perhaps except fixing minor details like not hijacking
the variable name). Care to resubmit with docs and tests?
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Martin Waitz @ 2007-05-21 21:11 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, skimo, Alex Riesen, git
In-Reply-To: <20070521165938.GA4118@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]
hoi :)
On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
> Here is one possible idea:
>
> We could store the GIT_DIR of submodule within the GIT_DIR of the
> superproject instead of the submodule directory itself. So instead of:
> /
> /.git
> /subdir
> /subdir/.git
>
> There would be:
> /
> /.git
> /subdir
> /.git/submodules/submodule-name.git
>
> This would require changes to the logic how git finds GIT_DIR (which would be
> really deep change), but it would provide place to store the submodule data
> while the submodule is not being checked out.
I agree that we need something like that.
We don't have to move the entire subproject.git into the superproject,
but we need to have all _referenced_ objects in the .git dir of the
superproject.
There are several possibilities to do so:
* move the entire .git dir
* move .git/objects
* explicitly copy all referenced objects
I have some experimental code to configure a per-subproject directory
in the superproject/.git as alternate object store for the submodule
to make the last two solutions possible. Perhaps I should dig it out again
and adapt it to current git.
If there is a 1:1 relationship between subproject and object store then
even efficient fsck and repack/prune are possible for the submodule without
loosing objects.
But such a 1:1 relationship is bad when you move subprojects to another
location (or include the same subproject several times in different
locations of the tree).
Perhaps the user should be able to choose which one he wants.
> > Not at all. There is no reason to believe that the case that
> > superproject and subproject come from related URLs is more
> > common. One of the reasons to do a separated project
>
> I definitely don't think it's more common. But it's the harder case and it
> might happen. Generally it will happen if some people work on both the
> superproject and the subproject. Of course the argument is that than it
> should not be separate projects, but maybe the teams just partly overlap.
I think it will be _very_ common to store super and subprojects in
related locations. First to be independent from third-party servers
while working on the superproject.
Second (and I think more important) because many times there will
be superproject related adaptations in the subproject. Yes they
are independent, and exactly for that reason the subproject upstream
maintainers may not take every change which is needed to satisfy the
superproject. We _now_ see that in all Linux distributions already.
So when you use superprojects to integrate several independent projects,
then the superproject maintainer/administrator should really keep a
clone of all subprojects handy on his site.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitweb - encoding problems
From: Ismail Dönmez @ 2007-05-21 21:09 UTC (permalink / raw)
To: Martin Koegler; +Cc: git, Jakub Narebski, Junio C Hamano
In-Reply-To: <20070521205721.GA21771@auto.tuwien.ac.at>
On Monday 21 May 2007 23:57:21 you wrote:
> binmode STDOUT, ':utf8';
>
> print decode_utf8('äöü');
[~]> perl test.pl
äöü
[~]> cat test.pl
use Encode;
binmode STDOUT, ':utf8';
print decode_utf8('äöü'),"\n";
[cartman@southpark][00:08:15]
[~]> perl --version
This is perl, v5.8.8 built for i686-linux
Copyright 1987-2006, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.
You got an old Encode.
--
Perfect is the enemy of good
^ permalink raw reply
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Frank Lichtenheld @ 2007-05-21 20:58 UTC (permalink / raw)
To: Jan Hudec; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070521195423.GC5082@efreet.light.src>
On Mon, May 21, 2007 at 09:54:23PM +0200, Jan Hudec wrote:
> On Mon, May 21, 2007 at 19:46:59 +0200, Frank Lichtenheld wrote:
> > This option will enclose key names in quotes (") if they
> > contain a subsection and then escape " and \. It will also
> > escape line breaks in values. Together this should produce
> > an easily parsable output.
>
> That will lead to either eval (which runs perl parser and probably won't win
> anything) or regexps (which is not big win over parsing the .ini directly
> with them) on the perl side. IMHO only thing that would actually be faster is
> NUL-separated entries.
> Either:
> KEY <NUL> VALUE <NUL>
>
> or:
> KEY <TAB> VALUE <NUL>
Both subsection names and values can contain <TAB> characters, so the
latter isn't possible.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* gitweb - encoding problems
From: Martin Koegler @ 2007-05-21 20:57 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano
I use ISO-8859-1 as my locale, so my blobs, commits and tags are in
this encoding.
On perl v5.8.6, decode_utf8 of any non utf-8 value returns undefined:
$cat xy
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
print decode_utf8('äöü');
$perl xy
[Mon May 21 22:00:00 2007] xy: Use of uninitialized value in print at xy line 14.
If gitweb encounters, eg. an "Umlaut" (äöü) in a commit/tag, use of
uninitialized value message are generated. In one case,
decode_utf8($long) in format_subject_html is undefined, which results
in a invalid link (a tag contains only title without any value
assignment) and a browser message, that the html is not valid.
The previous installed version of git/gitweb (1.5.0rc3) showed only
small black rhombuses, but didn't generate "uninitialized value"
messages or invalid html.
So there is regression between git-1.5.0 and git-1.5.2.
Adding $var = encode_utf8($var) if (!defined decode_utf8($var)) for
each "uninitialized value" message results in a correct result for me.
I wanted to post a patch with these changes, as it solved my locale problem.
But then I tried the same a different computer with a newer perl (v5.8.8).
$ cat x
#!/usr/bin/perl
use strict;
use warnings;
use CGI qw(:standard :escapeHTML -nosticky);
use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ':utf8';
print decode_utf8('äöü');
$ perl x
ￜￜï¿
Here perl decodes the ISO-8859-1 text to something differnent:
00000000 ef bf bd ef bf bd ef bf bd |ￜￜï¿
The result is, that all "Umlaute" are shown as a small black rhombus
in gitweb (and no invalid html).
mfg Martin Kögler
cat x |hexdump -C
00000000 23 21 2f 75 73 72 2f 62 69 6e 2f 70 65 72 6c 0a |#!/usr/bin/perl.|
00000010 75 73 65 20 73 74 72 69 63 74 3b 0a 75 73 65 20 |use strict;.use |
00000020 77 61 72 6e 69 6e 67 73 3b 0a 75 73 65 20 43 47 |warnings;.use CG|
00000030 49 20 71 77 28 3a 73 74 61 6e 64 61 72 64 20 3a |I qw(:standard :|
00000040 65 73 63 61 70 65 48 54 4d 4c 20 2d 6e 6f 73 74 |escapeHTML -nost|
00000050 69 63 6b 79 29 3b 0a 75 73 65 20 43 47 49 3a 3a |icky);.use CGI::|
00000060 55 74 69 6c 20 71 77 28 75 6e 65 73 63 61 70 65 |Util qw(unescape|
00000070 29 3b 0a 75 73 65 20 43 47 49 3a 3a 43 61 72 70 |);.use CGI::Carp|
00000080 20 71 77 28 66 61 74 61 6c 73 54 6f 42 72 6f 77 | qw(fatalsToBrow|
00000090 73 65 72 29 3b 0a 75 73 65 20 45 6e 63 6f 64 65 |ser);.use Encode|
000000a0 3b 0a 75 73 65 20 46 63 6e 74 6c 20 27 3a 6d 6f |;.use Fcntl ':mo|
000000b0 64 65 27 3b 0a 75 73 65 20 46 69 6c 65 3a 3a 46 |de';.use File::F|
000000c0 69 6e 64 20 71 77 28 29 3b 0a 75 73 65 20 46 69 |ind qw();.use Fi|
000000d0 6c 65 3a 3a 42 61 73 65 6e 61 6d 65 20 71 77 28 |le::Basename qw(|
000000e0 62 61 73 65 6e 61 6d 65 29 3b 0a 0a 62 69 6e 6d |basename);..binm|
000000f0 6f 64 65 20 53 54 44 4f 55 54 2c 20 27 3a 75 74 |ode STDOUT, ':ut|
00000100 66 38 27 3b 0a 0a 70 72 69 6e 74 20 64 65 63 6f |f8';..print deco|
00000110 64 65 5f 75 74 66 38 28 27 e4 f6 fc 27 29 3b 0a |de_utf8('äöü');.|
00000120
^ permalink raw reply
* [PATCH] rename dirlink to gitlink.
From: Martin Waitz @ 2007-05-21 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 10678 bytes --]
Unify naming of plumbing dirlink/gitlink concept:
perl -pi -e 's/dirlink/gitlink/g' -e 's/DIRLNK/GITLINK/g'
---
archive-tar.c | 4 ++--
archive-zip.c | 2 +-
builtin-fsck.c | 4 ++--
builtin-ls-tree.c | 2 +-
builtin-update-index.c | 4 ++--
cache-tree.c | 2 +-
cache.h | 10 +++++-----
diff.c | 2 +-
dir.c | 6 +++---
dir.h | 2 +-
entry.c | 4 ++--
list-objects.c | 2 +-
read-cache.c | 6 +++---
tree.c | 4 ++--
14 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 33e7657..66fe3e3 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -167,7 +167,7 @@ static void write_entry(const unsigned char *sha1, struct strbuf *path,
} else {
if (verbose)
fprintf(stderr, "%.*s\n", path->len, path->buf);
- if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
+ if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
*header.typeflag = TYPEFLAG_DIR;
mode = (mode | 0777) & ~tar_umask;
} else if (S_ISLNK(mode)) {
@@ -280,7 +280,7 @@ static int write_tar_entry(const unsigned char *sha1,
memcpy(path.buf + baselen, filename, filenamelen);
path.len = baselen + filenamelen;
path.buf[path.len] = '\0';
- if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
+ if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
strbuf_append_string(&path, "/");
buffer = NULL;
size = 0;
diff --git a/archive-zip.c b/archive-zip.c
index 3cbf6bb..444e162 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -182,7 +182,7 @@ static int write_zip_entry(const unsigned char *sha1,
goto out;
}
- if (S_ISDIR(mode) || S_ISDIRLNK(mode)) {
+ if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
method = 0;
attr2 = 16;
result = (S_ISDIR(mode) ? READ_TREE_RECURSIVE : 0);
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 44ce629..cbbcaf0 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -256,7 +256,7 @@ static int fsck_tree(struct tree *item)
case S_IFREG | 0644:
case S_IFLNK:
case S_IFDIR:
- case S_IFDIRLNK:
+ case S_IFGITLINK:
break;
/*
* This is nonstandard, but we had a few of these
@@ -715,7 +715,7 @@ int cmd_fsck(int argc, char **argv, const char *prefix)
struct object *obj;
mode = ntohl(active_cache[i]->ce_mode);
- if (S_ISDIRLNK(mode))
+ if (S_ISGITLINK(mode))
continue;
blob = lookup_blob(active_cache[i]->sha1);
if (!blob)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 1cb4dca..9a5977f 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -60,7 +60,7 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
int retval = 0;
const char *type = blob_type;
- if (S_ISDIRLNK(mode)) {
+ if (S_ISGITLINK(mode)) {
/*
* Maybe we want to have some recursive version here?
*
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 8f98991..509369e 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -134,7 +134,7 @@ static int process_directory(const char *path, int len, struct stat *st)
/* Exact match: file or existing gitlink */
if (pos >= 0) {
struct cache_entry *ce = active_cache[pos];
- if (S_ISDIRLNK(ntohl(ce->ce_mode))) {
+ if (S_ISGITLINK(ntohl(ce->ce_mode))) {
/* Do nothing to the index if there is no HEAD! */
if (resolve_gitlink_ref(path, "HEAD", sha1) < 0)
@@ -178,7 +178,7 @@ static int process_file(const char *path, int len, struct stat *st)
int pos = cache_name_pos(path, len);
struct cache_entry *ce = pos < 0 ? NULL : active_cache[pos];
- if (ce && S_ISDIRLNK(ntohl(ce->ce_mode)))
+ if (ce && S_ISGITLINK(ntohl(ce->ce_mode)))
return error("%s is already a gitlink, not replacing", path);
return add_one_path(ce, path, len, st);
diff --git a/cache-tree.c b/cache-tree.c
index 6369cc7..350a79b 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -326,7 +326,7 @@ static int update_one(struct cache_tree *it,
mode = ntohl(ce->ce_mode);
entlen = pathlen - baselen;
}
- if (mode != S_IFDIRLNK && !missing_ok && !has_sha1_file(sha1))
+ if (mode != S_IFGITLINK && !missing_ok && !has_sha1_file(sha1))
return error("invalid object %s", sha1_to_hex(sha1));
if (!ce->ce_mode)
diff --git a/cache.h b/cache.h
index 4204bc1..2497c21 100644
--- a/cache.h
+++ b/cache.h
@@ -40,8 +40,8 @@
* happens that everybody shares the same bit representation
* in the UNIX world (and apparently wider too..)
*/
-#define S_IFDIRLNK 0160000
-#define S_ISDIRLNK(m) (((m) & S_IFMT) == S_IFDIRLNK)
+#define S_IFGITLINK 0160000
+#define S_ISGITLINK(m) (((m) & S_IFMT) == S_IFGITLINK)
/*
* Intensive research over the course of many years has shown that
@@ -123,8 +123,8 @@ static inline unsigned int create_ce_mode(unsigned int mode)
{
if (S_ISLNK(mode))
return htonl(S_IFLNK);
- if (S_ISDIR(mode) || S_ISDIRLNK(mode))
- return htonl(S_IFDIRLNK);
+ if (S_ISDIR(mode) || S_ISGITLINK(mode))
+ return htonl(S_IFGITLINK);
return htonl(S_IFREG | ce_permissions(mode));
}
static inline unsigned int ce_mode_from_stat(struct cache_entry *ce, unsigned int mode)
@@ -142,7 +142,7 @@ static inline unsigned int ce_mode_from_stat(struct cache_entry *ce, unsigned in
}
#define canon_mode(mode) \
(S_ISREG(mode) ? (S_IFREG | ce_permissions(mode)) : \
- S_ISLNK(mode) ? S_IFLNK : S_ISDIR(mode) ? S_IFDIR : S_IFDIRLNK)
+ S_ISLNK(mode) ? S_IFLNK : S_ISDIR(mode) ? S_IFDIR : S_IFGITLINK)
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7)
diff --git a/diff.c b/diff.c
index 33297aa..9a5e980 100644
--- a/diff.c
+++ b/diff.c
@@ -1467,7 +1467,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
if (size_only && 0 < s->size)
return 0;
- if (S_ISDIRLNK(s->mode))
+ if (S_ISGITLINK(s->mode))
return diff_populate_gitlink(s, size_only);
if (!s->sha1_valid ||
diff --git a/dir.c b/dir.c
index 11fab7f..f543f50 100644
--- a/dir.c
+++ b/dir.c
@@ -321,7 +321,7 @@ static enum exist_status directory_exists_in_index(const char *dirname, int len)
break;
if (endchar == '/')
return index_directory;
- if (!endchar && S_ISDIRLNK(ntohl(ce->ce_mode)))
+ if (!endchar && S_ISGITLINK(ntohl(ce->ce_mode)))
return index_gitdir;
}
return index_nonexistent;
@@ -356,7 +356,7 @@ static enum exist_status directory_exists_in_index(const char *dirname, int len)
* also true and the directory is empty, in which case
* we just ignore it entirely.
* (b) if it looks like a git directory, and we don't have
- * 'no_dirlinks' set we treat it as a gitlink, and show it
+ * 'no_gitlinks' set we treat it as a gitlink, and show it
* as a directory.
* (c) otherwise, we recurse into it.
*/
@@ -383,7 +383,7 @@ static enum directory_treatment treat_directory(struct dir_struct *dir,
case index_nonexistent:
if (dir->show_other_directories)
break;
- if (!dir->no_dirlinks) {
+ if (!dir->no_gitlinks) {
unsigned char sha1[20];
if (resolve_gitlink_ref(dirname, "HEAD", sha1) == 0)
return show_directory;
diff --git a/dir.h b/dir.h
index 817c674..172147f 100644
--- a/dir.h
+++ b/dir.h
@@ -34,7 +34,7 @@ struct dir_struct {
unsigned int show_ignored:1,
show_other_directories:1,
hide_empty_directories:1,
- no_dirlinks:1;
+ no_gitlinks:1;
struct dir_entry **entries;
/* Exclude info */
diff --git a/entry.c b/entry.c
index 82bf725..ae64764 100644
--- a/entry.c
+++ b/entry.c
@@ -145,7 +145,7 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
"symlink %s (%s)", path, strerror(errno));
}
break;
- case S_IFDIRLNK:
+ case S_IFGITLINK:
if (to_tempfile)
return error("git-checkout-index: cannot create temporary subproject %s", path);
if (mkdir(path, 0777) < 0)
@@ -194,7 +194,7 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
unlink(path);
if (S_ISDIR(st.st_mode)) {
/* If it is a gitlink, leave it alone! */
- if (S_ISDIRLNK(ntohl(ce->ce_mode)))
+ if (S_ISGITLINK(ntohl(ce->ce_mode)))
return 0;
if (!state->force)
return error("%s is a directory", path);
diff --git a/list-objects.c b/list-objects.c
index 310f8d3..e5c88c2 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -87,7 +87,7 @@ static void process_tree(struct rev_info *revs,
process_tree(revs,
lookup_tree(entry.sha1),
p, &me, entry.path);
- else if (S_ISDIRLNK(entry.mode))
+ else if (S_ISGITLINK(entry.mode))
process_gitlink(revs, entry.sha1,
p, &me, entry.path);
else
diff --git a/read-cache.c b/read-cache.c
index d9f46da..ad4e187 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -92,7 +92,7 @@ static int ce_compare_gitlink(struct cache_entry *ce)
/*
* We don't actually require that the .git directory
- * under DIRLNK directory be a valid git directory. It
+ * under GITLINK directory be a valid git directory. It
* might even be missing (in case nobody populated that
* sub-project).
*
@@ -115,7 +115,7 @@ static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
return DATA_CHANGED;
break;
case S_IFDIR:
- if (S_ISDIRLNK(ntohl(ce->ce_mode)))
+ if (S_ISGITLINK(ntohl(ce->ce_mode)))
return 0;
default:
return TYPE_CHANGED;
@@ -142,7 +142,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
(has_symlinks || !S_ISREG(st->st_mode)))
changed |= TYPE_CHANGED;
break;
- case S_IFDIRLNK:
+ case S_IFGITLINK:
if (!S_ISDIR(st->st_mode))
changed |= TYPE_CHANGED;
else if (ce_compare_gitlink(ce))
diff --git a/tree.c b/tree.c
index e4a39aa..a372827 100644
--- a/tree.c
+++ b/tree.c
@@ -157,7 +157,7 @@ static void track_tree_refs(struct tree *item)
/* Count how many entries there are.. */
init_tree_desc(&desc, item->buffer, item->size);
while (tree_entry(&desc, &entry)) {
- if (S_ISDIRLNK(entry.mode))
+ if (S_ISGITLINK(entry.mode))
continue;
n_refs++;
}
@@ -169,7 +169,7 @@ static void track_tree_refs(struct tree *item)
while (tree_entry(&desc, &entry)) {
struct object *obj;
- if (S_ISDIRLNK(entry.mode))
+ if (S_ISGITLINK(entry.mode))
continue;
if (S_ISDIR(entry.mode))
obj = &lookup_tree(entry.sha1)->object;
--
1.5.2.2.g081e
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Make sure an autogenerated version has at least four parts
From: Martin Waitz @ 2007-05-21 20:06 UTC (permalink / raw)
To: Jan Hudec; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <20070521195745.GD5082@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
hoi :)
On Mon, May 21, 2007 at 09:57:45PM +0200, Jan Hudec wrote:
> That depends on what rules you use to compare versions. Under dpkg ones it
> would. I don't know what eg. rpm uses. (Note: - is BEFORE . in asciibet).
if rpm does not grok that then perhaps the version transformation should
be moved to the git.spec Makefile target.
That way at least the real git version is in line with git-describe.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Jan Hudec @ 2007-05-21 20:02 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, Alex Riesen, git
In-Reply-To: <20070521180506.GP942MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
On Mon, May 21, 2007 at 20:05:06 +0200, Sven Verdoolaege wrote:
> On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
> > We could store the GIT_DIR of submodule within the GIT_DIR of the
> > superproject instead of the submodule directory itself. So instead of:
> > /
> > /.git
> > /subdir
> > /subdir/.git
> >
> > There would be:
> > /
> > /.git
> > /subdir
> > /.git/submodules/submodule-name.git
>
> I have this already, except that I use /.git/submodules/submodule-name/.git
> because I was too lazy to figure out how to get clone to use the above
> without using --bare, because --bare disables separate-remotes.
>
> Is there any good reason, btw for --bare not to do separate-remotes ?
> We could throw out a lot of speical cases, especially the --bare http
> fetch if we would simply always do a separate-remotes.
Glad to hear it. I didn't really have time to read through all the patches.
> > This would require changes to the logic how git finds GIT_DIR (which would be
> > really deep change),
>
> Euhm.... I just add a symlink...
Yes. Except I am not sure mingw supports that.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make sure an autogenerated version has at least four parts
From: Jan Hudec @ 2007-05-21 19:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <20070521073650.GV5412@admingilde.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
On Mon, May 21, 2007 at 09:36:50 +0200, Martin Waitz wrote:
> hoi :)
>
> On Mon, May 21, 2007 at 02:52:21PM +1200, Sam Vilain wrote:
> > Otherwise, a custom "v1.5.2.42.gd00b" is considered newer than a
> > "v1.5.2.1.69.gcafe".
>
> or just use git describe output without replacing "-" with "."?
That depends on what rules you use to compare versions. Under dpkg ones it
would. I don't know what eg. rpm uses. (Note: - is BEFORE . in asciibet).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: René Scharfe @ 2007-05-21 19:54 UTC (permalink / raw)
To: git
Cc: git, Junio C Hamano, Frank Lichtenheld, Johan Herland,
Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070521060231.GI3141@spearce.org>
Shawn O. Pearce schrieb:
> Ren?? Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> Shawn O. Pearce schrieb:
>>> git-describe is more human-friendly than a SHA-1...
>> Yes, and the Makefile does even more than that: it adds a version file,
>> a spec file and another version file for git-gui.
>>
>> The first two are probably useful for most projects that actually do
>> versioned releases. We could have a simple parser that reads a
>> template, replaces @@VERSION@@ with a git-describe output string and
>> adds the result as a synthetic file to the archive. It's not exactly
>> trivial -- e.g., how to specify git-describe options, template file and
>> synthetic name, all in one command line parameter? -- but it's doable.
>
> Maybe something just as simple as allowing the user to specify a
> shell script in-tree that we unpack and run for them? That script
> prints to stdout the content of the file to include.
I doubt executing a shell script is simple. :-D You'd possibly get
different results on different platforms (dare I mention Windows?).
The template system I mentioned would be a kind of scripting language
itself, but in this case we define its syntax and can guarantee
consistency everywhere git runs. And since it would only have four
types of tokens (@@VERSION@@, @@COMMITID@@, @@@@ and string literals) it
could be fast and simple.
We could implement it as a checkout converter, preferably one that is
only applied by git-archive. Then we'd rename git.spec.in to git.spec,
assign the "specfile" attribute to it and let git-archive replace the
string @@VERSION@@ with git-describe's output. git-checkout would not
expand the special strings, so you can simply edit and version the file
as you can do with git.spec.in now. Michael would have a file
containing only @@COMMITID@@ to solve his original problem. Make sense?
> So now we're also really talking about, what should git-archive
> do for a subproject? Sometimes you really do want to repackage
> and redistribute the subproject as part of the superproject's
> tarball. Sometimes you don't. I think in the case of git.git and
> git-gui.git we want to include the subproject. ;-)
Oh, yes, subprojects. git-archive currently exports them as empty
directories. Using tar's append command you could simply build the
project+subproject archive in the Makefile. That wouldn't work well
with gitweb, though. Perhaps a --include-subproject=<path> option is
needed?
René
^ permalink raw reply
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Jan Hudec @ 2007-05-21 19:54 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <11797696193384-git-send-email-frank@lichtenheld.de>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
On Mon, May 21, 2007 at 19:46:59 +0200, Frank Lichtenheld wrote:
> This option will enclose key names in quotes (") if they
> contain a subsection and then escape " and \. It will also
> escape line breaks in values. Together this should produce
> an easily parsable output.
That will lead to either eval (which runs perl parser and probably won't win
anything) or regexps (which is not big win over parsing the .ini directly
with them) on the perl side. IMHO only thing that would actually be faster is
NUL-separated entries.
Either:
KEY <NUL> VALUE <NUL>
or:
KEY <TAB> VALUE <NUL>
I am not sure whether there can be multi-valued entries. If so, than there
are three options:
1. Simply repeated key/value pairs:
KEY <NUL> VALUE1 <NUL> KEY <NUL> VALUE2 <NUL>.
KEY <TAB> VALUE1 <NUL> KEY <TAB> VALUE2 <NUL> resp.
2. Key/count/values:
KEY <NUL> 1 <NUL> VALUE <NUL>
KEY <NUL> 2 <NUL> VALUE1 <NUL> VALUE2 <NUL>
(there's probably no benefit for the tab-nul format, because the first
value must be terminated with NUL)
3. Empty-entry terminated:
KEY <NUL> VALUE <NUL> <NUL>
KEY <NUL> VALUE1 <NUL> VALUE2 <NUL> <NUL>
(again no point in terminating the KEY with tab)
The advantage of such format is, that it can be parsed with:
local $/ = "\0";
while(<INPUT>) {
$hash{$_} = <INPUT>;
}
and slight variations for the other variants. It should be similarly easy
from python and C. Shell won't like it, though.
Note: In both bash and zsh, read -d '' line reads NUL-terminated "lines".
However, dash does not have -d option to read :-(.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-21 19:01 UTC (permalink / raw)
To: skimo; +Cc: Jan Hudec, Alex Riesen, git
In-Reply-To: <20070521180506.GP942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
>> We could store the GIT_DIR of submodule within the GIT_DIR of the
>> superproject instead of the submodule directory itself. So instead of:
>> /
>> /.git
>> /subdir
>> /subdir/.git
>>
>> There would be:
>> /
>> /.git
>> /subdir
>> /.git/submodules/submodule-name.git
>
> I have this already, except that I use /.git/submodules/submodule-name/.git
> because I was too lazy to figure out how to get clone to use the above
> without using --bare, because --bare disables separate-remotes.
>
> Is there any good reason, btw for --bare not to do separate-remotes ?
Traditinoally, the purpose of --bare is to set up distribution
points, either CVS style "shared public repository that
everybody pushes into and fetches from", or "owned by me and I
push my change into it to publish". In either case, there is no
point of even having an upstream in such a repository, let
alone refs/remotes/origin/ hierarchy.
So that's the "good reason" part.
Having said that, last night I was thinking about making the
layout after a clone a bit more flexible and orthogonal to
existence of working tree. What got me thinking about it was
different from your motivation, though.
If you have an ordinary working tree, and if you want to have a
clone of that working tree that you can work in, independently
(i.e. not treating the repository you cloned from any specially
from other repositories by marking it "origin"), currently there
is no straightforward way to do so, other than doing
something like:
(1) do a --bare clone, which would create "project.git";
(2) mkdir "project" && mv "project.git" "project/.git";
(3) edit "project/.git/config" and mark it as a non-bare
repository.
(4) "git checkout -f HEAD".
I'd call this a "pure" clone. It is as close as the original
repository you would get without copying other per-repository
data such as .git/info, .git/config, so that you can start using
it as an _independent _repository. It is like a --bare clone
but with a working tree associated with it.
What you want is probably the opposite. A bare, but non-pure
clone. By non-pure, what I mean is:
(1) it has an upstream ("origin"), hence
(2) it has refs/remotes/origin, and "remotes.origin.*"
If the word "non-pure" has a negative connotation, you could
call it "a follower repository".
In short, the current behaviour of --bare is "bare and pure",
and clone without --bare is "not bare, and a follower". What I
wanted was "not bare, but pure", and I think what you want is
"bare, but a follower".
^ permalink raw reply
* Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Yann Dirson @ 2007-05-21 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Robin Rosenberg, git
In-Reply-To: <b0943d9e0705210231j75ef2e57o922f7899f4b5814b@mail.gmail.com>
On Mon, May 21, 2007 at 10:31:09AM +0100, Catalin Marinas wrote:
> BTW, any of you would like to get added as a member to
> gna.org/projects/stgit (there are no advantages, only e-mail updates
> for filed bug reports)?
You should not disregard the added bonus of being able to be assigned
some of the bugs and tasks reported there :)
Best regards,
--
Yann.
^ permalink raw reply
* Re: [PATCH] config: Add --quoted option to produce machine-parsable output
From: Johannes Schindelin @ 2007-05-21 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Lichtenheld, Git Mailing List
In-Reply-To: <7vejladpfr.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 21 May 2007, Junio C Hamano wrote:
> Frank Lichtenheld <frank@lichtenheld.de> writes:
>
> > This option will enclose key names in quotes (") if they
> > contain a subsection and then escape " and \. It will also
> > escape line breaks in values. Together this should produce
> > an easily parsable output.
> >
> > Affects --list and --get-*
> >
> > Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
> > ---
> > builtin-config.c | 92 ++++++++++++++++++++++++++++++++++++++++++++++++-----
> > 1 files changed, 83 insertions(+), 9 deletions(-)
> >
> > Will add asciidoc documentation and test cases if people think that
> > this is a good idea.
> >
> > I'm writing C about once a year, so I really don't mind being told if
> > it's crap ;)
>
> We probably would want to make this compatible with the quoting rules
> various fo "host" language have. quote.c has host language support to
> implement {perl,python,tcl}_quote_print() for single string values or
> keys, so we should extend that idea.
>
> In your application, what you are trying to do is to show a "hash" (key
> => value) in a notation that is friendly to the host language.
>
> Git.pm could simply do:
>
> my $eval = `git config --perl --get-regexp 'gitcvs\..*'`;
> my $cfg = eval "$eval";
>
> if you code your "perl" notation to produce:
>
> +{
> 'gitcvs.ext.enabled' => 'false',
> 'gitcvs.logfile' => '/var/log/gitcvs.log',
> }
>
> in order to read things in.
>
> Hmm?
IOW, something like
http://article.gmane.org/gmane.comp.version-control.git/36922
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: Using git to store /etc, redux
From: Jan Hudec @ 2007-05-21 18:32 UTC (permalink / raw)
To: David Härdeman; +Cc: git
In-Reply-To: <20070519174815.GA5124@hardeman.nu>
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
On Sat, May 19, 2007 at 19:48:15 +0200, David Härdeman wrote:
> I recently had the idea to store and track /etc using git. When googling
> the topic I came across the "Using git to store /etc" thread from the
> end of last year which provided some interesting details on what would
> be necessary.
>
> It seems the file metadata (owner, group, mode, xattrs, etc) was the big
> stumbling point, so I wrote up a tool over the last few days which
> allows the metadata to be stored in a separate file which can be stored
> along with the rest of the data in the repo (or separately).
>
> This is also useful for tripwire type checks and for other types of
> storage which drops some of the metadata (tar comes to mind)...
>
> The tool (metastore) is available from:
> git://git.hardeman.nu/metastore.git
>
> Not completely cleaned up yet (it lacks a real README and some Makefile
> targets) but I hope it might be useful to others (it sure is to me).
>
> Please CC me on any replies.
Have you looked at IsiSetup (http://www.isisetup.ch/, linked from
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools) yet? It's a front-end
to git specifically targeted for versioning configuration. From a quick
glance at it's web I don't see whether it already stores the metadata you
describe, but in either case it could be interesting for you.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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