* [PATCHv3] git-log --format: Add %B tag with %B(x) option
From: Johannes Gilger @ 2009-09-19 9:58 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Schindelin, Johannes Gilger
In-Reply-To: <7vtyz083tk.fsf@alter.siamese.dyndns.org>
Since one can simply use spaces to indent any other --pretty field we
should have an option to do that with the body too.
Also the %B flag strips the trailing newlines, to enable more compact
display.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
Changes to PATCHv2:
- Make %B() strict: Only nonnegative integers are allowed between the brackets,
everything else yields the placemark itself as output to indicate a wrong
argument. This also goes for an empty argument.
Documentation/pretty-formats.txt | 2 ++
pretty.c | 29 ++++++++++++++++++++++++-----
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..533bc5e 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -123,6 +123,8 @@ The placeholders are:
- '%s': subject
- '%f': sanitized subject line, suitable for a filename
- '%b': body
+- '%B': body without trailing newline
+- '%B(x)': body indented by x spaces
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
diff --git a/pretty.c b/pretty.c
index f5983f8..8970378 100644
--- a/pretty.c
+++ b/pretty.c
@@ -605,13 +605,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
int h1, h2;
/* these are independent of the commit */
+
+ const char *body = msg + c->body_off;
+ const char *end = NULL;
+ /* check if we have arguments to the placeholder */
+ if (placeholder[1] == '(')
+ end = strchr(placeholder + 2, ')');
+
switch (placeholder[0]) {
case 'C':
- if (placeholder[1] == '(') {
- const char *end = strchr(placeholder + 2, ')');
+ if (end) {
char color[COLOR_MAXLEN];
- if (!end)
- return 0;
color_parse_mem(placeholder + 2,
end - (placeholder + 2),
"--pretty format", color);
@@ -733,7 +737,20 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
format_sanitized_subject(sb, msg + c->subject_off);
return 1;
case 'b': /* body */
- strbuf_addstr(sb, msg + c->body_off);
+ strbuf_addstr(sb, body);
+ return 1;
+ case 'B': /* body without trailing newline */
+ if (end) {
+ char *endp = NULL;
+ int indent = strtol(placeholder + 2, &endp, 10);
+ if (placeholder + 2 == endp || *endp != ')' || indent < 0)
+ return 0;
+ pp_remainder(CMIT_FMT_MEDIUM, &body, sb, indent);
+ strbuf_rtrim(sb);
+ return end - placeholder + 1;
+ }
+ strbuf_addstr(sb, body);
+ strbuf_rtrim(sb);
return 1;
}
return 0; /* unknown placeholder */
@@ -875,6 +892,8 @@ void pp_remainder(enum cmit_fmt fmt,
}
first = 0;
+ if (indent < 0)
+ indent = 0;
strbuf_grow(sb, linelen + indent + 20);
if (indent) {
memset(sb->buf + sb->len, ' ', indent);
--
1.6.5.rc1.20.geb7d9
^ permalink raw reply related
* Re: SmartGit, a new GUI front-end for Git
From: Thomas Singer @ 2009-09-19 9:54 UTC (permalink / raw)
To: git
In-Reply-To: <e5e204700909190158y48b9c162ncea29f4b1635dc18@mail.gmail.com>
Hi James,
Thanks for reporting this serious error. I will try to fix this in the next
hour and upload a new build.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
James Sadler wrote:
> Hi Thomas,
>
> I just launched SmartGit, and it ate my ~/.gitconfig. Luckily I had a
> backup (full of my own aliases and colour settings etc.).
>
> SmartGit replaced mine with a ~/.gitconfig containing _only_ my name
> and email settings. Not good. I would bet that 99% of all people on
> this list have their own customized version of ~/.gitconfig and
> SmartGit is probably going to eat it. If it helps, I am running OS X.
>
> James.
>
> 2009/9/19 Thomas Singer <thomas.singer@syntevo.com>:
>> Hi all,
>>
>> We would like to announce a new milestone build of our Git client "SmartGit"
>> (don't be offended by the name, it's historically based) which we feel is
>> ready now for a broader audience. SmartGit is quite stable and we want to
>> invite everyone who is interested in giving it a try:
>>
>> http://www.syntevo.com/smartgit/index.html
>>
>> Please don't expect all Git features and options implemented. We have
>> tried to first concentrate on the most important ones - from our rather
>> novice Git perspective.
>>
>> SmartGit runs on all operating systems which support a full Java 1.5
>> implementation, including virtually all Linux versions, OS X 10.4 - 10.6 and
>> Windows 2000 or newer. It requires a Git installation, although a couple of
>> time-critical operations are handled by the JGit library.
>>
>> We appreciate your feed-back in our mailing list
>>
>> http://www.syntevo.com/smartgit/community.html
>>
>> or directly to us (smartgit@syntevo.com). SmartGit 1.0 is planned to be
>> released free of charge for non-commercial use or to active members of the
>> Open Source community. Each pre-release build expires 3 months after the
>> build-date.
>>
>> At this occasion I would also like to express my appreciation to the
>> community for this great DVCS you have built. Approx. a 3/4 year ago I've
>> started to use Git. Although I had some starting problems with it using the
>> Git command line (mostly on Windows), I need to say that over time I really
>> fell in love with Git and its elaborate foundations and feature set.
>>
>> --
>> Best regards,
>> Thomas Singer
>> =============
>> syntevo GmbH
>> http://www.syntevo.com
>> http://blog.syntevo.com
>>
>>
>> --
>> 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
* Re: SmartGit, a new GUI front-end for Git
From: Jakub Narebski @ 2009-09-19 8:54 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4AB48E25.8020504@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> writes:
> We would like to announce a new milestone build of our Git client "SmartGit"
> (don't be offended by the name, it's historically based) which we feel is
> ready now for a broader audience. SmartGit is quite stable and we want to
> invite everyone who is interested in giving it a try:
>
> http://www.syntevo.com/smartgit/index.html
>
> Please don't expect all Git features and options implemented. We have
> tried to first concentrate on the most important ones - from our rather
> novice Git perspective.
[...]
Could you please add information about this Git client (Git GUI?)
to the http://git.or.cz/gitwiki/InterfacesFrontendsAndTools wiki
page?
Thanks in advance.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: SmartGit, a new GUI front-end for Git
From: James Sadler @ 2009-09-19 8:58 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4AB48E25.8020504@syntevo.com>
Hi Thomas,
I just launched SmartGit, and it ate my ~/.gitconfig. Luckily I had a
backup (full of my own aliases and colour settings etc.).
SmartGit replaced mine with a ~/.gitconfig containing _only_ my name
and email settings. Not good. I would bet that 99% of all people on
this list have their own customized version of ~/.gitconfig and
SmartGit is probably going to eat it. If it helps, I am running OS X.
James.
2009/9/19 Thomas Singer <thomas.singer@syntevo.com>:
> Hi all,
>
> We would like to announce a new milestone build of our Git client "SmartGit"
> (don't be offended by the name, it's historically based) which we feel is
> ready now for a broader audience. SmartGit is quite stable and we want to
> invite everyone who is interested in giving it a try:
>
> http://www.syntevo.com/smartgit/index.html
>
> Please don't expect all Git features and options implemented. We have
> tried to first concentrate on the most important ones - from our rather
> novice Git perspective.
>
> SmartGit runs on all operating systems which support a full Java 1.5
> implementation, including virtually all Linux versions, OS X 10.4 - 10.6 and
> Windows 2000 or newer. It requires a Git installation, although a couple of
> time-critical operations are handled by the JGit library.
>
> We appreciate your feed-back in our mailing list
>
> http://www.syntevo.com/smartgit/community.html
>
> or directly to us (smartgit@syntevo.com). SmartGit 1.0 is planned to be
> released free of charge for non-commercial use or to active members of the
> Open Source community. Each pre-release build expires 3 months after the
> build-date.
>
> At this occasion I would also like to express my appreciation to the
> community for this great DVCS you have built. Approx. a 3/4 year ago I've
> started to use Git. Although I had some starting problems with it using the
> Git command line (mostly on Windows), I need to say that over time I really
> fell in love with Git and its elaborate foundations and feature set.
>
> --
> Best regards,
> Thomas Singer
> =============
> syntevo GmbH
> http://www.syntevo.com
> http://blog.syntevo.com
>
>
> --
> 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
>
--
James
^ permalink raw reply
* SmartGit, a new GUI front-end for Git
From: Thomas Singer @ 2009-09-19 7:54 UTC (permalink / raw)
To: git
In-Reply-To: <4AB38D64.9010903@syntevo.com>
Hi all,
We would like to announce a new milestone build of our Git client "SmartGit"
(don't be offended by the name, it's historically based) which we feel is
ready now for a broader audience. SmartGit is quite stable and we want to
invite everyone who is interested in giving it a try:
http://www.syntevo.com/smartgit/index.html
Please don't expect all Git features and options implemented. We have
tried to first concentrate on the most important ones - from our rather
novice Git perspective.
SmartGit runs on all operating systems which support a full Java 1.5
implementation, including virtually all Linux versions, OS X 10.4 - 10.6 and
Windows 2000 or newer. It requires a Git installation, although a couple of
time-critical operations are handled by the JGit library.
We appreciate your feed-back in our mailing list
http://www.syntevo.com/smartgit/community.html
or directly to us (smartgit@syntevo.com). SmartGit 1.0 is planned to be
released free of charge for non-commercial use or to active members of the
Open Source community. Each pre-release build expires 3 months after the
build-date.
At this occasion I would also like to express my appreciation to the
community for this great DVCS you have built. Approx. a 3/4 year ago I've
started to use Git. Although I had some starting problems with it using the
Git command line (mostly on Windows), I need to say that over time I really
fell in love with Git and its elaborate foundations and feature set.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: Cygwin git dies silently
From: Clemens Buchacher @ 2009-09-19 8:19 UTC (permalink / raw)
To: John Ousterhout; +Cc: git
In-Reply-To: <A80C2B4F6C34430FA32A24BF94647076@ouster>
On Fri, Sep 18, 2009 at 04:48:42PM -0700, John Ousterhout wrote:
> "echo $?" says that git is exiting with status 53.
Git never returns 53. Googling for exit status 53 turns up some hits [1].
Clemens
[1] http://www.google.com/search?&q=exit+code+53
^ permalink raw reply
* Re: merge ignores --no-commit in fast-forward case
From: Björn Steinbrink @ 2009-09-19 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tomas Carnecky, git mailing list
In-Reply-To: <7vocpfz4gm.fsf@alter.siamese.dyndns.org>
On 2009.09.13 00:30:49 -0700, Junio C Hamano wrote:
> Tomas Carnecky <tom@dbservice.com> writes:
> > Three possible solutions that I see:
> >
> > 2) Refuse to do anything if user gives --no-commit and merge is fast-
> > forward
> > 3) Document this behavior in the manpage
> > 4) Quietly set deny_non_fast_forward when --no-commit was given
>
> Heh, this is new. People laugh at me when I number my bullets starting
> from zero, like all good computer scientists do ;-)
>
> Seriously, we should at least do #3, and as a backward incompatible change
> at least _consider_ doing #2 (I think #4 is merely an implementation detail
> of #2), and if list reaches concensus in favor of such a change, come up
> with a transition plan and do so in the 1.7.0 release.
Hm, I always treated --no-commit as a way of saying: I think this merge
might cause semantic problems, please let me fix those directly, instead
of having to deal with 'commit --amend' and 'diff HEAD^ HEAD'.
Obviously, in case of a fast-forward such semantic problems aren't to be
expected, and I've just been wrong in my expectations. And then I'm
happy with the fast-forward. I'd _not_ be happy if a merge commit would
be forced (that's what #4 was about, right? deny_non_fast_forward only
appears in builtin-receive-pack.c, so I guess allow_fast_forward=0
was meant...).
#2 would be ok with me, I guess. I expected the wrong thing from the
merge, so git may complain, though it means more typing ;-)
Björn
^ permalink raw reply
* Cygwin git dies silently
From: John Ousterhout @ 2009-09-18 23:48 UTC (permalink / raw)
To: git
I am trying to use the standard version of git that comes with Cygwin
(Cygwin says it's version 1.6.1.2-1), but when I invoke git from
Cygwin bash nothing happens: the shell prompt appears again with no
other output. I tried several different sets of git arguments, but
they all behave the same way. "echo $?" says that git is exiting with
status 53. Does anyone have any suggestions for what might be causing
this?
Thanks in advance for any help you can provide.
-John-
^ permalink raw reply
* [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Paul Mackerras @ 2009-09-19 0:07 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Murphy, John, git
In-Reply-To: <878wgcbb52.fsf@users.sourceforge.net>
Pat Thoyts writes:
> Tcl strings can eat all your memory. However, there is a limit to the
> size of the command line argument passed to CreateProcess. MSDN says
> of the lpCommandLine parameter:
> "The maximum length of this string is 32K characters."
> A solution for this case will be to use a pipe to read the responses
> instead of having it all returned to the caller.
> The following patch might be sufficient:
I knew about the 32k command-line limit under windows, but I don't see
how that applies in this case unless it is $revs that is too long (and
if that is the case then I don't see how your patch helps). Is there
also a 32k limit on the size of data returned by a command executed
with [exec]?
Paul.
^ permalink raw reply
* Re: merge ignores --no-commit in fast-forward case
From: Junio C Hamano @ 2009-09-18 23:05 UTC (permalink / raw)
To: Greg Price; +Cc: git
In-Reply-To: <20090918194717.GA18999@dr-wily.mit.edu>
Greg Price <price@ksplice.com> writes:
> Suppose we were to make such a change in 1.7.0 or a later version.
> What would the transition plan need to accomplish? For instance,
> we could print a warning every time 'merge --no-commit' does a
> fast-forward, and make the change in a later version -- might that
> suffice?
I guess so, but right now I don't want to (nor have bandwidth to) think
about things beyond the release we are currently in pre-release freeze
for. Helps from other people's braincells are very welcome.
> From: Greg Price <price@ksplice.com>
> Date: Fri, 18 Sep 2009 15:34:19 -0400
> Subject: [PATCH] Document behavior of --no-commit on fast forward.
>
> This behavior can be surprising, so document it.
If "surprising" is the problem (and it certainly is), perhaps it would be
better to rewrite it not to be so surprising, like:
--no-commit::
Do not create a new commit. If your current branch
fast-forwards to the branch you are merging, this option
has no effect (use --no-ff for that). Otherwise, a merge
is done and the index and the work tree files are updated,
but the command stops before creating a new commit that
records the result, in order to give the user a chance to
inspect and tweak the merge result before committing.
I dunno.
> Signed-off-by: Greg Price <price@ksplice.com>
> ---
> Documentation/merge-options.txt | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/merge-options.txt
> b/Documentation/merge-options.txt
> index adadf8e..6015e5d 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -31,7 +31,10 @@
> --no-commit::
> Perform the merge but pretend the merge failed and do
> not autocommit, to give the user a chance to inspect and
> - further tweak the merge result before committing.
> + further tweak the merge result before committing. If the
> + merge resolved as a fast-forward, the branch pointer will
> + be updated as usual; --no-ff can be combined with this
> + option to always preserve the branch pointer.
^ permalink raw reply
* Re: Big project, slow access!
From: R. Tyler Ballance @ 2009-09-18 21:32 UTC (permalink / raw)
To: Toan Pham; +Cc: git
In-Reply-To: <ffb2c0280909181138r7fde8722n80be4bdf95864c37@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
On Fri, 18 Sep 2009, Toan Pham wrote:
> Hi,
>
> I use git to maintain a project that is at least 8 gigs in size.
> The project is a Linux from Scratch repository that includes source
> codes to approximately 2000 open source projects,
> gcc tool-chain, 1000+ configurations for different software packages,
> source code for different kernel versions,
> and many linux distributions/flavors resulted from this LFS build environment.
>
> The git's object repository is now 4.6 gigs and consists of approx.
> 610,000 files and folders.
> The speed of git is now terribly slow. Each time I use basic commands
> like 'git status' or 'git diff',
> it would take at least 5 minutes for git to give me back a result.
> Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
Howdy Toan, we have a similarly large repository ~405k files, the .git
folder fully packed is ~6GB.
The advise to fully-pack your repository is likely going to have the
greatest impact on your performance in the short term, in the long term
however you might want to consider using git-filter-branch(1) or other
tools available to separate our the components of your current Git
reposotory into a series of repos.
The performance hit you're seeing likely has nothing to do with your
processor speed either, but rather your disk search speed (i'm waiting
for a new fancy SSD to help alleviate my issues ;))
> would someone please recommend on how i can optimize git's performance?
> Git is so slow, are there better ways to manage a project like this?
Rethink how your project is laid out, and whether certain binaries files
need to sit in the tree, or can be build on a need-by-need basis.
Cheers
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-18 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vm49ifb.fsf@alter.siamese.dyndns.org>
On Fri, Sep 18, 2009 at 4:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> This release candidate freeze is a period that no one can send patches?
>
> No.
>
> After -rc1, only fixes to regressions and severe bugs and trivially
> correct documentation patches will be applied to my tree, but all other
> kinds of patches are still sent to the list for discussion, so that the
> proposed changes can be discussed, polished and then become ready for the
> development cycle after the upcoming release.
> I often even pick them up and queue them to 'pu' and possibly 'next' as time permits.
If you don't want to pick a patch this means that it was not accepted,
right? I wrote others two trivial patches, one has comments, and I did
the changes suggested, but I guess not will be done about it because
it is just trivial.
>> And what did you mean with code churn?
>
> A change primarily for the sake of change without urgency nor real benefit
> in the longer term.
>
> It bothers nobody if a long literal string is written as a string literal
> in a dq pair with LFs quoted with backslashes, or as a run of multiple
> string literals, each of which ending with LF, to be concatenated by the
> compiler. It however would bother somebody who actually wants to modify
> these lines for a real change, and that is the best time for doing such a
> clean-up. Reasons for such a real change vary; to fix earlier mistakes
> (e.g. one line being excessively longer than others, or an option is
> misspelled), to add a new option, or to make the output of the program
> easier to read in general, etc.
This means that trivial patches like this one I wrote are generally
not accepted? Why is there this difficult (is it to maintain the high
level of the patches)? I thought if it is trivial it can be merged
after a review, into one of the integration branches. You write the
comments (the people in mailing list), I make the changes, and then
the patch is committed. But what I'm seeing here, this is not how the
things are done here. It is much more complicated than that I guess.
In a codereview tool I can send a patch for review, I can assign it to
someone review, he will make comments, I will make the necessary
changes, and when the patch is ready, it will be committed. What is
the workflow? With an email I can't assign a patch to someone, with
time it will be lost.
I'm just trying to understand what I have to do, to submit better
patches. Another issue that I saw, is about *issues* or bugs, they are
not tracked in a bug traker. It's just an email, so how can I work in
a bug if I don't know about it, have I to find the bugs myself?
^ permalink raw reply
* Re: [PATCH JGIT] Circular references shouldn't be created
From: Shawn O. Pearce @ 2009-09-18 21:20 UTC (permalink / raw)
To: Sohn, Matthias; +Cc: Robin Rosenberg, Avery Pennarun, git@vger.kernel.org
In-Reply-To: <C89280B882467443A695734861B942B28759DEAA@DEWDFECCR09.wdf.sap.corp>
"Sohn, Matthias" <matthias.sohn@sap.com> wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote on Freitag, 18. September 2009 00:52
> > I think we should do this in the UI by not allowing the user to make a
> > choice that would result in a loop and fixing the way the UI resolves
> > choices. When creating a new branch we should analyze the selected
> > ref and dereference it if it is a symbolic name like HEAD or if it is a
> > tag,
> > and perhaps show it like "HEAD (refs/heads/master)" in the the dialog.
> >
> > Using unresolvable refs as the base for a new branch should be
> > disallowed.
>
> If we would do it in the EGit UI how about catching such cases
> in other applications using JGit ?
I agree with Matthias here, other applications using JGit will
also want to be able to detect a ref loop at ref creation time,
and also at ref reading time. We should put the test function into
JGit and allow the UI to call that test function to determine if
creating that symref right now would create a loop. EGit UI can
then use that function to qualify the user's selection, and prevent
the user from making a choice which would create a loop.
--
Shawn.
^ permalink raw reply
* Re: Big project, slow access!
From: Nicolas Pitre @ 2009-09-18 20:19 UTC (permalink / raw)
To: Thiago Farina; +Cc: Toan Pham, git
In-Reply-To: <a4c8a6d00909181205x6b8c348ct270fba6d27df5604@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1384 bytes --]
On Fri, 18 Sep 2009, Thiago Farina wrote:
> On Fri, Sep 18, 2009 at 3:38 PM, Toan Pham <tpham3783@gmail.com> wrote:
> > Hi,
> >
> > I use git to maintain a project that is at least 8 gigs in size.
> > The project is a Linux from Scratch repository that includes source
> > codes to approximately 2000 open source projects,
> > gcc tool-chain, 1000+ configurations for different software packages,
> > source code for different kernel versions,
> > and many linux distributions/flavors resulted from this LFS build environment.
> >
> > The git's object repository is now 4.6 gigs and consists of approx.
> > 610,000 files and folders.
> > The speed of git is now terribly slow. Each time I use basic commands
> > like 'git status' or 'git diff',
> > it would take at least 5 minutes for git to give me back a result.
> > Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
> >
> > would someone please recommend on how i can optimize git's performance?
> > Git is so slow, are there better ways to manage a project like this?
> Git is so slow? What you expect with 4.6 gigs? It take some time to do
> the things. And it is not slow. It is very fast, and it was created
> with this goal, to be more fast than others VCS.
I wrote some piece of the code in Git and I do know how it is
possible for git to become very slow. Denying it is not the way to go.
Nicolas
^ permalink raw reply
* Re: very slow "git gc --aggressive" in GIT-1.6.4.4
From: Michael Andreen @ 2009-09-18 19:56 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0909181223j1ffc99edkdb3700adb37fa147@mail.gmail.com>
On Friday 18 September 2009 21:23:59 Leo Razoumov wrote:
> I noticed that "git gc --agressive" takes 5 times longer with
> git-1.6.4.4 than with git-1.6.2.5.
>
> Below are benchmarks on my Linux Ubuntu-9.04 laptop (Core2 Duo 2.54GHz).
> As a test repo I use a mirror of the official GIT upstream.
git-1.6.3 and later changed the settings for --aggressive to window=250 and
depth=250, which produces a tighter pack. The earlier setting wasn't really
aggressive.
/Michael
^ permalink raw reply
* Re: merge ignores --no-commit in fast-forward case
From: Greg Price @ 2009-09-18 19:47 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vocpfz4gm.fsf@alter.siamese.dyndns.org>
I've hit this issue in scripts where someone has written
if ! git merge some-branch --no-commit; then
# deal or have the user deal
fi
git commit -m '...'
intending that if the merge succeeds it has left the changes from
some-branch uncommitted. And the script works, until for some reason
some-branch is on top of HEAD. So Tomas is not the only person who
was surprised or confused by the present behavior. =)
In this case the workaround is to add --no-ff to the command, which is
effectively what the proposed change would do automatically.
Suppose we were to make such a change in 1.7.0 or a later version.
What would the transition plan need to accomplish? For instance,
we could print a warning every time 'merge --no-commit' does a
fast-forward, and make the change in a later version -- might that suffice?
Cheers,
Greg
PS - Here's one version of a documentation patch for #3.
>From 83282bbbd0c918016e71e4ff6fd8a823315fed0e Mon Sep 17 00:00:00 2001
From: Greg Price <price@ksplice.com>
Date: Fri, 18 Sep 2009 15:34:19 -0400
Subject: [PATCH] Document behavior of --no-commit on fast forward.
This behavior can be surprising, so document it.
Signed-off-by: Greg Price <price@ksplice.com>
---
Documentation/merge-options.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/merge-options.txt
b/Documentation/merge-options.txt
index adadf8e..6015e5d 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -31,7 +31,10 @@
--no-commit::
Perform the merge but pretend the merge failed and do
not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
+ further tweak the merge result before committing. If the
+ merge resolved as a fast-forward, the branch pointer will
+ be updated as usual; --no-ff can be combined with this
+ option to always preserve the branch pointer.
--commit::
Perform the merge and commit the result. This option can
--
1.6.3.1.499.ge7b8da
^ permalink raw reply related
* very slow "git gc --aggressive" in GIT-1.6.4.4
From: Leo Razoumov @ 2009-09-18 19:23 UTC (permalink / raw)
To: Git Mailing List
I noticed that "git gc --agressive" takes 5 times longer with
git-1.6.4.4 than with git-1.6.2.5.
Below are benchmarks on my Linux Ubuntu-9.04 laptop (Core2 Duo 2.54GHz).
As a test repo I use a mirror of the official GIT upstream.
GIT-v1.6.4.4
-----------------
git.upstream> time git gc --agressive
Counting objects: 105217, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (103507/103507), done.
Writing objects: 100% (105217/105217), done.
Total 105217 (delta 77228), reused 0 (delta 0)
git gc --aggressive 168.31s user 0.58s system 180% cpu 1:33.52 total
GIT-1.6.2.5.LR1
---------------------
git.upstream> time git gc --aggressive
Counting objects: 105217, done.
Delta compression using 2 threads.
Compressing objects: 100% (103507/103507), done.
Writing objects: 100% (105217/105217), done.
Total 105217 (delta 76235), reused 0 (delta 0)
git gc --aggressive 30.97s user 0.48s system 141% cpu 22.177 total
==========================================
168 seconds for git-1.6.4.4 versus 22 seconds for git-1.6.2.5.
What gives?
--Leo--
^ permalink raw reply
* Re: [PATCHv2] git-log --format: Add %B tag with %B(x) option
From: Junio C Hamano @ 2009-09-18 19:12 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <1253296845-17219-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> %B(c5) is simply no ident, while %B(5c) is 5 spaces indent. Don't know if this
> is unwanted behaviour, but that's what strtol gives us.
Not really.
"strto[u]l(arg, &endp, 10)" parses arg as a decimal and moves "char *endp"
to point at where the number ended, so you can tell things like:
- return value of 0 with (arg == endp) being "an empty input, the user
did not necessarily meant zero"; or
- (*endp != '\0') being "some garbage after the number".
^ permalink raw reply
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Junio C Hamano @ 2009-09-18 19:11 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00909180802r713d7644mcb4e98ae4352a03a@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> This release candidate freeze is a period that no one can send patches?
No.
After -rc1, only fixes to regressions and severe bugs and trivially
correct documentation patches will be applied to my tree, but all other
kinds of patches are still sent to the list for discussion, so that the
proposed changes can be discussed, polished and then become ready for the
development cycle after the upcoming release. I often even pick them up
and queue them to 'pu' and possibly 'next' as time permits.
> Only you
> merge the patches into the master branch? When someone send a patch,
> you get it, make a topic-branch in your private repository, and if it
> is good it will be merged into 'pu branch'?
"A note from the maintainer" I send out every once in a while (also can be
seen at http://members.cox.net/junkio/) explains how things work.
> And what did you mean with code churn?
A change primarily for the sake of change without urgency nor real benefit
in the longer term.
It bothers nobody if a long literal string is written as a string literal
in a dq pair with LFs quoted with backslashes, or as a run of multiple
string literals, each of which ending with LF, to be concatenated by the
compiler. It however would bother somebody who actually wants to modify
these lines for a real change, and that is the best time for doing such a
clean-up. Reasons for such a real change vary; to fix earlier mistakes
(e.g. one line being excessively longer than others, or an option is
misspelled), to add a new option, or to make the output of the program
easier to read in general, etc.
>> A real improvement patch from that somebody _could_ be to remove the
>> trailing whitespaces from the output string, and in that case I would not
>> mind if two patches (one preparatory patch which is this one, and the
>> other being the removal of trailing whitespaces) were squashed together.
>> In fact, in such a trivial case, it probably be better to squash them into
>> one.
> If I understand correctly, do you want a function...
No.
What I meant was that I might have said it is a real improvement if your
patch also removed the trailing whitespace from the literal string, as I
hinted in my original response.
Such a submission may have looked like this. Notice that the changing of
the style for multi-line string literal is "while at it". I called a
patch whose only change falls into that category a needless code churn.
-- >8 --
Subject: [PATCH] pack-objects: remove SP at the end of usage string
From: Thiago Farina <tfransosi@gmail.com>
These spaces immediately before the end of lines are unnecessary.
While at it, instead of using a single string literal with backslashes
at end of each line, split the lines into individual string literals
and tell the compiler to concatenate them.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-pack-objects.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7a390e1..02f9246 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -22,15 +22,15 @@
#include <pthread.h>
#endif
-static const char pack_usage[] = "\
-git pack-objects [{ -q | --progress | --all-progress }] \n\
- [--max-pack-size=N] [--local] [--incremental] \n\
- [--window=N] [--window-memory=N] [--depth=N] \n\
- [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
- [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
- [--stdout | base-name] [--include-tag] \n\
- [--keep-unreachable | --unpack-unreachable] \n\
- [<ref-list | <object-list]";
+static const char pack_usage[] =
+ "git pack-objects [{ -q | --progress | --all-progress }]\n"
+ " [--max-pack-size=N] [--local] [--incremental]\n"
+ " [--window=N] [--window-memory=N] [--depth=N]\n"
+ " [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]\n"
+ " [--threads=N] [--non-empty] [--revs [--unpacked | --all]*]\n"
+ " [--reflog] [--stdout | base-name] [--include-tag]\n"
+ " [--keep-unreachable | --unpack-unreachable \n"
+ " [<ref-list | <object-list]";
struct object_entry {
struct pack_idx_entry idx;
^ permalink raw reply related
* Re: Big project, slow access!
From: Thiago Farina @ 2009-09-18 19:05 UTC (permalink / raw)
To: Toan Pham; +Cc: git
In-Reply-To: <ffb2c0280909181138r7fde8722n80be4bdf95864c37@mail.gmail.com>
On Fri, Sep 18, 2009 at 3:38 PM, Toan Pham <tpham3783@gmail.com> wrote:
> Hi,
>
> I use git to maintain a project that is at least 8 gigs in size.
> The project is a Linux from Scratch repository that includes source
> codes to approximately 2000 open source projects,
> gcc tool-chain, 1000+ configurations for different software packages,
> source code for different kernel versions,
> and many linux distributions/flavors resulted from this LFS build environment.
>
> The git's object repository is now 4.6 gigs and consists of approx.
> 610,000 files and folders.
> The speed of git is now terribly slow. Each time I use basic commands
> like 'git status' or 'git diff',
> it would take at least 5 minutes for git to give me back a result.
> Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
>
> would someone please recommend on how i can optimize git's performance?
> Git is so slow, are there better ways to manage a project like this?
Git is so slow? What you expect with 4.6 gigs? It take some time to do
the things. And it is not slow. It is very fast, and it was created
with this goal, to be more fast than others VCS.
>
>
> Thank you.
>
>
> Toan
> --
> 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
* Re: Big project, slow access!
From: Nicolas Pitre @ 2009-09-18 19:02 UTC (permalink / raw)
To: Toan Pham; +Cc: git
In-Reply-To: <ffb2c0280909181138r7fde8722n80be4bdf95864c37@mail.gmail.com>
On Fri, 18 Sep 2009, Toan Pham wrote:
> Hi,
>
> I use git to maintain a project that is at least 8 gigs in size.
> The project is a Linux from Scratch repository that includes source
> codes to approximately 2000 open source projects,
> gcc tool-chain, 1000+ configurations for different software packages,
> source code for different kernel versions,
> and many linux distributions/flavors resulted from this LFS build environment.
How did you organize things in your repository?
> The git's object repository is now 4.6 gigs and consists of approx.
> 610,000 files and folders.
> The speed of git is now terribly slow. Each time I use basic commands
> like 'git status' or 'git diff',
> it would take at least 5 minutes for git to give me back a result.
Did you repack your repository? If so, what parameter did you use?
> Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
If so you'll have problems repacking your repository. You'd need a
64-bit machine with enough RAM to be able to make the repository fully
packed, so it might then be tight enough to fit more confortably on a
32-bit machine afterwards.
> would someone please recommend on how i can optimize git's performance?
> Git is so slow, are there better ways to manage a project like this?
You could have a look at submodule support.
Nicolas
^ permalink raw reply
* Big project, slow access!
From: Toan Pham @ 2009-09-18 18:38 UTC (permalink / raw)
To: git
Hi,
I use git to maintain a project that is at least 8 gigs in size.
The project is a Linux from Scratch repository that includes source
codes to approximately 2000 open source projects,
gcc tool-chain, 1000+ configurations for different software packages,
source code for different kernel versions,
and many linux distributions/flavors resulted from this LFS build environment.
The git's object repository is now 4.6 gigs and consists of approx.
610,000 files and folders.
The speed of git is now terribly slow. Each time I use basic commands
like 'git status' or 'git diff',
it would take at least 5 minutes for git to give me back a result.
Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
would someone please recommend on how i can optimize git's performance?
Git is so slow, are there better ways to manage a project like this?
Thank you.
Toan
^ permalink raw reply
* [PATCHv2] git-log --format: Add %B tag with %B(x) option
From: Johannes Gilger @ 2009-09-18 18:00 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Schindelin, Johannes Gilger
In-Reply-To: <7vk4zxgnim.fsf@alter.siamese.dyndns.org>
Since one can simply use spaces to indent any other --pretty field we
should have an option to do that with the body too.
Also the %B flag strips the trailing newlines, to enable more compact
display.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
Hi again,
I followed Junio's implementation-advice. Since we have two placeholders which
take () arguments I put the scanning for those at the top, to avoid repetition.
I used strtol in place of atoi and I also had to to add a check for ident > 0
since the indent determines the growth-size of the buffer, and negative values
produced nasty stuff (obviously).
As for general extendability: The current code deals with %B(42) as well as
%B(42,23[,...]), so even old versions could be used with "new" pretty-formats.
%B(c5) is simply no ident, while %B(5c) is 5 spaces indent. Don't know if this
is unwanted behaviour, but that's what strtol gives us.
Dscho sent me a pointer to a patch [1], which not only adds indent but also
rewrapping. But since this is my second patch and Dscho's patch depended on two
other patches I didn't want to get in over my head by making his patches a
prerequisite.
A last word on future formats: We can use (x,y,z) easily, another thing one
might think of (or at least I do) is using an %an[20] syntax, returning only
the first 20 chars of %an, so one can make onelined outputs nicely
column-aligned for fields like the author.
Greetings,
Jojo
[1] - http://repo.or.cz/w/git/dscho.git?a=commit;h=ad48dfca58169c35e227e135638b4970fe4dc9a5
Documentation/pretty-formats.txt | 2 ++
pretty.c | 25 ++++++++++++++++++++-----
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..533bc5e 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -123,6 +123,8 @@ The placeholders are:
- '%s': subject
- '%f': sanitized subject line, suitable for a filename
- '%b': body
+- '%B': body without trailing newline
+- '%B(x)': body indented by x spaces
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
diff --git a/pretty.c b/pretty.c
index f5983f8..7b88827 100644
--- a/pretty.c
+++ b/pretty.c
@@ -605,13 +605,17 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
int h1, h2;
/* these are independent of the commit */
+
+ const char *body = msg + c->body_off;
+ const char *end = NULL;
+ /* check if we have arguments to the placeholder */
+ if (placeholder[1] == '(')
+ end = strchr(placeholder + 2, ')');
+
switch (placeholder[0]) {
case 'C':
- if (placeholder[1] == '(') {
- const char *end = strchr(placeholder + 2, ')');
+ if (end) {
char color[COLOR_MAXLEN];
- if (!end)
- return 0;
color_parse_mem(placeholder + 2,
end - (placeholder + 2),
"--pretty format", color);
@@ -733,7 +737,16 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
format_sanitized_subject(sb, msg + c->subject_off);
return 1;
case 'b': /* body */
- strbuf_addstr(sb, msg + c->body_off);
+ strbuf_addstr(sb, body);
+ return 1;
+ case 'B': /* body without trailing newline */
+ if (end) {
+ pp_remainder(CMIT_FMT_MEDIUM, &body, sb, strtol(placeholder + 2, NULL, 10));
+ strbuf_rtrim(sb);
+ return end - placeholder + 1;
+ }
+ strbuf_addstr(sb, body);
+ strbuf_rtrim(sb);
return 1;
}
return 0; /* unknown placeholder */
@@ -875,6 +888,8 @@ void pp_remainder(enum cmit_fmt fmt,
}
first = 0;
+ if (indent < 0)
+ indent = 0;
strbuf_grow(sb, linelen + indent + 20);
if (indent) {
memset(sb->buf + sb->len, ' ', indent);
--
1.6.5.rc1.20.geb7d9
^ permalink raw reply related
* Re: [PATCH] git-push: add option --repo-all
From: Junio C Hamano @ 2009-09-18 16:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <m3r5u43a8h.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> I have created 'pushall' *alias* for that purpose, but I think that
> such functionality would be better added to "git remote" rather than
> to "git push".
Also Linus added a mystery feature that you can have more than one pushURL
to a [remote "there"] section to push to multiple places quite a while
ago, so use of it is another possibile solution for what Kirill wants to
solve.
I do not think it is such a useful command line option that can be used to
only say "everything"; your suggestion to hook into the grouping mechanism
"git remote" has sounds much nicer.
Thanks.
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Johannes Sixt @ 2009-09-18 15:16 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Murphy, John, git
In-Reply-To: <878wgcbb52.fsf@users.sourceforge.net>
Pat Thoyts schrieb:
> "Murphy, John" <john.murphy@bankofamerica.com> writes:
>> There is a error when running gitk --all when there are more than 797 refs in a repository.
>> We get an error message:
>>
>> Error reading commits: fatal ambiguous argument '3': unknown revision or path not in the working tree.
>> Use '--' to separate paths from revisions.
>>
>> I believe issue is with this line of the code in proc parseviewrevs:
>>
>> if {[catch {set ids [eval exec git rev-parse "$revs"]} err]}
>>
>> When there are more than 797 refs the output of git rev-parse is too large to fit into the string, ids.
>>
>> 797 refs = 32,677 bytes.
>> 798 refs = 32,718 bytes my guess is a little too close for comfort to 32,768 bytes.
>>
>> As I was deleting refs locally the error message would change from '3' to any char [A-Z,0-9].
I cannot reproduce the error. I have a repository with 100 commits in a
linear history and 5000 refs (50 refs per commit). They are named
refs/heads/branch-XXXX. I don't see any problems with 'gitk --all'.
> +proc git-rev-parse {args} {
> + set ids {}
> + set pipe [open |[linsert $args 0 git rev-parse] r]
> + while {[gets $pipe line] != -1} {
> + lappend ids $line
> + }
> + close $pipe
> + return $ids
> +}
> +
> proc parseviewrevs {view revs} {
> global vposids vnegids
>
> if {$revs eq {}} {
> set revs HEAD
> }
> - if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
> + if {[catch {set ids [git-rev-parse $revs]} err]} {
Sorry, but you are changing the wrong end of git rev-parse. The limit is
on the command line, but if you run 'gitk --all', then $revs is simply
"--all" - no limit is exceeded. You changed the output of rev-parse, but
there is no limit on how much Tcl can eat of rev-parse's output.
The error must be in some other git invocation.
-- Hannes
^ 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