* [PATCHv4] git-log --format: Add %B tag with %B(n) option
From: Johannes Gilger @ 2009-09-22 21:30 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Schindelin, Johannes Gilger
In-Reply-To: <7vfxaercma.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>
---
Hey,
I moved the indent >= 0 check to the caller. Also changed the documentation, n
should indicate more strongly that n is supposed to be a natural number.
You mentioned small style issues but I'm not sure what you meant. One thing
that could be made more compact is calling
pp_remainder(CMIT_FMT_MEDIUM, &body, sb, indent < 0 ? 0 : indent);
and thereby saving two extra lines. I saw this at a lot of other spaces in
git.git, but saw no specific guideline in CodingGuidelines.
Yet another option is aborting for negative indent values, issuing return 0;
Greetings,
Jojo
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..ca694c9 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(n)': %B indented by n 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..dafa8e0 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,22 @@ 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 != ')')
+ return 0;
+ if (indent < 0)
+ indent = 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 */
--
1.6.5.rc1.38.g1fbd3
^ permalink raw reply related
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Pat Thoyts @ 2009-09-22 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <7vws3ru4w8.fsf@alter.siamese.dyndns.org>
(nobody) writes:
>Junio C Hamano <gitster@pobox.com> writes:
>
>> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>>
>> That looks like an ugly hack (aka sweeping the issue under the rug).
>>
>> What if there are many tags and the user used --tags? Don't you have
>> exactly the same problem? Likewise, what if $revs were "..master"?
>
>Sorry, I meant "--all --not master" to grab all the topics not merged to
>master yet.
>
>But my point still stands.
Not exactly. The problem is that the call to parseviewrevs will expand
--all into a tcl list containing all the revision ids. We can do some
testing if we dig into this with the tcl console:
% llength [set revs [parseviewrevs {} --all]]
1001
% string length $revs
41040
In start_rev-list this list gets added to the command line for git-log
in the $args variable. This is always going to exceed windows'
commandline limit (32k).
Some testing shows that a number of rev-parse arguments do not get
expanded into a list of ids. All these can be ignored. But --all,
--tags and --branches do. Maybe --remotes as well.
These arguments are accetable to git-log so it looks to me like they
can be left as-is.
The vposids and vnegids arrays are getting used for something
though. So the patch is not complete. They appear to be caching the
set of revisions present in the current view for use in updatecommits
to do something.
So - needs more work.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Paul Mackerras @ 2009-09-22 23:30 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Johannes Sixt, Murphy, John, git
In-Reply-To: <874oqvc0n3.fsf@users.sourceforge.net>
Pat Thoyts writes:
> That script gives me a repository I can test against. thanks.
> The start_rev_list function calls parseviewrevs and expands the
> arguments into a list of appropriate revision ids. In this case --all
> gets expanded to a list of 1000 sha1 ids. This is appended to any
> other view arguments and passed to git log on the command line
> yielding our error.
> git log can accept a --all argument it seems so it looks like we can
> just short-circuit the parseviewrevs function when --all is passed in
> and return --all instead of expanding the list. The following seems to
> work for me with this test repository.
What the code is trying to do here is to get git log to give us all
the commits that the user asked for *except* any commits we have
already received. So, when gitk is first invoked, this means all the
commits that the user asked for. If the user presses F5 or does
File->Update, then we do git log with some starting points removed
(those that haven't changed since the last update) and some negative
arguments added (to exclude the previous starting points).
To do that accurately, we need to know exactly what set of revisions
we are asking git log to start from, and exactly what set of revisions
we are asking git log to stop at. The problem with just passing --all
to git log, as your patch does, is that the list of revs might change
between when gitk expands --all and when git log expands --all (due to
commits getting added, heads getting reset etc.). Then, if the user
presses F5, some commits might get missed.
If git log had an argument to tell it to mark those commits that were
a starting point or a finishing point, then I could simplify this
logic enormously, plus we wouldn't have to pass a long parameter list
to git log. It may still turn out to be necessary to add a negative
argument for each previous starting point, though, when refreshing the
list.
I think the simplest fix for now is to arrange to take the
non-optimized path on windows when the list of revs gets too long,
i.e., set $vcanopt($view) to 0 and take that path. That means that
refreshing the view will be slow, but I think it's the best we can do
at this point.
Paul.
^ permalink raw reply
* [PATCH] Documentation: Update the style of 'git-describe' command.
From: Thiago Farina @ 2009-09-22 23:48 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Update the old version 'git-describe' that appears in the documentation.
Since the new version is prefered, use 'git describe' instead.
Also changes 'committish' to 'commit-ish', since the latter form is the most
used.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
Documentation/gitcli.txt | 2 +-
builtin-describe.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index be39ed7..b6c0637 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -81,7 +81,7 @@ couple of magic command line options:
+
---------------------------------------------
$ git describe -h
-usage: git-describe [options] <committish>*
+usage: git describe [options] <commit-ish>*
--contains find the tag that comes after the commit
--debug debug search strategy on stderr
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..961deb4 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -10,7 +10,7 @@
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
- "git describe [options] <committish>*",
+ "git describe [options] <commit-ish>*",
NULL
};
--
1.6.5.rc1.44.ga1675
^ permalink raw reply related
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-09-23 0:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Pat Thoyts, Johannes Sixt, Murphy, John, git
In-Reply-To: <19129.24056.422939.880134@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> If git log had an argument to tell it to mark those commits that were
> a starting point or a finishing point, then I could simplify this
> logic enormously, plus we wouldn't have to pass a long parameter list
> to git log. It may still turn out to be necessary to add a negative
> argument for each previous starting point, though, when refreshing the
> list.
>
> I think the simplest fix for now is to arrange to take the
> non-optimized path on windows when the list of revs gets too long,
> i.e., set $vcanopt($view) to 0 and take that path. That means that
> refreshing the view will be slow, but I think it's the best we can do
> at this point.
Hmph.
The negative ones you can learn by giving --boundary, but I do not think
the set of starting points are something you can get out of log output.
Even if you could, you would have the same issue giving them from the
command line anyway. The right solution would likely to be to give the
same --stdin option as rev-list to "git log", I think.
^ permalink raw reply
* Re: [PATCH] Documentation: Update the style of 'git-describe' command.
From: Junio C Hamano @ 2009-09-23 0:07 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253663286-5919-1-git-send-email-tfransosi@gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> $ git describe -h
> -usage: git-describe [options] <committish>*
> +usage: git describe [options] <commit-ish>*
I think the first half of this line is correct but the other half is not.
$ git grep --color -c -e committish -- Documentation/
Documentation/git-describe.txt:6
Documentation/git-fast-import.txt:8
Documentation/git-name-rev.txt:1
Documentation/git-shortlog.txt:1
Documentation/gitcli.txt:1
Documentation/howto/revert-branch-rebase.txt:1
$ git grep --color -c -e commit-ish -- Documentation/
Documentation/git-rebase.txt:1
Documentation/git.txt:2
^ permalink raw reply
* Re: [PATCH] builtin-mailinfo.c: Trim only first pair of square brackets in subject
From: Jason Holden @ 2009-09-23 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neil Roberts, git
In-Reply-To: <7vocp3t0oz.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I think we all agree that the behaviour should be improved, but I think
> neither Roger's patch nor Andreas's one was the solution.. People who
> care need to carry discussions and proposed patches forward to help us
> agree on an acceptable solution.
An additional use case for this is that at $dayjob, we use GForge
Advanced Server. With GForge, commits are tied to the bug-tracker
by including the bug-id in the commit message with the syntax
[#NNN], where NNN is a unique id for each submitted bug.
So the typical first line of a commit message looks something like:
[#100] Fix bug in foo.c
sent using git-send-email, this becomes
[PATCH] [#100] Fix bug in foo.c
But of course, both [PATCH] and [#100] get stripped off when applied
with git-am, forcing a manual edit.
The reg-expression stuff isn't necessary for my particular use-case.
Stripping off brackets that have any variant of "PATCH" in them, or
just stripping off the first set of brackets would work for me.
--
Regards,
Jason Holden
^ permalink raw reply
* Re: [PATCH] Documentation: Update the style of 'git-describe' command.
From: Thiago Farina @ 2009-09-23 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3a6eo759.fsf@alter.siamese.dyndns.org>
On Tue, Sep 22, 2009 at 8:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> $ git describe -h
>> -usage: git-describe [options] <committish>*
>> +usage: git describe [options] <commit-ish>*
>
> I think the first half of this line is correct but the other half is not.
>
> $ git grep --color -c -e committish -- Documentation/
> Documentation/git-describe.txt:6
> Documentation/git-fast-import.txt:8
> Documentation/git-name-rev.txt:1
> Documentation/git-shortlog.txt:1
> Documentation/gitcli.txt:1
> Documentation/howto/revert-branch-rebase.txt:1
>
> $ git grep --color -c -e commit-ish -- Documentation/
> Documentation/git-rebase.txt:1
> Documentation/git.txt:2
I did this:
git$ grep --color -n "commit-ish" *.c
builtin-revert.c:29: "git revert [options] <commit-ish>",
builtin-revert.c:34: "git cherry-pick [options] <commit-ish>",
builtin-send-pack.c:368: * (3) if both new and old are commit-ish,
and new is a
remote.c:1388: /* Both new and old must be commit-ish and new is descendant of
git$ grep --color -n "committish" *.c
builtin-describe.c:13: "git describe [options] <committish>*",
builtin-merge.c:885: * committish that is the same as HEAD there instead.
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-23 4:43 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <d2e97e800909220254sc677abeia220c19f6ef5bd28@mail.gmail.com>
2009/9/22 Michael Wookey <michaelwookey@gmail.com>:
> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>> On another note, I see *many* build warnings for things like
>>> "signed/unsigned compares". I'd be willing to work through these warnings
>>> and fix them. Thoughts?
>>
>> Well, first find out why these are a problem with MSVC and not GCC. Are the
>> types different on these platforms? signed vs unsigned should show up with
>> GCC as well. We need to make sure that we don't fix signed/unsigned issues
>> on one platform, just to introduce it to another platform.
>> In any case, it would be good for someone to have a look at these, just so
>> we can determine the cause for most of them, and then we should figure out
>> on the list how to deal with them.
>
> Well, at warning level 4, MSVC is quite verbose. Perhaps the current
> gcc build flags are more forgiving?
Ah, gcc does produces similar warnings when "-Wextra" is added to the CFLAGS:
CFLAGS = -g -O2 -Wall -Wextra
IMHO, warnings such as these should be worked through and fixed, or
there may be some latent bug waiting to appear.
^ permalink raw reply
* Re: [PATCH v3] Trivial fix: Make all the usage strings to use the same pattern.
From: Junio C Hamano @ 2009-09-23 5:16 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00909221255i2f45e19ex95a13b027886d3e4@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> On Tue, Sep 22, 2009 at 4:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> What does this _fix_?
> The answer here is nothing. But I think the benefit is to a have a
> pattern, but if it is _not_ desired, I can stop here.
That was not what I asked.
What does this _fix_? Does the benefit of this patch outweigh the
cost, and if it does, in what way?
Does the benefit of "having a pattern" outweigh the cost of this patch?
That was the primary question.
The same patch, depending on the time it is considered for inclusion, can
have different cost. Because it is about cost vs benefit ratio, asking
"is it desired?" has no black/white answer.
If we were writing git from scratch, we would have written things in a way
that matches a certain pattern, so the answer to the question for any
"needless churn to bring a pattern in" patch would be "yes", but that is
only true if we _were_ writing git from scratch.
But because we are not, changes involve some cost. Is it worth the pain?
What is the best way to minimize the pain, and when is the best time to
apply such a patch? These are the concerns a maturing project has to
worry about a patch like this.
The answer at this point is a _very_ qualified "maybe". Yes, if it were
pain-free, having a pattern would be much better than not having one. If
on the other hand if that means people need to re-re-review 2500 lines of
patch every 15 minutes and I have to resolve needless conflicts,...
If I were you, I'd pretend as if I have only one chance left, and try to
come up with a perfect [*1*] patch that does not touch any file that is
different between master and next, and follow it up with a set of separate
patches for files that are different between master and next, one patch
per file.
[Footnote]
*1* that means no "Huh? Why is bisect_helper's usage named differently
from others?" kind of glitches anywhere.
^ permalink raw reply
* Feature Enhancement Idea.
From: Deon George @ 2009-09-23 6:17 UTC (permalink / raw)
To: git
Hi,
I'm not sure if this is the right place, but I thought I'd post my
idea and maybe somebody will either redirect me to the right place, or
give me that "that wont happen".
Im fairly new to GIT (wish I had discovered it long ago), and I really
like using it - great work guys/garls :)
My idea is to enhance GIT to support (I'll call it) development
"layers". The current design of GIT is that the working repository and
working directory assume that all files belong together in the same
project. I would like to see GIT go 3D and support layers, so that
files (and/or file content) can belong to multiple repositories (or
considered unique projects), even though the working tree presents all
files as if they were one.
To explain further...
Lets say, I am not the primary developer of a project, however I am a
"module"/"plugin"/"addon" contributor to a project - ie: my primary
involvement is to write additions to existing projects. (EG: I
write/support a driver in the kernel (that is not included in the base
tree), or I write an "addon" to an existing application, using that
existing applications "module" capability).
As part of me developing my "module" (or modules if I develop more
than one), I need the working tree to have the "base" and "my bits". I
want to manage both the changes I make to "my bits", and also record
any changes that need to be made to the "base" (so that "my module(s)"
will work). Normally, the changes to the "base" would be submitted
upstream (and hopefully accepted), while I would normally be
responsible for the packaging and change control of "my bits".
If the upstream chooses not to accept my contributions (ie: my changes
never appear in base), then whenever I package "my bits", GIT would
also include the base components as well.
I know I can achieve some of this by using GIT branches (I've been
doing that so far), however, GIT branches has a few limitations that I
am sure that GIT "layers" would overcome... Ultimately, I believe GIT
can handle my layers idea - and it should be possible to have multiple
layers (where multiple components could come from different GIT
repositories), however, they are all "checked out" into the one
working tree.
Thinking about this further, there would be two possible layer
scenarios (I think GIT can handle both).
* File autonomy (most cases)
This is where files (by filename) belong to different projects. EG: If
my working tree had files "a, b & c", "1, 2 & 3", and "X Y & Z". Files
"abc" could be layer one (the base), files "123" could be layer two
(dependant on base) and files XYZ could be layer three (which could be
dependant on base OR dependant on layer two).
Whenever modifications were done to any file, GIT would know which
layer owns the file and GIT processing is done as normal. Upstream
pulls from any layer should not normally generated any conflicts,
unless there are filename clashes between layers (and in this
situation the layer hierarchy should be considered authoritative, with
the conflict needed to be resolved in a lower layer.)
* Content autonomy
This is were some content in files belongs to "my work" (eg: Modifying
a Makefile to compile my work when the base is compiled). In this
situation, I may have two outcomes - I either want the changes to
flagged for upstream (to hopefully be included), or I may want to keep
the changes with my work, because I know it upstream would never
accept them (or it isnt appropriate).
In either cases, upstream pulls should be considered authoritative and
any conflicts I would need to resolve as normal commit (either wanting
them to be resubmittable for upstream, or commiting them as part of my
work.)
Like I mentioned, I can achieve some of this by the use of branches
already, however, where it comes complicated, is when:
* I commit a change to the wrong branch (and thus upstream will never
see my enhancements),
* I want to identify changes to one layer (that I went to send to
upstream for review), without including the other layers (because it
probably isnt relevant)
* I want to work on more than one layer (I need to be diligent about
pulling and merging)
An example of usage might be:
* git clone ... (or git init) -layer "A"
* git checkout -b mywork -layer "A"
* git clone ... (or git init) -layer "B" -dependson "A"
* git checkout -b mymodule -layer "B"
* add/remove/edit files
* git add file x -layer "A"
* git add file y -layer "B"
* git rm file z -layer "A"
* git commit (as usual)
* git tag "V2.8" -layer "A"
* git tag "mymodule V1.0" -layer "B"
git diff -layer "A" mywork.. would show my changes that I would want
sent upstream (without mymodule commits)
git archive -layer "B" would package up my module for distribution
(without layer "A")
git archive -layer "A" would package up my version of layer A (without
layer "B")
Could this be included as part of GITs functionality (or is it
possible already) ?
...deon
^ permalink raw reply
* Re: git-svn-problem: Unnecessary downloading entire branch?
From: Eric Wong @ 2009-09-23 6:55 UTC (permalink / raw)
To: Martin Larsson; +Cc: git
In-Reply-To: <1253102039.6509.143.camel@martin>
Martin Larsson <martin.liste.larsson@gmail.com> wrote:
> I have a local git-copy of the company svn-repository. The git-copy is
> up-to-date (git svn fetch). I then add a new branch in the
> svn-repository (svn cp http://.../trunk http://...branches/JIRA-4444).
> When I then do 'git svn fetch' again, it pulls all the files from the
> svn-repository.
>
> I was expecting it to only pull the fact that a new branch was made
> (taking milliseconds), not all the files in the branch (taking more than
> half an hour to complete). Why does it need to transfer all the files?
Are some branches at a different depth in the repository? E.g:
project/trunk
project/branches/feature-a
project/branches/martin/feature-b
project/branches/martin/feature-c
project/branches/feature-d
project/branches/feature-e
Basically a refs layout like this in your $GIT_CONFIG:
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/*:refs/remotes/*
Is going to get git svn confused and think "martin" is a branch when
it is rather a container of a branch.
However if you have a consistent depth and two branch containers
("martin" and his evil twin, "nitram"):
project/trunk
project/branches/martin/feature-b
project/branches/martin/feature-c
project/branches/nitram/feature-a
project/branches/nitram/feature-d
project/branches/nitram/feature-e
As of git v1.6.4, you can repeat "branches" or "tags" lines in
$GIT_CONFIG thanks to Marc Branchaud:
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/martin/*:refs/remotes/martin/*
branches = project/branches/nitram/*:refs/remotes/nitram/*
This is a known problem with the (extremely flexible and therefore
inconsistent) way SVN repositories can be laid out.
> I did have problems getting the original svn-repository. It took several
> days and stopped several times in the process. Each time it stopped, I
> just issued 'git svn fetch' again and it seemed to continue. Could this
> be related? How could I make a better copy?
It could be the server disconnecting you or a bad Internet connection.
Resuming "git svn fetch" should be perfectly safe, though.
--
Eric Wong
^ permalink raw reply
* What's cooking in git.git (Sep 2009, #05; Wed, 23)
From: Junio C Hamano @ 2009-09-23 6:56 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
We are in pre-release feature freeze. 'next' will hold topics meant for
1.6.6 and 1.7.0.
Tonight's tip of 'master' is 1.6.5-rc2, and I'll disappear for about a
week. Hopefully when I come back in early October all the regressions are
found and already squashed ;-)
--------------------------------------------------
[New Topics]
* jc/fix-tree-walk (2009-09-14) 9 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
and I am only half satisfied with the current status of the series.
To fix the resolve merge regression seen in t6035, git-merge-resolve needs
to be rewritten not to use the one-path-at-a-time "git merge-index".
* jp/fetch-tag-match (2009-09-17) 1 commit
- fetch: Speed up fetch by rewriting find_non_local_tags
I did not have much energy left while dealing with the "fix-tree-walk"
series, so I just queued this without reading nor thinking about it very
much. I personally liked my version that had far smaller number of lines
changed (which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain. We'll see.
* jg/log-format-body-indent (2009-09-19) 1 commit
- [NEEDSWORK: tests] git-log --format: Add %B tag with %B(x) option
* jl/submodule-add-noname (2009-09-22) 1 commit
- git submodule add: make the <path> parameter optional
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
Tonight's 'pu' ships with this and this series seems to break a few
tests. I didn't debug.
--------------------------------------------------
[Cooking]
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'. It is a fix for longstanding bug and 1.6.5 will not contain
this topic.
* db/vcs-helper-rest (2009-09-03) 6 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.
* jh/notes (2009-09-12) 13 commits
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- notes.[ch] fixup: avoid old-style declaration
- Teach notes code to free its internal data structures on request.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
Ejected from 'pu' (see jc/fix-tree-walk above).
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-09-15 at 9cbfa00)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
(merged to 'next' on 2009-09-07 at 165dc3c)
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
Will not be in 1.6.5.
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-09-07 at 3622199)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ping?
* nd/sparse (2009-08-20) 19 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-09-07 at 8a7c563)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-09-06 at 19d4beb)
+ status: typo fix in usage
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #05; Wed, 23)
From: Sverre Rabbelier @ 2009-09-23 8:01 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: git
In-Reply-To: <7vhbuui1ys.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Sep 23, 2009 at 08:56, Junio C Hamano <gitster@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits
> (merged to 'next' on 2009-09-07 at 5f6b0ff)
> + fast-import: test the new option command
> + fast-import: add option command
> + fast-import: test the new feature command
> + fast-import: add feature command
> + fast-import: put marks reading in it's own function
> + fast-import: put option parsing code in separate functions
> (this branch is used by jh/notes.)
>
> Ping?
Ping indeed, Shawn? Blocking on a reply to whether I should drop the
option part and make location of the marks file a feature or not in
general, and $128290 in specific [0].
[0] http://article.gmane.org/gmane.comp.version-control.git/128290
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Christian Couder @ 2009-09-23 8:26 UTC (permalink / raw)
To: Deon George; +Cc: git
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
Hi,
On Wed, Sep 23, 2009 at 8:17 AM, Deon George <deon.george@gmail.com> wrote:
> Hi,
>
> I'm not sure if this is the right place, but I thought I'd post my
> idea and maybe somebody will either redirect me to the right place, or
> give me that "that wont happen".
>
> Im fairly new to GIT (wish I had discovered it long ago), and I really
> like using it - great work guys/garls :)
>
> My idea is to enhance GIT to support (I'll call it) development
> "layers". The current design of GIT is that the working repository and
> working directory assume that all files belong together in the same
> project. I would like to see GIT go 3D and support layers, so that
> files (and/or file content) can belong to multiple repositories (or
> considered unique projects), even though the working tree presents all
> files as if they were one.
Perhaps you could have a look at "git replace" that is now in the master branch.
It could be improved to provide different "views" of a single repository.
I don't think that alone it would provide everything you want though.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH] Initial manually svn property setting support for git-svn
From: Eric Wong @ 2009-09-23 8:58 UTC (permalink / raw)
To: David Fraser; +Cc: git, David Moore
In-Reply-To: <1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>
David Fraser <davidf@sjsoft.com> wrote:
> This basically stores an attribute 'svn-properties' for each file that
> needs them changed, and then sets the properties when committing.
Hi David,
Please wrap your commit messages and emails at 72 columns or less.
All git svn code should be wrapped at 80 or less, too.
> Issues remaining:
> * The way it edits the .gitattributes file is suboptimal - it just
> appends to the end the latest version
Consider using $GIT_DIR/info/attributes or having an option to use that
instead. Keeping a .gitattributes file in the git working tree but
_out_ of SVN is important and required, but also difficult to get right.
There are users working on projects that frown upon using unsupported
clients like git svn, and accidentally checking .gitattributes into
the project would likely annoy non-git users. It's best to keep
*.git* stuff outside of SVN projects unless they allow/want it.
But also you should not fail to consider the case that somebody else did
intentionally commit .gitattributes into svn and you have little choice
but to commit your modifications to .gitattributes. Things like
maintaining a mapping between svn:ignore and .gitignore has never
happened because of the corner cases that could pop up.
> * It could use the existing code to get the current svn properties to
> see if properties need to be changed; but this doesn't work on add
> * It would be better to cache all the svn properties locally - this
> could be done automatically in .gitattributes but I'm not sure
> everyone would want this, etc
It should be possible to infer/rebuild this by parsing unhandled.log
files git svn generates by default. There are definitely people who
don't want .gitattributes being written to automatically.
> * No support for deleting properties
What advantage(s) does having this feature in git svn this give over
using:
svn prop(edit|set|del) ARGS $(git svn info --url)
In my experience, explicitly set properties are rarely-used so I
need to be convinced it's worth supporting in the future.
> Usage is:
> git svn propset PROPNAME PROPVALUE PATH
>
> Added minimal documentation for git-svn propset
We'll also need a test case to ensure it continues working as other
changes get made and refactoring gets done.
> +sub check_attr
> +{
> + my ($attr,$path) = @_;
Please use formatting consistent with the rest of the file. Always use
tabs for indent here.
> + if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
Consider command_output_pipe for better portability/consistency in
Git.pm instead of open(my $fh, "-|", @args) which is Perl 5.8+-only.
Thanks for the effort and keep us informed of improvements you make.
--
Eric Wong
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Johan Herland @ 2009-09-23 9:06 UTC (permalink / raw)
To: git; +Cc: Deon George
In-Reply-To: <5b5e291e0909222317q47ae36d4la470f17ec3902124@mail.gmail.com>
On Wednesday 23 September 2009, Deon George wrote:
> Could this be included as part of GITs functionality (or is it
> possible already) ?
Have a look at git submodules ('git help submodule'), or the git-subtree
script that has been discussed on this list a couple of times [1].
[1] http://alumnit.ca/~apenwarr/log/?m=200904#30 and
http://github.com/apenwarr/git-subtree
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [ANNOUNCE] TopGit 0.8
From: Uwe Kleine-König @ 2009-09-23 9:32 UTC (permalink / raw)
To: git
Cc: Jon Ringle, Bert Wesarg, Ilpo Järvinen, Marc Weber,
Bernhard R. Link, martin f. krafft
Hello,
I'm happy to announce that TopGit 0.8 was released today.
TopGit aims to make handling of large amount of interdependent topic
branches easier. In fact, it is designed especially for the case when
you maintain a queue of third-party patches on top of another (perhaps
Git-controlled) project and want to easily organize, maintain and submit
them - TopGit achieves that by keeping a separate topic branch for each
patch and providing few tools to maintain the branches
It has been a bit silent around TopGit for some time. Still a few
patches accumulated since the last relase. To get them out I have made
this release.
The highlight is a new command tg-push that makes pushing topgit
branches more comfortable. Thanks to Marc Weber and Bert Wesarg.
Other than that there are quite a few bugfixes.
If ever you have problems with or suggestions for or need for discussion
about TopGit, join us in #topgit in the freenode irc network.
As usual the release is available at
http://repo.or.cz/w/topgit.git
I will talk to martin to get this release into Debian/unstable soon.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Avoid declaration after statement
From: Sebastian Schuberth @ 2009-09-23 9:44 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <213f3c7799721c3f42ffa689498175f0495048eb.1253088099.git.mstormo@gmail.com>
> From: Frank Li <lznuaa@gmail.com>
>
> MSVC does not understand this C99 style
>
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Indeed, even in recent Visual Studio versions the C compiler only
understands C90, not C99. Would it make sense to just force MSVC to
compile *.c files with the C++ compiler to fix this, rather than
patching files (which might be necessary for future files, too)? See
the "/TP" command line option to "CL".
--
Sebastian
^ permalink raw reply
* Re: Add MinGW header files to build git with MSVC
From: Sebastian Schuberth @ 2009-09-23 10:03 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <7afd55f9b2f0f7859f757c715034cc3520e07f0e.1253088099.git.mstormo@gmail.com>
> From: Frank Li <lznuaa@gmail.com>
>
> Added the header files dirent.h, unistd.h and utime.h
> Add alloca.h, which simply includes malloc.h, which defines alloca
>
> Signed-off-by: Frank Li <lznuaa@gmail.com>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
[...]
> create mode 100644 compat/vcbuild/include/sys/utime.h
Have you considered simply including MSVC's sys/utime.h here? From a
first glance, it seems as if it contains all required symbols.
--
Sebastian
^ permalink raw reply
* Re: Feature Enhancement Idea.
From: Deon George @ 2009-09-23 11:12 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200909231106.03305.johan@herland.net>
2009/9/23 Johan Herland <johan@herland.net>:
> Have a look at git submodules ('git help submodule'), or the git-subtree
> script that has been discussed on this list a couple of times [1].
git submodule looks like it will do a little of what I want - I'll do
some more reading on it to see exactly how it works. Thanks for the
tip.
My initial look at it seems to miss an important feature that my layer
idea would provide. It looks like git submodule assumes that
everything in a subdirectory belongs to a repository - with my layer
idea, I would want any layer to share the same directory structure and
files (or content) belonging to a distinct layer's repository.
IE:
the base might provide
plugins
plugins/README
modules
modules/README
lib/common.php
and a layer might provide
plugins/a.php
modules/a.php
lib/a.php
another layer might provide
plugins/b.php
modules/b.php
lib/b.php
If I was a C developer, I'd have a go at creating it - but I'm just a
php developer :)
...deon
^ permalink raw reply
* Re: Add MinGW header files to build git with MSVC
From: Marius Storm-Olsen @ 2009-09-23 11:29 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: msysGit, git, Johannes.Schindelin, gitster, j6t, lznuaa, raa.lkml,
snaury
In-Reply-To: <a416a9d0-90f3-40b7-bd39-ea67ceb2e0b9@j19g2000vbp.googlegroups.com>
Sebastian Schuberth said the following on 23.09.2009 12:03:
>> From: Frank Li <lznuaa@gmail.com>
>>
>> Added the header files dirent.h, unistd.h and utime.h
>> Add alloca.h, which simply includes malloc.h, which defines alloca
>>
>> Signed-off-by: Frank Li <lznuaa@gmail.com>
>> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
>
> [...]
>
>> create mode 100644 compat/vcbuild/include/sys/utime.h
>
> Have you considered simply including MSVC's sys/utime.h here? From a
> first glance, it seems as if it contains all required symbols.
This was a patch which originated from Frank Li's original series.
While we might have been able to simply use the MSVC one, I'm sure
Frank had a reason for overriding it with the small content which you
see in this patch. We'll have to ask Frank about that. We can always
remove it now, if the MSVC version works ok and doesn't introduce any
compiler errors/warnings.
While I appreciate your comments, they are a tad late, as the whole
series is already in master.. :)
See http://repo.or.cz/w/git.git?a=shortlog;h=refs/heads/master
So, give it a try, to see if removing the include override
compat/vcbuild/include/utime.h
doesn't introduce a regression, and send a patch for it.
--
.marius
^ permalink raw reply
* [PATCH] Test for correct behaviour on %B(1) and %B(-1)
From: Johannes Gilger @ 2009-09-23 13:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Johannes Gilger
In-Reply-To: <7vmy4mo85b.fsf@alter.siamese.dyndns.org>
Small test for correct indentation of the new %B tag (and whether
negative values are ignored as an incorrect placeholder).
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
---
Hi Junio,
seeing as the %B-patch is in your pu you seem to be almost happy with it. It's
marked NEEDSWORK: tests, so I thought I give that a try too. Probably best to
be squashed with the other one.
Greetings,
Jojo
t/t4202-log.sh | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 1e952ca..9b7825d 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -32,8 +32,9 @@ test_expect_success setup '
git commit -m fifth &&
git rm a/two &&
+ echo -e "sixth\n\nlineone\nlinetwo" >sixth &&
test_tick &&
- git commit -m sixth
+ git commit -F sixth
'
@@ -63,8 +64,15 @@ test_expect_success 'format' '
test_cmp expect actual
'
+printf "sixth\n\n lineone\n linetwo\n%%B(-1)\n" > expect
+test_expect_success 'format (subject %s, body %B(1), %B(-1))' '
+
+ git log --format="%s%n%n%B(1)%n%B(-1)" 394ef78..5821e35 > actual &&
+ test_cmp expect actual
+'
+
cat > expect << EOF
-804a787 sixth
+5821e35 sixth
394ef78 fifth
5d31159 fourth
2fbe8c0 third
@@ -150,22 +158,22 @@ test_expect_success 'git log --follow' '
'
cat > expect << EOF
-804a787 sixth
+5821e35 sixth
394ef78 fifth
5d31159 fourth
EOF
test_expect_success 'git log --no-walk <commits> sorts by commit time' '
- git log --no-walk --oneline 5d31159 804a787 394ef78 > actual &&
+ git log --no-walk --oneline 5d31159 5821e35 394ef78 > actual &&
test_cmp expect actual
'
cat > expect << EOF
5d31159 fourth
-804a787 sixth
+5821e35 sixth
394ef78 fifth
EOF
test_expect_success 'git show <commits> leaves list of commits as given' '
- git show --oneline -s 5d31159 804a787 394ef78 > actual &&
+ git show --oneline -s 5d31159 5821e35 394ef78 > actual &&
test_cmp expect actual
'
--
1.6.5.rc1.38.g1fbd3
^ permalink raw reply related
* Re: Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Sebastian Schuberth @ 2009-09-23 15:04 UTC (permalink / raw)
To: msysGit
Cc: Marius Storm-Olsen, git, Johannes.Schindelin, gitster, j6t,
lznuaa, raa.lkml, snaury
In-Reply-To: <aa80ad559c731ca73179956e34b2743d903fbbec.1253088099.git.mstormo@gmail.com>
On Sep 16, 10:20 am, Marius Storm-Olsen <mstormo@gmail.com> wrote:
> These scripts generate projects for the MSVC IDE (.vcproj files) or
> QMake (.pro files), based on the output of a 'make -n MSVC=1 V=1' run.
>
> This enables us to simply do the necesarry changes in the Makefile, and you
> can update the other buildsystems by regenerating the files. Keeping the
> other buildsystems up-to-date with main development.
I know I'm a little late with my comments as this patch set has
already been merged to master. However, for future reference I'd like
to point out that something similar could be archived by using e.g.
CMake, and only maintaining the CMake project file. I'm not suggesting
to actually switch to CMake at this time, but I wanted to point out
that a guy called Pau Garcia i Quiles already seems to have created a
preliminary CMakeLists.txt file for Git [1], and also tried to build
Git for Windows using his CMake-generated MSVC project files.
[1] "CMake-ifying git", http://www.elpauer.org/?p=324
--
Sebastian
^ permalink raw reply
* Re: gitk management of git diff-tree processes
From: David Holmer @ 2009-09-23 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <1253632204.8531.78.camel@blackbird>
On Tue, 2009-09-22 at 11:10 -0400, David Holmer wrote:
> I find that if I am in gitk browsing through commits, gitk seems to be
> spawning a git diff-tree process in order to display the changes and
> patch file list in the bottom panes.
>
> I have a certain commit that adds a very large amount of data to my
> repository (1.2 GB). Understandably, the git diff-tree process that
> tries to display the changes in this commit takes a VERY long time to
> run (e.g. churns indefinitely).
>
> The issue is that I find that if I simply browse past this commit (e.g.
> using up/down arrows), gitk starts up a git diff-tree process and leaves
> it running. As many times as I pass the commit (e.g. while looking at
> changes before and after this commit), I end up with multiple processes
> all running and my CPUs quickly go to 100%. Furthermore, even if I exit
> gitk, all the git diff-tree processes keep running unless I manually
> kill them.
>
> Perhaps gitk could kill the git diff-tree process it spawns if its
> output is no longer needed (e.g. user browses to a different commit, or
> gitk exits).
>
> Thank you,
> David
>
> $ ps -aF
> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
> david 23635 1 18 88365 102892 0 10:49 pts/1 00:01:11 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23640 1 18 88368 102908 1 10:49 pts/1 00:01:10 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23644 1 16 88368 102904 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23646 1 16 88367 102916 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23652 1 17 88365 102892 1 10:49 pts/1 00:01:07 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23656 1 17 88368 102920 1 10:49 pts/1 00:01:06 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23660 1 16 88369 102932 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23664 1 16 88368 102908 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23670 1 16 88368 102904 1 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23680 1 17 88365 102896 1 10:49 pts/1 00:01:05 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
> david 23851 10444 0 692 1032 0 10:56 pts/1 00:00:00 ps -aF
>
> $ git version
> git version 1.6.4.4
>
Looking at the code of gitk, I believe the git diff-tree process is
spawned by proc getblobdiffs (gitk-git/gitk:7322). It sets up a command
that matches all the arguments I see in the above ps -aF listing
(gitk-git/gitk:7335):
set cmd [diffcmd $ids "-p $textconv -C --cc --no-commit-id -U
$diffcontext"]
It then seems to setup this command to be run and the output processed
via proc filerun (gitk-git/gitk:7352):
filerun $bdf [list getblobdiffline $bdf $diffids]
I am not very familiar with TCL. Is there a standard/correct way to
pre-maturely halt this filerun processing? It seems to use the fileevent
to know when there is more data to process.
A Google search turned up a way to get the PID from $bfd and said that
on unix systems you could run a kill, but that TCL had no built in kill
mechanism. This seems a bit hackish/non-cross platform. Is there a
better mechanism? Would something like closing the file descriptor cause
the filerun processing to finish and the git diff-tree to terminate with
a broken pipe?
Thank you,
David
--
David G. Holmer, Ph.D.
dholmer@persistentsystems.com
CTO and Co-Founder
Persistent Systems, LLC
www.persistentsystems.com
Office: 212-561-5895
Mobile: 650-533-4964
Fax: 212-202-3625
^ 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