* Re: [PATCH 3/5] Unify whitespace checking
From: Wincent Colaiuta @ 2007-12-14 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4taywfw.fsf@gitster.siamese.dyndns.org>
El 14/12/2007, a las 1:03, Junio C Hamano escribió:
>> - git diff --check | grep "space before tab"
>> + git diff --check | grep "Space in indent is followed by a tab"
>>
> Hmph. I think with the multiple detection this rewording would make
> the
> error message very long to read. Was the rewording really necessary?
Well, that wording came from builtin-apply.c so it wasn't really a "re-
wording" but an extraction. The other string comes from "diff.c". So I
had to pick one of them in unifying them and basically the one from
builtin-apply.c won because it was the site where I extracted from
first. So basically it was arbitrary.
If I were to actually *re-word* the message I think something like
this would be the compromise between clarity and conciseness:
"space before tab in indent"
And in the same spirit, the other two strings extracted from builtin-
apply.c into the new whitespace_error_string() function:
"Adds trailing whitespace"
"Indent more than 8 places with spaces"
Could be shortened to:
"trailing whitespace" (diff.c says "white space at end")
"indent using spaces"
But I personally have no strong conviction about this, so I'm happy
for it to be whatever you want.
>> +/* If stream is non-NULL, emits the line after checking. */
>> +unsigned check_and_emit_line(const char *line, int len, unsigned
>> ws_rule,
>> + FILE *stream, const char *set,
>> + const char *reset, const char *ws)
>> +{
>
> Honestly, I regretted suggesting this, fearing that it might make the
> checking too costly, but the code is clean, readable, and does not
> look
> costly at all. Nice job.
Thanks. The check_and_emit_line function itself is fairly clean
internally (apart from the somewhat ugly parameter list, but that was
mostly inherited from the emit_line_with_ws function which it
replaces). It's the sites where check_and_emit_line is called that
look a bit ugly, but those can hopefully be cleaned up at some point
in the future.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Don't use the pager when running "git diff --check"
From: Wincent Colaiuta @ 2007-12-14 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmysdx3la.fsf@gitster.siamese.dyndns.org>
El 14/12/2007, a las 6:11, Junio C Hamano escribió:
> Jeff King <peff@peff.net> writes:
>
>> On Thu, Dec 13, 2007 at 08:45:38PM +0100, Wincent Colaiuta wrote:
>>
>>> In 89d07f75 "git diff" learnt to not run the pager if the user
>>> passes
>>> the --exit-code switch. This commit does the same for the --check
>>> switch for the same reason: we want the user to get the exit status
>>> from "git diff", not the pager.
>>
>> But --check is also producing useful output, which might need
>> paged. So
>> you are sacrificing existing interactive use of --check for
>> scriptable
>> exit-code uses. If you really want the exit code, why not "git diff
>> --check --exit-code"?
>>
>> OTOH, I am not too sad to lose the paging behavior; it would take
>> quite
>> a few whitespace errors to scroll off the screen.
>
> You are right. While I do not personally miss paging output, it is a
> regression not to page --check output by default.
I thought this was ok because "git diff --exit-code" also produces
useful output and also turns off the pager.
> By the way, there is no reason to make --check and --exit-code
> mutually
> exclusive either. You could say with --exit-code the command will
> exit
> with status 01 or'ed in if trees are not identical, and with --check
> the
> command will exit with status 02 or'ed in.
Yes, this sounds fine to me.
Cheers,
Wincent
^ permalink raw reply
* Re: git merge --no-commit <branch>; does commit
From: Alex Riesen @ 2007-12-14 7:49 UTC (permalink / raw)
To: Michael Dressel; +Cc: git
In-Reply-To: <alpine.LSU.0.99999.0712132224280.5606@castor.milkiway.cos>
Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:
> On Thu, 13 Dec 2007, Alex Riesen wrote:
>> On 13/12/2007, Michael Dressel <MichaelTiloDressel@t-online.de> wrote:
>>> git merge --no-commit <branch> does "create" a commit. At lesat the
>>> head and index are moved to the new commit fetched from <branch>. Maybe
>>> that is because git was able to do a fast forward?
>>
>> Yes. Because fast-forward is what it called: fast-forward.
>> It does not do any commits at all.
>>
>
> It looks like I misunderstood the meaning of --no-commit. I have to use
> --squash in this case.
>
Maybe. Or maybe you misunderstood the meaning of --squash, which also
is not a merge.
^ permalink raw reply
* Re: [PATCH] Don't use the pager when running "git diff --check"
From: Wincent Colaiuta @ 2007-12-14 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7bxu3w5.fsf@gitster.siamese.dyndns.org>
El 14/12/2007, a las 8:33, Junio C Hamano escribió:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> By the way, there is no reason to make --check and --exit-code
>> mutually
>> exclusive either.
>
> Perhaps something like this. Regardless of the exclusivity issue, I
> think the "diff_result_code()" helper function is a good clean-up.
Totally agreed. It replaces some groups of very-similar lines.
I'll integrate these (and the other suggestions) some time this
morning and post a new version of the series that incorporates all the
feedback and patch suggestions.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Don't use the pager when running "git diff --check"
From: Junio C Hamano @ 2007-12-14 7:57 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Jeff King, git
In-Reply-To: <5A086A2E-16DB-4A3C-92E6-F879189A87FE@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> I'll integrate these (and the other suggestions) some time this
> morning and post a new version of the series that incorporates all the
> feedback and patch suggestions.
Heh, I am about to push out fixed-up results, so it might save both of
us some time if you looked at it first and then complained on my
screwups.
^ permalink raw reply
* Re: [PATCH] Authentication support for pserver
From: Junio C Hamano @ 2007-12-14 8:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, martyn, martin
In-Reply-To: <87mysdepeh.fsf@cpan.org>
avar@cpan.org (Ævar Arnfjörð Bjarmason) writes:
> diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
> index 258a62f..5ca84fc 100644
> --- a/Documentation/git-cvsserver.txt
> +++ b/Documentation/git-cvsserver.txt
Looks good. I'll queue only so that I won't lose it and wait for Acks
from Mart[iy]ns. Please sign off your patch.
Thanks.
^ permalink raw reply
* Re: git-svn: expand handling of From: and Signed-off-by:
From: Junio C Hamano @ 2007-12-14 8:21 UTC (permalink / raw)
To: Eric Wong; +Cc: Andy Whitcroft, git
In-Reply-To: <20071213163253.GC18433@soma>
Eric Wong <normalperson@yhbt.net> writes:
> Some minor whitespace damage (which Junio can fix up), but
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Thanks Andy.
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] git-svn: unlink internal index files after operations
From: Eric Wong @ 2007-12-14 8:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20071213202757.GA2387@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-13 08:27:34 -0800, Eric Wong wrote:
>
> > Being git, we can generate these very quickly on the fly as needed,
> > so there's no point in wasting space for these things for large
> > projects.
>
> Excellent!
>
> For existing repos, I assume the correct thing to do is to just blast
> all the existing index files manually?
Yes. index files inside $GIT_DIR/svn have always been safely deletable
(except while a git-svn is actually running :).
I'll probably work on an automated full migration strategy at some
point (handling rev_db => rev_map, mainly) when I have time.
--
Eric Wong
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Andreas Ericsson @ 2007-12-14 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Kristian Høgsberg, Pierre Habouzit, git
In-Reply-To: <7vir31vmsn.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> I agree. I am already a little bit uncomfortable with the "--abbrev 10"
>> won't work but "--foo 10" will, because it requires that the user
>> remember which arguments are optional and which are required. But
>> switching it to "--abbrev 10 works, but --abbrev $foo does not, unless
>> of course $foo is an integer, in which case you must use --abbrev=$foo"
>> is just a little bit too DWIM. E.g., if you are scripting, it's just one
>> more source of error (if I have $foo, how must I write --abbrev $foo for
>> it to ensure that I _don't_ trigger the optional argument?).
>
> Oh, there is no question that scripted callers need a way to safely
> disambiguate, and be able to call "git cmd" with always the default
> abbreviation for whatever $foo it gets from the user unambiguously.
>
> I do not disagree with that.
>
> But that is different from making it harder for end users (not scripters
> but command line users).
>
> Again, I am not saying that my suggested alternative is superiour; I
> just threw it out to as an example of a different approach to achieve
> disambiguation than the "some flags must have its parameter stuck with
> it, some don't" behaviour, which will surely be confusing to the command
> line end users.
>
> To contrast the two, with Pierre's, if you want $n-digit abbreviations
> and $cnt-lines of output in your script, your script would say:
>
> git cmd --abbrev=$n -n $cnt $foo
>
> because you as a script writer are required to know --abbrev is such a
> magic flag that take optional parameter and cannot be fed as two options
> (you can also write "-n=$cnt", but I am talking about --abbrev part).
>
> If you are accepting the default abbreviation, on the other hand:
>
> git cmd --abbrev -n $cnt $foo
>
> which looks nice. The latter needs to be written in a funky way:
>
> git cmd --abbrev= $foo
>
> if we take "empty parameter to a flag that take optional parameter means
> use the default setting"; we could introduce a magic 'default' token to
> read it slightly better:
>
> git cmd --abbrev=default $foo
>
> but that does not change the fact that it makes it harder for
> scripters. I do not disagree with that.
>
> The command line end users, who want to do the same, but has a bit more
> concrete than unknown $n, $cnt, or $foo, can do
>
> git cmd --abbrev HEAD~4
>
> in either approach. However, with Pierre's, the command line end users
> can say either:
>
> git cmd --abbrev=10 -n=4
> git cmd --abbrev=10 -n 4
> git cmd --abbrev=10 -n4
>
> but they cannot say:
>
> git cmd --abbrev 10 -n 4
>
> They need to learn the difference between --abbrev and -n, because you
> avoid DWIMmery for the sake of script writers. I have a slight
> suspicion that it is backwards.
>
> If there is _no_ existing users and previous versions of git, one
> plausible alternative that would be much cleaner than anything we
> discussed so far would be to always require '-n=4' (or "-n4") form and
> never accept "-n 4", even for a flag that takes mandatory parameter.
> Then there is no room for confusion. Users (both command line end users
> and script writers) need to learn only one rule: flag parameters are
> always with the flag, not given as two words.
>
> I really wish the world were that simple, but I do no think that would
> fly well with the existing users' fingers.
I think you're right in that last sentence. It would also be terribly
inconsistent with the other 3000 or so command-line programs one has
in ones path.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFH] convert shortlog to use parse_options
From: Pierre Habouzit @ 2007-12-14 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Kristian Høgsberg, git
In-Reply-To: <7vir31vmsn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
On Fri, Dec 14, 2007 at 05:59:52AM +0000, Junio C Hamano wrote:
> git cmd --abbrev=10 -n=4
actually -n=4 isn't understood atm, only -n4 and -n 4 are.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Something is broken in repack
From: Paolo Bonzini @ 2007-12-14 8:20 UTC (permalink / raw)
To: gcc; +Cc: git
In-Reply-To: <fcaeb9bf0712132224u54ca845ap4836dfe1cda37b29@mail.gmail.com>
> I'm thinking about "git clone --keep" to mark initial packs precious.
> But 'git clone' is under rewrite to C. Let's wait until C rewrite is
> done.
It should be the default, IMHO.
Paolo
^ permalink raw reply
* Re: git-send-email doesn't like me+git ML
From: Andreas Ericsson @ 2007-12-14 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <20071214014753.GB8914@fawkes>
Jing Xue wrote:
> OK, this is bewildering. I tried a couple of times sending a trivial
> patch (the one that makes git-stash show keep quiet when there aren't
> any stashes), but it never made it to the list every time I used
> git-send-email, yet as soon as I did it as a regular email, i.e.,
> starting a new message in mutt, pasting the patch into the body, and
> sending it, it worked just fine.
>
> My mail log shows the mails (the one thru git-send-email) went out just
> fine. And it always worked when I tried to use git-send-email to send
> the patch to my gmail address. It just doesn't work with the list - and
> that obviously can't be. 8-)
>
I've had similar problems. I think it's actually a filtering issue on the
receiving end though, as some seem to see the mails on the list (while
most don't). Looking at the headers, I see the hostname of my laptop as
originating host when using git-send-email, which obviously will fail
for any receiving host that tries to connect back to verify that the
originating sender is indeed a real SMTP server.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [RFH] Multiple repository for mult-module project
From: Imran M Yousuf @ 2007-12-14 8:58 UTC (permalink / raw)
To: git
Hi,
I have a project that has started recently and has 7 modules and as
days pass by the number of modules will only increase. Currently I am
using SVN and I am so impressed with GIT's concept and Linus's
presentation at Google that I want to use GIT but as the rest of the
team wants to use SVN I guess I will have do it GIT with SVN. I want
to create separate repositories for each modules and then group them
under a master module which I am calling project. In this regard I
would also like to mention that the whole project gets syncd with a
SVN server as mentioned earlier. Can someone please point me to any
article/blog or link where I can learn
on how to do it. If someone would take time to explain the how-to over
email that is also fine by me :).
Thank you & best regards,
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
^ permalink raw reply
* Re: Something is broken in repack
From: Harvey Harrison @ 2007-12-14 9:01 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: gcc, git
In-Reply-To: <fjtect$8qn$1@ger.gmane.org>
On Fri, 2007-12-14 at 09:20 +0100, Paolo Bonzini wrote:
> > I'm thinking about "git clone --keep" to mark initial packs precious.
> > But 'git clone' is under rewrite to C. Let's wait until C rewrite is
> > done.
>
> It should be the default, IMHO.
>
While it doesn't mark the packs as .keep, git will reuse all of the old
deltas you got in the original clone, so you're not losing anything.
Harvey
^ permalink raw reply
* Re: [PATCH 2/2] xdi_diff: trim common trailing lines
From: Peter Baumann @ 2007-12-14 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vmysez0oa.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 13, 2007 at 02:31:49PM -0800, Junio C Hamano wrote:
> This implements earlier Linus's optimization to trim common lines at the
> end before passing them down to low level xdiff interface for all of our
> xdiff users.
>
> We could later enhance this to also trim common leading lines, but that
> would need tweaking of the output function to add the number of lines
> trimmed at the beginning to line numbers that appear in the hunk
> headers.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> xdiff-interface.c | 34 +++++++++++++++++++++++++++++++++-
> 1 files changed, 33 insertions(+), 1 deletions(-)
>
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 69a022c..f2cd488 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -103,9 +103,41 @@ int xdiff_outf(void *priv_, mmbuffer_t *mb, int nbuf)
> return 0;
> }
>
> +/*
> + * Trim down common substring at the end of the buffers,
> + * but leave at least ctx lines at the end.
> + */
> +static void trim_common_tail(mmfile_t *a, mmfile_t *b, int ctx)
Should ctx be a long? (see comment below)
> +{
> + const int blk = 1024;
> + long trimmed = 0, recovered = 0;
> + int i;
> + char *ap = a->ptr + a->size;
> + char *bp = b->ptr + b->size;
> + long smaller = (a->size < b->size) ? a->size : b->size;
> +
> + while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
> + trimmed += blk;
> + ap -= blk;
> + bp -= blk;
> + }
> +
> + for (i = 0, recovered = 0; recovered < trimmed && i <= ctx; i++) {
> + while (recovered < trimmed && ap[recovered] != '\n')
> + recovered++;
> + }
> + a->size -= (trimmed - recovered);
> + b->size -= (trimmed - recovered);
> +}
> +
> int xdi_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp, xdemitconf_t const *xecfg, xdemitcb_t *xecb)
> {
> - return xdl_diff(mf1, mf2, xpp, xecfg, xecb);
> + mmfile_t a = *mf1;
> + mmfile_t b = *mf2;
> +
> + trim_common_tail(&a, &b, xecfg->ctxlen);
xdemitconf_t has the following definition
typedef struct s_xdemitconf {
long ctxlen;
unsigned long flags;
find_func_t find_func;
void *find_func_priv;
} xdemitconf_t;
So you are loosing some values in your trim_common_tail function by making ctx
only an int. (Not sure that it matters, but I noticed it while glancing over
your code).
> +
> + return xdl_diff(&a, &b, xpp, xecfg, xecb);
> }
>
> int read_mmfile(mmfile_t *ptr, const char *filename)
-Peter
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Jeff King @ 2007-12-14 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Markus Klinik, git
In-Reply-To: <20071214044554.GB10169@sigill.intra.peff.net>
On Thu, Dec 13, 2007 at 11:45:54PM -0500, Jeff King wrote:
> So it seems that we could probably go with something more like 64K, and
> then only truly pathological cases should trigger the behavior.
So here is a cleaned up patch. It bumps the maximum size to 64kB, adds
scalar support (nobody uses it, but it makes sense for the interface to
match that of safe_pipe_capture -- I am even tempted to just replace
safe_pipe_capture entirely and convert the few other callers), and
cleans up the unused safe_pipe_capture_blob.
-- >8 --
cvsexportcommit: fix massive commits
Because we feed the changed filenames to CVS on the command
line, it was possible for massive commits to overflow the
system exec limits. Instead, we now do an xargs-like split
of the arguments.
This means that we lose some of the atomicity of calling CVS
in one shot. Since CVS commits are not atomic, but the CVS
protocol is, the possible effects of this are not clear;
however, since CVS doesn't provide a different interface,
this is our only option for large commits (short of writing
a CVS client library).
The argument size limit is arbitrarily set to 64kB. This
should be high enough to trigger only in rare cases where it
is necessary, so normal-sized commits are not affected by
the atomicity change.
---
I think the atomicity might matter if you are using cvsexportcommit to
talk to a CVS server backed by something besides CVS, like
git-cvsserver. Which of course would be useless, but who is to say
that other such systems don't exist with CVS as an SCM lingua franca?
git-cvsexportcommit.perl | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 92e4162..d2e50c3 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -195,11 +195,11 @@ foreach my $f (@files) {
my %cvsstat;
if (@canstatusfiles) {
if ($opt_u) {
- my @updated = safe_pipe_capture(@cvs, 'update', @canstatusfiles);
+ my @updated = xargs_safe_pipe_capture([@cvs, 'update'], @canstatusfiles);
print @updated;
}
my @cvsoutput;
- @cvsoutput= safe_pipe_capture(@cvs, 'status', @canstatusfiles);
+ @cvsoutput = xargs_safe_pipe_capture([@cvs, 'status'], @canstatusfiles);
my $matchcount = 0;
foreach my $l (@cvsoutput) {
chomp $l;
@@ -295,7 +295,7 @@ if ($dirtypatch) {
if ($opt_c) {
print "Autocommit\n $cmd\n";
- print safe_pipe_capture(@cvs, 'commit', '-F', '.msg', @files);
+ print xargs_safe_pipe_capture([@cvs, 'commit', '-F', '.msg'], @files);
if ($?) {
die "Exiting: The commit did not succeed";
}
@@ -335,15 +335,24 @@ sub safe_pipe_capture {
return wantarray ? @output : join('',@output);
}
-sub safe_pipe_capture_blob {
- my $output;
- if (my $pid = open my $child, '-|') {
- local $/;
- undef $/;
- $output = (<$child>);
- close $child or die join(' ',@_).": $! $?";
- } else {
- exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
- }
- return $output;
+sub xargs_safe_pipe_capture {
+ my $MAX_ARG_LENGTH = 65536;
+ my $cmd = shift;
+ my @output;
+ my $output;
+ while(@_) {
+ my @args;
+ my $length = 0;
+ while(@_ && $length < $MAX_ARG_LENGTH) {
+ push @args, shift;
+ $length += length($args[$#args]);
+ }
+ if (wantarray) {
+ push @output, safe_pipe_capture(@$cmd, @args);
+ }
+ else {
+ $output .= safe_pipe_capture(@$cmd, @args);
+ }
+ }
+ return wantarray ? @output : $output;
}
--
1.5.4.rc0.1088.g8a30-dirty
^ permalink raw reply related
* git-browse-help?
From: Jeff King @ 2007-12-14 9:28 UTC (permalink / raw)
To: Christian Couder; +Cc: git
The new 'git-browse-help' seems to purely be a helper script for "git
help" (judging from the commit messages and the lack of documentation).
Should it perhaps be "git--browse-help" or "git-help--browse" to follow
our "this is not for users" convention (see add--interactive,
fetch--tool, and rebase--interactive).
I became aware of it because "br" used to tab-complete "branch" but now
doesn't. :) And if we're going to change it, pre-1.5.4 is the time.
-Peff
^ permalink raw reply
* Re: [PATCH 2/5] New version of pre-commit hook
From: Jakub Narebski @ 2007-12-14 10:23 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <06C937AD-24B3-496B-AE76-B63CA007BEBB@wincent.com>
Dnia piątek 14. grudnia 2007 08:24, Wincent Colaiuta napisał:
> El 14/12/2007, a las 1:17, Jakub Narebski escribió:
>
>> Wincent Colaiuta wrote:
>>
>>> Now that "git diff --check" indicates problems with its exit code the
>>> pre-commit hook becomes a trivial one-liner.
>>
>>> - if (/^(?:[<>=]){7}/) {
>>> - bad_line("unresolved merge conflict", $_);
>>> - }
>>
>> Aren't you losing this check with rewrite?
>
> Yes. If that's a problem then this is definitely a "no-goer".
Well, this only means that it wouldn't be one-liner, but replacing
all whitespace damage checks by "git diff --check" is still a good
idea.
Perhaps we could add 'merge conflict' check to git diff/git applyt too...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Something is broken in repack
From: Jakub Narebski @ 2007-12-14 10:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Paolo Bonzini, git, gcc
In-Reply-To: <fcaeb9bf0712132224u54ca845ap4836dfe1cda37b29@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On Dec 14, 2007 1:14 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> > > Hmmm... it is even documented in git-gc(1)... and git-index-pack(1) of
> > > all things.
> >
> > I found that the .keep file is not transmitted over the network (at
> > least I tried with git+ssh:// and http:// protocols), however.
>
> I'm thinking about "git clone --keep" to mark initial packs precious.
> But 'git clone' is under rewrite to C. Let's wait until C rewrite is
> done.
But if you clone via network, pack might be network optimized if you
use "smart" transport, not disk optimized, at least with current git
which regenerates pack also on clone AFAIK.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Something is broken in repack
From: Nguyen Thai Ngoc Duy @ 2007-12-14 10:52 UTC (permalink / raw)
To: Jakub Narebski, Harvey Harrison; +Cc: Paolo Bonzini, git, gcc
In-Reply-To: <m3odctr245.fsf@roke.D-201>
On Dec 14, 2007 4:01 PM, Harvey Harrison <harvey.harrison@gmail.com> wrote:
> While it doesn't mark the packs as .keep, git will reuse all of the old
> deltas you got in the original clone, so you're not losing anything.
There is another reason I want it. I have an ~800MB pack and I don't
want git to rewrite the pack every time I repack my changes. So it's
kind of disk-wise (don't require 800MB on disk to prepare new pack,
and don't write too much).
On Dec 14, 2007 5:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> But if you clone via network, pack might be network optimized if you
> use "smart" transport, not disk optimized, at least with current git
> which regenerates pack also on clone AFAIK.
Um.. that's ok it just regenerate once.
--
Duy
^ permalink raw reply
* [StGit PATCH 00/17] Series short description
From: David Kågedal @ 2007-12-14 10:55 UTC (permalink / raw)
To: catalin.marinas, git
The following series an emacs interface to stgit patch stacks. It
shows a buffer with the the output of "stg series" and allows you to
do some common operations on it, such as push/pop, commit/uncommit,
edit, rename, repair, and coalesce.
The coalesce command obviosly requires the kha/experimental branch.
The edit command requires the edit fixes in kha/safe.
---
David Kågedal (10):
Emacs mode: coalesce command
Emacs mode: Add mark command
Emacs mode: Added stgit-new
Emacs mode: added fontification
Emacs mode: Add stgit-edit command
Emacs mode: added stgit-commit and stgit-uncommit
Emacs mode: add stgit-repair
Emacs mode: Bind n and p
Emacs mode: Improve the output buffer state
Add an StGit mode for emacs
Karl Hasselström (7):
Emacs mode: show patches' short description
Emacs mode: Bind "G" to "stg goto"
Emacs mode: Let "P" push or pop patch at point
Emacs mode: push/pop next patch, not patch at point
Emacs mode: Makefile for building stgit.el
Emacs mode: Add an explanatory header
Emacs mode: Show keybindings when user presses "h" or "?"
contrib/Makefile | 19 +++
contrib/stgit.el | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 396 insertions(+), 0 deletions(-)
create mode 100644 contrib/Makefile
create mode 100644 contrib/stgit.el
--
Signature
^ permalink raw reply
* [StGit PATCH 01/17] Add an StGit mode for emacs
From: David Kågedal @ 2007-12-14 10:55 UTC (permalink / raw)
To: catalin.marinas, git
In-Reply-To: <20071214105238.18066.23281.stgit@krank>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
contrib/stgit.el | 141 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 141 insertions(+), 0 deletions(-)
create mode 100644 contrib/stgit.el
diff --git a/contrib/stgit.el b/contrib/stgit.el
new file mode 100644
index 0000000..1bdc0a5
--- /dev/null
+++ b/contrib/stgit.el
@@ -0,0 +1,141 @@
+(defun stgit (dir)
+ "Manage stgit patches"
+ (interactive "DDirectory: \n")
+ (switch-to-stgit-buffer dir)
+ (stgit-refresh))
+
+(defun switch-to-stgit-buffer (dir)
+ "Switch to a (possibly new) buffer displaying StGit patches for DIR"
+ (setq dir (file-name-as-directory dir))
+ (let ((buffers (buffer-list)))
+ (while (and buffers
+ (not (with-current-buffer (car buffers)
+ (and (eq major-mode 'stgit-mode)
+ (string= default-directory dir)))))
+ (setq buffers (cdr buffers)))
+ (switch-to-buffer (if buffers
+ (car buffers)
+ (create-stgit-buffer dir)))))
+
+(defun create-stgit-buffer (dir)
+ "Create a buffer for showing StGit patches.
+Argument DIR is the repository path."
+ (let ((buf (create-file-buffer (concat dir "*stgit*")))
+ (inhibit-read-only t))
+ (with-current-buffer buf
+ (setq default-directory dir)
+ (stgit-mode)
+ (setq buffer-read-only t))
+ buf))
+
+(defmacro stgit-capture-output (name &rest body)
+ "Capture StGit output and show it in a window at the end"
+ `(let ((output-buf (get-buffer-create ,(or name "*StGit output*"))))
+ (with-current-buffer output-buf
+ (erase-buffer))
+ (let ((standard-output output-buf))
+ ,@body)
+ (if (with-current-buffer output-buf (< (point-min) (point-max)))
+ (display-buffer output-buf t))))
+(put 'stgit-capture-output 'lisp-indent-function 1)
+
+(defun stgit-run (&rest args)
+ (apply 'call-process "stg" nil standard-output nil args))
+
+(defun stgit-refresh ()
+ "Update the contents of the stgit buffer"
+ (interactive)
+ (let ((inhibit-read-only t)
+ (curline (line-number-at-pos))
+ (curpatch (stgit-patch-at-point)))
+ (erase-buffer)
+ (insert "Branch: ")
+ (stgit-run "branch")
+ (stgit-run "series")
+ (if curpatch
+ (stgit-goto-patch curpatch)
+ (goto-line curline))))
+
+(defvar stgit-mode-hook nil
+ "Run after `stgit-mode' is setup.")
+
+(defvar stgit-mode-map nil
+ "Keymap for StGit major mode.")
+
+(unless stgit-mode-map
+ (setq stgit-mode-map (make-keymap))
+ (suppress-keymap stgit-mode-map)
+ (define-key stgit-mode-map "g" 'stgit-refresh)
+ (define-key stgit-mode-map "r" 'stgit-rename)
+ (define-key stgit-mode-map ">" 'stgit-push-next)
+ (define-key stgit-mode-map "<" 'stgit-pop)
+ (define-key stgit-mode-map "=" 'stgit-show))
+
+(defun stgit-mode ()
+ "Major mode for interacting with StGit.
+Commands:
+\\{stgit-mode-map}"
+ (kill-all-local-variables)
+ (buffer-disable-undo)
+ (setq mode-name "StGit"
+ major-mode 'stgit-mode
+ goal-column 2)
+ (use-local-map stgit-mode-map)
+ (set (make-local-variable 'list-buffers-directory) default-directory)
+ (run-hooks 'stgit-mode-hook))
+
+(defun stgit-patch-at-point ()
+ "Return the patch name on the current line"
+ (save-excursion
+ (beginning-of-line)
+ (if (looking-at "[>+-] \\(.*\\)")
+ (match-string 1)
+ nil)))
+
+(defun stgit-goto-patch (patch)
+ "Move point to the line containing PATCH"
+ (let ((p (point)))
+ (goto-char (point-min))
+ (if (re-search-forward (concat "[>+-] " (regexp-quote patch) "$") nil t)
+ (progn (move-to-column goal-column)
+ t)
+ (goto-char p)
+ nil)))
+
+(defun stgit-rename (name)
+ "Rename the patch under point"
+ (interactive (list (read-string "Patch name: " (stgit-patch-at-point))))
+ (let ((old-name (stgit-patch-at-point)))
+ (unless old-name
+ (error "No patch on this line"))
+ (stgit-capture-output nil
+ (stgit-run "rename" old-name name))
+ (stgit-refresh)
+ (stgit-goto-patch name)))
+
+(defun stgit-push-next ()
+ "Push the patch on the line after pos"
+ (interactive)
+ (forward-line 1)
+ (let ((patch (stgit-patch-at-point)))
+ (stgit-capture-output nil
+ (stgit-run "push" patch))
+ (stgit-refresh)))
+
+(defun stgit-pop ()
+ "Pop the patch on the current line"
+ (interactive)
+ (let ((patch (stgit-patch-at-point)))
+ (stgit-capture-output nil
+ (stgit-run "pop" patch))
+ (stgit-refresh)
+ (previous-line)))
+
+(defun stgit-show ()
+ "Show the patch on the current line"
+ (interactive)
+ (stgit-capture-output "*StGit patch*"
+ (stgit-run "show" (stgit-patch-at-point))
+ (with-current-buffer standard-output
+ (goto-char (point-min))
+ (diff-mode))))
^ permalink raw reply related
* [StGit PATCH 02/17] Emacs mode: Show keybindings when user presses "h" or "?"
From: David Kågedal @ 2007-12-14 10:56 UTC (permalink / raw)
To: catalin.marinas, git
In-Reply-To: <20071214105238.18066.23281.stgit@krank>
From: Karl Hasselström <kha@treskal.com>
These are the same keys the git emacs mode uses.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/stgit.el | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index 1bdc0a5..09dec8b 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -65,6 +65,8 @@ Argument DIR is the repository path."
(unless stgit-mode-map
(setq stgit-mode-map (make-keymap))
(suppress-keymap stgit-mode-map)
+ (define-key stgit-mode-map "?" 'stgit-help)
+ (define-key stgit-mode-map "h" 'stgit-help)
(define-key stgit-mode-map "g" 'stgit-refresh)
(define-key stgit-mode-map "r" 'stgit-rename)
(define-key stgit-mode-map ">" 'stgit-push-next)
@@ -139,3 +141,8 @@ Commands:
(with-current-buffer standard-output
(goto-char (point-min))
(diff-mode))))
+
+(defun stgit-help ()
+ "Display help for the StGit mode."
+ (interactive)
+ (describe-function 'stgit-mode))
^ permalink raw reply related
* [StGit PATCH 03/17] Emacs mode: Add an explanatory header
From: David Kågedal @ 2007-12-14 10:56 UTC (permalink / raw)
To: catalin.marinas, git
In-Reply-To: <20071214105238.18066.23281.stgit@krank>
From: Karl Hasselström <kha@treskal.com>
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/stgit.el | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index 09dec8b..cce0c0e 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -1,3 +1,14 @@
+;; stgit.el: An emacs mode for StGit
+;;
+;; Copyright (C) 2007 David Kågedal <davidk@lysator.liu.se>
+;;
+;; To install: put this file on the load-path and place the following
+;; in your .emacs file:
+;;
+;; (require 'stgit)
+;;
+;; To start: `M-x stgit'
+
(defun stgit (dir)
"Manage stgit patches"
(interactive "DDirectory: \n")
@@ -146,3 +157,5 @@ Commands:
"Display help for the StGit mode."
(interactive)
(describe-function 'stgit-mode))
+
+(provide 'stgit)
^ permalink raw reply related
* [StGit PATCH 04/17] Emacs mode: Makefile for building stgit.el
From: David Kågedal @ 2007-12-14 10:57 UTC (permalink / raw)
To: catalin.marinas, git
In-Reply-To: <20071214105238.18066.23281.stgit@krank>
From: Karl Hasselström <kha@treskal.com>
Shamelessly stolen from git's contrib/emacs/Makefile.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/Makefile | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 contrib/Makefile
diff --git a/contrib/Makefile b/contrib/Makefile
new file mode 100644
index 0000000..8556910
--- /dev/null
+++ b/contrib/Makefile
@@ -0,0 +1,19 @@
+EMACS = emacs
+
+ELC = stgit.elc
+INSTALL ?= install
+INSTALL_ELC = $(INSTALL) -m 644
+prefix ?= $(HOME)
+emacsdir = $(prefix)/share/emacs/site-lisp
+RM ?= rm -f
+
+all: $(ELC)
+
+install: all
+ $(INSTALL) -d $(DESTDIR)$(emacsdir)
+ $(INSTALL_ELC) $(ELC:.elc=.el) $(ELC) $(DESTDIR)$(emacsdir)
+
+%.elc: %.el
+ $(EMACS) -batch -f batch-byte-compile $<
+
+clean:; $(RM) $(ELC)
^ permalink raw reply related
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