* 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
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-18 15:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd45pgjhr.fsf@alter.siamese.dyndns.org>
On Thu, Sep 17, 2009 at 9:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> On Thu, Sep 17, 2009 at 7:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Thiago Farina <tfransosi@gmail.com> writes:
>>>
>>>> +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]";
>>>
>>> Do you still want to keep the trailing whitespace on these lines?
>> I did this to maintain the same output of the old string, but if you
>> want I can change, what you suggest?
>
> If you need to add or remove an option to actually _change_ the string, a
> patch like this, as a preparatory step before the real improvement, would
> be a very welcome clean-up. I however would suggest doing nothing, if
> this is the only patch you are going to send against this program in the
> near future, to be honest.
OK.
>
> Even though we do not have any other patch in flight that changes this
> program at this moment (as expected, because we are in -rc freeze), which
> means there is not much risk for this patch to cause needless conflicts
> with others, we generally avoid code churn like this one, as a principle
> for a maturing project.
This release candidate freeze is a period that no one can send patches?
If you could, point me to a documentation about how is the development
process adopted by git.
As I can see, anybody can send patches to this mailing list for
review, but if no one cares about the my patch for example, it doesn't
get a review and any feedback.
In a web review tool, the patch is assigned to someone review it, but
here it is impossible, so how the things are tracked here? 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'? And what did you mean with
code churn?
>
> The _very best_ thing you can do for the project on this particular issue
> is to keep an eye on the list and the next time somebody wants to patch
> this program in a way that affects the usage string, remind that person to
> first clean-up the string without changing anything else as a preparation
> patch; I however admit that I am asking a lot more work out of you.
>
> 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 to remove the
trailing whitespace from a given string? Like the functions that work
with whitespaces in ws.c?
>
> And that somebody _could_ be you.
>
^ permalink raw reply
* [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Pat Thoyts @ 2009-09-18 14:06 UTC (permalink / raw)
To: Murphy, John; +Cc: git, Paul Mackerras
In-Reply-To: <6F87406399731F489FBACE5C5FFA04584BFA53@ex2k.bankofamerica.com>
"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 am a novice tcl programmer but is seems like ids could be an array.
>There are also many other areas in the code where git rev-parse is called and using array may also be necessary.
>
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:
--- patch begins -----
[PATCH] Avoid command-line limits when executing git rev-parse on windows.
This patch solves the problem handling large numbers of references
reported by John Murphy that is due to limits in executing processes
in Windows by reading the rev-parse result over a pipe.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
gitk | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 1306178..1bd7d65 100755
--- a/gitk
+++ b/gitk
@@ -236,13 +236,23 @@ proc parseviewargs {n arglist} {
return $allknown
}
+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]} {
# we get stdout followed by stderr in $err
# for an unknown rev, git rev-parse echoes it and then errors out
set errlines [split $err "\n"]
@@ -273,7 +283,7 @@ proc parseviewrevs {view revs} {
set pos {}
set neg {}
set sdm 0
- foreach id [split $ids "\n"] {
+ foreach id $ids {
if {$id eq "--gitk-symmetric-diff-marker"} {
set sdm 4
} elseif {[string match "^*" $id]} {
--
1.6.4.msysgit.0
--
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 related
* Re: Git crashes on pull
From: Tay Ray Chuan @ 2009-09-18 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, git, Michael Wookey
In-Reply-To: <7vzl8v4y5g.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Sep 16, 2009 at 6:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks.
>
> The sad part of the story was that this regression was introduced by a
> change to work around recent breakage observed when fetching from the http
> server github runs, and it was the primary purpose of pushing 1.6.4.3 out.
>
> Now we need to cut a 1.6.4.4 with this fix-on-fix soon, like tomorrow.
sorry for all the trouble caused.
Junio, do you think moving out the free() would be a better option? Setting it to NULL just so we can free() is rather contrived, I feel.
-- >8 --
Subject: [PATCH] http.c: move free() out of cleanup block
Instead of initializing a variable (url) just so we can do a free() on
it, as in b202514 (http.c: avoid freeing an uninitialized pointer), we
move the free() out of cleanup block.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http.c b/http.c
index 23b2a19..a67f62e 100644
--- a/http.c
+++ b/http.c
@@ -866,7 +866,7 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
int ret = 0;
char *hex = xstrdup(sha1_to_hex(sha1));
char *filename;
- char *url = NULL;
+ char *url;
struct strbuf buf = STRBUF_INIT;
if (has_pack_index(sha1)) {
@@ -885,9 +885,9 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
if (http_get_file(url, filename, 0) != HTTP_OK)
ret = error("Unable to get pack index %s\n", url);
+ free(url);
cleanup:
free(hex);
- free(url);
return ret;
}
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH 2/2] gitk: Fix the geometry when restoring from zoomed state
From: Pat Thoyts @ 2009-09-18 13:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Alexy Borzenkov
In-Reply-To: <19122.10359.725107.949551@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>Pat Thoyts writes:
>
>> The patch to handle the geometry of a restored gitk by Alexy Borzenkov
>> causes the position of the columns to creep each time the application
>> is restarted. This patch addresses this by remembering the application
>> geometry for the normal state and saving that regardless of the actual
>> state when the application is closed.
>
>So this patch replaces Alexey's patch, then? The context in your patch
>doesn't match the changes made in Alexey's patch AFAICS.
Correct. I posted a response to Alexy's patch saying I'd post an
alternative as I had trouble with the columns resizing and creeping
due to the assertion of 'wm state normal' during the settings save
each time.
See
http://thread.gmane.org/gmane.comp.version-control.git/128026/focus=128652
The context of mine should be the gitk repository master (was
c21398be).
--
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] git-push: add option --repo-all
From: Paolo Bonzini @ 2009-09-18 11:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <200909181302.49335.jnareb@gmail.com>
> Well, git-remote has "git remote update" subcommand for fetching from
> a group of remote repositories, so it is not only about managing remotes.
> I think "git remote push" (or something like that) would fit in
> git-remote area of competence.
>
> Besides git-remote understands groups of remote repositories for fetch
> (update), which would be (I think) a good idea also for push.
Agreed.
Paolo
^ permalink raw reply
* Re: [PATCH] git-push: add option --repo-all
From: Jakub Narebski @ 2009-09-18 11:02 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: git
In-Reply-To: <877hvwzkw7.wl%catap@catap.ru>
Kirill A. Korinskiy wrote:
> At Fri, 18 Sep 2009 01:52:49 -0700 (PDT),
> Jakub Narebski <jnareb@gmail.com> wrote:
> > "Kirill A. Korinskiy" <catap@catap.ru> writes:
> > > ---
> > > Documentation/git-push.txt | 4 ++-
> > > builtin-push.c | 34 +++++++++++++++++++++-----------
> > > t/t5523-push-repo-all.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 71 insertions(+), 13 deletions(-)
> > > create mode 100755 t/t5523-push-repo-all.sh
> >
> > 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".
>
> not sure, because git remote make interface for managment remotes
> repos and push make interface for pushing to remote repo. I just add a
> pushing to all repos.
>
> I thought about pushing to some remotes repos, yes, but could not come
> up with a good symantics.
Well, git-remote has "git remote update" subcommand for fetching from
a group of remote repositories, so it is not only about managing remotes.
I think "git remote push" (or something like that) would fit in
git-remote area of competence.
Besides git-remote understands groups of remote repositories for fetch
(update), which would be (I think) a good idea also for push.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-push: add option --repo-all
From: Kirill A. Korinskiy @ 2009-09-18 10:44 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <m3r5u43a8h.fsf@localhost.localdomain>
Example of usage: I write some software on my laptop and some time
pushing to my home/private server for backup. Some time ago my
software is done and I openin it on github, but I'm don't like kill my
private repos. Now update a two remotes repo is'n sexy, because I'm
need using a some shell wrapper:
git remote show | while read repo; do git push $repo; done
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
Documentation/git-push.txt | 3 ++
builtin-push.c | 34 +++++++++++++++++++++-----------
t/t5523-push-repo-all.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 12 deletions(-)
create mode 100755 t/t5523-push-repo-all.sh
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..92e45c2 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -134,6 +134,9 @@ useful if you write an alias or script around 'git-push'.
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
+--repo-all::
+ Send changes to all remote repos.
+
-v::
--verbose::
Run verbosely.
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..2b25293 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository> | --repo-all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -88,19 +88,13 @@ static void setup_default_push_refspecs(void)
}
}
-static int do_push(const char *repo, int flags)
+static int do_push(struct remote *remote, void *priv)
{
+ int flags = *((int *)priv);
int i, errs;
- struct remote *remote = remote_get(repo);
const char **url;
int url_nr;
- if (!remote) {
- if (repo)
- die("bad repository '%s'", repo);
- die("No destination configured to push to.");
- }
-
if (remote->mirror)
flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
@@ -171,13 +165,16 @@ int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
int tags = 0;
+ int repo_all = 0;
int rc;
+ struct remote *remote;
const char *repo = NULL; /* default repository */
struct option options[] = {
OPT_BIT('q', "quiet", &flags, "be quiet", TRANSPORT_PUSH_QUIET),
OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
+ OPT_BOOLEAN( 0 , "repo-all", &repo_all, "push to all remote repos"),
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
@@ -197,11 +194,24 @@ int cmd_push(int argc, const char **argv, const char *prefix)
add_refspec("refs/tags/*");
if (argc > 0) {
- repo = argv[0];
- set_refspecs(argv + 1, argc - 1);
+ if (repo_all) {
+ set_refspecs(argv, argc);
+ } else {
+ repo = argv[0];
+ set_refspecs(argv + 1, argc - 1);
+ }
}
- rc = do_push(repo, flags);
+ remote = remote_get(repo);
+ if (!remote && !repo_all) {
+ if (repo)
+ die("bad repository '%s'", repo);
+ die("No destination configured to push to.");
+ }
+
+ rc = repo_all ?
+ for_each_remote(do_push, &flags) : do_push(remote, &flags);
+
if (rc == -1)
usage_with_options(push_usage, options);
else
diff --git a/t/t5523-push-repo-all.sh b/t/t5523-push-repo-all.sh
new file mode 100755
index 0000000..865b8a1
--- /dev/null
+++ b/t/t5523-push-repo-all.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='pushing to all remote repos repository'
+
+. ./test-lib.sh
+
+mk_repos () {
+ rm -rf maste mirror-1 mirror-2 &&
+ mkdir mirror-1 &&
+ (
+ cd mirror-1 &&
+ git init
+ ) &&
+ mkdir mirror-2 &&
+ (
+ cd mirror-2 &&
+ git init
+ ) &&
+ mkdir master &&
+ (
+ cd master &&
+ git init &&
+ git remote add mirror-1 ../mirror-1
+ git remote add mirror-2 ../mirror-2
+ )
+}
+
+
+test_expect_success 'push to mirrors' '
+
+ mk_repos &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git remote show &&
+ git push --all --repo-all -f
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/heads/master) &&
+ mirror_1_master=$(cd mirror-1 && git show-ref -s --verify refs/heads/master) &&
+ mirror_2_master=$(cd mirror-2 && git show-ref -s --verify refs/heads/master) &&
+ test "$master_master" = "$mirror_1_master" &&
+ test "$master_master" = "$mirror_2_master"
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] git-push: add option --repo-all
From: Jakub Narebski @ 2009-09-18 8:52 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1253258222-11475-1-git-send-email-catap@catap.ru>
"Kirill A. Korinskiy" <catap@catap.ru> writes:
> Example of usage: I write some software on my laptop and some time
> pushing to my home/private server for backup. Some time ago my
> software is done and I openin it on github, but I'm don't like kill my
> private repos. Now update a two remotes repo is'n sexy, because I'm
> need using a some shell wrapper:
>
> git remote show | while read repo; do git push $repo; done
Signoff?
> ---
> Documentation/git-push.txt | 4 ++-
> builtin-push.c | 34 +++++++++++++++++++++-----------
> t/t5523-push-repo-all.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 71 insertions(+), 13 deletions(-)
> create mode 100755 t/t5523-push-repo-all.sh
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".
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 14/15] Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Johannes Sixt @ 2009-09-18 8:21 UTC (permalink / raw)
To: Marius Storm-Olsen, gitster
Cc: Johannes Sixt, git, Johannes.Schindelin, msysgit, lznuaa,
raa.lkml, snaury
In-Reply-To: <4AB32FE2.1060604@gmail.com>
Marius Storm-Olsen schrieb:
> Johannes Sixt said the following on 17.09.2009 22:28:
>> why do
>> you need entries for *.obj, *.idb, and *.pdb?
>
> When using only the vcproj generator, you are correct. However, if you
> use the qmake generator, and create vcprojs from those, the *.idb and
> *.pdb files are located in the project directory itself, and not under
> Debug/. I'm not too worried about this case though, so for me, the three
> entries *.obj, *.idb and *.pdb can go.
Fair enough.
> Junio, you want me to push a new patch?
That's not necessary. I just wanted to make sure that you added the
entries deliberately.
With these questions answered, and the most recent change to 04/15 that
adjust test-genrandom.c, the MinGW aspect of this series is
Acked-by: Johannes Sixt <j6t@kdbg.org>
Thank you very much for your work and persistency!
-- Hannes
^ permalink raw reply
* [PATCH] git-push: add option --repo-all
From: Kirill A. Korinskiy @ 2009-09-18 7:17 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
Example of usage: I write some software on my laptop and some time
pushing to my home/private server for backup. Some time ago my
software is done and I openin it on github, but I'm don't like kill my
private repos. Now update a two remotes repo is'n sexy, because I'm
need using a some shell wrapper:
git remote show | while read repo; do git push $repo; done
---
Documentation/git-push.txt | 4 ++-
builtin-push.c | 34 +++++++++++++++++++++-----------
t/t5523-push-repo-all.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 13 deletions(-)
create mode 100755 t/t5523-push-repo-all.sh
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..734e745 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,6 @@ SYNOPSIS
--------
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
DESCRIPTION
@@ -134,6 +133,9 @@ useful if you write an alias or script around 'git-push'.
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
+--repo-all::
+ Send changes to all remote repos.
+
-v::
--verbose::
Run verbosely.
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..2b25293 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository> | --repo-all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -88,19 +88,13 @@ static void setup_default_push_refspecs(void)
}
}
-static int do_push(const char *repo, int flags)
+static int do_push(struct remote *remote, void *priv)
{
+ int flags = *((int *)priv);
int i, errs;
- struct remote *remote = remote_get(repo);
const char **url;
int url_nr;
- if (!remote) {
- if (repo)
- die("bad repository '%s'", repo);
- die("No destination configured to push to.");
- }
-
if (remote->mirror)
flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
@@ -171,13 +165,16 @@ int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
int tags = 0;
+ int repo_all = 0;
int rc;
+ struct remote *remote;
const char *repo = NULL; /* default repository */
struct option options[] = {
OPT_BIT('q', "quiet", &flags, "be quiet", TRANSPORT_PUSH_QUIET),
OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
+ OPT_BOOLEAN( 0 , "repo-all", &repo_all, "push to all remote repos"),
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
@@ -197,11 +194,24 @@ int cmd_push(int argc, const char **argv, const char *prefix)
add_refspec("refs/tags/*");
if (argc > 0) {
- repo = argv[0];
- set_refspecs(argv + 1, argc - 1);
+ if (repo_all) {
+ set_refspecs(argv, argc);
+ } else {
+ repo = argv[0];
+ set_refspecs(argv + 1, argc - 1);
+ }
}
- rc = do_push(repo, flags);
+ remote = remote_get(repo);
+ if (!remote && !repo_all) {
+ if (repo)
+ die("bad repository '%s'", repo);
+ die("No destination configured to push to.");
+ }
+
+ rc = repo_all ?
+ for_each_remote(do_push, &flags) : do_push(remote, &flags);
+
if (rc == -1)
usage_with_options(push_usage, options);
else
diff --git a/t/t5523-push-repo-all.sh b/t/t5523-push-repo-all.sh
new file mode 100755
index 0000000..865b8a1
--- /dev/null
+++ b/t/t5523-push-repo-all.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='pushing to all remote repos repository'
+
+. ./test-lib.sh
+
+mk_repos () {
+ rm -rf maste mirror-1 mirror-2 &&
+ mkdir mirror-1 &&
+ (
+ cd mirror-1 &&
+ git init
+ ) &&
+ mkdir mirror-2 &&
+ (
+ cd mirror-2 &&
+ git init
+ ) &&
+ mkdir master &&
+ (
+ cd master &&
+ git init &&
+ git remote add mirror-1 ../mirror-1
+ git remote add mirror-2 ../mirror-2
+ )
+}
+
+
+test_expect_success 'push to mirrors' '
+
+ mk_repos &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git remote show &&
+ git push --all --repo-all -f
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/heads/master) &&
+ mirror_1_master=$(cd mirror-1 && git show-ref -s --verify refs/heads/master) &&
+ mirror_2_master=$(cd mirror-2 && git show-ref -s --verify refs/heads/master) &&
+ test "$master_master" = "$mirror_1_master" &&
+ test "$master_master" = "$mirror_2_master"
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: git workflow for fully distributed mini-teams
From: Rustom Mody @ 2009-09-18 7:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4AB24C06.5030207@viscovery.net>
On Thu, Sep 17, 2009 at 8:17 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> [On this list, we reply to all, so that the Cc list remains]
>
> Rustom Mody schrieb:
>> I started looking at git bundle and find things like master\~10.
>> Whats the backslash doing?
>
> It's intended as markup for the pipeline that generates the documentation
> from git-bundle.txt. Either the markup is incorrect, or there is a bug in
> the pipeline, because I only see it in the generated HTML. Ignore it.
Seems to be there in my git-bundle.txt as well as git-bundle.html.
So its probably the markup not the pipeline.
^ 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