* [PATCH 6/6] archive: remove extra arguments parsing code
From: René Scharfe @ 2008-07-14 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <487B92FC.5030103@lsrfire.ath.cx>
Replace the code that calls backend specific argument parsers by a
simple flag mechanism. This reduces code size and complexity.
We can add back such a mechanism (based on incremental parse_opt(),
perhaps) when we need it. The compression level parameter, though,
is going to be shared by future compressing backends like tgz.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive-zip.c | 13 -------------
archive.h | 6 +-----
builtin-archive.c | 29 ++++++++++++++++-------------
3 files changed, 17 insertions(+), 31 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 8131289..d56e5cf 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -282,16 +282,3 @@ int write_zip_archive(struct archiver_args *args)
return err;
}
-
-void *parse_extra_zip_args(int argc, const char **argv)
-{
- for (; argc > 0; argc--, argv++) {
- const char *arg = argv[0];
-
- if (arg[0] == '-' && isdigit(arg[1]) && arg[2] == '\0')
- zlib_compression_level = arg[1] - '0';
- else
- die("Unknown argument for zip format: %s", arg);
- }
- return NULL;
-}
diff --git a/archive.h b/archive.h
index 88ee3be..96bb1cd 100644
--- a/archive.h
+++ b/archive.h
@@ -13,19 +13,16 @@ struct archiver_args {
time_t time;
const char **pathspec;
unsigned int verbose : 1;
- void *extra;
};
typedef int (*write_archive_fn_t)(struct archiver_args *);
-typedef void *(*parse_extra_args_fn_t)(int argc, const char **argv);
-
typedef int (*write_archive_entry_fn_t)(struct archiver_args *args, const unsigned char *sha1, const char *path, size_t pathlen, unsigned int mode, void *buffer, unsigned long size);
struct archiver {
const char *name;
write_archive_fn_t write_archive;
- parse_extra_args_fn_t parse_extra;
+ unsigned int flags;
};
extern int parse_archive_args(int argc, const char **argv, const struct archiver **ar, struct archiver_args *args);
@@ -41,7 +38,6 @@ extern void parse_pathspec_arg(const char **pathspec,
*/
extern int write_tar_archive(struct archiver_args *);
extern int write_zip_archive(struct archiver_args *);
-extern void *parse_extra_zip_args(int argc, const char **argv);
extern int write_archive_entries(struct archiver_args *args, write_archive_entry_fn_t write_entry);
diff --git a/builtin-archive.c b/builtin-archive.c
index e7f4ec6..88204bf 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -15,9 +15,11 @@
static const char archive_usage[] = \
"git-archive --format=<fmt> [--prefix=<prefix>/] [--verbose] [<extra>] <tree-ish> [path...]";
+#define USES_ZLIB_COMPRESSION 1
+
const struct archiver archivers[] = {
- { "tar", write_tar_archive, NULL },
- { "zip", write_zip_archive, parse_extra_zip_args },
+ { "tar", write_tar_archive },
+ { "zip", write_zip_archive, USES_ZLIB_COMPRESSION },
};
static int run_remote_archiver(const char *remote, int argc,
@@ -137,10 +139,9 @@ void parse_treeish_arg(const char **argv, struct archiver_args *ar_args,
int parse_archive_args(int argc, const char **argv, const struct archiver **ar,
struct archiver_args *args)
{
- const char *extra_argv[MAX_EXTRA_ARGS];
- int extra_argc = 0;
const char *format = "tar";
const char *base = "";
+ int compression_level = -1;
int verbose = 0;
int i;
@@ -168,12 +169,12 @@ int parse_archive_args(int argc, const char **argv, const struct archiver **ar,
i++;
break;
}
- if (arg[0] == '-') {
- if (extra_argc > MAX_EXTRA_ARGS - 1)
- die("Too many extra options");
- extra_argv[extra_argc++] = arg;
+ if (arg[0] == '-' && isdigit(arg[1]) && arg[2] == '\0') {
+ compression_level = arg[1] - '0';
continue;
}
+ if (arg[0] == '-')
+ die("Unknown argument: %s", arg);
break;
}
@@ -184,11 +185,13 @@ int parse_archive_args(int argc, const char **argv, const struct archiver **ar,
if (!*ar)
die("Unknown archive format '%s'", format);
- if (extra_argc) {
- if (!(*ar)->parse_extra)
- die("'%s' format does not handle %s",
- (*ar)->name, extra_argv[0]);
- args->extra = (*ar)->parse_extra(extra_argc, extra_argv);
+ if (compression_level != -1) {
+ if ((*ar)->flags & USES_ZLIB_COMPRESSION)
+ zlib_compression_level = compression_level;
+ else {
+ die("Argument not supported for format '%s': -%d",
+ format, compression_level);
+ }
}
args->verbose = verbose;
args->base = base;
--
1.5.6.2.212.g08b51
^ permalink raw reply related
* [PATCH 5/6] archive: unify file attribute handling
From: René Scharfe @ 2008-07-14 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <487B92FC.5030103@lsrfire.ath.cx>
Now that all file attribute handling for git archive has moved to archive.c,
we can unexport sha1_file_to_archive() and is_archive_path_ignored() even
disappears.
Add setup_archive_check(), modelled after similar functions used in the code
of other commands that support multiple file attributes.
Also remove convert_to_archive(), as it's only remaining function with
attribute handling gone was to call format_subst() if commit was not NULL,
which is now checked in sha1_file_to_archive().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive.c | 63 ++++++++++++++++++++++--------------------------------------
archive.h | 3 --
2 files changed, 23 insertions(+), 43 deletions(-)
diff --git a/archive.c b/archive.c
index 58de55e..b8b45ba 100644
--- a/archive.c
+++ b/archive.c
@@ -36,34 +36,9 @@ static void format_subst(const struct commit *commit,
free(to_free);
}
-static int convert_to_archive(const char *path,
- const void *src, size_t len,
- struct strbuf *buf,
- const struct commit *commit)
-{
- static struct git_attr *attr_export_subst;
- struct git_attr_check check[1];
-
- if (!commit)
- return 0;
-
- if (!attr_export_subst)
- attr_export_subst = git_attr("export-subst", 12);
-
- check[0].attr = attr_export_subst;
- if (git_checkattr(path, ARRAY_SIZE(check), check))
- return 0;
- if (!ATTR_TRUE(check[0].value))
- return 0;
-
- format_subst(commit, src, len, buf);
- return 1;
-}
-
-void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
- unsigned int mode, enum object_type *type,
- unsigned long *sizep,
- const struct commit *commit)
+static void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
+ unsigned int mode, enum object_type *type,
+ unsigned long *sizep, const struct commit *commit)
{
void *buffer;
@@ -75,7 +50,8 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
strbuf_init(&buf, 0);
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
- convert_to_archive(path, buf.buf, buf.len, &buf, commit);
+ if (commit)
+ format_subst(commit, buf.buf, buf.len, &buf);
buffer = strbuf_detach(&buf, &size);
*sizep = size;
}
@@ -83,18 +59,17 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
return buffer;
}
-int is_archive_path_ignored(const char *path)
+static void setup_archive_check(struct git_attr_check *check)
{
static struct git_attr *attr_export_ignore;
- struct git_attr_check check[1];
+ static struct git_attr *attr_export_subst;
- if (!attr_export_ignore)
+ if (!attr_export_ignore) {
attr_export_ignore = git_attr("export-ignore", 13);
-
+ attr_export_subst = git_attr("export-subst", 12);
+ }
check[0].attr = attr_export_ignore;
- if (git_checkattr(path, ARRAY_SIZE(check), check))
- return 0;
- return ATTR_TRUE(check[0].value);
+ check[1].attr = attr_export_subst;
}
struct archiver_context {
@@ -110,6 +85,9 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
struct archiver_context *c = context;
struct archiver_args *args = c->args;
write_archive_entry_fn_t write_entry = c->write_entry;
+ struct git_attr_check check[2];
+ const char *path_without_prefix;
+ int convert = 0;
int err;
enum object_type type;
unsigned long size;
@@ -119,9 +97,14 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
strbuf_grow(&path, PATH_MAX);
strbuf_add(&path, base, baselen);
strbuf_addstr(&path, filename);
+ path_without_prefix = path.buf + args->baselen;
- if (is_archive_path_ignored(path.buf + args->baselen))
- return 0;
+ setup_archive_check(check);
+ if (!git_checkattr(path_without_prefix, ARRAY_SIZE(check), check)) {
+ if (ATTR_TRUE(check[0].value))
+ return 0;
+ convert = ATTR_TRUE(check[1].value);
+ }
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
strbuf_addch(&path, '/');
@@ -133,8 +116,8 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
return READ_TREE_RECURSIVE;
}
- buffer = sha1_file_to_archive(path.buf + args->baselen, sha1, mode,
- &type, &size, args->commit);
+ buffer = sha1_file_to_archive(path_without_prefix, sha1, mode,
+ &type, &size, convert ? args->commit : NULL);
if (!buffer)
return error("cannot read %s", sha1_to_hex(sha1));
if (args->verbose)
diff --git a/archive.h b/archive.h
index 4e44549..88ee3be 100644
--- a/archive.h
+++ b/archive.h
@@ -43,9 +43,6 @@ extern int write_tar_archive(struct archiver_args *);
extern int write_zip_archive(struct archiver_args *);
extern void *parse_extra_zip_args(int argc, const char **argv);
-extern void *sha1_file_to_archive(const char *path, const unsigned char *sha1, unsigned int mode, enum object_type *type, unsigned long *size, const struct commit *commit);
-extern int is_archive_path_ignored(const char *path);
-
extern int write_archive_entries(struct archiver_args *args, write_archive_entry_fn_t write_entry);
#endif /* ARCHIVE_H */
--
1.5.6.2.212.g08b51
^ permalink raw reply related
* Re: Syncing up to a tree with a numeric EXTRAVERSION
From: Miklos Vajna @ 2008-07-14 19:29 UTC (permalink / raw)
To: vb; +Cc: git
In-Reply-To: <f608b67d0807141224v258172a7pfe655a0ceb0f8efd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Mon, Jul 14, 2008 at 12:24:33PM -0700, vb <vb@vsbe.com> wrote:
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 19
> EXTRAVERSION = .2
> NAME=Avast! A bilge rat!
>
> (...)
>
> so, the question is where do I find the tree with the Makefile
> EXTRAVERSION set to .2?
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.19.y.git ?
Hope this helps.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Syncing up to a tree with a numeric EXTRAVERSION
From: vb @ 2008-07-14 19:24 UTC (permalink / raw)
To: git
I have vendor provided linux tree which includes some vendor specific
code. The tree's top level Makefile has this header:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
EXTRAVERSION = .2
NAME=Avast! A bilge rat!
so, this is what I want to pull from the repository to see what's
different. The thing is that when I go to the Makefile history in the
master git repository
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=Makefile;h=e3c5eb66ec52dee13127e3b2b83f84c3184bd8be;hb=bce7f793daec3e65ec5c5705d2457b81fe7b5725;pg=1)
I don't see a tag for this version, all which is there between 19-rc6
and 20-rc1 are
2006-12-14 Linus Torvalds Linux v2.6.20-rc1 v2.6.20-rc1
2006-12-13 Jeff Dike [PATCH] Fix crossbuilding checkstack
2006-12-12 Samuel Tardieu Use consistent casing in help message
2006-12-10 Oleg Verych [PATCH] kbuild: fix-rR-is-now-default
2006-11-29 Linus Torvalds Linux 2.6.19 v2.6.19
2006-11-16 Linus Torvalds Linux 2.6.19-rc6 v2.6.19-rc6
so, the question is where do I find the tree with the Makefile
EXTRAVERSION set to .2?
TIA,
vadim
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Teemu Likonen @ 2008-07-14 19:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Gerrit Pape, Johannes Schindelin, Petr Baudis, git
In-Reply-To: <7v3amcgujd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote (2008-07-14 12:00 -0700):
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:
> >> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> >> > > I'm saying this because I believe the best conservative upper
> >> > > bound for backwards compatibility is Git version in Debian
> >> > > stable. It gets
> > Please consider it as a critical usability problem.
> >
> > Maybe we can release 1.4.5 with the ability to read index v2? That
> > wouldn't be hard to backport the reading part of it.
> I am of two minds here.
>
> On one hand, I am sympathetic to distros that want to give long time
> support for ancient versions to keep working in an ever-changing new
> world. It is a wonderful thing that there are distros that aim for
> ultra conservative stability, and I applaud them.
>
> But as the upstream, we have our own deprecation schedule.
As Debian stable (4.0 "Etch") and its git 1.4.4.4 was mentioned I'd like
to point out that git 1.5.6 is available for Etch users from
kind-of-semi-official <www.backports.org>. So I guess Debian stable
users aren't left completely behind. Git's web page already advertises
backports.org version for Etch.
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Junio C Hamano @ 2008-07-14 19:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080714085555.GJ32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Getting alternates list for http://repo.or.cz/r/repo.git/
> Getting pack list for http://repo.or.cz/r/repo.git/
> Getting index for pack 5111285cac0f895cd9367c9939ced68e2c43dcc0
> error: non-monotonic index
> /usr/bin/git-fetch: line 297: 30402 Segmentation fault git-http-fetch -v -a "$head" "$remote/"
Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
the server side need a knob to tell it to stay conservative because the
repository may be served over dumb protocols to avoid this problem.
That knob could even be called
[repack]
usedeltabaseoffset = false
[pack]
indexversion = 1
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Junio C Hamano @ 2008-07-14 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Steffen Prohaska
In-Reply-To: <200807142054.35027.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Montag, 14. Juli 2008, Johannes Schindelin wrote:
>> Hi,
>>
>> On Mon, 14 Jul 2008, Johannes Sixt wrote:
>> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
>> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
>> > > > *path)
>> > > > }
>> > > > }
>> > > >
>> > > > -void setup_path(const char *cmd_path)
>> > > > +void setup_path(void)
>> > >
>> > > It seems to me that this patch would not do anything different, but
>> > > with less code change, if setup_path() would set argv0_path, and not a
>> > > new function was introduced.
>> >
>> > This is just to play a safe game. I had it that way, but I decided to
>> > have the call to the new git_set_argv0_path() early in git.c because the
>> > call to setup_path() in git.c is very late, and it could happen that we
>> > call system_path() (which needs argv0_path) before that. Although I
>> > didn't audit the code whether this really happens.
>>
>> Well, okay... I would have rather seen it not change (since there was no
>> bug to fix), or as a separate patch, but it's Junio's call.
>
> I investigated this, and, yes, there indeed are calls to system_path() before
> setup_path(), for example:
>
> commit_pager_choice
> setup_pager
> git_config
> git_etc_gitconfig
> system_path(ETC_GITCONFIG)
>
> Junio, do you want git_set_argv0_path() in a separate patch?
I think that would be easier to explain in the commit log what is going
on, if it is a separate patch.
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Junio C Hamano @ 2008-07-14 19:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Gerrit Pape, Johannes Schindelin, Petr Baudis, git
In-Reply-To: <alpine.LFD.1.10.0807141351540.12484@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 14 Jul 2008, Gerrit Pape wrote:
>
>> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
>> > On Mon, 14 Jul 2008, Petr Baudis wrote:
>> > > I'm saying this because I believe the best conservative upper bound for
>> > > backwards compatibility is Git version in Debian stable. It gets
>> > > probably the most stale from all the widely used software distributions
>> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
>> > > fails miserably on the new packs.
>> >
>> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>>
>> Please don't. It wouldn't help, rather the opposite I think, espacially
>> the bus. We don't introduce new upstream versions into a Debian stable
>> release, there's a great effort done for each stable release to reach
>> high quality integration of all the software packages available in
>> Debian. Once that status is reached, only security fixes and criticial
>> usability fixes are added.
>
> Please consider it as a critical usability problem.
>
> Maybe we can release 1.4.5 with the ability to read index v2? That
> wouldn't be hard to backport the reading part of it.
I am of two minds here.
On one hand, I am sympathetic to distros that want to give long time
support for ancient versions to keep working in an ever-changing new
world. It is a wonderful thing that there are distros that aim for ultra
conservative stability, and I applaud them.
But as the upstream, we have our own deprecation schedule. We should of
course plan carefully not to harm existing users of our releases, but
frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
is an eternity in git timescale. Maybe we will slow down someday, and
this 18-month is not a set-in-stone rule in any way, but at this point
even without the packfile format issues, I personally think anything
before 1.5.0 is irrelevant --- maybe they are interesting as historical
curiosities, but not more than that.
We could:
$ git checkout -b maint-1.4 v1.4.4.4
$ git merge maint
$ git tag v1.4.4.5
and push the result out. While I would imagine that the end-user
experience after such a maintenance release would be very positive, that
is not something distros who really want to stay with a stale version for
a good reason would want to swallow ;-).
If we _were_ to keep v1.4.4.X series alive, serious backporting efforts
will be necessary. For example, recent 'git-shell' futureproofing was
made not just to 1.5.6.X series but was backported to 1.5.4.X and 1.5.5.X,
and we would probably need to give it to 1.4.4.X as well. What other
things are there that are missing in 1.4.4.X? It would take nontrivial
engineering resource to even list them, let alone assessing how much
effort is required for such backporting and actually doing it.
The remotes/ layout, use of "git-add" for new contents (instead of only
new files), reflogs, detached HEAD, --pretty=format:%<blah>, bundles,
mergetool,... all the things that a modern git workflow revolves around
and are described in the user manuals the users find on the net are not
found in 1.4.4.X series. If a user of such a conservative distro needs to
work with a repository prepared on another platform with newer git,
perhaps crossmounted, should we backport "git branch -r" so that the user
can confortably work with remote tracking branches? Should we backport
reflogs?
If a distro chooses to support its users whom they force to pin at 1.4.4.X
series, it's primarily _their_ choice. I do not mind helping them in such
a backport, but the request has to come from the distro first with a
specific list of items that need to be supported.
^ permalink raw reply
* Re: [PATCH] Fix relative built-in paths to be relative to the command invocation
From: Johannes Sixt @ 2008-07-14 18:54 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807141319420.8950@racer>
On Montag, 14. Juli 2008, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 14 Jul 2008, Johannes Sixt wrote:
> > Zitat von Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > > On Sun, 13 Jul 2008, Johannes Sixt wrote:
> > > > @@ -84,7 +90,7 @@ static void add_path(struct strbuf *out, const char
> > > > *path)
> > > > }
> > > > }
> > > >
> > > > -void setup_path(const char *cmd_path)
> > > > +void setup_path(void)
> > >
> > > It seems to me that this patch would not do anything different, but
> > > with less code change, if setup_path() would set argv0_path, and not a
> > > new function was introduced.
> >
> > This is just to play a safe game. I had it that way, but I decided to
> > have the call to the new git_set_argv0_path() early in git.c because the
> > call to setup_path() in git.c is very late, and it could happen that we
> > call system_path() (which needs argv0_path) before that. Although I
> > didn't audit the code whether this really happens.
>
> Well, okay... I would have rather seen it not change (since there was no
> bug to fix), or as a separate patch, but it's Junio's call.
I investigated this, and, yes, there indeed are calls to system_path() before
setup_path(), for example:
commit_pager_choice
setup_pager
git_config
git_etc_gitconfig
system_path(ETC_GITCONFIG)
Junio, do you want git_set_argv0_path() in a separate patch?
-- Hannes
^ permalink raw reply
* Re: RA layer request failed
From: Carlos Oliveira @ 2008-07-14 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <3cfdbff10807141141h2a182dd5vc79a6b41bdbea748@mail.gmail.com>
Just some additional information:
- it is not a connectivity problem: I can commit from a conventional svn client
- git version is 1.5.6 on cygwin
-Carlos
On Mon, Jul 14, 2008 at 2:41 PM, Carlos Oliveira <coliveira@gmail.com> wrote:
> Hi Everyone,
>
> I am using git svn dcommit, and I am receiving the following message:
>
> RA layer request failed: COPY of <file>: 40 Not Found ... at
> /usr/bin/git-svn line 461
>
> This is the first time I see this message after I started using git
> svn (I use it a lot).
> This all started when I had a interrupted dcommit, which I managed to
> rebase to a safe
> state.
>
> Does anyone know what this error means, and how I can fix it?
>
> Thanks,
> -Carlos
>
^ permalink raw reply
* RA layer request failed
From: Carlos Oliveira @ 2008-07-14 18:41 UTC (permalink / raw)
To: git
Hi Everyone,
I am using git svn dcommit, and I am receiving the following message:
RA layer request failed: COPY of <file>: 40 Not Found ... at
/usr/bin/git-svn line 461
This is the first time I see this message after I started using git
svn (I use it a lot).
This all started when I had a interrupted dcommit, which I managed to
rebase to a safe
state.
Does anyone know what this error means, and how I can fix it?
Thanks,
-Carlos
^ permalink raw reply
* [PATCH,v2] Make git-add -i accept ranges like 7-
From: Ciaran McCreesh @ 2008-07-14 18:29 UTC (permalink / raw)
To: gitster; +Cc: git, Ciaran McCreesh
In-Reply-To: <7vfxqcgwni.fsf@gitster.siamese.dyndns.org>
git-add -i ranges expect number-number. But for the supremely lazy, typing in
that second number when selecting "from patch 7 to the end" is wasted effort.
So treat an empty second number in a range as "until the last item".
Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
---
Oops, my bad.
Attempt 2 changes the regex to require a number in the first half of the range.
I was planning to allow for -7, meaning 'up to 7', but this collides with - at
the start being used to unchoose things. There's not much point adding a
special thing for 'from the start' though, since '1' is only one character to
type.
Documentation/git-add.txt | 5 +++--
git-add--interactive.perl | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 46dd56c..3558905 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -187,8 +187,9 @@ update::
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
- 2,3,4,5,7,9 from the list. You can say '*' to choose
- everything.
+ 2,3,4,5,7,9 from the list. If the second number in a range is
+ omitted, all remaining patches are taken. E.g. "7-" to choose
+ 7,8,9 from the list. You can say '*' to choose everything.
+
What you chose are then highlighted with '*',
like this:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 801d7c0..a6a5c52 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -406,9 +406,9 @@ sub list_and_choose {
if ($choice =~ s/^-//) {
$choose = 0;
}
- # A range can be specified like 5-7
- if ($choice =~ /^(\d+)-(\d+)$/) {
- ($bottom, $top) = ($1, $2);
+ # A range can be specified like 5-7 or 5-.
+ if ($choice =~ /^(\d+)-(\d*)$/) {
+ ($bottom, $top) = ($1, length($2) ? $2 : 1 + @stuff);
}
elsif ($choice =~ /^\d+$/) {
$bottom = $top = $choice;
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] Make git-add -i accept ranges like 7-
From: Junio C Hamano @ 2008-07-14 18:15 UTC (permalink / raw)
To: Ciaran McCreesh; +Cc: git
In-Reply-To: <1216058784-32584-1-git-send-email-ciaran.mccreesh@googlemail.com>
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> writes:
> git-add -i ranges expect number-number. But for the supremely lazy, typing in
> that second number when selecting "from patch 7 to the end" is wasted effort.
> So treat an empty second number in a range as "until the last item".
You didn't describe why you changed the first regexp from \d+ to \d*,
which would allow "-9" as a valid input as well.
But in that case $bottom will become an empty string. Don't you need to
adjust the users of this data in the codepaths that follow this part? I
didn't check.
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 801d7c0..72a8858 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -406,9 +406,9 @@ sub list_and_choose {
> if ($choice =~ s/^-//) {
> $choose = 0;
> }
> - # A range can be specified like 5-7
> - if ($choice =~ /^(\d+)-(\d+)$/) {
> - ($bottom, $top) = ($1, $2);
> + # A range can be specified like 5-7 or 5-.
> + if ($choice =~ /^(\d*)-(\d*)$/) {
> + ($bottom, $top) = ($1, length($2) ? $2 : 1 + @stuff);
> }
> elsif ($choice =~ /^\d+$/) {
> $bottom = $top = $choice;
> --
> 1.5.6.2
^ permalink raw reply
* [PATCH] shortlog: support --pretty=format: option
From: Johannes Schindelin @ 2008-07-14 18:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Junio C Hamano, Ingo Molnar, Git Mailing List,
Thomas Gleixner
In-Reply-To: <alpine.DEB.1.00.0807141844160.8950@racer>
With this patch, the user can override the default setting, to print
the commit messages using a user format instead of the onelines of the
commits. Example:
$ git shortlog --pretty='format:%s (%h)' <commit>..
Note that shortlog will only respect a user format setting, as the other
formats do not make much sense.
Wished for by Andrew Morton.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 14 Jul 2008, Johannes Schindelin wrote:
> Note that I do not think it would be all that hard to teach
> shortlog the --pretty option.
Well...
builtin-shortlog.c | 11 +++++++++++
shortlog.h | 1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 0136202..f8bcbfc 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -154,6 +154,15 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
if (!author)
die("Missing author: %s",
sha1_to_hex(commit->object.sha1));
+ if (log->user_format) {
+ struct strbuf buf = STRBUF_INIT;
+
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf,
+ DEFAULT_ABBREV, "", "", DATE_NORMAL, 0);
+ insert_one_record(log, author, buf.buf);
+ strbuf_release(&buf);
+ return;
+ }
if (*buffer)
buffer++;
insert_one_record(log, author, !*buffer ? "<none>" : buffer);
@@ -271,6 +280,8 @@ parse_done:
usage_with_options(shortlog_usage, options);
}
+ log.user_format = rev.commit_format == CMIT_FMT_USERFORMAT;
+
/* assume HEAD if from a tty */
if (!nongit && !rev.pending.nr && isatty(0))
add_head_to_pending(&rev);
diff --git a/shortlog.h b/shortlog.h
index 31ff491..6608ee8 100644
--- a/shortlog.h
+++ b/shortlog.h
@@ -11,6 +11,7 @@ struct shortlog {
int wrap;
int in1;
int in2;
+ int user_format;
char *common_repo_prefix;
int email;
--
1.5.6.2.511.ge432a
^ permalink raw reply related
* [PATCH] Make git-add -i accept ranges like 7-
From: Ciaran McCreesh @ 2008-07-14 18:06 UTC (permalink / raw)
To: git; +Cc: Ciaran McCreesh
git-add -i ranges expect number-number. But for the supremely lazy, typing in
that second number when selecting "from patch 7 to the end" is wasted effort.
So treat an empty second number in a range as "until the last item".
Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
---
Documentation/git-add.txt | 5 +++--
git-add--interactive.perl | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 46dd56c..3558905 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -187,8 +187,9 @@ update::
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
- 2,3,4,5,7,9 from the list. You can say '*' to choose
- everything.
+ 2,3,4,5,7,9 from the list. If the second number in a range is
+ omitted, all remaining patches are taken. E.g. "7-" to choose
+ 7,8,9 from the list. You can say '*' to choose everything.
+
What you chose are then highlighted with '*',
like this:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 801d7c0..72a8858 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -406,9 +406,9 @@ sub list_and_choose {
if ($choice =~ s/^-//) {
$choose = 0;
}
- # A range can be specified like 5-7
- if ($choice =~ /^(\d+)-(\d+)$/) {
- ($bottom, $top) = ($1, $2);
+ # A range can be specified like 5-7 or 5-.
+ if ($choice =~ /^(\d*)-(\d*)$/) {
+ ($bottom, $top) = ($1, length($2) ? $2 : 1 + @stuff);
}
elsif ($choice =~ /^\d+$/) {
$bottom = $top = $choice;
--
1.5.6.2
^ permalink raw reply related
* Re: Closing the merge window for 1.6.0
From: Nicolas Pitre @ 2008-07-14 17:54 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Schindelin, Petr Baudis, Junio C Hamano, git
In-Reply-To: <20080714124109.25414.qmail@06d015ec9c6744.315fe32.mid.smarden.org>
On Mon, 14 Jul 2008, Gerrit Pape wrote:
> On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > I'm saying this because I believe the best conservative upper bound for
> > > backwards compatibility is Git version in Debian stable. It gets
> > > probably the most stale from all the widely used software distributions
> > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > > fails miserably on the new packs.
> >
> > Can't we just hit Debian's Git maintainer with a clue bat or a bus,
>
> Please don't. It wouldn't help, rather the opposite I think, espacially
> the bus. We don't introduce new upstream versions into a Debian stable
> release, there's a great effort done for each stable release to reach
> high quality integration of all the software packages available in
> Debian. Once that status is reached, only security fixes and criticial
> usability fixes are added.
Please consider it as a critical usability problem.
Maybe we can release 1.4.5 with the ability to read index v2? That
wouldn't be hard to backport the reading part of it.
Nicolas
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:46 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807141019010.3305@woody.linux-foundation.org>
On Mon, 14 Jul 2008, Linus Torvalds wrote:
>
> Some really ugly scripting like this will do it:
>
> #!/bin/sh
> git log --pretty='format:commit %H
> Author: %an <%ae>
Side note: you can make it a one-liner with '%n' (not \n') if you want, ie
#!/bin/sh
git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)%n' $@ | git shortlog
if you want to make it look even more like line noise.
And if you want to be _really_ fancy, you can even make it a git
alias. Just add somethign like this to your ~/.gitconfig file:
[alias]
mylog=!GIT_PAGER='git --no-pager shortlog' git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)%n'
which is the _real_ git-mans way to do it.
It does the "shortlog" output by using "git shortlog" as a pager, but then
to avoid recursion, we have to turn off paging of shortlog output itself.
Heh. And the reason to do that is that the arguments always go to the end,
so since we want to give the args to "git log", we can't put the pipe at
the end.
I will have to go wash up after writing the above.
Linus
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Johannes Schindelin @ 2008-07-14 17:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Junio C Hamano, Ingo Molnar, Git Mailing List,
Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807141019010.3305@woody.linux-foundation.org>
Hi,
On Mon, 14 Jul 2008, Linus Torvalds wrote:
> git log --pretty='format:commit %H
> Author: %an <%ae>
>
> %s (%h)
> ' $@ | git shortlog
Surely you meant
git log --pretty='format:commit %H%nAuthor: %an <%ae>%n%n %s (%h)' \
$@ | git shortlog
Note that I do not think it would be all that hard to teach shortlog the
--pretty option.
Ciao,
Dscho
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:23 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <alpine.LFD.1.10.0807140948220.3305@woody.linux-foundation.org>
On Mon, 14 Jul 2008, Linus Torvalds wrote:
>
> As it is, that is one ugly function that only takes the one-liner thing -
> at least partly because of how it traditionally worked (as a a filter over
> the log messages, rather than as a "git shortlog xyz..abc" kind of
> stand-alone thing).
Heh. I guess you _could_ use the filter capability here (but it will
sometimes truncate the line, so..)
Some really ugly scripting like this will do it:
#!/bin/sh
git log --pretty='format:commit %H
Author: %an <%ae>
%s (%h)
' $@ | git shortlog
where we use the regular "git log" with a user-supplied format to generate
a log with the subject line and the shortened hash appended (the "%s (%h)"
part) and then we use "git shortlog" as a filter to sort things together
by author etc.
There is absolutely _nothing_ that git won't do with a little bit of
scripting, but I do have to admit that this one isn't a wonderfully
beautiful script ;)
Linus
^ permalink raw reply
* Re: [git pull] core/softirq for v2.6.27
From: Linus Torvalds @ 2008-07-14 17:11 UTC (permalink / raw)
To: Andrew Morton, Junio C Hamano
Cc: Ingo Molnar, Git Mailing List, Thomas Gleixner
In-Reply-To: <20080714094422.e7ae255a.akpm@linux-foundation.org>
On Mon, 14 Jul 2008, Andrew Morton wrote:
>
> This was a git-shortlog feature request ;)
Heh. You should cc git or Junio if so.
The way shortlog is done (very different from regular logs, due to the
whole organize-by-name etc thing) that is sadly pretty ugly to do: we
don't support the pretty-formats etc. And the way things are done, adding
support for the generic "--pretty=xyz" (including custom formats) would be
pretty painful.
So it would have to be a total special-case.
Junio, git people - what Andrew is asking for is for git shortlog to show
the commit ID (in shortened form) at the end:
> > It would be nice if these short-form summaries were to include the
> > commit IDs. eg:
> >
> > Carlos R. Mafra (1):
> > Remove argument from open_softirq which is always NULL (962cf36)
and I do think it would be nice. I've had some other things I would find
shortlog format additions useful for (size of patch etc), so if it could
be somehow generalized that would be wonderful.
As it is, that is one ugly function that only takes the one-liner thing -
at least partly because of how it traditionally worked (as a a filter over
the log messages, rather than as a "git shortlog xyz..abc" kind of
stand-alone thing).
Linus
^ permalink raw reply
* Re: I want delete fault commit from my git repository
From: Jakub Narebski @ 2008-07-14 16:41 UTC (permalink / raw)
To: chongyc; +Cc: git
In-Reply-To: <9f01c190-73b6-48b1-88d9-ed67d0945d81@k13g2000hse.googlegroups.com>
chongyc <chongyc27@gmail.com> writes:
> I have found buggy commit object which I had committed into git
> repository wrongly
>
> So I am going to delete it from my git repository
>
> How to do it ?
If it is just created commit (and not yet published), use
"git commit --amend" to correct it, or "git reset --hard HEAD^"
to just drop it.
If you have published history (somebody is relying on history
containing broken commit) the only way is to add commit reverting
changes brought by broken commit using git-revert.
If you can rewrite history, use "git rebase --interactive" and simply
remove the commit from instructions/series file if the commit you want
to remove is not too deep in history, or use git-filter-branch if
broken commit is somewhere deeper. See documentation for details.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] typo
From: Frederik Schwarzer @ 2008-07-14 16:30 UTC (permalink / raw)
To: git; +Cc: gitster
>From ffa0baf13d033b3dc6b49e86ed3de9fb3003ec4e Mon Sep 17 00:00:00 2001
From: Frederik Schwarzer <schwarzerf@gmail.com>
Date: Mon, 14 Jul 2008 18:22:52 +0200
Subject: [PATCH] typo
full stop in the middle of the sentence
Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..8478ca6 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4619,7 +4619,7 @@ sub migrate_from_v1 {
mkpath([$svn_dir]);
print STDERR "Data from a previous version of git-svn exists, but\n\t",
"$svn_dir\n\t(required for this version ",
- "($::VERSION) of git-svn) does not. exist\n";
+ "($::VERSION) of git-svn) does not exist.\n";
my ($fh, $ctx) = command_output_pipe(qw/rev-parse --symbolic --all/);
while (<$fh>) {
my $x = $_;
--
1.5.6.2
^ permalink raw reply related
* Re: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
From: João Abecasis @ 2008-07-14 15:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <7bf6f1d20807140827u56abc74fs4e289384db054a0e@mail.gmail.com>
find-rev and rebase error out on svm because git-svn doesn't trace the
original svn revision numbers back to git commits. The updated test
case, included in the patch, shows the issue and passes with the rest of
the patch applied.
This fixes Git::SVN::find_by_url to find branches based on the
svm:source URL, where useSvmProps is set. Also makes sure cmd_find_rev
and working_head_info use the information they have to correctly track
the source repository. This is enough to get find-rev and rebase
working.
Signed-off-by: João Abecasis <joao@abecasis.name>
---
git-svn.perl | 39 ++++++++++++++++++++++++++++++++++---
t/t9110-git-svn-use-svm-props.sh | 9 ++++++++
2 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..0aa994a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -537,13 +537,13 @@ sub cmd_find_rev {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my (undef, undef, undef, $gs) = working_head_info($head, \@refs);
+ my (undef, undef, $uuid, $gs) = working_head_info($head, \@refs);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
}
my $desired_revision = substr($revision_or_hash, 1);
- $result = $gs->rev_map_get($desired_revision);
+ $result = $gs->rev_map_get($desired_revision, $uuid);
} else {
my (undef, $rev, undef) = cmt_metadata($revision_or_hash);
$result = $rev;
@@ -1162,7 +1162,7 @@ sub working_head_info {
if (defined $url && defined $rev) {
next if $max{$url} and $max{$url} < $rev;
if (my $gs = Git::SVN->find_by_url($url)) {
- my $c = $gs->rev_map_get($rev);
+ my $c = $gs->rev_map_get($rev, $uuid);
if ($c && $c eq $hash) {
close $fh; # break the pipe
return ($url, $rev, $uuid, $gs);
@@ -1416,11 +1416,17 @@ sub fetch_all {
sub read_all_remotes {
my $r = {};
+ my $use_svm_props = eval { command_oneline(qw/config --bool
+ svn.useSvmProps/) };
+ $use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
$local_ref =~ s{^/}{};
$r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
+ $r->{$remote}->{svm} = {} if $use_svm_props;
+ } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
+ $r->{$1}->{svm} = {};
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=
@@ -1437,6 +1443,23 @@ sub read_all_remotes {
}
}
}
+
+ map {
+ if (defined $r->{$_}->{svm}) {
+ my $svm;
+ eval {
+ my $section = "svn-remote.$_";
+ $svm = {
+ source => tmp_config('--get',
+ "$section.svm-source"),
+ replace => tmp_config('--get',
+ "$section.svm-replace"),
+ }
+ };
+ $r->{$_}->{svm} = $svm;
+ }
+ } keys %$r;
+
$r;
}
@@ -1563,13 +1586,21 @@ sub find_by_url { # repos_root and, path are optional
}
my $p = $path;
my $rwr = rewrite_root({repo_id => $repo_id});
+ my $svm = $remotes->{$repo_id}->{svm}
+ if defined $remotes->{$repo_id}->{svm};
unless (defined $p) {
$p = $full_url;
my $z = $u;
+ my $prefix = '';
if ($rwr) {
$z = $rwr;
+ } elsif (defined $svm) {
+ $z = $svm->{source};
+ $prefix = $svm->{replace};
+ $prefix =~ s#^\Q$u\E(?:/|$)##;
+ $prefix =~ s#/$##;
}
- $p =~ s#^\Q$z\E(?:/|$)## or next;
+ $p =~ s#^\Q$z\E(?:/|$)#$prefix# or next;
}
foreach my $f (keys %$fetch) {
next if $f ne $p;
diff --git a/t/t9110-git-svn-use-svm-props.sh b/t/t9110-git-svn-use-svm-props.sh
index 047659f..04d2a65 100755
--- a/t/t9110-git-svn-use-svm-props.sh
+++ b/t/t9110-git-svn-use-svm-props.sh
@@ -49,4 +49,13 @@ test_expect_success 'verify metadata for /dir' "
grep '^git-svn-id: $dir_url@1 $uuid$'
"
+test_expect_success 'find commit based on SVN revision number' "
+ git-svn find-rev r12 |
+ grep `git rev-parse HEAD`
+ "
+
+test_expect_success 'empty rebase' "
+ git-svn rebase
+ "
+
test_done
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] git-svn: find-rev and rebase for SVN::Mirror repositories
From: João Abecasis @ 2008-07-14 15:27 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20080714091243.GA27794@untitled>
Hi Eric,
Thanks for your reply and comments.
Eric Wong <normalperson@yhbt.net> wrote:
> João Abecasis <joao@abecasis.name> wrote:
>> find-rev and rebase error out on svm because git-svn doesn't trace the original
>> svn revision numbers back to git commits. The updated test case, included in the
>> patch, shows the issue and passes with the rest of the patch applied.
>>
>> This fixes Git::SVN::find_by_url to find branches based on the svm:source URL,
>> where useSvmProps is set. Also makes sure cmd_find_rev and working_head_info use
>> the information they have to correctly track the source repository. This is
>> enough to get find-rev and rebase working.
>>
>> Signed-off-by: João Abecasis <joao@abecasis.name>
>> ---
>> Incidentally, I've tried submitting these fixes before, but failed to
>> get much attention, so I could be doing something wrong... Any input
>> on the patch or my approach to this list is appreciated. This time I
>> reworded the commit message and added Eric Wong to the CC list, since
>> he seems to be Ack'ing git-svn patches.
>
> Hi João,
>
> Sorry, I haven't been following the mailing list much lately, and
> even keeping up with my inbox is getting to be a chore :(
I can relate to that ;-)
> The commit message should be wrapped at 72 characters or less.
> Some further notes below (mostly whitespace issues, but one
> regression).
Noted.
>> sub read_all_remotes {
>> my $r = {};
>> + my $usesvmprops = eval { command_oneline(qw/config --bool
>> + svn.useSvmProps/) };
>> + $usesvmprops = $usesvmprops eq 'true' if $usesvmprops;
>
> Always use tabs for indentation (but spaces for alignment is alright).
>
> I'd also rather not propagate the crazy alllowercasewithoutunderscores
> convention of git-config into code, either. $uses_svm_props is much
> easier to parse when I'm half-awake :)
Done!
>> foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
>> if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
>> my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
>> $local_ref =~ s{^/}{};
>> $r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
>> + $r->{$remote}->{svm} = {} if $usesvmprops;
>> + } elsif (m!^(.+)\.usesvmprops=\s*(.*)\s*$!) {
>> + $r->{$1}->{svm} = {};
>> } elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
>> $r->{$1}->{url} = $2;
>> } elsif (m!^(.+)\.(branches|tags)=
>> @@ -1437,6 +1443,21 @@ sub read_all_remotes {
>> }
>> }
>> }
>> +
>> + map {
>> + if (defined $r->{$_}->{svm}) {
>> + my $svm;
>> + eval {
>> + my $section = "svn-remote.$_";
>> + $svm = {
>> + source => tmp_config('--get', "$section.svm-source"),
>> + replace => tmp_config('--get', "$section.svm-replace"),
>> + }
>> + };
>> + $r->{$_}->{svm} = $svm;
>> + }
>> + } keys %$r;
>> +
>
> Please wrap all code at 80-columns.
Okidoki. I just wasn't sure how wide was a tab ;-)
>> @@ -1563,13 +1584,21 @@ sub find_by_url { # repos_root and, path are optional
>> }
>> my $p = $path;
>> my $rwr = rewrite_root({repo_id => $repo_id});
>> + my $svm = $remotes->{$repo_id}->{svm}
>> + if defined $remotes->{$repo_id}->{svm};
>> unless (defined $p) {
>> $p = $full_url;
>> my $z = $u;
>> + my $prefix = '';
>> if ($rwr) {
>> $z = $rwr;
>> + } elsif (defined $svm) {
>> + $z = $svm->{source};
>> + $prefix = $svm->{replace};
>> + $prefix =~ s#^\Q$u\E(?:/|$)##;
>> + $prefix =~ s#/$##;
>> }
>> - $p =~ s#^\Q$z\E(?:/|$)## or next;
>> + $p =~ s#^\Q$z\E(?=/|$)#$prefix# or next;
>
> This broke t9100 for me at: 'able to dcommit to a subdirectory'
> Changing the ?= back to ?: works.
Duh! Missed that. I had to make a couple of tweaks after the tests
were working, because I had some another test case that was breaking
somewhere. Anyway, my other test case (which is the one where I need
it to work) works without that change after all.
> Thanks for the patch, please let us know if that change is OK.
Let's go with that, since it works. If I do find a test case where it
breaks we'll fix it later.
Updated patch coming up.
Cheers,
João
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-14 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <20080712221207.GB22323@leksak.fem-net>
Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
> Hi,
>
> Michael J Gruber wrote:
>> "git commit" allows empty commits with the "--allow-empty" option, i.e.
>> commits which introduce no change at all. This is sometimes useful for
>> keeping a log of untracked work related to tracked content.
>>
>> "git rebase" removes empty commits, for the good reason that rebasing
>> may make certain commits obsolete; but I don't want that in the case
>> mentioned above. Is there any way to specify "--preserve-empty" or
>> similar?
>
> First I can speak for git-sequencer: there is no such thing as a
> "preserve empty" option, but currently, when you are picking a commit
> that has already been applied so that no changes occur, it will pause.
> (It will not pause if it is a fast-forward.)
> Yet, I was unsure if this is a "correct" behavior, but it seemed to be
> useful, because you can inspect the situation.
>
> In my mind, the same should happen with an empty commit, so I tested it:
> 1. It pauses.
> 2. In that pause I only need to run "git commit --allow-empty" and I have
> the picked empty patch with that commit message.
>
> So if this behavior is kept, there is no such need for such an option.
>
> Now I'm checking it with the old rebase-i (I'm always referring to
> git-rebase--interactive as rebase-i) and exactly the same behavior
> occurs.
>
> But rebase is not rebase-i.
> So I've also checked both, pure rebase and rebase-m: then the empty commit
> is lost.
>
> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
> and then "git rebase --continue" and you have what you want.
I assume this is with git from master? With git 1.5.6.2 rebase -i
doesn't stop there, not even when I change "pick" to "edit"!
So, I guess for now I'll use my hacked git-rebase ("-m", I didn't hack
git-format-patch), maybe 1.6.0 will behave as described above. Anyway
thanks for the hint about distinguishing between rebase and rebase -i.
Michael
^ 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