* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-05 10:11 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta, Git Mailing List
In-Reply-To: <47060BB3.3030208@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Yes, but it's so enormously powerful once you get a grip on it that I can't
> for the life of me imagine an scm system without it. You just can't do
> "scm commit --interactive" without it in a sane way,
darcs|hg record do a very similar job. The real difference between
darcs and others here is not "scm commit --interactive", but the fact
that you can split the work among multiple commands, the index
maintains a persistant state.
> or check which merge- conflicts you've already resolved,
At least bzr and baz have this kind of conflict management. It's just
a separate file, containing the list of unresolved conflicts.
> or compare working tree with what the next commit *will* look like,
To me, *that* is the point.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 10:08 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, gitster
In-Reply-To: <1191447902-27326-1-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Wed, Oct 03, 2007 at 09:45:01PM +0000, Kristian Høgsberg wrote:
> +static int parse_one(const char **argv,
> + struct option *options, int count,
> + const char *usage_string)
> +{
> + const char *eq, *arg, *value;
> + int i, processed;
gcc complains processed could be returned without being initialized
first, so should be processed = 0; Even if it cannot occurs, it avoid
raising eyebrows.
> + case OPTION_INTEGER:
> + if (value == NULL) {
> + error("option %s requires a value.", argv);
^^^
should probably be arg.
--
·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: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 10:02 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4d8e3fd30710050206h7a177472x7c92f91204b15aa4@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
>> Paolo Ciarrocchi wrote:
>>> On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>>>>
>>>>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
>>>>>>> Am I wrong?
>>>>>> About it being a majority, yes, I suspect so.
>>>>>>
>>>>> Maybe in the next survey we should include question "do you usually do
>>>>> 'git commit' or 'git commit -a'" :-)
>>>> Not meaning to discourage you, but it is a known fact that Linus does "git
>>>> commit" without "-a" quite often.
>>>>
>>>> And if that were not bad enough for your plan, I myself omit "-a"
>>>> regularly. So you would get a veto from me, too.
>>> So you are used to do something like (please correct me if I'm wrong):
>>> - modify A
>>> - modify B
>>> - modify C
>>> - modify D
>>> - modify E
>>>
>
>>> $ git add A B E (A, B and E are now in the staging area)
>>> $ git commit -m "I just modified A,B and E"
>> I do something like that, except that for full-file commits I'd rather
>> say
>>
>> git commit -s A B E
>>
>> I never pass -m to git commit. It's too easy to get into habit of being
>> sloppy with historic documentation that way.
>
> Right.
> But in the scenario you described isn't enough to type "git commit -s".
> Why did you write "git commit -s A B E".
>
Because that way I don't have to do "git add A B E" first.
>
>>> $ git add C D (C and D are now in the staging area)
>>> $ git commit -m "I just modified C and D"
>>>
>> See above :)
>>
>> There's also the times when I hack on some feature and find some small
>> bug/easy-to-write-feature, so I make the change for that other thing,
>> swap to a different branch and do 'git commit -s --interactive' to
>> just break out that small fix.
>>
>> Or if I have to add some logic to some other function in a file I've
>> modified for other purposes and want it to be two separate commits,
>> I just make the change and then run 'git commit --interactive' to
>> make it two separate commits.
>
> Very interesting!
>
>> I just don't do 'git commit -a' for the same reason I don't do
>> 'git commit -m', really. It tends to be habit-forming, and bisect
>> has saved my arse enough times for me to *want* my changes to be
>> small and isolated. Debugging a 5-line patch is so much more pleasant
>> than debugging a 30k-lines one that spans over several different files.
>
> Yeah, I see.
> Thanks for your comments Andreas, very appreciated.
>
> Just to clarify my goal, since I had that interesting discussion with
> an hg user I started looking for simple examples of the usage of the
> "staging area" to be added to the introduction to git documentation.
> The role of the index/staging area seems to be something complex for a
> git newbie.
>
Yes, but it's so enormously powerful once you get a grip on it that I can't
for the life of me imagine an scm system without it. You just can't do
"scm commit --interactive" without it in a sane way, or check which merge-
conflicts you've already resolved, or compare working tree with what the
next commit *will* look like, or... The list goes on. Like I said, it's so
immensely powerful that all the things you can do when you have one is, all
by itself, reason enough to switch from any other scm to git.
As for the "git commit should default to -a" discussion, I think it's pretty
clear where I stand ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: stgit: editing description of patch
From: Catalin Marinas @ 2007-10-05 9:16 UTC (permalink / raw)
To: git
In-Reply-To: <20071004173929.GD21717@diana.vm.bytemark.co.uk>
(for whatever reason, gnus decided that it no longer likes the
authenticated SMTP server, so I'm trying to post via gmane).
On Thu, 04 Oct 2007 19:39:29 +0200, Karl Hasselström wrote:
> On 2007-10-04 12:45:17 -0400, Jon Smirl wrote:
>
>> Why are the patch name and the short description independent
>> variables? Wouldn't it make more sense to treat these as a single
>> unified item? If I rename the patch it would automatically edit the
>> first line of the description, etc...
>
> I guess Catalin would have to answer that -- it's "always" been like
> that. But one obvious problem are patches with identical messages --
> just today I created a series of seven patches that all had "debug"
> for a message. Another is that you usually want descriptive commit
> messages, but may want short and easy-to-type patch names.
That's pretty much the case. There are also the historical reasons (quilt
does the same) plus the fact the exporting should really generate shorter
and simpler file names rather than name with capitals and spaces. I've
also seen people writing a single paragraph over several lines without a
short description. You wouldn't really want a patch name that long.
Anyway, 'stg series -d' would show the patch name together with the short
description.
>> When importing a patch from a saved email, stg should strip all the
>> email headers out of the description. I have to manually fix that
>> up.
>
> Do you do "stg import -M"? That's for importing one or more patches
> contained in an mbox. Without the -M, I think the default is to expect
> plain diff input.
There is also 'stg import -m' for single e-mails rather than mbox. StGIT
should be able to cope with attachments as well.
Catalin
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Johannes Sixt @ 2007-10-05 9:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005085522.32EFF1E16E@madism.org>
Pierre Habouzit schrieb:
> @@ -281,20 +283,19 @@ static int apply_filter(const char *path, const char *src, size_t len,
> ret = 0;
> }
> if (close(pipe_feed[0])) {
> - ret = error("read from external filter %s failed", cmd);
> + error("read from external filter %s failed", cmd);
> ret = 0;
> }
> status = finish_command(&child_process);
> if (status) {
> - ret = error("external filter %s failed %d", cmd, -status);
> + error("external filter %s failed %d", cmd, -status);
> ret = 0;
> }
If you want to, you can leave away these cosmetical corrections since I'm
working on a patch that replaces this entire passus. (Will be needed for the
MinGW port).
-- Hannes
^ permalink raw reply
* Re: Many gits are offline this week
From: Paolo Ciarrocchi @ 2007-10-05 9:14 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On 10/5/07, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Hi Randal,
is there any material (slides, docs) you can share before the talks?
Thanks!
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-05 9:06 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4705FB52.3030208@op5.se>
On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
> Paolo Ciarrocchi wrote:
> > On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> Hi,
> >>
> >> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
> >>
> >>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
> >>>>> Am I wrong?
> >>>> About it being a majority, yes, I suspect so.
> >>>>
> >>> Maybe in the next survey we should include question "do you usually do
> >>> 'git commit' or 'git commit -a'" :-)
> >> Not meaning to discourage you, but it is a known fact that Linus does "git
> >> commit" without "-a" quite often.
> >>
> >> And if that were not bad enough for your plan, I myself omit "-a"
> >> regularly. So you would get a veto from me, too.
> >
> > So you are used to do something like (please correct me if I'm wrong):
> > - modify A
> > - modify B
> > - modify C
> > - modify D
> > - modify E
> >
> > $ git A B E
>
>
> This isn't really a valid command. I'm not sure where you got it from.
Doh! Don't consider it, it's just a silly copy and paste error! It has
no meaning!
> > $ git add A B E (A, B and E are now in the staging area)
> > $ git commit -m "I just modified A,B and E"
>
> I do something like that, except that for full-file commits I'd rather
> say
>
> git commit -s A B E
>
> I never pass -m to git commit. It's too easy to get into habit of being
> sloppy with historic documentation that way.
Right.
But in the scenario you described isn't enough to type "git commit -s".
Why did you write "git commit -s A B E".
> > $ git C D
>
> Again not a valid command, but...
See above, just a very silly copy and paste error.
> > $ git add C D (C and D are now in the staging area)
> > $ git commit -m "I just modified C and D"
> >
>
> See above :)
>
> There's also the times when I hack on some feature and find some small
> bug/easy-to-write-feature, so I make the change for that other thing,
> swap to a different branch and do 'git commit -s --interactive' to
> just break out that small fix.
>
> Or if I have to add some logic to some other function in a file I've
> modified for other purposes and want it to be two separate commits,
> I just make the change and then run 'git commit --interactive' to
> make it two separate commits.
Very interesting!
> I just don't do 'git commit -a' for the same reason I don't do
> 'git commit -m', really. It tends to be habit-forming, and bisect
> has saved my arse enough times for me to *want* my changes to be
> small and isolated. Debugging a 5-line patch is so much more pleasant
> than debugging a 30k-lines one that spans over several different files.
Yeah, I see.
Thanks for your comments Andreas, very appreciated.
Just to clarify my goal, since I had that interesting discussion with
an hg user I started looking for simple examples of the usage of the
"staging area" to be added to the introduction to git documentation.
The role of the index/staging area seems to be something complex for a
git newbie.
Regards
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Pierre Habouzit @ 2007-10-05 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bernt Hansen
In-Reply-To: <20071005082026.GE19879@artemis.corp>
* crlf_to_git and ident_to_git:
Don't grow the buffer if there is enough space in the first place.
As a side effect, when the editing is done "in place", we don't grow, so
the buffer pointer doesn't changes, and `src' isn't invalidated anymore.
Thanks to Bernt Hansen for the bug report.
* apply_filter:
Fix memory leak due to fake in-place editing that didn't collected the
old buffer when the filter succeeds. Also a cosmetic fix.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This patch is on top of master, and supersedes both patch I sent before.
Following dscho's remark, I only grow the buffer if they aren't big enough
in the first place, which ensures that buffers are not touched if edited in
place.
convert.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/convert.c b/convert.c
index 0d5e909..aa95834 100644
--- a/convert.c
+++ b/convert.c
@@ -110,7 +110,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (strbuf_avail(buf) + buf->len < len)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
@@ -281,20 +283,19 @@ static int apply_filter(const char *path, const char *src, size_t len,
ret = 0;
}
if (close(pipe_feed[0])) {
- ret = error("read from external filter %s failed", cmd);
+ error("read from external filter %s failed", cmd);
ret = 0;
}
status = finish_command(&child_process);
if (status) {
- ret = error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", cmd, -status);
ret = 0;
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
@@ -422,7 +423,9 @@ static int ident_to_git(const char *path, const char *src, size_t len,
if (!ident || !count_ident(src, len))
return 0;
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (strbuf_avail(buf) + buf->len < len)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
for (;;) {
dollar = memchr(src, '$', len);
--
1.5.3.4.207.gb504-dirty
^ permalink raw reply related
* Re: Correction for post-receive-email
From: Andreas Ericsson @ 2007-10-05 8:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Eric Mertens
In-Reply-To: <200710050913.58835.andyparkins@gmail.com>
Andy Parkins wrote:
> On Friday 2007 October 05, Eric Mertens wrote:
>
>> I noticed that my mutt wasn't correctly detecting the signature block
>> on the end of the automated emails I was receiving from the script in
>> contrib. I've made this trivial change in my local copy of the script,
>> but I figured that if I was going to be modifying the source code I
>> should share my changes.
>
> That change has been in my pending queue for a while. It's technically
> correct, but I've never submitted it. The reason I haven't is that it adds
> trailing whitespace.
>
> Perhaps one of the shell gurus can offer a nicer way of having a trailing
> space be output in a heredoc that doesn't add a trailing space in the source
> script?
>
space=' '
cat << EOF
--$space
EOF
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 8:52 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>>
>>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
>>>>> Am I wrong?
>>>> About it being a majority, yes, I suspect so.
>>>>
>>> Maybe in the next survey we should include question "do you usually do
>>> 'git commit' or 'git commit -a'" :-)
>> Not meaning to discourage you, but it is a known fact that Linus does "git
>> commit" without "-a" quite often.
>>
>> And if that were not bad enough for your plan, I myself omit "-a"
>> regularly. So you would get a veto from me, too.
>
> So you are used to do something like (please correct me if I'm wrong):
> - modify A
> - modify B
> - modify C
> - modify D
> - modify E
>
> $ git A B E
This isn't really a valid command. I'm not sure where you got it from.
> $ git add A B E (A, B and E are now in the staging area)
> $ git commit -m "I just modified A,B and E"
I do something like that, except that for full-file commits I'd rather
say
git commit -s A B E
I never pass -m to git commit. It's too easy to get into habit of being
sloppy with historic documentation that way.
> $ git C D
Again not a valid command, but...
> $ git add C D (C and D are now in the staging area)
> $ git commit -m "I just modified C and D"
>
See above :)
There's also the times when I hack on some feature and find some small
bug/easy-to-write-feature, so I make the change for that other thing,
swap to a different branch and do 'git commit -s --interactive' to
just break out that small fix.
Or if I have to add some logic to some other function in a file I've
modified for other purposes and want it to be two separate commits,
I just make the change and then run 'git commit --interactive' to
make it two separate commits.
I just don't do 'git commit -a' for the same reason I don't do
'git commit -m', really. It tends to be habit-forming, and bisect
has saved my arse enough times for me to *want* my changes to be
small and isolated. Debugging a 5-line patch is so much more pleasant
than debugging a 30k-lines one that spans over several different files.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Pierre Habouzit @ 2007-10-05 8:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <Pine.LNX.4.64.0710050930030.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Fri, Oct 05, 2007 at 08:30:45AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 5 Oct 2007, Pierre Habouzit wrote:
>
> > When crlf_to_git or ident_to_git are called "in place", the buffer
> > already is big enough and should not be resized (as it could make the
> > buffer address change, hence invalidate the `src' pointers !).
>
> I wonder why we resize at all if the buffer is big enough to begin with.
strbuf_grow takes care of that itself but indeed you make me see that
my patch is wrong. if buf->len > len then len - buf->len is err a bit
big.
I'll roll better ones.
--
·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: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-05 8:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nguyen Thai Ngoc Duy, Wincent Colaiuta, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710042209410.4174@racer.site>
On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
> > > > Am I wrong?
> > >
> > > About it being a majority, yes, I suspect so.
> > >
> >
> > Maybe in the next survey we should include question "do you usually do
> > 'git commit' or 'git commit -a'" :-)
>
> Not meaning to discourage you, but it is a known fact that Linus does "git
> commit" without "-a" quite often.
>
> And if that were not bad enough for your plan, I myself omit "-a"
> regularly. So you would get a veto from me, too.
So you are used to do something like (please correct me if I'm wrong):
- modify A
- modify B
- modify C
- modify D
- modify E
$ git A B E
$ git add A B E (A, B and E are now in the staging area)
$ git commit -m "I just modified A,B and E"
$ git C D
$ git add C D (C and D are now in the staging area)
$ git commit -m "I just modified C and D"
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Johannes Schindelin @ 2007-10-05 8:30 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005082026.GE19879@artemis.corp>
Hi,
On Fri, 5 Oct 2007, Pierre Habouzit wrote:
> When crlf_to_git or ident_to_git are called "in place", the buffer
> already is big enough and should not be resized (as it could make the
> buffer address change, hence invalidate the `src' pointers !).
I wonder why we resize at all if the buffer is big enough to begin with.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix memory leak in apply_filter.
From: Pierre Habouzit @ 2007-10-05 8:29 UTC (permalink / raw)
To: Junio C Hamano, Bernt Hansen; +Cc: git
In-Reply-To: <20071005082026.GE19879@artemis.corp>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
While we're at it... Here is a stupid memory leak in apply_filter.
On top of the previous commit.
The same, repost, unsigned doh.
convert.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 4664197..d5c197f 100644
--- a/convert.c
+++ b/convert.c
@@ -293,10 +293,9 @@ static int apply_filter(const char *path, const char *src, size_t len,
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
--
1.5.3.4.208.gdcc67-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Johannes Schindelin @ 2007-10-05 8:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steven Grimm, git
In-Reply-To: <4705EFF2.9090506@op5.se>
Hi,
On Fri, 5 Oct 2007, Andreas Ericsson wrote:
> Steven Grimm wrote:
> > git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> > leaves old commits dangling. Since dcommit is already unsafe to run
> > concurrently with other git commands, no additional risk is introduced
> > by making it prune those old objects as needed.
> >
> > Signed-off-by: Steven Grimm <koreth@midwinter.com>
> > ---
> >
> > This is in response to a colleague who complained that, after I
> > installed the latest git release, he was getting lots of "too many
> > unreachable loose objects" errors from the new "git gc --auto" run.
> > Those objects turned out to be dangling commits from a year's worth of
> > git-svn usage, since every git-svn commit will abandon at least one
> > existing commit in order to rewrite it with the svn version data.
> >
> > git-svn.perl | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 777e436..be62ee1 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -441,6 +441,12 @@ sub cmd_dcommit {
> > }
> > command_noisy(@finish, $gs->refname);
> > $last_rev = $cmt_rev;
> > +
> > + # rebase will have made the just-committed revisions
> > + # unreachable; over time that can build up lots of
> > + # loose objects in the repo. prune is unsafe to run
> > + # concurrently but so is dcommit.
> > + command_noisy(qw/gc --auto --prune/);
> > }
> > }
> > }
>
> I'd be surprised if this would ever prune anything, as git doesn't throw
> out objects reachable by reflog (or, I assume, any of the objects
> reachable from objects reachable from reflog).
It will so, in due time. Reflogs have an expiry date, and will be culled
by git gc --auto. So if you dcommit often (which I do), the objects will
be pruned, eventually.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix memory leak in apply_filter.
From: Pierre Habouzit @ 2007-10-05 8:27 UTC (permalink / raw)
To: Junio C Hamano, Bernt Hansen; +Cc: git
In-Reply-To: <20071005082026.GE19879@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
While we're at it... Here is a stupid memory leak in apply_filter.
On top of the previous commit.
convert.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 4664197..d5c197f 100644
--- a/convert.c
+++ b/convert.c
@@ -293,10 +293,9 @@ static int apply_filter(const char *path, const char *src, size_t len,
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
--
1.5.3.4.208.gdcc67-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Peter Baumann @ 2007-10-05 8:21 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071005001528.GA13029@midwinter.com>
On Thu, Oct 04, 2007 at 05:15:28PM -0700, Steven Grimm wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
>
I don't like the automatic prune. What if someone has other objects in
there which shouldn't be pruned? Making git svn dcommit doing the prune
would be at least suprising, because how is one supposed to know that
doing a commit into svn will prune all your precious objects?
Sure, I can unterstand from where you are coming from, but I'd prefere
if this could be specified on a case by case basis, e.g. from the
cmdline or as a config option.
-Peter
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
> --
> 1.5.3.4.203.gcc61a
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Pierre Habouzit @ 2007-10-05 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bernt Hansen
In-Reply-To: <87wsu2sad0.fsf@gollum.intra.norang.ca>
When crlf_to_git or ident_to_git are called "in place", the buffer already
is big enough and should not be resized (as it could make the buffer address
change, hence invalidate the `src' pointers !).
Also fix the growth length at the same time: we want to replace the buffer
content (not append) in those functions as they are filters.
Thanks to Bernt Hansen for the bug report.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This patch is done on top of master, as strbuf's have been merged.
This is a major issue.
convert.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/convert.c b/convert.c
index 0d5e909..4664197 100644
--- a/convert.c
+++ b/convert.c
@@ -110,7 +110,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (src != buf->buf)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
@@ -281,12 +283,12 @@ static int apply_filter(const char *path, const char *src, size_t len,
ret = 0;
}
if (close(pipe_feed[0])) {
- ret = error("read from external filter %s failed", cmd);
+ error("read from external filter %s failed", cmd);
ret = 0;
}
status = finish_command(&child_process);
if (status) {
- ret = error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", cmd, -status);
ret = 0;
}
@@ -422,7 +424,9 @@ static int ident_to_git(const char *path, const char *src, size_t len,
if (!ident || !count_ident(src, len))
return 0;
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (src != buf->buf)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
for (;;) {
dollar = memchr(src, '$', len);
--
1.5.3.4.207.gc79d4-dirty
^ permalink raw reply related
* Re: Correction for post-receive-email
From: Andy Parkins @ 2007-10-05 8:13 UTC (permalink / raw)
To: git; +Cc: Eric Mertens
In-Reply-To: <449c8cfc0710050014j9bbf057ka108ee27dea49a89@mail.gmail.com>
On Friday 2007 October 05, Eric Mertens wrote:
> I noticed that my mutt wasn't correctly detecting the signature block
> on the end of the automated emails I was receiving from the script in
> contrib. I've made this trivial change in my local copy of the script,
> but I figured that if I was going to be modifying the source code I
> should share my changes.
That change has been in my pending queue for a while. It's technically
correct, but I've never submitted it. The reason I haven't is that it adds
trailing whitespace.
Perhaps one of the shell gurus can offer a nicer way of having a trailing
space be output in a heredoc that doesn't add a trailing space in the source
script?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Andreas Ericsson @ 2007-10-05 8:04 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071005001528.GA13029@midwinter.com>
Steven Grimm wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
>
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
I'd be surprised if this would ever prune anything, as git doesn't throw out
objects reachable by reflog (or, I assume, any of the objects reachable from
objects reachable from reflog).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Andreas Ericsson @ 2007-10-05 7:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Benoit SIGOURE, git
In-Reply-To: <20071005014229.GS2137@spearce.org>
Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> On 10/4/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>> On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
>>>> Note that Git is GPLv2, and it will probably stay that forever, so you
>>>> are _free_ to start a commercial support scheme for Git, but others
>>>> are free not to choose it. This question is to get to know if there is
>>>> sufficient demand for commercial Git support for it to be viable.
>>> Once again (AFAIR this was already raised during one of the previous
>>> summary) what's the link between GPLv2 and commercial support? You
>>> seem to imply that because Git won't move to GPLv3, it's a good thing
>>> for potential paid support, or something. I don't quite see how
>>> GPLvX comes into play with commercial support. I'm not a license
>>> expert though.
>> The only link between GPL and commercial support is that GPL does not
>> prohibit commercial support (like noncommercial-free licenses for example),
>> and that having commercial support doesn't mean that license would change
>> to proprietary (it cannot).
>
> Right. There has been some discussion in the past about forming
> "The Git Company".
>
> When this survey question was first posed there was some concern that
> Git might move to a commerical license of some sort and perhaps not
> be GPLvX anymore. That concern is a non-issue; the copyrights for
> Git are held by over 300 people, many of whom are kernel hackers and
> strong believers in the value of GPLv2. I'm not a kernel hacker,
> but I also believe strongly in the value of the GPLv2 license.
> You won't see me agreeing to move code I wrote to a non-GPL license
> anytime soon. Most (if not all!) of Git's authors feel the same way.
>
> There's several reasons why forming "The Git Company" might help
> the overall Git cause, and this question was a feeler to see if
> the community was interested in acquiring support through it. Many
> other open source projects seem to get some benefit from having a
> company loosely affiliated with them, not the least of which are
> things like:
>
> - some of the developers can focus more time on the project and
> still keep food on the table;
>
> - there are people focused on advertising/marketing the project
> and its benfits to potential end-users;
>
> - companies that feel warm-and-fuzzy by having a phone number they
> can call for help are more likely to want to use the project
> for critical services;
>
> - companies that want training or short-term consulting services
> know who they can contact for expertise.
>
> and the list goes on. The problem with said company is it costs
> money to keep the lights on and employees fed; money which obviously
> cannot be extorted from users through arcane licensing agreements.
Actually it can. I work for precisely such a company (although using
Nagios, cacti and syslog-ng as the base of our products rather than
git). The GPL doesn't state how one is allowed to charge money for
the products, but since larger networks with more users generate more
support calls, we also use a license payment model, where larger
customers pay more and smaller pay less.
The difference between proprietary software is that we have to trust
ur customers to *want* to pay the licenses, as it would be ridiculously
easy for them to replace our versions of the programs with the pristine
oss kind, or even with our patches, as we aren't allowed to keep them
private. However, doing so voids the support-agreement, as we don't take
support for code we haven't audited and tested. In other words, we *must*
provide first-class support and coding aid to our customers, or they
won't want to pay anymore. In practice, it all works out rather well, and
everyone gets something they want.
* I get paid to work with something I like.
* Customers get support, well-tested upgrades and nifty extensions.
* Project maintainers get patches, money, hardware and appreciation.
That last bit is important though. It's not terribly expensive for us to
buy a couple of books or a laptop and send it as a christmas gift to some
project maintainer, but doing so shows appreciation and also buys us the
attention of the developers for when we want our feature-patches accepted ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] gtksourceview2 support for gitview
From: Frederick Akalin @ 2007-10-05 7:20 UTC (permalink / raw)
To: git, gitster; +Cc: Frederick Akalin
Added support for gtksourceview2 module (pygtksourceview 1.90.x) in
gitview. Also refactored code that creates the source buffer and view.
Signed-off-by: Frederick Akalin <akalin@akalin.cx>
---
contrib/gitview/gitview | 53 +++++++++++++++++++++++++++-------------------
1 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 5931766..449ee69 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -28,11 +28,19 @@ import string
import fcntl
try:
+ import gtksourceview2
+ have_gtksourceview2 = True
+except ImportError:
+ have_gtksourceview2 = False
+
+try:
import gtksourceview
have_gtksourceview = True
except ImportError:
have_gtksourceview = False
- print "Running without gtksourceview module"
+
+if not have_gtksourceview2 and not have_gtksourceview:
+ print "Running without gtksourceview2 or gtksourceview module"
re_ident = re.compile('(author|committer) (?P<ident>.*) (?P<epoch>\d+) (?P<tz>[+-]\d{4})')
@@ -58,6 +66,26 @@ def show_date(epoch, tz):
return time.strftime("%Y-%m-%d %H:%M:%S", time.gmtime(secs))
+def get_source_buffer_and_view():
+ if have_gtksourceview2:
+ buffer = gtksourceview2.Buffer()
+ slm = gtksourceview2.LanguageManager()
+ gsl = slm.get_language("diff")
+ buffer.set_highlight_syntax(True)
+ buffer.set_language(gsl)
+ view = gtksourceview2.View(buffer)
+ elif have_gtksourceview:
+ buffer = gtksourceview.SourceBuffer()
+ slm = gtksourceview.SourceLanguagesManager()
+ gsl = slm.get_language_from_mime_type("text/x-patch")
+ buffer.set_highlight(True)
+ buffer.set_language(gsl)
+ view = gtksourceview.SourceView(buffer)
+ else:
+ buffer = gtk.TextBuffer()
+ view = gtk.TextView(buffer)
+ return (buffer, view)
+
class CellRendererGraph(gtk.GenericCellRenderer):
"""Cell renderer for directed graph.
@@ -582,17 +610,7 @@ class DiffWindow(object):
hpan.pack1(scrollwin, True, True)
scrollwin.show()
- if have_gtksourceview:
- self.buffer = gtksourceview.SourceBuffer()
- slm = gtksourceview.SourceLanguagesManager()
- gsl = slm.get_language_from_mime_type("text/x-patch")
- self.buffer.set_highlight(True)
- self.buffer.set_language(gsl)
- sourceview = gtksourceview.SourceView(self.buffer)
- else:
- self.buffer = gtk.TextBuffer()
- sourceview = gtk.TextView(self.buffer)
-
+ (self.buffer, sourceview) = get_source_buffer_and_view()
sourceview.set_editable(False)
sourceview.modify_font(pango.FontDescription("Monospace"))
@@ -956,16 +974,7 @@ class GitView(object):
vbox.pack_start(scrollwin, expand=True, fill=True)
scrollwin.show()
- if have_gtksourceview:
- self.message_buffer = gtksourceview.SourceBuffer()
- slm = gtksourceview.SourceLanguagesManager()
- gsl = slm.get_language_from_mime_type("text/x-patch")
- self.message_buffer.set_highlight(True)
- self.message_buffer.set_language(gsl)
- sourceview = gtksourceview.SourceView(self.message_buffer)
- else:
- self.message_buffer = gtk.TextBuffer()
- sourceview = gtk.TextView(self.message_buffer)
+ (self.message_buffer, sourceview) = get_source_buffer_and_view()
sourceview.set_editable(False)
sourceview.modify_font(pango.FontDescription("Monospace"))
--
1.5.3.3
^ permalink raw reply related
* Correction for post-receive-email
From: Eric Mertens @ 2007-10-05 7:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hello,
(My apologies if my incorrectly addressed subscribe message went to the list)
I noticed that my mutt wasn't correctly detecting the signature block
on the end of the automated emails I was receiving from the script in
contrib. I've made this trivial change in my local copy of the script,
but I figured that if I was going to be modifying the source code I
should share my changes.
--
Eric Mertens
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Correct-signature-block-delimiter-in-post-receive-em.patch --]
[-- Type: text/x-patch; name="0001-Correct-signature-block-delimiter-in-post-receive-em.patch", Size: 792 bytes --]
From 119f84fa6f6bb33c6fc524ab4277d38bebc10468 Mon Sep 17 00:00:00 2001
From: Eric Mertens <emertens@gmail.com>
Date: Fri, 5 Oct 2007 00:06:52 -0700
Subject: [PATCH] Correct signature block delimiter in post-receive-email by adding a trailing space
This change allows mail clients like Mutt to easily detect the signature
and is consistent with the signature block article on Wikipedia.
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index cbbd02f..828651a 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -198,7 +198,7 @@ generate_email_footer()
hooks/post-receive
- --
+ --
$projectdesc
EOF
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Alex Riesen @ 2007-10-05 6:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1191553750-25562-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain, Fri, Oct 05, 2007 05:09:10 +0200:
> If the repository got mangled by FAT capitalization rules, then a ref
> such as "HEAD" will become "head" once it is back on a non-FAT FS.
> Check for this condition in resolve_refs and in the setup code.
>
> Suggested-by: Francois Marier <francois@debian.org>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> This should probably help people putting their git repos on
> FAT USB sticks.
Can the people just mount FAT partitions with shortname=mixed?
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-05 6:40 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004161935.GC17487@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> The stat-information, and sha1sum are actually a cache, but they don't
>> have to be user-visible, except for speed.
>
> That's a big exception.--b.
Speed _is_ important, of course. But the user only benefits from
speed, he doesn't have to manipulate it explicitely. I may be
repeating myself, but "diff --cached" doesn't mean "diff using the
stat-cache", it means "diff using the cached _content_", which is
really unrelated from the stat-cache.
Mercurial also has fast diff (perhaps a bit slower that git, but same
order of magnitude), and has no user-visible index.
--
Matthieu
^ 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