* Re: [PATCH] Use setenv(), fix warnings
From: Junio C Hamano @ 2006-02-26 20:29 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060226203756.05dcfb26.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> putenv(3):
> "If the argument `string` is of the form `name`, and does not
> contain an `=' character, then the variable `name` is removed from
> the environment."
>
> So the variable is emptied, not removed. But usually empty environment
> variables are treated as if they didn't exist...
Yes we were aware of that when we did it.
^ permalink raw reply
* Re: the war on trailing whitespace
From: Junio C Hamano @ 2006-02-26 20:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, junkio, git
In-Reply-To: <20060226103604.2d97696c.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> Thanks. But it defaults to nowarn. Nobody will turn it on and nothing
> improves.
This WS is clearly a policy, and while I personally agree that
it is a _good_ policy, I am a bit hesitant to hardcode this
stricter policy as the default to lower level tools.
I have a feeling that Linus is saying that pre-applypatch hook
is good enough, and you have to educate people who feed things
to you ;-)
^ permalink raw reply
* Re: the war on trailing whitespace
From: Dave Jones @ 2006-02-26 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, junkio, git
In-Reply-To: <Pine.LNX.4.64.0602261213340.22647@g5.osdl.org>
On Sun, Feb 26, 2006 at 12:16:25PM -0800, Linus Torvalds wrote:
> Few enough people run "git-apply" on its own. Most people (certainly me)
> end up using it through some email-applicator script or other. So the plan
> was that the --whitespace=warn/error flag would go there, and that
> git-apply by default would work more like "patch".
>
> But hey, I have no strong preferences, and it's easy enough to make the
> default be warn (and add a "--whitespace=ok" flag to turn it off).
>
> Personally, I don't mind whitespace that much. In particular, I _suspect_
> I often have empty lines like
>
> int i;
>
> i = 10;
>
> where the "empty" line actually has the same indentation as the lines
> around it. Is that wrong? Perhaps.
I think I have the same anal-retentive problem Andrew has, because I have ..
highlight RedundantSpaces term=standout ctermbg=red guibg=red
match RedundantSpaces /\s\+$\| \+\ze\t/
in my .vimrc, which highlights this (and other trailing whitespace) as
a big red blob. I do this in part for the same reason Andrew does,
so that when someone sends me a diff with a zillion spaces at the EOL,
it screams at me, I spot them, and chop them out.
Dave
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Linus Torvalds @ 2006-02-26 20:18 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226195552.GA30735@trixie.casa.cgf.cx>
On Sun, 26 Feb 2006, Christopher Faylor wrote:
>
> If the speed of cygwin's fork is an issue then I'd previously suggested
> using spawn*. The spawn family of functions were designed to emulate
> Windows functions of the same name. They start a new process without
> the requirement of forking.
I thought that cygwin didn't implement the posix_spawn*() family?
Anyway, we probably _can_ use posix_spawn() in various places, and
especially if that helps windows performance, we should.
Linus
^ permalink raw reply
* Re: the war on trailing whitespace
From: Linus Torvalds @ 2006-02-26 20:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: junkio, git
In-Reply-To: <20060226103604.2d97696c.akpm@osdl.org>
On Sun, 26 Feb 2006, Andrew Morton wrote:
>
> Thanks. But it defaults to nowarn. Nobody will turn it on and nothing
> improves.
Few enough people run "git-apply" on its own. Most people (certainly me)
end up using it through some email-applicator script or other. So the plan
was that the --whitespace=warn/error flag would go there, and that
git-apply by default would work more like "patch".
But hey, I have no strong preferences, and it's easy enough to make the
default be warn (and add a "--whitespace=ok" flag to turn it off).
Personally, I don't mind whitespace that much. In particular, I _suspect_
I often have empty lines like
int i;
i = 10;
where the "empty" line actually has the same indentation as the lines
around it. Is that wrong? Perhaps.
Linus
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-02-26 19:55 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0602230607n22146a77k36929f0ad9e44d53@mail.gmail.com>
On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
>On 2/23/06, Andreas Ericsson <ae@op5.se> wrote:
>>>>Not to be unhelpful or anything, but activestate perl seems to be quite
>>>>a lot of bother. Is it worth supporting it?
>>>
>>>
>>>It's not activestate perl actually. It's only one platform it also
>>>_has_ to support. Is it worth supporting Windows?
>>
>>With or without cygwin? With cygwin, I'd say "yes, unless it makes
>>things terribly difficult to maintain and so long as we don't take
>>performance hits on unices". Without cygwin, I'd say "What? It runs
>>on windows?".
>
>There not much difference with or without cygwin. The penalties of
>doing any kind of support for it will pile up (as they started to do
>with pipes). Someday we'll have to start dropping features on Windows
>or restrict them beyond their usefullness. The fork emulation in
>cygwin isn't perfect,
If the speed of cygwin's fork is an issue then I'd previously suggested
using spawn*. The spawn family of functions were designed to emulate
Windows functions of the same name. They start a new process without
the requirement of forking.
>signals do not work reliably (if at all),
I'm not sure if you're mixing cygwin with windows here but if signals do
not work reliably in Cygwin then that is something that we'd like to
know about. Signals *obviously* have to work fairly well for programs
like ssh, bash, and X to work, however.
Native Windows, OTOH, hardly has any signals at all and deals with
signals in a way that is only vaguely like linux.
>filesystem is slow and locked down, and exec-attribute is NOT really
>useful even on NTFS (it is somehow related to execute permission and
>open files. I still cannot figure out how exactly are they related).
Again, it's not clear if you're talking about Windows or Cygwin but
under Cygwin, in the default configuration, the exec attribute means the
same thing to cygwin as it does to linux.
As always, if you have questions or problems with cygwin, you can ask in
the proper forum. The available cygwin mailing lists are here:
http://cygwin.com/lists.html.
Would getting git into the cygwin distribution solve any problems with
git adoption on Windows? This would get an automatic green light from
anyone who was interested, if so. Someone would just have to send an
"ITP" (Intent To Package) to the cygwin-apps mailing list and provide a
package using the guidelines here: http://cygwin.com/setup.html .
cgf
--
Christopher Faylor spammer? -> aaaspam@sourceware.org
Cygwin Co-Project Leader
TimeSys, Inc.
^ permalink raw reply
* Re: the war on trailing whitespace
From: Sam Ravnborg @ 2006-02-26 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0602260925170.22647@g5.osdl.org>
On Sun, Feb 26, 2006 at 09:29:00AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 25 Feb 2006, Andrew Morton wrote:
> >
> > I'd suggest a) git will simply refuse to apply such a patch unless given a
> > special `forcing' flag, b) even when thus forced, it will still warn and c)
> > with a different flag, it will strip-then-apply, without generating a
> > warning.
>
> This doesn't do the "strip-then-apply" thing, but it allows you to make
> git-apply generate a warning or error on extraneous whitespace.
Can this somehow be done in a way so everyone that clones your tree
will inherit the warn/error on whitespace setting?
In this way we make sure it gets enabled automagically in many trees
and I do not have to remember yet another options.
Alternatively something that is enabled for a tree so I only have to do
something once - a trigger maybe?
Sam
^ permalink raw reply
* Re: [PATCH] Use setenv(), fix warnings
From: Jason Riedy @ 2006-02-26 19:38 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060226203756.05dcfb26.tihirvon@gmail.com>
And Timo Hirvonen writes:
- It appears that statically allocated strings are accepted but
- _automatic_ variables aren't.
The putenv()-ed string has to exist as long as the environment
does. You can twiddle the environment just by twiddling the
string you registered. What fun!
- I noticed setenv is now in compat/ so I though it was good idea
- to use it.
All uses of putenv() originally were setenv(). I finally realized
a compat/setenv.c was better than playing whack-a-setenv on every
release... (Ah, hindsight.)
Note that the current compat/setenv.c _LEAKS MEMORY_ on purpose.
Because putenv() requires the string to stay around, we can't
ever free it. I hope any library implementing bits of git
(libgitbit?) avoids setting environment variables.
- So the variable is emptied, not removed. But usually empty environment
- variables are treated as if they didn't exist...
More specifically, git treats both "" and NULL as empty, or at
least it did last time I checked.
Jason
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andrew Morton @ 2006-02-26 18:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0602260925170.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
>
> On Sat, 25 Feb 2006, Andrew Morton wrote:
> >
> > I'd suggest a) git will simply refuse to apply such a patch unless given a
> > special `forcing' flag, b) even when thus forced, it will still warn and c)
> > with a different flag, it will strip-then-apply, without generating a
> > warning.
>
> This doesn't do the "strip-then-apply" thing, but it allows you to make
> git-apply generate a warning or error on extraneous whitespace.
>
> Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
> to make it a fatal error to have whitespace at the end.
Thanks. But it defaults to nowarn. Nobody will turn it on and nothing
improves.
> Totally untested, of course. But it compiles, so it must be fine.
Who cares, as long as the patch doesn't add trailing whitespace? ) ;)
> HOWEVER! Note that this literally will check every single patch-line with
> "+" at the beginning. Which means that if you fix a simple typo, and the
> line had a space at the end before, and you didn't remove it, that's still
> considered a "new line with whitespace at the end", even though obviously
> the line wasn't really new.
>
> I assume this is what you wanted, and there isn't really any sane
> alternatives (you could make the warning activate only for _pure_
> additions with no deletions at all in that hunk, but that sounds a bit
> insane).
Yup. So by the time we've patched every line in the kernel, it's
trailing-whitespace-free.
^ permalink raw reply
* Re: [PATCH] Use setenv(), fix warnings
From: Timo Hirvonen @ 2006-02-26 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzge570u.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Feb 2006 10:06:41 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Timo Hirvonen <tihirvon@gmail.com> writes:
>
> > - Use setenv() instead of putenv()
> > - Fix -Wundef -Wold-style-definition warnings
> > - Make pll_free() static
>
> I think the last one makes sense, and I can see why some people
> may prefer -Wundef but I am not sure about the first one. Care
> to defend why we should prefer setenv()? IIRC, initially we did
> not use setenv() anywhere because certain platforms only had
> putenv().
I was confused by putenv(3) man page. I thought it wanted malloc'ed
strings (no 'const' in the parameter -> warning). It appears that
statically allocated strings are accepted but _automatic_ variables
aren't. I noticed setenv is now in compat/ so I though it was good idea
to use it.
Sorry for the noise.
> > diff --git a/fsck-objects.c b/fsck-objects.c
> > @@ -483,7 +483,7 @@ int main(int argc, char **argv)
> > if (standalone && check_full)
> > die("Only one of --standalone or --full can be used.");
> > if (standalone)
> > - putenv("GIT_ALTERNATE_OBJECT_DIRECTORIES=");
> > + setenv("GIT_ALTERNATE_OBJECT_DIRECTORIES", "", 1);
>
> For platforms with only putenv we did this; here, what we really
> wanted to do was unsetenv.
putenv(3):
"If the argument `string` is of the form `name`, and does not
contain an `=' character, then the variable `name` is removed from
the environment."
So the variable is emptied, not removed. But usually empty environment
variables are treated as if they didn't exist...
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Use setenv(), fix warnings
From: Junio C Hamano @ 2006-02-26 18:06 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060226171346.33ad3e47.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> - Use setenv() instead of putenv()
> - Fix -Wundef -Wold-style-definition warnings
> - Make pll_free() static
I think the last one makes sense, and I can see why some people
may prefer -Wundef but I am not sure about the first one. Care
to defend why we should prefer setenv()? IIRC, initially we did
not use setenv() anywhere because certain platforms only had
putenv().
> diff --git a/fsck-objects.c b/fsck-objects.c
> @@ -483,7 +483,7 @@ int main(int argc, char **argv)
> if (standalone && check_full)
> die("Only one of --standalone or --full can be used.");
> if (standalone)
> - putenv("GIT_ALTERNATE_OBJECT_DIRECTORIES=");
> + setenv("GIT_ALTERNATE_OBJECT_DIRECTORIES", "", 1);
For platforms with only putenv we did this; here, what we really
wanted to do was unsetenv.
^ permalink raw reply
* Re: the war on trailing whitespace
From: Linus Torvalds @ 2006-02-26 17:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: Junio C Hamano, git
In-Reply-To: <20060225210712.29b30f59.akpm@osdl.org>
On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.
This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.
Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.
Totally untested, of course. But it compiles, so it must be fine.
HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.
I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).
Linus
---
diff --git a/apply.c b/apply.c
index 244718c..e7b3dca 100644
--- a/apply.c
+++ b/apply.c
@@ -34,6 +34,12 @@ static int line_termination = '\n';
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM] <patch>...";
+static enum whitespace_eol {
+ nowarn,
+ warn_on_whitespace,
+ error_on_whitespace
+} new_whitespace = nowarn;
+
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
* we've seen, and the longest filename. That allows us to do simple
@@ -815,6 +821,22 @@ static int parse_fragment(char *line, un
oldlines--;
break;
case '+':
+ /*
+ * We know len is at least two, since we have a '+' and
+ * we checked that the last character was a '\n' above
+ */
+ if (isspace(line[len-2])) {
+ switch (new_whitespace) {
+ case nowarn:
+ break;
+ case warn_on_whitespace:
+ new_whitespace = nowarn; /* Just once */
+ error("Added whitespace at end of line at line %d", linenr);
+ break;
+ case error_on_whitespace:
+ die("Added whitespace at end of line at line %d", linenr);
+ }
+ }
added++;
newlines--;
break;
@@ -1839,6 +1861,17 @@ int main(int argc, char **argv)
line_termination = 0;
continue;
}
+ if (!strncmp(arg, "--whitespace=", 13)) {
+ if (strcmp(arg+13, "warn")) {
+ new_whitespace = warn_on_whitespace;
+ continue;
+ }
+ if (strcmp(arg+13, "error")) {
+ new_whitespace = error_on_whitespace;
+ continue;
+ }
+ die("unrecognixed whitespace option '%s'", arg+13);
+ }
if (check_index && prefix_length < 0) {
prefix = setup_git_directory();
^ permalink raw reply related
* [PATCH] Use setenv(), fix warnings
From: Timo Hirvonen @ 2006-02-26 15:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
- Use setenv() instead of putenv()
- Fix -Wundef -Wold-style-definition warnings
- Make pll_free() static
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
cache.h | 2 +-
exec_cmd.c | 2 +-
fetch-pack.c | 2 +-
fsck-objects.c | 4 ++--
pack-objects.c | 2 +-
pack-redundant.c | 4 ++--
path.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
4001390d41ffd2c816cead47c256e598bedff452
diff --git a/cache.h b/cache.h
index 5020f07..58eec00 100644
--- a/cache.h
+++ b/cache.h
@@ -10,7 +10,7 @@
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
-#if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT
+#if defined(DT_UNKNOWN) && !defined(NO_D_TYPE_IN_DIRENT)
#define DTYPE(de) ((de)->d_type)
#else
#undef DT_UNKNOWN
diff --git a/exec_cmd.c b/exec_cmd.c
index 55af33b..b5e59a9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -13,7 +13,7 @@ void git_set_exec_path(const char *exec_
/* Returns the highest-priority, location to look for git programs. */
-const char *git_exec_path()
+const char *git_exec_path(void)
{
const char *env;
diff --git a/fetch-pack.c b/fetch-pack.c
index 09738fe..535de10 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -82,7 +82,7 @@ static void mark_common(struct commit *c
Get the next rev to send, ignoring the common.
*/
-static const unsigned char* get_rev()
+static const unsigned char* get_rev(void)
{
struct commit *commit = NULL;
diff --git a/fsck-objects.c b/fsck-objects.c
index 6439d55..f9c69f5 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -20,7 +20,7 @@ static int check_strict = 0;
static int keep_cache_objects = 0;
static unsigned char head_sha1[20];
-#if NO_D_INO_IN_DIRENT
+#ifdef NO_D_INO_IN_DIRENT
#define SORT_DIRENT 0
#define DIRENT_SORT_HINT(de) 0
#else
@@ -483,7 +483,7 @@ int main(int argc, char **argv)
if (standalone && check_full)
die("Only one of --standalone or --full can be used.");
if (standalone)
- putenv("GIT_ALTERNATE_OBJECT_DIRECTORIES=");
+ setenv("GIT_ALTERNATE_OBJECT_DIRECTORIES", "", 1);
fsck_head_link();
fsck_object_dir(get_object_directory());
diff --git a/pack-objects.c b/pack-objects.c
index 0287449..21ee572 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -768,7 +768,7 @@ static int sha1_sort(const struct object
return memcmp(a->sha1, b->sha1, 20);
}
-static struct object_entry **create_final_object_list()
+static struct object_entry **create_final_object_list(void)
{
struct object_entry **list;
int i, j;
diff --git a/pack-redundant.c b/pack-redundant.c
index 1869b38..cd81f5a 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -45,7 +45,7 @@ static inline void llist_item_put(struct
free_nodes = item;
}
-static inline struct llist_item *llist_item_get()
+static inline struct llist_item *llist_item_get(void)
{
struct llist_item *new;
if ( free_nodes ) {
@@ -275,7 +275,7 @@ static void cmp_two_packs(struct pack_li
}
}
-void pll_free(struct pll *l)
+static void pll_free(struct pll *l)
{
struct pll *old;
struct pack_list *opl;
diff --git a/path.c b/path.c
index 334b2bd..6500a40 100644
--- a/path.c
+++ b/path.c
@@ -243,7 +243,7 @@ char *enter_repo(char *path, int strict)
if (access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_symref("HEAD") == 0) {
- putenv("GIT_DIR=.");
+ setenv("GIT_DIR", ".", 1);
check_repository_format();
return path;
}
--
1.2.1
^ permalink raw reply related
* Re: [PATCH 4/4] Read author names and emails from a file
From: Andreas Ericsson @ 2006-02-26 11:49 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20060226051131.24860.15804.stgit@backpacker.hemma.treskal.com>
Karl Hasselström wrote:
> Read a file with lines on the form
>
> username User's Full Name <email@addres.org>
>
> and use "User's Full Name <email@addres.org>" as the GIT author and
> committer for Subversion commits made by "username". If encountering a
> commit made by a user not in the list, abort.
>
This is a good thing, but wouldn't it be better to use the same format
as that of cvsimport's -A flag? Also, I imagine one would like to save
those files within the .git directory for incremental importing, also
like cvsimport does.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-svn and working with tags
From: Nicolas Vilz 'niv' @ 2006-02-26 11:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
Hi guys,
I am about to use a git/svn construct for a project next week to track
my work and the work of my co-workers.
Reason for this is, that all the others are working on windows-boxes and
I am the lonesome gunman, who wants to work with git on a linux box
contributing the others on svn side.
There is still a lot of work todo, preparing both backends, git and svn,
for serving almost the same content structure.
I think, i can do a little scripting to switch my git-SVN-HEAD to
another branch. But how am i intended to export tags to svn?
tags should simply go to <repos>/tags/<tagname>
branches go to <repos>/branches/<branchname>
master goes to <repos>/trunk
A svn-import should be no problem then. The re-exporting back to one
branch or svn_path is described in git-svn howto. but how about tags?
do i have to consider the tags on svn-side manually?
any ideas/hints?
Sincerly
Nicolas
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [PATCH] contrib/git-svn: optimize sequential commits to svn
From: Eric Wong @ 2006-02-26 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11409493473353-git-send-email-normalperson@yhbt.net>
Avoid running 'svn up' to a previous revision if we know the
revision we just committed is the first descendant of the
revision we came from.
This reduces the time to do a series of commits by about 25%.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
ea810425ed7d5d16c12b3f49246ba2a03ac3d23d
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 84d43de..29c8690 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -30,6 +30,7 @@ use File::Basename qw/dirname basename/;
use File::Path qw/mkpath/;
use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
use File::Spec qw//;
+use POSIX qw/strftime/;
my $sha1 = qr/[a-f\d]{40}/;
my $sha1_short = qr/[a-f\d]{6,40}/;
my ($_revision,$_stdin,$_no_ignore_ext,$_no_stop_copy,$_help,$_rmdir,$_edit,
@@ -591,6 +592,7 @@ sub handle_rmdir {
sub svn_commit_tree {
my ($svn_rev, $commit) = @_;
my $commit_msg = "$GIT_DIR/$GIT_SVN/.svn-commit.tmp.$$";
+ my %log_msg = ( msg => '' );
open my $msg, '>', $commit_msg or croak $!;
chomp(my $type = `git-cat-file -t $commit`);
@@ -606,6 +608,7 @@ sub svn_commit_tree {
if (!$in_msg) {
$in_msg = 1 if (/^\s*$/);
} else {
+ $log_msg{msg} .= $_;
print $msg $_ or croak $!;
}
}
@@ -625,9 +628,30 @@ sub svn_commit_tree {
join("\n",@ci_output),"\n";
my ($rev_committed) = ($committed =~ /^Committed revision (\d+)\./);
- # resync immediately
- my @svn_up = (qw(svn up), "-r$svn_rev");
+ my @svn_up = qw(svn up);
push @svn_up, '--ignore-externals' unless $_no_ignore_ext;
+ if ($rev_committed == ($svn_rev + 1)) {
+ push @svn_up, "-r$rev_committed";
+ sys(@svn_up);
+ my $info = svn_info('.');
+ my $date = $info->{'Last Changed Date'} or die "Missing date\n";
+ if ($info->{'Last Changed Rev'} != $rev_committed) {
+ croak "$info->{'Last Changed Rev'} != $rev_committed\n"
+ }
+ my ($Y,$m,$d,$H,$M,$S,$tz) = ($date =~
+ /(\d{4})\-(\d\d)\-(\d\d)\s
+ (\d\d)\:(\d\d)\:(\d\d)\s([\-\+]\d+)/x)
+ or croak "Failed to parse date: $date\n";
+ $log_msg{date} = "$tz $Y-$m-$d $H:$M:$S";
+ $log_msg{author} = $info->{'Last Changed Author'};
+ $log_msg{revision} = $rev_committed;
+ $log_msg{msg} .= "\n";
+ my $parent = file_to_s("$REV_DIR/$svn_rev");
+ git_commit(\%log_msg, $parent, $commit);
+ return $rev_committed;
+ }
+ # resync immediately
+ push @svn_up, "-r$svn_rev";
sys(@svn_up);
return fetch("$rev_committed=$commit")->{revision};
}
@@ -724,7 +748,7 @@ sub svn_info {
# only single-lines seem to exist in svn info output
while (<$info_fh>) {
chomp $_;
- if (m#^([^:]+)\s*:\s*(\S*)$#) {
+ if (m#^([^:]+)\s*:\s*(\S.*)$#) {
$ret->{$1} = $2;
push @{$ret->{-order}}, $1;
}
--
1.2.2.ga559
^ permalink raw reply related
* [PATCH] contrib/git-svn: add show-ignore command
From: Eric Wong @ 2006-02-26 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Recursively finds and lists the svn:ignore property on
directories. The output is suitable for appending to the
$GIT_DIR/info/exclude file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 25 +++++++++++++++++++++++++
contrib/git-svn/git-svn.txt | 7 +++++++
2 files changed, 32 insertions(+), 0 deletions(-)
0858c770ef3e0f440c20a255baaf4792b3201813
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index a32ce15..84d43de 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -49,6 +49,7 @@ my %cmd = (
fetch => [ \&fetch, "Download new revisions from SVN" ],
init => [ \&init, "Initialize and fetch (import)"],
commit => [ \&commit, "Commit git revisions to SVN" ],
+ 'show-ignore' => [ \&show_ignore, "Show svn:ignore listings" ],
rebuild => [ \&rebuild, "Rebuild git-svn metadata (after git clone)" ],
help => [ \&usage, "Show help" ],
);
@@ -258,6 +259,30 @@ sub commit {
}
+sub show_ignore {
+ require File::Find or die $!;
+ my $exclude_file = "$GIT_DIR/info/exclude";
+ open my $fh, '<', $exclude_file or croak $!;
+ chomp(my @excludes = (<$fh>));
+ close $fh or croak $!;
+
+ $SVN_URL ||= file_to_s("$GIT_DIR/$GIT_SVN/info/url");
+ chdir $SVN_WC or croak $!;
+ my %ign;
+ File::Find::find({wanted=>sub{if(lstat $_ && -d _ && -d "$_/.svn"){
+ s#^\./##;
+ @{$ign{$_}} = safe_qx(qw(svn propget svn:ignore),$_);
+ }}, no_chdir=>1},'.');
+
+ print "\n# /\n";
+ foreach (@{$ign{'.'}}) { print '/',$_ if /\S/ }
+ delete $ign{'.'};
+ foreach my $i (sort keys %ign) {
+ print "\n# ",$i,"\n";
+ foreach (@{$ign{$i}}) { print '/',$i,'/',$_ if /\S/ }
+ }
+}
+
########################### utility functions #########################
sub setup_git_svn {
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index cf098d7..b4b7789 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -61,6 +61,11 @@ rebuild::
the directory/repository you're tracking has moved or changed
protocols.
+show-ignore::
+ Recursively finds and lists the svn:ignore property on
+ directories. The output is suitable for appending to
+ the $GIT_DIR/info/exclude file.
+
OPTIONS
-------
-r <ARG>::
@@ -152,6 +157,8 @@ Tracking and contributing to an Subversi
git commit git-svn-HEAD..my-branch
# Something is committed to SVN, pull the latest into your branch::
git-svn fetch && git pull . git-svn-HEAD
+# Append svn:ignore settings to the default git exclude file:
+ git-svn show-ignore >> .git/info/exclude
DESIGN PHILOSOPHY
-----------------
--
1.2.2.ga559
^ permalink raw reply related
* [PATCH] contrib/git-svn: version 0.10.0
From: Eric Wong @ 2006-02-26 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11409493473344-git-send-email-normalperson@yhbt.net>
New features deserve an increment of the minor version. This will very
likely become 1.0.0 unless release-critical bugs are found.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
8d35c4193507147a6caa8a25b0ed1e5e9c43a49c
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 29c8690..9f12836 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -8,7 +8,7 @@ use vars qw/ $AUTHOR $VERSION
$GIT_SVN_INDEX $GIT_SVN
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
-$VERSION = '0.9.1';
+$VERSION = '0.10.0';
$GIT_DIR = $ENV{GIT_DIR} || "$ENV{PWD}/.git";
$GIT_SVN = $ENV{GIT_SVN_ID} || 'git-svn';
$GIT_SVN_INDEX = "$GIT_DIR/$GIT_SVN/index";
--
1.2.2.ga559
^ permalink raw reply related
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-02-26 8:22 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <tnxwtfq8gok.fsf@arm.com>
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Suggestions/corrections from the list has been collected during the
past week, so I resend
the updated patch.
Please consider for apply.
One note. The suggestion of Jonas ( -*gitview* -> *gitview* :: )
has not been applied because
the output had no indent on project name. I played a little with
asciidoc to get an indent but without
success, so I revert to original indented format.
Documentation/git-tools.txt | 97 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-tools.txt
8f41794257a6efe46f44e056710dfadcfbf362d7
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000..7854972
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,97 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding link.
+
+
+Alternative/Augmentative Porcelains
+-----------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of
use, providing
+ generally smoother user experience than the "raw" Core GIT itself and indeed
+ many other version control systems.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but
it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://www.procode.org/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the GIT
+ environment. You can easily manage your patches in the
scope of GIT until they
+ get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple TK GUI for browsing history of GIT
repositories easily.
+
+
+ - *gitview* (contrib/)
+
+ gitview is a GTK based repository browser for git
+
+
+ - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
+
+ GITweb provides full-fledged web interface for GIT repositories.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+ Currently it is the fastest and most feature rich among
the git viewers
+ and commit tools.
+
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (contrib/)
+
+ git-svn is a simple conduit for changesets between a
single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt
repository and commit
+ series in git back and forth.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select
which files
+ to committed (or ignored / reverted) write commit
messages and perform
+ the commit itself.
+
+ - *pcl-cvs* (contrib/)
+
+ This is an Emacs interface for git. The user interface is
modeled on
+ pcl-cvs. It has been developed on Emacs 21 and will
probably need some
+ tweaking to work on XEmacs.
+
--
1.2.2.g8fcf1
^ permalink raw reply related
* [PATCH 3/4] Convert the svn:ignore property
From: Karl Hasselström @ 2006-02-26 5:11 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060226050335.24860.95155.stgit@backpacker.hemma.treskal.com>
Put the value of the svn:ignore property in a regular file when
converting a Subversion repository to GIT. The Subversion and GIT
ignore syntaxes are similar enough that it often just works to set the
filename to .gitignore and do nothing else.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 8 +++++
git-svnimport.perl | 60 +++++++++++++++++++++++++++++++++++++--
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index b5c7721..c95ff84 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
- <SVN_repository_URL> [ <path> ]
+ [ -I <ignorefile_name> ] <SVN_repository_URL> [ <path> ]
DESCRIPTION
@@ -65,6 +65,12 @@ When importing incrementally, you might
Prepend 'rX: ' to commit messages, where X is the imported
subversion revision.
+-I <ignorefile_name>::
+ Import the svn:ignore directory property to files with this
+ name in each directory. (The Subversion and GIT ignore
+ syntaxes are similar enough that using the Subversion patterns
+ directly with "-I .gitignore" will almost always just work.)
+
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 6603b96..0dd9fab 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -29,19 +29,21 @@ die "Need SVN:Core 1.2.1 or better" if $
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
-our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,$opt_b,$opt_r,$opt_s,$opt_l,$opt_d,$opt_D);
+our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
+ $opt_b,$opt_r,$opt_I,$opt_s,$opt_l,$opt_d,$opt_D);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from SVN
[-o branch-for-HEAD] [-h] [-v] [-l max_rev]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
- [-d|-D] [-i] [-u] [-r] [-s start_chg] [-m] [-M regex] [SVN_URL]
+ [-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
+ [-m] [-M regex] [SVN_URL]
END
exit(1);
}
-getopts("b:C:dDhil:mM:o:rs:t:T:uv") or usage();
+getopts("b:C:dDhiI:l:mM:o:rs:t:T:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -130,6 +132,24 @@ sub file {
return ($name, $mode);
}
+sub ignore {
+ my($self,$path,$rev) = @_;
+
+ print "... $rev $path ...\n" if $opt_v;
+ my (undef,undef,$properties)
+ = $self->{'svn'}->get_dir($path,$rev,undef);
+ if (exists $properties->{'svn:ignore'}) {
+ my ($fh, $name) = tempfile('gitsvn.XXXXXX',
+ DIR => File::Spec->tmpdir(),
+ UNLINK => 1);
+ print $fh $properties->{'svn:ignore'};
+ close($fh);
+ return $name;
+ } else {
+ return undef;
+ }
+}
+
package main;
use URI;
@@ -341,6 +361,34 @@ sub get_file($$$) {
return [$mode, $sha, $path];
}
+sub get_ignore($$$$$) {
+ my($new,$old,$rev,$branch,$path) = @_;
+
+ return unless $opt_I;
+ my $svnpath = revert_split_path($branch,$path);
+ my $name = $svn->ignore("$svnpath",$rev);
+ if ($path eq '/') {
+ $path = $opt_I;
+ } else {
+ $path = File::Spec->catfile($path,$opt_I);
+ }
+ if (defined $name) {
+ my $pid = open(my $F, '-|');
+ die $! unless defined $pid;
+ if (!$pid) {
+ exec("git-hash-object", "-w", $name)
+ or die "Cannot create object: $!\n";
+ }
+ my $sha = <$F>;
+ chomp $sha;
+ close $F;
+ unlink $name;
+ push(@$new,['0644',$sha,$path]);
+ } else {
+ push(@$old,$path);
+ }
+}
+
sub split_path($$) {
my($rev,$path) = @_;
my $branch;
@@ -546,6 +594,9 @@ sub commit {
my $opath = $action->[3];
print STDERR "$revision: $branch: could not fetch '$opath'\n";
}
+ } elsif ($node_kind eq $SVN::Node::dir) {
+ get_ignore(\@new, \@old, $revision,
+ $branch,$path);
}
} elsif ($action->[0] eq "D") {
push(@old,$path);
@@ -554,6 +605,9 @@ sub commit {
if ($node_kind eq $SVN::Node::file) {
my $f = get_file($revision,$branch,$path);
push(@new,$f) if $f;
+ } elsif ($node_kind eq $SVN::Node::dir) {
+ get_ignore(\@new, \@old, $revision,
+ $branch,$path);
}
} else {
die "$revision: unknown action '".$action->[0]."' for $path\n";
^ permalink raw reply related
* [PATCH 4/4] Read author names and emails from a file
From: Karl Hasselström @ 2006-02-26 5:11 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060226050335.24860.95155.stgit@backpacker.hemma.treskal.com>
Read a file with lines on the form
username User's Full Name <email@addres.org>
and use "User's Full Name <email@addres.org>" as the GIT author and
committer for Subversion commits made by "username". If encountering a
commit made by a user not in the list, abort.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 13 ++++++++++++-
git-svnimport.perl | 23 ++++++++++++++++++++---
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index c95ff84..e0e3a5d 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
[ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
- [ -I <ignorefile_name> ] <SVN_repository_URL> [ <path> ]
+ [ -I <ignorefile_name> ] [ -A <author_file> ]
+ <SVN_repository_URL> [ <path> ]
DESCRIPTION
@@ -71,6 +72,16 @@ When importing incrementally, you might
syntaxes are similar enough that using the Subversion patterns
directly with "-I .gitignore" will almost always just work.)
+-A <author_file>::
+ Read a file with lines on the form
+
+ username User's Full Name <email@addres.org>
+
+ and use "User's Full Name <email@addres.org>" as the GIT
+ author and committer for Subversion commits made by
+ "username". If encountering a commit made by a user not in the
+ list, abort.
+
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 0dd9fab..75ce8e0 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -30,7 +30,7 @@ $SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
- $opt_b,$opt_r,$opt_I,$opt_s,$opt_l,$opt_d,$opt_D);
+ $opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D);
sub usage() {
print STDERR <<END;
@@ -38,12 +38,12 @@ Usage: ${\basename $0} # fetch/updat
[-o branch-for-HEAD] [-h] [-v] [-l max_rev]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
- [-m] [-M regex] [SVN_URL]
+ [-m] [-M regex] [-A author_file] [SVN_URL]
END
exit(1);
}
-getopts("b:C:dDhiI:l:mM:o:rs:t:T:uv") or usage();
+getopts("A:b:C:dDhiI:l:mM:o:rs:t:T:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
@@ -68,6 +68,19 @@ if ($opt_M) {
push (@mergerx, qr/$opt_M/);
}
+our %users = ();
+if ($opt_A) {
+ die "Cannot open $opt_A\n" unless -f $opt_A;
+ open(my $authors,$opt_A);
+ while(<$authors>) {
+ chomp;
+ next unless /^(\S+)\s+(.+?)\s+<(\S+)>$/;
+ (my $user,my $name,my $email) = ($1,$2,$3);
+ $users{$user} = [$name,$email];
+ }
+ close($authors);
+}
+
select(STDERR); $|=1; select(STDOUT);
@@ -485,6 +498,10 @@ sub commit {
if (not defined $author) {
$author_name = $author_email = "unknown";
+ } elsif ($opt_A) {
+ die "User $author is not listed in $opt_A\n"
+ unless exists $users{$author};
+ ($author_name,$author_email) = @{$users{$author}};
} elsif ($author =~ /^(.*?)\s+<(.*)>$/) {
($author_name, $author_email) = ($1, $2);
} else {
^ permalink raw reply related
* [PATCH 2/4] Convert executable flag
From: Karl Hasselström @ 2006-02-26 5:11 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060226050335.24860.95155.stgit@backpacker.hemma.treskal.com>
Convert the svn:executable property to file mode 755 when converting
an SVN repository to GIT.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
git-svnimport.perl | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index ee2940f..6603b96 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -112,16 +112,22 @@ sub file {
DIR => File::Spec->tmpdir(), UNLINK => 1);
print "... $rev $path ...\n" if $opt_v;
- my $pool = SVN::Pool->new();
- eval { $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
- $pool->clear;
+ my (undef, $properties);
+ eval { (undef, $properties)
+ = $self->{'svn'}->get_file($path,$rev,$fh); };
if($@) {
return undef if $@ =~ /Attempted to get checksum/;
die $@;
}
+ my $mode;
+ if (exists $properties->{'svn:executable'}) {
+ $mode = '0755';
+ } else {
+ $mode = '0644';
+ }
close ($fh);
- return $name;
+ return ($name, $mode);
}
package main;
@@ -296,7 +302,7 @@ sub get_file($$$) {
my $svnpath = revert_split_path($branch,$path);
# now get it
- my $name;
+ my ($name,$mode);
if($opt_d) {
my($req,$res);
@@ -316,8 +322,9 @@ sub get_file($$$) {
return undef if $res->code == 301; # directory?
die $res->status_line." at $url\n";
}
+ $mode = '0644'; # can't obtain mode via direct http request?
} else {
- $name = $svn->file("$svnpath",$rev);
+ ($name,$mode) = $svn->file("$svnpath",$rev);
return undef unless defined $name;
}
@@ -331,7 +338,6 @@ sub get_file($$$) {
chomp $sha;
close $F;
unlink $name;
- my $mode = "0644"; # SV does not seem to store any file modes
return [$mode, $sha, $path];
}
^ permalink raw reply related
* [PATCH 1/4] Mention -r in usage summary
From: Karl Hasselström @ 2006-02-26 5:11 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20060226050335.24860.95155.stgit@backpacker.hemma.treskal.com>
I added the -r option to git-svnimport some time ago, but forgot to
update the usage summary in the documentation.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 5c543d5..b5c7721 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -10,10 +10,10 @@ git-svnimport - Import a SVN repository
SYNOPSIS
--------
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
- [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
- [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
- [ -s start_chg ] [ -m ] [ -M regex ]
- <SVN_repository_URL> [ <path> ]
+ [ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
+ [ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
+ [ -s start_chg ] [ -m ] [ -r ] [ -M regex ]
+ <SVN_repository_URL> [ <path> ]
DESCRIPTION
^ permalink raw reply related
* [PATCH 0/4] some git-svnimport improvements
From: Karl Hasselström @ 2006-02-26 5:03 UTC (permalink / raw)
To: Git Mailing List
This patch series teaches git-svnimport about the svn:executable and
svn:ignore Subversion properties (try to guess from their names what
they do!), and lets the user specify a file with username -> Full Name
<email@address> mappings.
I vaguely recall some discussion some time ago about the format of
this kind of username mapping file, but I ended up just picking the
simplest format I could think of since that was the boring part.
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andrew Morton @ 2006-02-26 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wxq7psj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > It's invariably pointless to add lines which have trailing whitespace.
> > Nobody cares much, but my scripts spam me when it happens, so I've become
> > obsessive....
>
> I do not call me obsessive, but I do enable pre-commit and
> pre-applypatch hooks I ship with git myself.
It's apparent that few others do this.
> > I realise that we cannot do this when doing git fetches, but when importing
> > patches and mboxes, git ought to whine loudly about input which matches the
> > above regexp, and it should offer an option to tidy it up. Perhaps by
> > default.
>
> I stole the policy the sample hook scripts use from you; it is
> not enabled by default, and as the tool manufacturer I am a bit
> reluctant to do so.
>
It's not strong enough. I mean, if you ask a developer "do you wish to add
new trialing whitespace to the kernel" then obviously their answer would be
"no". So how do we help them in this?
I'd suggest a) git will simply refuse to apply such a patch unless given a
special `forcing' flag, b) even when thus forced, it will still warn and c)
with a different flag, it will strip-then-apply, without generating a
warning.
^ 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