* 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
* Re: [PATCH 14/15] Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Marius Storm-Olsen @ 2009-09-18 6:59 UTC (permalink / raw)
To: Johannes Sixt, gitster
Cc: git, Johannes.Schindelin, msysgit, lznuaa, raa.lkml, snaury
In-Reply-To: <200909172228.28174.j6t@kdbg.org>
Johannes Sixt said the following on 17.09.2009 22:28:
> On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -179,3 +179,14 @@ configure
>> tags
>> TAGS
>> cscope*
>> +*.obj
>> +*.lib
>> +*.sln
>> +*.suo
>> +*.ncb
>> +*.vcproj
>> +*.user
>> +*.idb
>> +*.pdb
>> +Debug/
>> +Release/
>
> If I understand correctly, then 'make MSVC=1' still produce *.o files, not
> *.obj. But if the VC++ project is used, I expect that the *.obj, *.idb, and
> *.pdb end up in Debug/ or Release/ directories. Then 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.
Junio, you want me to push a new patch?
--
.marius
^ permalink raw reply
* Re: [RFC 15/15] Tag GIT_VERSION when Git is built with MSVC
From: Marius Storm-Olsen @ 2009-09-18 6:44 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Johannes.Schindelin, msysgit, gitster, lznuaa, raa.lkml,
snaury
In-Reply-To: <200909172218.15678.j6t@kdbg.org>
Johannes Sixt said the following on 17.09.2009 22:18:
> On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
>> This may help us debug issues on Windows, as we now can build Git
>> natively on Windows with both MinGW and MSVC.
>>
>> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
>> ---
>> I'm just throwing this one out there. If people think manipulating
>> the version here, to ease debugging, I don't mind if this patch is
>> squashed into patch 12.
>> If people don't like it, just skip this path.
>>
>> Makefile | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index aa918eb..2c20922 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -878,6 +878,7 @@ ifneq (,$(findstring CYGWIN,$(uname_S)))
>> UNRELIABLE_FSTAT = UnfortunatelyYes
>> endif
>> ifdef MSVC
>> + GIT_VERSION := $(GIT_VERSION).MSVC
>> pathsep = ;
>> NO_PREAD = YesPlease
>> NO_OPENSSL = YesPlease
>
> I like it, but I would not squash it into patch 12.
Ok good, we'll just keep it as is then.
Thanks.
--
.marius
^ permalink raw reply
* RE: [PATCH JGIT] Circular references shouldn't be created
From: Sohn, Matthias @ 2009-09-18 6:37 UTC (permalink / raw)
To: Robin Rosenberg, Avery Pennarun; +Cc: Shawn O. Pearce, git@vger.kernel.org
In-Reply-To: <200909180051.47794.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote on Freitag, 18. September 2009 00:52
>torsdag 17 september 2009 23:40:12 skrev Avery Pennarun
> <apenwarr@gmail.com>:
> > On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias
> <matthias.sohn@sap.com> wrote:
> > > void link(final String name, final String target) throws
> IOException {
> > > + if (name.equals(target))
> > > + throw new IllegalArgumentException(
> > > + "illegal circular reference
> : symref " + name
> > > + + " cannot
> refer to " + target);
> >
> > This isn't a very thorough fix. It doesn't catch longer loops, like
> >
> > HEAD -> chicken -> HEAD
> >
> > or
> >
> > a -> b -> c -> d -> a
> >
> > Experimenting with original git.git's implementation, I see that this
> > is allowed:
> >
> > git symbolic-ref refs/heads/boink refs/heads/boink
> >
> > It succeeds and creates a file that looks like this:
> >
> > ref: refs/heads/boink
> >
> > And "git show-ref refs/heads/boink" says: nothing (but returns an
> error code).
> >
> > And "git log refs/heads/boink" says:
> >
> > warning: ignoring dangling symref refs/heads/boink.
> > fatal: ambiguous argument 'refs/heads/boink': unknown revision or
> > path not in the working tree.
> > Use '--' to separate paths from revisions
> >
> > Clearly, in git.git, symref loops are caught at ref read time, not
> > write time. This makes sense, since someone might foolishly twiddle
> > the repository by hand and you don't want to get into an infinite loop
> > in that case. Also, it's potentially useful to allow people to set
> > invalid symrefs *temporarily*, as part of a multi step process.
Looks like I was a bit short-sighted yesterday, I will try to cook a better
solution.
>
> I had already written a patch much like this when I decided we need to
> do much better.
>
> 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 ?
--
Matthias
^ permalink raw reply
* Re: Add compiled date to git --version output?
From: Nazri Ramliy @ 2009-09-18 6:04 UTC (permalink / raw)
To: git
In-Reply-To: <7v8wgchmcc.fsf@alter.siamese.dyndns.org>
Thanks for the input guys, I've come to the conclusion that the extra
effort needed to properly implement this is not worth the benefit of
the outcome.
As some of you mentioned, ls -l `which git` is better suited for the
purpose, and that can be done universally for all files where the
filesystem stores the create timestamp of each.
nazri.
^ permalink raw reply
* Re: Add compiled date to git --version output?
From: Junio C Hamano @ 2009-09-18 5:07 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: git
In-Reply-To: <544dda350909172117r44761577m11e7d30a1a5d0c91@mail.gmail.com>
Nazri Ramliy <ayiehere@gmail.com> writes:
> Sometimes I wanted to know how outdated git is on my system.
>
> Coming up with a script to parse "git --version" output to get the SHA1,
> and compare that to master's SHA1 seemed a little overkill compared to
> this:
>
> diff --git a/help.c b/help.c
> index 294337e..bc83491 100644
> --- a/help.c
> +++ b/help.c
> @@ -361,6 +361,9 @@ const char *help_unknown_cmd(const char *cmd)
>
> int cmd_version(int argc, const char **argv, const char *prefix)
> {
> - printf("git version %s\n", git_version_string);
> + printf("git version %s compiled %s %s\n",
> + git_version_string,
> + __DATE__,
> + __TIME__);
> return 0;
> }
>
> With this, git --version gives:
>
> git version 1.6.5.rc1.19.g8426.dirty compiled Sep 18 2009 12:03:29
>
> Thoughts?
It's open source, so you are welcome to do that to your binary.
Personally, I do not want it. My build scripts depend on the version
string at the end if the output to omit re-building what is already
installed.
Seriously, the version number is useful to track down the bug, and perhaps
your compiler and library versions might be useful to help diagnose build
related errors, but when would that __DATE__/__TIME__ be useful more than
what "ls -l /usr/bin/git" would give you?
^ permalink raw reply
* Re: Add compiled date to git --version output?
From: David Aguilar @ 2009-09-18 5:03 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: git
In-Reply-To: <544dda350909172117r44761577m11e7d30a1a5d0c91@mail.gmail.com>
On Fri, Sep 18, 2009 at 12:17:48PM +0800, Nazri Ramliy wrote:
> Sometimes I wanted to know how outdated git is on my system.
$ ls -la $(which git)
> Coming up with a script to parse "git --version" output to get the SHA1,
> and compare that to master's SHA1 seemed a little overkill compared to
> this:
>
> diff --git a/help.c b/help.c
> index 294337e..bc83491 100644
> --- a/help.c
> +++ b/help.c
> @@ -361,6 +361,9 @@ const char *help_unknown_cmd(const char *cmd)
>
> int cmd_version(int argc, const char **argv, const char *prefix)
> {
> - printf("git version %s\n", git_version_string);
> + printf("git version %s compiled %s %s\n",
> + git_version_string,
> + __DATE__,
> + __TIME__);
> return 0;
> }
>
> With this, git --version gives:
>
> git version 1.6.5.rc1.19.g8426.dirty compiled Sep 18 2009 12:03:29
>
> Thoughts?
For whatever it's worth, I would feel more comfortable if this
were guarded behind an option e.g. 'git version --date'.
I suspect that there are a fair number of scripts out there
parsing the output of 'git version'. 'git version' is not
plumbing but we still might want to avoid breaking them.
Is it better to say "compiled on $date" or "compiled $date"?
It's meant to be informational (aka not an actual English
sentence) so I guess it could go either way; "compiled on"
is a little more proper, though.
What about "born on $date" since it gives users a subliminal
suggestion that they should consider upgrading to a fresh git?
;)
--
David
^ permalink raw reply
* Re: Add compiled date to git --version output?
From: Brian Gernhardt @ 2009-09-18 4:43 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: git
In-Reply-To: <544dda350909172117r44761577m11e7d30a1a5d0c91@mail.gmail.com>
On Sep 18, 2009, at 12:17 AM, Nazri Ramliy wrote:
> + printf("git version %s compiled %s %s\n",
> + git_version_string,
> + __DATE__,
> + __TIME__);
> Thoughts?
Any idea how compatible that is? Sure, it'll work with GCC's cpp, but
we try to work with a huge variety of compilers.
At the very least you might want to wrap it all in #ifdefs or something:
#if defined(__DATE__) && defined(__TIME__)
/* your version */
#else
/* old version */
#endif
(Or play fun tricks with #ifndef ... #define, but then you also have
to play with the format string or something.)
~~Brian
^ permalink raw reply
* Add compiled date to git --version output?
From: Nazri Ramliy @ 2009-09-18 4:17 UTC (permalink / raw)
To: git
Sometimes I wanted to know how outdated git is on my system.
Coming up with a script to parse "git --version" output to get the SHA1,
and compare that to master's SHA1 seemed a little overkill compared to
this:
diff --git a/help.c b/help.c
index 294337e..bc83491 100644
--- a/help.c
+++ b/help.c
@@ -361,6 +361,9 @@ const char *help_unknown_cmd(const char *cmd)
int cmd_version(int argc, const char **argv, const char *prefix)
{
- printf("git version %s\n", git_version_string);
+ printf("git version %s compiled %s %s\n",
+ git_version_string,
+ __DATE__,
+ __TIME__);
return 0;
}
With this, git --version gives:
git version 1.6.5.rc1.19.g8426.dirty compiled Sep 18 2009 12:03:29
Thoughts?
Nazri
^ permalink raw reply related
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Junio C Hamano @ 2009-09-18 0:54 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00909171506l6c4b6a49i22d7b337a0c6cfa2@mail.gmail.com>
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.
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.
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.
And that somebody _could_ be you.
^ permalink raw reply
* Re: [PATCH] git-log --format: Add %B tag with %B(x) option
From: Junio C Hamano @ 2009-09-17 23:27 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Git Mailing List
In-Reply-To: <1253227671-20493-1-git-send-email-heipei@hackvalue.de>
Johannes Gilger <heipei@hackvalue.de> writes:
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 2a845b1..c04f118 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 with x spaces
First the design issues.
Because this will set a precedent for possible future formatting features
that take optional parameters, we need to pick the syntax carefully not
only for this feature but for the later ones that we haven't invented yet.
Let's say that pair of parentheses is a good choice and if later features
want to take more than one, it would be reasonable for them to use a
comma-separated list, e.g. %Q(1,2,3).
I wonder if it is reasonable to invoke print_wrapped_text(), not just
limit this feature to indenting.
Now, let's look at the implementation.
> diff --git a/pretty.c b/pretty.c
> index f5983f8..6d530e1 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -735,6 +735,19 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
> case 'b': /* body */
> strbuf_addstr(sb, msg + c->body_off);
> return 1;
> + case 'B':
> + if (placeholder[1] == '(') {
> + const char *body = msg + c->body_off;
> + const char *end = strchr(placeholder + 2, ')');
> + if(!end)
> + return 0;
Style: "if (!end)"
I'd sleep better if the syntax checking is done as a separate phase way
before this in the codepath.
> + pp_remainder(CMIT_FMT_MEDIUM, &body, sb, atoi(placeholder + 2));
What happens when atoi() fails, or %B(12Q) was given?
We tend to use strto[u]l when parsing integers and check for errors.
^ permalink raw reply
* Re: [PATCH JGIT] Circular references shouldn't be created
From: Robin Rosenberg @ 2009-09-17 22:51 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Sohn, Matthias, Shawn O. Pearce, git@vger.kernel.org
In-Reply-To: <32541b130909171440w1a6d2394t4acc6a2f791c143@mail.gmail.com>
torsdag 17 september 2009 23:40:12 skrev Avery Pennarun <apenwarr@gmail.com>:
> On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias <matthias.sohn@sap.com> wrote:
> > void link(final String name, final String target) throws IOException {
> > + if (name.equals(target))
> > + throw new IllegalArgumentException(
> > + "illegal circular reference : symref " + name
> > + + " cannot refer to " + target);
>
> This isn't a very thorough fix. It doesn't catch longer loops, like
>
> HEAD -> chicken -> HEAD
>
> or
>
> a -> b -> c -> d -> a
>
> Experimenting with original git.git's implementation, I see that this
> is allowed:
>
> git symbolic-ref refs/heads/boink refs/heads/boink
>
> It succeeds and creates a file that looks like this:
>
> ref: refs/heads/boink
>
> And "git show-ref refs/heads/boink" says: nothing (but returns an error code).
>
> And "git log refs/heads/boink" says:
>
> warning: ignoring dangling symref refs/heads/boink.
> fatal: ambiguous argument 'refs/heads/boink': unknown revision or
> path not in the working tree.
> Use '--' to separate paths from revisions
>
> Clearly, in git.git, symref loops are caught at ref read time, not
> write time. This makes sense, since someone might foolishly twiddle
> the repository by hand and you don't want to get into an infinite loop
> in that case. Also, it's potentially useful to allow people to set
> invalid symrefs *temporarily*, as part of a multi step process.
I had already written a patch much like this when I decided we need to do much better.
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.
-- robin
^ permalink raw reply
* [PATCH] git-log --format: Add %B tag with %B(x) option
From: Johannes Gilger @ 2009-09-17 22:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Gilger
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 list,
in my never-ending quest to beautify my personal log output I just whipped this
up. Maybe you like it too or at least can tell me what's wrong with it ;)
Please CC me as I'm not on the list anymore (but keep up through Gmane though).
Documentation/pretty-formats.txt | 2 ++
pretty.c | 13 +++++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 2a845b1..c04f118 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 with 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..6d530e1 100644
--- a/pretty.c
+++ b/pretty.c
@@ -735,6 +735,19 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'b': /* body */
strbuf_addstr(sb, msg + c->body_off);
return 1;
+ case 'B':
+ if (placeholder[1] == '(') {
+ const char *body = msg + c->body_off;
+ const char *end = strchr(placeholder + 2, ')');
+ if(!end)
+ return 0;
+ pp_remainder(CMIT_FMT_MEDIUM, &body, sb, atoi(placeholder + 2));
+ strbuf_rtrim(sb);
+ return end - placeholder + 1;
+ }
+ strbuf_addstr(sb, msg + c->body_off);
+ strbuf_rtrim(sb);
+ return 1;
}
return 0; /* unknown placeholder */
}
--
1.6.5.rc1.20.geb7d9
^ permalink raw reply related
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-17 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdjhgrjv.fsf@alter.siamese.dyndns.org>
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?
^ permalink raw reply
* Re: [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Junio C Hamano @ 2009-09-17 22:00 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253224300-18017-1-git-send-email-tfransosi@gmail.com>
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?
^ permalink raw reply
* [PATCH] Avoid the use of backslash-at-eol in pack-objects usage string.
From: Thiago Farina @ 2009-09-17 21:51 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
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..4494a68 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]*] [--reflog] \n"
+ " [--stdout | base-name] [--include-tag] \n"
+ " [--keep-unreachable | --unpack-unreachable] \n"
+ " [<ref-list | <object-list]";
struct object_entry {
struct pack_idx_entry idx;
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: [PATCH JGIT] Circular references shouldn't be created
From: Avery Pennarun @ 2009-09-17 21:40 UTC (permalink / raw)
To: Sohn, Matthias; +Cc: Shawn O. Pearce, Robin Rosenberg, git@vger.kernel.org
In-Reply-To: <C89280B882467443A695734861B942B28759DB95@DEWDFECCR09.wdf.sap.corp>
On Thu, Sep 17, 2009 at 3:23 PM, Sohn, Matthias <matthias.sohn@sap.com> wrote:
> void link(final String name, final String target) throws IOException {
> + if (name.equals(target))
> + throw new IllegalArgumentException(
> + "illegal circular reference : symref " + name
> + + " cannot refer to " + target);
This isn't a very thorough fix. It doesn't catch longer loops, like
HEAD -> chicken -> HEAD
or
a -> b -> c -> d -> a
Experimenting with original git.git's implementation, I see that this
is allowed:
git symbolic-ref refs/heads/boink refs/heads/boink
It succeeds and creates a file that looks like this:
ref: refs/heads/boink
And "git show-ref refs/heads/boink" says: nothing (but returns an error code).
And "git log refs/heads/boink" says:
warning: ignoring dangling symref refs/heads/boink.
fatal: ambiguous argument 'refs/heads/boink': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Clearly, in git.git, symref loops are caught at ref read time, not
write time. This makes sense, since someone might foolishly twiddle
the repository by hand and you don't want to get into an infinite loop
in that case. Also, it's potentially useful to allow people to set
invalid symrefs *temporarily*, as part of a multi step process.
Have fun,
Avery
^ permalink raw reply
* [PATCH JGIT] Circular references shouldn't be created
From: Sohn, Matthias @ 2009-09-17 19:23 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git@vger.kernel.org
From: Matthias Sohn <matthias.sohn@sap.com>
Circular references shouldn't be created
Fix for bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=286743
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
---
.../tst/org/spearce/jgit/lib/RefTest.java | 9 +++++++++
.../src/org/spearce/jgit/lib/RefDatabase.java | 4 ++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
index fabbe7e..ce6328b 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RefTest.java
@@ -155,4 +155,13 @@ public void testOrigResolvedNamesSymRef() throws IOException {
assertEquals("refs/heads/master", ref.getName());
assertEquals("HEAD", ref.getOrigName());
}
+
+ public void testIllegalCircularRef() throws IOException {
+ try {
+ db.writeSymref("HEAD", "HEAD");
+ fail("creation of circular reference should fail");
+ } catch (IllegalArgumentException expected) {
+ // attempt to create circular reference should fail
+ }
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 09cb9bb..483b1d0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -174,6 +174,10 @@ RefRename newRename(String fromRef, String toRef) throws IOException {
* @throws IOException
*/
void link(final String name, final String target) throws IOException {
+ if (name.equals(target))
+ throw new IllegalArgumentException(
+ "illegal circular reference : symref " + name
+ + " cannot refer to " + target);
final byte[] content = Constants.encode("ref: " + target + "\n");
lockAndWriteFile(fileForRef(name), content);
synchronized (this) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Daniel Barkalow @ 2009-09-17 21:04 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, Christian Couder, git, Johannes Schindelin,
Stephan Beyer, Jakub Narebski, Linus Torvalds
In-Reply-To: <c07716ae0909170525h21ab26f5y84b0fbce2192c69@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 914 bytes --]
On Thu, 17 Sep 2009, Christian Couder wrote:
> On Thu, Sep 17, 2009 at 7:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > I'd like to see at least the following rows filled as well.
> >
> > X U A A --m-s ??? ??? ???
> > --merge ??? ??? ???
> > X U B A --m-s ??? ??? ???
> > --merge ??? ??? ???
> >
> >> In this table, A, B and C are some different states of a file.
> >
> > ... and X is "don't care", and U is "unmerged index".
>
> I will have a look, but it seems to me that --m-s and --merge
> behave the same in these cases.
It's still worth documenting, since it used to be entirely undocumented
(and probably not what it should have been), and also because you're
making it something reliable for the first time in this series.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Junio C Hamano @ 2009-09-17 20:43 UTC (permalink / raw)
To: Johannes Sixt
Cc: Christian Couder, Christian Couder, git, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Linus Torvalds
In-Reply-To: <4AB23410.6080508@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Christian Couder schrieb:
>> On Thu, Sep 17, 2009 at 9:24 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Junio C Hamano schrieb:
>>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>> $ git stash
>>> $ git reset --hard $target
>>> $ git stash pop
>>
> It "can"? Do you say that you intend --merge-safe for something else in
> addition to the above stash + reset --hard + stash pop sequence? What?
I think I am starting to understand. The use case in a larger picture
would look like
$ (edit/add/commit)+ to work towards something
... And you _finished_ that something.
$ (edit/add)+ to work towards something else that is wonderful
... Now you notice that all the commits for that earlier something
... are crap and you would want to discard them, while still keeping
... changes for "something else that is wonderful".
... Luckily, you haven't committed anything you would want to keep,
... and you can afford to reset the tip commits away.
$ git reset --keep-local-changes HEAD~7
... or howmanyever commits you want to discard.
The reset in this case is done purely to discard the crap, not to redo
them (you have something else you want to work on in your work tree and
index, and they are not fixups---if they were you wouldn't have resetted
but used "commit --amend" or "rebase -i").
It is more like switching branches but in this case you are switching to
your own branch immediately after rewinding that same branch.
In other words, as far as the index, the work tree and where HEAD will
point at are concerned, the new mode of reset works exactly like this:
$ (edit/add)+ to work towards something wonderful
... notice that the work does not belong to the current branch
... and you would want to switch to another branch while carrying
... your local changes.
$ git checkout another-branch
The only difference being that reset will stay on the same branch and
remove some commits from the tip of it, while checkout will leave the
original branch intact.
It makes sense that it has the same "safety" as "checkout" has when
switching branches; when you have modification in the index for a path,
and the path is different between switched-to commit and the current
commit, the command errors out with "cannot merge" (or a better message).
One drawback is that you can use this new mode of resetting only until you
make a commit that is part of the new "something else that is wonderful"
topic. After that "git reset" with this new option is not useful for this
workflow, and you would need to stash then rebase -i then unstash.
^ permalink raw reply
* Re: [PATCH 14/15] Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)
From: Johannes Sixt @ 2009-09-17 20:28 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, lznuaa, raa.lkml,
snaury
In-Reply-To: <aa80ad559c731ca73179956e34b2743d903fbbec.1253088099.git.mstormo@gmail.com>
On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -179,3 +179,14 @@ configure
> tags
> TAGS
> cscope*
> +*.obj
> +*.lib
> +*.sln
> +*.suo
> +*.ncb
> +*.vcproj
> +*.user
> +*.idb
> +*.pdb
> +Debug/
> +Release/
If I understand correctly, then 'make MSVC=1' still produce *.o files, not
*.obj. But if the VC++ project is used, I expect that the *.obj, *.idb, and
*.pdb end up in Debug/ or Release/ directories. Then why do you need entries
for *.obj, *.idb, and *.pdb?
-- Hannes
^ permalink raw reply
* Re: [RFC 15/15] Tag GIT_VERSION when Git is built with MSVC
From: Johannes Sixt @ 2009-09-17 20:18 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: git, Johannes.Schindelin, msysgit, gitster, lznuaa, raa.lkml,
snaury
In-Reply-To: <894136433cc5b03a4b89a1f9c0e4f8a2704222fa.1253088099.git.mstormo@gmail.com>
On Mittwoch, 16. September 2009, Marius Storm-Olsen wrote:
> This may help us debug issues on Windows, as we now can build Git
> natively on Windows with both MinGW and MSVC.
>
> Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
> ---
> I'm just throwing this one out there. If people think manipulating
> the version here, to ease debugging, I don't mind if this patch is
> squashed into patch 12.
> If people don't like it, just skip this path.
>
> Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index aa918eb..2c20922 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -878,6 +878,7 @@ ifneq (,$(findstring CYGWIN,$(uname_S)))
> UNRELIABLE_FSTAT = UnfortunatelyYes
> endif
> ifdef MSVC
> + GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
> NO_PREAD = YesPlease
> NO_OPENSSL = YesPlease
I like it, but I would not squash it into patch 12.
-- Hannes
^ permalink raw reply
* Gitk --all error when there are more than 797 refs in a repository
From: Murphy, John @ 2009-09-17 19:07 UTC (permalink / raw)
To: git
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.
We were using:
git 1.6.3.2.314.ge3519
and then I upgraded to test if there was a change:
git 1.6.5.rc1.18.g401ce7
We are also using:
tcl 8.4.1
cygwin 1.5.25-7
Windows XP Pro SP3
^ permalink raw reply
* [PATCH v3] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 17:20 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Also makes the output more consistent with the other usage strings that use
usage_with_options to show the usage string.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..2006cc5 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -9,7 +9,11 @@
* bundle supporting "fetch", "pull", and "ls-remote".
*/
-static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] =
+ "git bundle create <file> <git-rev-list args>\n"
+ " or: git bundle verify <file>\n"
+ " or: git bundle list-heads <file> [refname...]\n"
+ " or: git bundle unbundle <file> [refname...]";
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
@@ -20,7 +24,7 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
char buffer[PATH_MAX];
if (argc < 3)
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +63,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: What's cooking in git.git (Sep 2009, #04; Wed, 16)
From: Nick Edelen @ 2009-09-17 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vm6kskd.fsf@alter.siamese.dyndns.org>
> * 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
>
> Replaced but I do not think this is ready for 'pu' yet.
Er, what direction would you suggest taking to bring this patchset up
to scratch? I've run several tests locally, and it seems to work as
intended, but I wouldn't assert that I've taken every possibility into
account. Should I submit some tests/benchmarks in more real-world
environments? I'm afraid that I'm not personally among the intended
audience for this, so I don't have a really solid idea of how this
might perform in the wild.
- Nick
^ 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