* [PATCH 4/5] Avoid printing unnecessary warnings during fetch and push
From: Shawn O. Pearce @ 2007-09-18 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If a transport doesn't support an option we already are telling
the higher level application (fetch or push) that the option is not
valid by sending back a >0 return value from transport_set_option
so there's not a strong motivation to have the function perform the
output itself. Instead we should let the higher level application
do the output if it is necessary. This avoids always telling the
user that depth isn't supported on HTTP urls even when they did
not pass a --depth option to git-fetch.
If the user passes an option and the option value is invalid we now
properly die in git-fetch instead of just spitting out a message
and running anyway. This mimics prior behavior better where
incorrect/malformed options are not accepted by the process.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-fetch.c | 18 +++++++++++++++---
transport.c | 11 ++---------
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 670af0b..b9722e5 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -430,6 +430,17 @@ static int do_fetch(struct transport *transport,
return 0;
}
+static void set_option(const char *name, const char *value)
+{
+ int r = transport_set_option(transport, name, value);
+ if (r < 0)
+ die("Option \"%s\" value \"%s\" is not valid for %s\n",
+ name, value, transport->url);
+ if (r > 0)
+ warning("Option \"%s\" is ignored for %s\n",
+ name, transport->url);
+}
+
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
@@ -525,10 +536,11 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
if (quiet)
transport->verbose = 0;
if (upload_pack)
- transport_set_option(transport, TRANS_OPT_UPLOADPACK, upload_pack);
+ set_option(TRANS_OPT_UPLOADPACK, upload_pack);
if (keep)
- transport_set_option(transport, TRANS_OPT_KEEP, "yes");
- transport_set_option(transport, TRANS_OPT_DEPTH, depth);
+ set_option(TRANS_OPT_KEEP, "yes");
+ if (depth)
+ set_option(TRANS_OPT_DEPTH, depth);
if (!transport->url)
die("Where do you want to fetch from today?");
diff --git a/transport.c b/transport.c
index 7f94d30..cc76e3f 100644
--- a/transport.c
+++ b/transport.c
@@ -460,16 +460,9 @@ struct transport *transport_get(struct remote *remote, const char *url)
int transport_set_option(struct transport *transport,
const char *name, const char *value)
{
- int ret = 1;
if (transport->ops->set_option)
- ret = transport->ops->set_option(transport, name, value);
- if (ret < 0)
- fprintf(stderr, "For '%s' option %s cannot be set to '%s'\n",
- transport->url, name, value);
- if (ret > 0)
- fprintf(stderr, "For '%s' option %s is ignored\n",
- transport->url, name);
- return ret;
+ return transport->ops->set_option(transport, name, value);
+ return 1;
}
int transport_push(struct transport *transport,
--
1.5.3.1.1000.g7319b
^ permalink raw reply related
* [PATCH 5/5] Use 'unsigned:1' when we mean boolean options
From: Shawn O. Pearce @ 2007-09-18 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These options are all strictly boolean (true/false). Its easier to
document this implicitly by making their storage type a single bit.
There is no compelling memory space reduction reason for this change,
it just makes the structure definition slightly more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
fetch-pack.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fetch-pack.h b/fetch-pack.h
index cdcd84f..ad13076 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -4,14 +4,14 @@
struct fetch_pack_args
{
const char *uploadpack;
- int quiet;
- int keep_pack;
int unpacklimit;
- int use_thin_pack;
- int fetch_all;
- int verbose;
int depth;
- int no_progress;
+ unsigned quiet:1,
+ keep_pack:1,
+ use_thin_pack:1,
+ fetch_all:1,
+ verbose:1,
+ no_progress:1;
};
void setup_fetch_pack(struct fetch_pack_args *args);
--
1.5.3.1.1000.g7319b
^ permalink raw reply related
* Re: [PATCH 1/3] git-apply: fix whitespace stripping
From: David Kastrup @ 2007-09-18 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <11899829424173-git-send-email-bfields@citi.umich.edu>
"J. Bruce Fields" <bfields@citi.umich.edu> writes:
> The algorithm isn't right here: it accumulates any set of 8 spaces into
> tabs even if they're separated by tabs, so
>
> <four spaces><tab><four spaces><tab>
>
> is converted to
>
> <tab><tab><tab>
>
> when it should be just
>
> <tab><tab>
>
> So teach git-apply that a tab hides any group of less than 8 previous
> spaces in a row.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> ---
> builtin-apply.c | 13 ++++++++++---
> 1 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 976ec77..70359c1 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -1642,15 +1642,22 @@ static int apply_line(char *output, const char *patch, int plen)
>
> buf = output;
> if (need_fix_leading_space) {
> + int consecutive_spaces = 0;
> /* between patch[1..last_tab_in_indent] strip the
> * funny spaces, updating them to tab as needed.
> */
> for (i = 1; i < last_tab_in_indent; i++, plen--) {
> char ch = patch[i];
> - if (ch != ' ')
> + if (ch != ' ') {
> + consecutive_spaces = 0;
> *output++ = ch;
> - else if ((i % 8) == 0)
> - *output++ = '\t';
> + } else {
> + consecutive_spaces++;
> + if (consecutive_spaces == 8) {
> + *output++ = '\t';
> + consecutive_spaces = 0;
> + }
> + }
> }
> fixed = 1;
> i = last_tab_in_indent;
> --
> 1.5.3.1.42.gfe5df
As far as I can see, this does not really work since it does not
maintain an idea of a current column.
If you have
abcd<four spaces><tab><four spaces><tab>
then indeed the resulting conversion needs to be <tab><tab><tab>
whereas with
abc<four spaces><tab><four spaces><tab>
the resulting conversion needs to be just <tab><tab>
--
David Kastrup
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Junio C Hamano @ 2007-09-18 8:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070918085413.GA11751@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I thought we were holding counts of hashes, in which case there _is_ no
> overflow.
The raw hashval (the fingerprint recorded in struct spanhash) is
further reduced and used as an index into spahash_top.data[].
So more than one hashval can try to sit in the same slot in
spanhash_top.data[] array.
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Jeff King @ 2007-09-18 9:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhclswdsm.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 18, 2007 at 01:58:17AM -0700, Junio C Hamano wrote:
> > I thought we were holding counts of hashes, in which case there _is_ no
> > overflow.
>
> The raw hashval (the fingerprint recorded in struct spanhash) is
> further reduced and used as an index into spahash_top.data[].
> So more than one hashval can try to sit in the same slot in
> spanhash_top.data[] array.
Right, that's sort of what I was hinting at in the original message. Can
we just make the hash table big enough to use the fingerprint hashes
directly? It's going to use a bit more memory, but lookups should be
very fast. I'll try to experiment and get some numbers.
-Peff
^ permalink raw reply
* git-fsck/lost-found's speed vs git-prune's
From: Mike Hommey @ 2007-09-18 9:09 UTC (permalink / raw)
To: git
Hi,
I was wondering if that was to be expected for git-fsck to be
significantly slower than git-prune (by several orders of magnitude) ?
$ time git-lost-found
real 8m22.167s
user 6m44.153s
sys 1m16.613s
$ time git-prune
real 0m0.376s
user 0m0.304s
sys 0m0.000s
Mike
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 9:12 UTC (permalink / raw)
To: Sam Vilain
Cc: Junio C Hamano, Lars Hjemli, Eric Wong, Andreas Ericsson,
Johannes Schindelin, Chris Shoemaker, git
In-Reply-To: <46EF7EA1.6020402@vilain.net>
Sam Vilain wrote:
>>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
>>>
>> That unfortunately does not solve the problem.
>>
>
> I think we 'just' need to fix pushing merges back to SVN - so that they
> properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
> if it is ambiguous which branch to push to, force the user to decide.
>
Whoops, I missed the thrust of the current issue; it won't be ambiguous,
it'll be unambiguously wrong, so this doesn't apply.
In which case I'd guess the moral equivalent of --track would have to go
forward, or a per-branch basis.
I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.
Ideally, it should also have the property that it doesn't cycle; null
merges between two branches should not carry on indefinitely.
Sam.
^ permalink raw reply
* Re: git-fsck/lost-found's speed vs git-prune's
From: Sam Vilain @ 2007-09-18 9:14 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070918090926.GA8927@glandium.org>
Mike Hommey wrote:
> Hi,
>
> I was wondering if that was to be expected for git-fsck to be
> significantly slower than git-prune (by several orders of magnitude) ?
>
> $ time git-lost-found
>
> real 8m22.167s
> user 6m44.153s
> sys 1m16.613s
>
> $ time git-prune
>
> real 0m0.376s
> user 0m0.304s
> sys 0m0.000s
>
You're probably already packed. I'd expect a similar speed difference
between git-fsck and git-fsck --full.
Sam.
^ permalink raw reply
* Re: [PATCH] Drop UTF-8 characters in manual pages
From: Junio C Hamano @ 2007-09-18 9:15 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <11901003792475-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> The default character encoding for english manual pages is ISO8859-1,
On which distro?
> so
> UTF-8 characters are just displayed as their sequence of bytes, which is
> not very appealing.
Perhaps not. I cannot decide what to do with
Documentation/git-pack-redundant.txt, though.
^ permalink raw reply
* Re: diffcore-rename performance mode
From: Junio C Hamano @ 2007-09-18 9:17 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070918090105.GA11854@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 18, 2007 at 01:58:17AM -0700, Junio C Hamano wrote:
>
>> > I thought we were holding counts of hashes, in which case there _is_ no
>> > overflow.
>>
>> The raw hashval (the fingerprint recorded in struct spanhash) is
>> further reduced and used as an index into spahash_top.data[].
>> So more than one hashval can try to sit in the same slot in
>> spanhash_top.data[] array.
>
> Right, that's sort of what I was hinting at in the original message. Can
> we just make the hash table big enough to use the fingerprint hashes
> directly? It's going to use a bit more memory, but lookups should be
> very fast. I'll try to experiment and get some numbers.
Thanks -- I vaguely recall large hash was disastrous for me
(trashed cache), but that was on a different hardware, different
time.
^ permalink raw reply
* Re: git-fsck/lost-found's speed vs git-prune's
From: Junio C Hamano @ 2007-09-18 9:18 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070918090926.GA8927@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> I was wondering if that was to be expected for git-fsck to be
> significantly slower than git-prune (by several orders of magnitude) ?
fsck validates objects are correct and sane. prune only looks
at reachability.
^ permalink raw reply
* Re: [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-18 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dan Libby, git
In-Reply-To: <7vlkb4wdzq.fsf@gitster.siamese.dyndns.org>
Some people seem to create SVN branch names with spaces
or other shell metacharacters.
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
---
Junio C Hamano:
> > - open(H,"git-rev-parse --verify $parent |");
> > + open(H,'-|',"git-rev-parse","--verify",$parent);
>
> I seem to be missing the context, but please describe what
> problem this fixes in the commit log message. I guess some
> people use shell metacharacters and/or SP in their branch names
> and this is about that problem?
Exactly. Sorry; it seems that the original question hasn't been posted
to the mailing list.
diff --git a/git-svnimport.perl b/git-svnimport.perl
index d3ad5b9..aa5b3b2 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -633,7 +633,7 @@ sub commit {
my $rev;
if($revision > $opt_s and defined $parent) {
- open(H,"git-rev-parse --verify $parent |");
+ open(H,'-|',"git-rev-parse","--verify",$parent);
$rev = <H>;
close(H) or do {
print STDERR "$revision: cannot find commit '$parent'!\n";
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
BOFH excuse #11:
magnetic interference from money/credit cards
^ permalink raw reply related
* Re: [PATCH] Drop UTF-8 characters in manual pages
From: Mike Hommey @ 2007-09-18 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4wgwczs.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 18, 2007 at 02:15:35AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > The default character encoding for english manual pages is ISO8859-1,
>
> On which distro?
Debian, at least, though transition to UTF-8 manpages is going to happen
(it seems there was a lack of proper encoding handling in man-db until
very recently)
> > so
> > UTF-8 characters are just displayed as their sequence of bytes, which is
> > not very appealing.
>
> Perhaps not. I cannot decide what to do with
> Documentation/git-pack-redundant.txt, though.
I'd say just use a transliterated form until man-db mess is sorted out.
Mike
^ permalink raw reply
* Re: git-fsck/lost-found's speed vs git-prune's
From: Mike Hommey @ 2007-09-18 9:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4phswcuj.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 18, 2007 at 02:18:44AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > I was wondering if that was to be expected for git-fsck to be
> > significantly slower than git-prune (by several orders of magnitude) ?
>
> fsck validates objects are correct and sane. prune only looks
> at reachability.
Now, the speed difference makes sense, but I wouldn't expect lost-found
to actually bother validating objects...
Mike
^ permalink raw reply
* [PATCH] Mention that 'push .. master' is in explicit form master:refs/heads/master
From: Jari Aalto @ 2007-09-18 9:59 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto AT cante.net>
---
Documentation/git-push.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 7b8e075..71ac450 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -105,7 +105,9 @@ git push origin master::
Find a ref that matches `master` in the source repository
(most likely, it would find `refs/heads/master`), and update
the same ref (e.g. `refs/heads/master`) in `origin` repository
- with it.
+ with it. The following would be exactly same command:
+
+ git push origin master:refs/heads/master
git push origin :experimental::
Find a ref that matches `experimental` in the `origin` repository
--
1.5.3
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply related
* [PATCH] Fix lapsus in builtin-apply.c
From: Pierre Habouzit @ 2007-09-18 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
I found this issue trying to refactor the "quote" module. It's
definitely worth to push this in maint.
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 05ce220..86d89a4 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -254,7 +254,7 @@ static char *find_name(const char *line, char *def, int p_value, int terminate)
if (name) {
char *cp = name;
while (p_value) {
- cp = strchr(name, '/');
+ cp = strchr(cp, '/');
if (!cp)
break;
cp++;
--
1.5.3.1
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: commit summary, --pretty=short and other tools
From: Johannes Schindelin @ 2007-09-18 10:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Benoit SIGOURE, Mike Hommey, git
In-Reply-To: <46EF7BF7.3070107@op5.se>
Hi,
On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> const char *find_commit_subject_end(const char *commit_msg)
> {
> const char *dot, *paragraph_end;
> paragraph_end = strstr(commit_msg, "\n\n");
> dot = strchr(commit_msg, '.');
> return min_non_null(dot, paragraph_end); }
>
> would probably get it right very nearly always.
Counterexample (not even mentioning the missing handling of NULL):
http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
And no, the responsible developer showed a strong unwillingness to adapt
to better tools and workflows.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] More builtin-fetch fixes
From: Andreas Ericsson @ 2007-09-18 10:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <20070918085444.GN3099@spearce.org>
Shawn O. Pearce wrote:
> but for some of the really common cases we are quite
> happy with builtin-fetch. Especially its performance as we're
> seeing speedups of 25x or more on Cygwin/Windows.
>
Excellent news, and great job. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Johannes Schindelin @ 2007-09-18 10:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20070918072627.GB3506@coredump.intra.peff.net>
Hi,
On Tue, 18 Sep 2007, Jeff King wrote:
> This is based on the git-import.sh script, but is a little
> more robust and efficient. More importantly, it should
> serve as a quick template for interfacing fast-import with
> perl scripts.
Yes, please! Maybe somebody will then grab the low-hanging fruit of
writing a "git-fast-export", which can be used to dump a complete
repository in text format?
Ciao,
Dscho
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Andreas Ericsson @ 2007-09-18 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, Mike Hommey, git
In-Reply-To: <Pine.LNX.4.64.0709181109130.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Andreas Ericsson wrote:
>
>> const char *find_commit_subject_end(const char *commit_msg)
>> {
>> const char *dot, *paragraph_end;
>> paragraph_end = strstr(commit_msg, "\n\n");
>> dot = strchr(commit_msg, '.');
>> return min_non_null(dot, paragraph_end); }
>>
>> would probably get it right very nearly always.
>
> Counterexample (not even mentioning the missing handling of NULL):
>
Well, pseudo code doesn't have to handle NULL's, as it never gets bad
pseudo-input ;-)
> http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
>
> And no, the responsible developer showed a strong unwillingness to adapt
> to better tools and workflows.
>
Hmm, how about any interpunctuation char or newline followed by newline or
the first dot?
It would cover this case and not be overly hard to code.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Benoit SIGOURE @ 2007-09-18 10:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Mike Hommey, git
In-Reply-To: <Pine.LNX.4.64.0709181109130.28586@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Andreas Ericsson wrote:
>
>> const char *find_commit_subject_end(const char *commit_msg)
>> {
>> const char *dot, *paragraph_end;
>> paragraph_end = strstr(commit_msg, "\n\n");
>> dot = strchr(commit_msg, '.');
>> return min_non_null(dot, paragraph_end); }
>>
>> would probably get it right very nearly always.
>
> Counterexample (not even mentioning the missing handling of NULL):
>
> http://brick.kernel.dk/git/?
> p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
>
> And no, the responsible developer showed a strong unwillingness to
> adapt
> to better tools and workflows.
>
OK, look, I think this is the typical case where there is no single
solution to fit all use cases.
To handle this specific case, you could say "OK let's stop at
punctuation symbols then". But what if my commit message is "Add
namespace::member whatever."
If there is a single line followed by a blank line: it's a git-style
commit message, do what was done before.
Otherwise, we need some heuristic to find the relevant part of the
commit message (if there is such a relevant part in the first place!).
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Andreas Ericsson @ 2007-09-18 10:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709181115250.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 18 Sep 2007, Jeff King wrote:
>
>> This is based on the git-import.sh script, but is a little
>> more robust and efficient. More importantly, it should
>> serve as a quick template for interfacing fast-import with
>> perl scripts.
>
> Yes, please! Maybe somebody will then grab the low-hanging fruit of
> writing a "git-fast-export", which can be used to dump a complete
> repository in text format?
>
I thought that was already taken care of since format-patch handles
--root flag properly?
Otherwise, "git repack -a --window=0 --depth=0" should provide an
easily parseable dump of an entire repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Jeff King @ 2007-09-18 10:30 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <46EFA84C.3080906@op5.se>
On Tue, Sep 18, 2007 at 12:28:28PM +0200, Andreas Ericsson wrote:
>> Yes, please! Maybe somebody will then grab the low-hanging fruit of
>> writing a "git-fast-export", which can be used to dump a complete
>> repository in text format?
>
> I thought that was already taken care of since format-patch handles
> --root flag properly?
>
> Otherwise, "git repack -a --window=0 --depth=0" should provide an
> easily parseable dump of an entire repo.
I think he means a dump that you can meaningfully edit with sed or a
text editor. And even nicer, one that could be fed back into
git-fast-import. So you could do something like:
git-fast-export A..B >dump
vi dump
git-fast-import <dump
to rewrite history in a very flexible way.
-Peff
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Johannes Schindelin @ 2007-09-18 10:54 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Andreas Ericsson, Mike Hommey, git
In-Reply-To: <CEE6032F-39FB-42D8-A57A-671E4E0875C7@lrde.epita.fr>
Hi,
On Tue, 18 Sep 2007, Benoit SIGOURE wrote:
> On Sep 18, 2007, at 12:13 PM, Johannes Schindelin wrote:
>
> > On Tue, 18 Sep 2007, Andreas Ericsson wrote:
> >
> > > const char *find_commit_subject_end(const char *commit_msg)
> > > {
> > > const char *dot, *paragraph_end;
> > > paragraph_end = strstr(commit_msg, "\n\n");
> > > dot = strchr(commit_msg, '.');
> > > return min_non_null(dot, paragraph_end); }
> > >
> > > would probably get it right very nearly always.
> >
> > Counterexample (not even mentioning the missing handling of NULL):
> >
> > http://brick.kernel.dk/git/?p=qemu.git;a=commit;h=eb66d86e295cd5a8f13221589806e15db62a62fa
> >
> > And no, the responsible developer showed a strong unwillingness to adapt
> > to better tools and workflows.
> >
>
> OK, look, I think this is the typical case where there is no single solution
> to fit all use cases.
> To handle this specific case, you could say "OK let's stop at punctuation
> symbols then". But what if my commit message is "Add namespace::member
> whatever."
>
> If there is a single line followed by a blank line: it's a git-style commit
> message, do what was done before.
That's the current behaviour already. And has been for a long time.
> Otherwise, we need some heuristic to find the relevant part of the commit
> message (if there is such a relevant part in the first place!).
Or do we?
I was opposed to this change, since I think that there is really no way to
fit all exisiting (!) repositories.
And since oneline was always only meant as a hint, it might just as well
have stayed at "just one line, the first one".
Maybe you guys find a better method, such as providing a regular
expression in the config or something, but let's not do another change
that does not work for all cases.
Ciao,
Dscho
^ permalink raw reply
* [rfc] git submodules howto
From: Miklos Vajna @ 2007-09-18 10:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
hi,
i saw several "is there any step by step howto on how to use git
submodules?" question on irc, and as far as i think there is none
available at the moment
here is how i use it at the moment:
$ mkdir lib
$ cd lib
$ git init
Initialized empty Git repository in .git/
$ echo "libmakefile" > Makefile
$ dg add Makefile
$ git commit -m "libmakefile"
Created initial commit 57c1dce: libmakefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ cd ..
$ mkdir main
$ cd main
$ git init
Initialized empty Git repository in .git/
$ echo "main makefile" > Makefile
$ git add Makefile
$ git commit -m "main makefile"
Created initial commit 8935291: main makefile
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 Makefile
$ git submodule add ../lib lib
Initialized empty Git repository in /home/vmiklos/scm/git/sub/main/lib/.git/
0 blocks
$ git commit -m "added lib submodule"
Created commit 9dbfedf: added lib submodule
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 .gitmodules
create mode 160000 lib
$ cd ..
$ git clone main cloned
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/.git/
0 blocks
$ cd cloned
$ git submodule init
Submodule 'lib' (/home/vmiklos/scm/git/sub/lib/.git) registered for path 'lib'
$ git submodule update
Initialized empty Git repository in /home/vmiklos/scm/git/sub/cloned/lib/.git/
0 blocks
Submodule path 'lib': checked out '57c1dce0e083e9ee50d06111d6aa1523116c2e15'
$ cat Makefile
main makefile
$ cat lib/Makefile
libmakefile
my questions:
1) is this correct? :) i use it and it seem to do what i except, but
maybe it's not correct
2) does this worth adding to the documentation? maybe to a .txt under
Documentation/howto? or to git-submodule.txt?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox