* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-14 20:58 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
In-Reply-To: <18235.22445.16228.535898@lisa.zopyra.com>
Hi,
On Wed, 14 Nov 2007, Bill Lear wrote:
> On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:
>
> >But cloning void to start the same project by multiple people and
> >pushing their initial commits as roots to start a project indicates the
> >lack of developer communication (besides, it just feels like a bad
> >style, a hangover from centralized SCM mentality, but that is fine).
> >...
>
> We have several users who have been using git for the past 9 months and
> they each find this unreasonably complicated. [...]
>
> Well, here's what we'd like:
>
> % mkdir new_repo
> % cd new_repo
> % git --bare init
>
> [on another machine:]
> % git clone git://host/new_repo
> % cd new_repo
> % git init
> [add content]
> % git commit -a -m "Initial stuff"
> % git push
I have a better idea:
[the initial import, on another machine:]
% mkdir new_repo
% cd new_repo
% git init
[add content]
% git commit -a -m "Initial stuff"
% git remote add origin git://host/repo
% git push origin master
If you do not want to be bothered with setting up the default
"remote" and "merge" config variables manually, it is reasonable to ask
for support to do that in "git remote".
If you really think that this workflow has anything to do with cloning an
empty repository, I cannot help you. I mean, you did not need to clone
the big, empty void to do the initial commit, or did you?
(I actually think that it is another example of cvs/svn damage, where you
_need_ to clone first, or otherwise you will _never_ be able to commit
to the repository.)
BTW I am somewhat disgusted by your usage of git:// for pushing.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Junio C Hamano @ 2007-11-14 21:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: Guido Ostkamp, git
In-Reply-To: <20071114204732.GE3973@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Guido Ostkamp, Wed, Nov 14, 2007 21:31:13 +0100:
>> ...
>> cc: acomp failed for diff-delta.c
>> make: *** [diff-delta.o] Error 2
>>
>> This is because 'struct delta_index' is declared with no size in delta.h
>> and with size in diff-delta.c which does not fit.
>
> Huh?! Ever heard of forward declaration?
We are not the first people who pass around a pointer to an
opaque struct in the API to hide away the implementation. It
would be surprising if the Workshop Compiler chokes on this and
not other projects.
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Junio C Hamano @ 2007-11-14 21:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Jeff King
In-Reply-To: <20071113230234.GI3268@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test: it already checks whether the references updated correctly.
I think the Subject: goes a lot better with a description like this:
Add test that checks the case where X does Y and make
sure Z happens.
Because we haven't settled on what the exit status from
"git push" command itself should be in such a partial
failure case, do not check the exit status from it for
now.
> diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
> index 20718d4..a51bbdc 100755
> --- a/t/t5404-tracking-branches.sh
> +++ b/t/t5404-tracking-branches.sh
> @@ -10,6 +10,7 @@ test_expect_success 'setup' '
> git commit -m 1 &&
> git branch b1 &&
> git branch b2 &&
> + git branch b3 &&
> git clone . aa &&
> git checkout b1 &&
> ...
So it makes another ref "b3" point at the initial commit,...
> ...
> test_expect_success 'check tracking branches updated correctly after push' '
> cd aa &&
> b1=$(git rev-parse origin/b1) &&
> b2=$(git rev-parse origin/b2) &&
> + b3=$(git rev-parse origin/b3) &&
> git checkout -b b1 origin/b1 &&
> echo aa-b1 >>file &&
> git commit -a -m aa-b1 &&
... then records what was cloned,...
> @@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
> git checkout master &&
> echo aa-master >>file &&
> git commit -a -m aa-master &&
> + {
> + git push
> + test "$(git rev-parse origin/b1)" = "$b1" &&
> + test "$(git rev-parse origin/b2)" = "$b2" &&
> + test "$(git rev-parse origin/b3)" = "$b3" &&
> + test "$(git rev-parse origin/master)" = \
> + "$(git rev-parse master)"
> + }
> +'
... and checks that untouched "b3" stays the same (iow, tests
up-to-date case).
> +
> +test_expect_success 'delete remote branch' '
> + git push origin :refs/heads/b3
> + {
> + git rev-parse origin/b3
> + test $? != 0 || \
> + say "Hmm... Maybe tracking ref should be deleted?"
> + } &&
Ah, you meant that tracking should be deleted so this should be
fixed in the code but the test is disabled for now. Let's be a
bit more explicit about such a temporary disabled test, like
this:
git push origin :refs/heads/b3
# The remote-tracking branch origin/b3 should be deleted;
# we need to update the code and enable this test.
: git rev-parse --verify origin/b3 &&
> + cd "$start_dir" &&
> + {
> + git rev-parse refs/heads/b3
> + test $? != 0
> + }
> '
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Junio C Hamano @ 2007-11-14 21:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Jeff King
In-Reply-To: <20071113230234.GI3268@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test: it already checks whether the references updated correctly.
I think the Subject: goes a lot better with a description like this:
Enhance the test to check the case where X does Y and to
make sure Z happens.
Because we haven't settled on what the exit status from
"git push" command itself should be in such a partial
failure case, do not check the exit status from it for
now.
> diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
> index 20718d4..a51bbdc 100755
> --- a/t/t5404-tracking-branches.sh
> +++ b/t/t5404-tracking-branches.sh
> @@ -10,6 +10,7 @@ test_expect_success 'setup' '
> git commit -m 1 &&
> git branch b1 &&
> git branch b2 &&
> + git branch b3 &&
> git clone . aa &&
> git checkout b1 &&
> ...
So it makes another ref "b3" point at the initial commit,...
> ...
> test_expect_success 'check tracking branches updated correctly after push' '
> cd aa &&
> b1=$(git rev-parse origin/b1) &&
> b2=$(git rev-parse origin/b2) &&
> + b3=$(git rev-parse origin/b3) &&
> git checkout -b b1 origin/b1 &&
> echo aa-b1 >>file &&
> git commit -a -m aa-b1 &&
... then records what was cloned,...
> @@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
> git checkout master &&
> echo aa-master >>file &&
> git commit -a -m aa-master &&
> + {
> + git push
> + test "$(git rev-parse origin/b1)" = "$b1" &&
> + test "$(git rev-parse origin/b2)" = "$b2" &&
> + test "$(git rev-parse origin/b3)" = "$b3" &&
> + test "$(git rev-parse origin/master)" = \
> + "$(git rev-parse master)"
> + }
> +'
... and checks that untouched "b3" stays the same (iow, tests
up-to-date case).
> +
> +test_expect_success 'delete remote branch' '
> + git push origin :refs/heads/b3
> + {
> + git rev-parse origin/b3
> + test $? != 0 || \
> + say "Hmm... Maybe tracking ref should be deleted?"
> + } &&
Ah, you meant that tracking should be deleted so this should be
fixed in the code but the test is disabled for now. Let's be a
bit more explicit about such a temporary disabled test, like
this:
git push origin :refs/heads/b3
# The remote-tracking branch origin/b3 should be deleted;
# we need to update the code and enable this test.
: git rev-parse --verify origin/b3 &&
> + cd "$start_dir" &&
> + {
> + git rev-parse refs/heads/b3
> + test $? != 0
> + }
> '
^ permalink raw reply
* Re: [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
From: Robin Rosenberg @ 2007-11-14 21:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <200711132243.05877.johannes.sixt@telecom.at>
tisdag 13 november 2007 skrev Johannes Sixt:
> On Tuesday 13 November 2007 22:39, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > > diff --git a/sha1_file.c b/sha1_file.c
> > > index f007874..560c0e0 100644
> > > --- a/sha1_file.c
> > > +++ b/sha1_file.c
> > > @@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path)
> > > char *pos = path;
> > > struct stat st;
> > >
> > > - if (*pos == '/')
> > > + if (is_absolute_path(path))
> > > pos++;
> >
> > Is this enough? On Windows, certain "absolute" paths would need "pos +=
> > 3", no?
>
> True, but this series is not yet about the MinGW port itself. It will be
> changed eventually, but not at this time.
D:/FOO and //deathstar/core work fine in cygwin, which is supported. but git
do not work well with such paths in some places.
-- robin
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Johannes Schindelin @ 2007-11-14 22:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20071114203409.GD3973@steel.home>
Hi,
On Wed, 14 Nov 2007, Alex Riesen wrote:
> Alex Riesen, Wed, Nov 14, 2007 20:45:22 +0100:
>
> > Well, I do not know it _should_ fail. Personally, I would not even
> > care: I see no way to cover with just one exit code multiple failures.
> > Some references were updated and I don't even know which. So I'd
> > better check whatever exit code.
>
> "I'd better check whatever was updated and damn the exit code"
My point was: why not check both? I mean, you know if it fails in your
case. Better to test for this behaviour, than to have it succeed here,
but fail there.
It's really easy, too: if it does not succeed, it fails. Just test for
it.
Ciao,
Dscho "consistency is good"
^ permalink raw reply
* refining .gitignores
From: Bruce Stephens @ 2007-11-14 22:36 UTC (permalink / raw)
To: git
How do I get a list of files (in HEAD, say) that would be ignored by
the .gitignore files (and the other usual settings)?
It feels like something like this ought to work:
git ls-files -z | xargs -0 git ls-files --ignored
But listing its arguments that are ignored by .gitignore (etc.)
doesn't seem to be what "git ls-files --ignored" does. Or at least,
not quite as straightforwardly as that.
The motivation is (obviously) that I fear some of the .gitignore
patterns are too broad, and a reasonable check is that none of the
files that are already committed would be caught by the patterns.
^ permalink raw reply
* [PATCH] Add test that checks diverse aspects of updating remote and tracking branches
From: Alex Riesen @ 2007-11-14 22:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <7vbq9wfqb0.fsf@gitster.siamese.dyndns.org>
Because we haven't settled on what the exit status from
"git push" command itself should be in such a partial
failure case, do not check the exit status from it for
now.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Wed, Nov 14, 2007 22:52:19 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Ignore exit code of git push in t5404, as it is not relevant for the
> > test: it already checks whether the references updated correctly.
>
> I think the Subject: goes a lot better with a description like this:
>
> Add test that checks the case where X does Y and make
> sure Z happens.
Add test that checks diverse aspects of updating remote and tracking
branches.
> Because we haven't settled on what the exit status from
> "git push" command itself should be in such a partial
> failure case, do not check the exit status from it for
> now.
This I'll leave as is.
> > + git branch b3 &&
>
> So it makes another ref "b3" point at the initial commit,...
Right
> > + b3=$(git rev-parse origin/b3) &&
>
> ... then records what was cloned,...
Precisely
> > + test "$(git rev-parse origin/b3)" = "$b3" &&
>
> ... and checks that untouched "b3" stays the same (iow, tests
> up-to-date case).
Yep.
> > +
> > +test_expect_success 'delete remote branch' '
> > + git push origin :refs/heads/b3
> > + {
> > + git rev-parse origin/b3
> > + test $? != 0 || \
> > + say "Hmm... Maybe tracking ref should be deleted?"
> > + } &&
>
> Ah, you meant that tracking should be deleted so this should be
> fixed in the code but the test is disabled for now. Let's be a
> bit more explicit about such a temporary disabled test, like
> this:
>
> git push origin :refs/heads/b3
>
> # The remote-tracking branch origin/b3 should be deleted;
> # we need to update the code and enable this test.
> : git rev-parse --verify origin/b3 &&
Nice, will take this. Except we have to check for absence of the
tracking branch. git-rev-parse must fail.
t/t5404-tracking-branches.sh | 64 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
create mode 100755 t/t5404-tracking-branches.sh
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
new file mode 100755
index 0000000..d861a14
--- /dev/null
+++ b/t/t5404-tracking-branches.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+test_description='tracking branch update checks for git push'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo 1 >file &&
+ git add file &&
+ git commit -m 1 &&
+ git branch b1 &&
+ git branch b2 &&
+ git branch b3 &&
+ git clone . aa &&
+ git checkout b1 &&
+ echo b1 >>file &&
+ git commit -a -m b1 &&
+ git checkout b2 &&
+ echo b2 >>file &&
+ git commit -a -m b2
+'
+
+start_dir="$(pwd)"
+
+test_expect_success 'check tracking branches updated correctly after push' '
+ cd aa &&
+ b1=$(git rev-parse origin/b1) &&
+ b2=$(git rev-parse origin/b2) &&
+ b3=$(git rev-parse origin/b3) &&
+ git checkout -b b1 origin/b1 &&
+ echo aa-b1 >>file &&
+ git commit -a -m aa-b1 &&
+ git checkout -b b2 origin/b2 &&
+ echo aa-b2 >>file &&
+ git commit -a -m aa-b2 &&
+ git checkout master &&
+ echo aa-master >>file &&
+ git commit -a -m aa-master &&
+ {
+ git push
+ test "$(git rev-parse origin/b1)" = "$b1" &&
+ test "$(git rev-parse origin/b2)" = "$b2" &&
+ test "$(git rev-parse origin/b3)" = "$b3" &&
+ test "$(git rev-parse origin/master)" = \
+ "$(git rev-parse master)"
+ }
+'
+
+test_expect_success 'delete remote branch' '
+ git push origin :refs/heads/b3
+ {
+ # The remote-tracking branch origin/b3 should be deleted;
+ # we need to update the code and enable this test.
+ : git rev-parse --verify origin/b3
+ : test $? != 0
+ } &&
+ cd "$start_dir" &&
+ {
+ git rev-parse refs/heads/b3
+ test $? != 0
+ }
+'
+
+test_done
--
1.5.3.5.692.ge1737
^ permalink raw reply related
* Re: refining .gitignores
From: Alex Riesen @ 2007-11-14 23:02 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git
In-Reply-To: <804pfobgkp.fsf@tiny.isode.net>
Bruce Stephens, Wed, Nov 14, 2007 23:36:06 +0100:
> How do I get a list of files (in HEAD, say) that would be ignored by
> the .gitignore files (and the other usual settings)?
>
> It feels like something like this ought to work:
>
> git ls-files -z | xargs -0 git ls-files --ignored
>
> But listing its arguments that are ignored by .gitignore (etc.)
> doesn't seem to be what "git ls-files --ignored" does. Or at least,
> not quite as straightforwardly as that.
git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i -o
> The motivation is (obviously) that I fear some of the .gitignore
> patterns are too broad, and a reasonable check is that none of the
> files that are already committed would be caught by the patterns.
git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i
(IOW, remove the -o aka --others)
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Guido Ostkamp @ 2007-11-14 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Guido Ostkamp, git
In-Reply-To: <7vprycfrk6.fsf@gitster.siamese.dyndns.org>
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Guido Ostkamp, Wed, Nov 14, 2007 21:31:13 +0100:
>>> ...
>>> cc: acomp failed for diff-delta.c
>>> make: *** [diff-delta.o] Error 2
>>>
>>> This is because 'struct delta_index' is declared with no size in delta.h
>>> and with size in diff-delta.c which does not fit.
>>
>> Huh?! Ever heard of forward declaration?
>
> We are not the first people who pass around a pointer to an opaque
> struct in the API to hide away the implementation. It would be
> surprising if the Workshop Compiler chokes on this and not other
> projects.
You got the original error report from Sun's compiler included in my
earlier email. This happens with at least Sun Forte 6.1 (Solaris 8) and
Sun Workshop 11 (Solaris 10), IIRC.
The function declarations regarding create_delta() in delta.h and
diff-delta.c are identical with respect to the type names of the parameter
(only some internal names e.g. like 'buf' vs. 'trg_buf' are slightly
different, but this has no effect).
The main difference is that the 'struct delta_index' is opaque in delta.h
and non-opaque in diff-delta.c; the patch clearly shows it solves the
error. So we've got a solution.
If you feel we could try something else, please let me know and I'll check
it out.
Please keep me on CC, as I'm not subscribed to the list, thanks.
Regards
Guido
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Alex Riesen @ 2007-11-14 23:28 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711150011020.4135@bianca.dialin.t-online.de>
Guido Ostkamp, Thu, Nov 15, 2007 00:21:55 +0100:
> The main difference is that the 'struct delta_index' is opaque in delta.h
> and non-opaque in diff-delta.c; the patch clearly shows it solves the
> error. So we've got a solution.
It is not the solution. How do you think the rest of Git compiles?
> If you feel we could try something else, please let me know and I'll check
> it out.
Yes. Read the mail I sent before:
Try removing the "const". Looks like that compiler is too stupid
to understand it.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Bill Lear @ 2007-11-14 23:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711142047170.4362@racer.site>
On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:
>...
>I have a better idea:
>
>[the initial import, on another machine:]
>% mkdir new_repo
>% cd new_repo
>% git init
>[add content]
>% git commit -a -m "Initial stuff"
>% git remote add origin git://host/repo
>% git push origin master
>
>If you do not want to be bothered with setting up the default
>"remote" and "merge" config variables manually, it is reasonable to ask
>for support to do that in "git remote".
Um, ok, but the above means that this repo now differs from other
repos, in that pushing now involves more than 'git push', i.e.,
'git push origin master'. Is there not a way to configure it "as if"
I had done a 'git clone' and thereafter could just do 'git push'?
I want to do: 1) point to origin; 2) push; and not have to remember
"oh yeah, this is that 'special' repo and I have to tack on 'origin
master' or it won't work", or to clone it somewhere else and work
there.
>If you really think that this workflow has anything to do with cloning an
>empty repository, I cannot help you. I mean, you did not need to clone
>the big, empty void to do the initial commit, or did you?
I just want to point to it and treat it as if it had been cloned to
begin with: it is my future "point of origin". If it is not cloning,
then it is "pointing to it as my origin", as if it were created by the
clone.
What's wrong with 'git init --mirror git://host/repo'? Is it just
another special case that's busy work helping only a few, or does
it belong elsewhere in your opinion?
>(I actually think that it is another example of cvs/svn damage, where you
>_need_ to clone first, or otherwise you will _never_ be able to commit
>to the repository.)
I think there is a tendency here to blame every shortcoming of git on
someone else's supposedly unsanitary past rather than facing up to
inherent problems in git itself. We have several very senior, very
dedicated software developers who LOVE git, and who loathe CVS, but
who nevertheless find many vexing issues in git.
>BTW I am somewhat disgusted by your usage of git:// for pushing.
Whatever. We went through this before on the list and push support
was added to git://. We have SUCKY sysadmin support at our company
and permissions were getting HOSED using ssh pushes. The git://
protocol makes everything clean on the repo side and no nasty
surprises with permissions and no delays begging the support team to
clean things up.
Bill
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Björn Steinbrink @ 2007-11-15 0:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: Guido Ostkamp, Junio C Hamano, git
In-Reply-To: <20071114232809.GH3973@steel.home>
On 2007.11.15 00:28:09 +0100, Alex Riesen wrote:
> Guido Ostkamp, Thu, Nov 15, 2007 00:21:55 +0100:
> > The main difference is that the 'struct delta_index' is opaque in delta.h
> > and non-opaque in diff-delta.c; the patch clearly shows it solves the
> > error. So we've got a solution.
>
> It is not the solution. How do you think the rest of Git compiles?
>
> > If you feel we could try something else, please let me know and I'll check
> > it out.
>
> Yes. Read the mail I sent before:
>
> Try removing the "const". Looks like that compiler is too stupid
> to understand it.
No, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05
It's the "struct hack", ie. the incomplete array at the end of
delta_index. Still looking for a fix/workaround.
Björn
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-15 0:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsso3poo.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* lt/rev-list-interactive (Mon Nov 12 23:16:08 2007 -0800) 5 commits
+ Fix parent rewriting in --early-output
+ revision walker: mini clean-up
+ Enhance --early-output format
+ Add "--early-output" log flag for interactive GUI use
+ Simplify topo-sort logic
* lt/rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
+ Fix rev-list when showing objects involving submodules
This fix from Dscho and Linus will need to be cherry-picked to
'maint' as well.
* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits
+ git-checkout: Test for relative path use.
+ git-checkout: Support relative paths containing "..".
This will allow you to stay in a subdirectory and check out
paths in directories outside. With Dscho's "git status" that
shows relatives paths (in kh/commit series), this would make
cutting and pasting paths you forgot to "git add" easier.
* ph/parseopt-sh (Mon Nov 12 12:07:40 2007 +0000) 17 commits
+ git-quiltimport.sh fix --patches handling
+ git-am: -i does not take a string parameter.
+ sh-setup: don't let eval output to be shell-expanded.
+ git-sh-setup: fix parseopt `eval` string underquoting
+ Give git-am back the ability to add Signed-off-by lines.
+ git-rev-parse --parseopt
+ scripts: Add placeholders for OPTIONS_SPEC
+ Migrate git-repack.sh to use git-rev-parse --parseopt
+ Migrate git-quiltimport.sh to use git-rev-parse --parseopt
+ Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
dashdash
+ Migrate git-instaweb.sh to use git-rev-parse --parseopt
+ Migrate git-merge.sh to use git-rev-parse --parseopt
+ Migrate git-am.sh to use git-rev-parse --parseopt
+ Migrate git-clone to use git-rev-parse --parseopt
+ Migrate git-clean.sh to use git-rev-parse --parseopt.
+ Update git-sh-setup(1) to allow transparent use of git-rev-parse -
-parseopt
+ Add a parseopt mode to git-rev-parse to bring parse-options to
shell scripts.
The rate of incoming fix with this topic has slowed down, which
is a good indication that this is getting ready.
----------------------------------------------------------------
[Actively cooking]
* jk/send-pack (Tue Nov 13 06:37:10 2007 -0500) 24 commits
- send-pack: assign remote errors to each ref
- send-pack: check ref->status before updating tracking refs
- send-pack: track errors for each ref
- Merge branch 'aw/mirror-push' into jk/send-pack
- Merge branch 'ar/send-pack-remote-track' into jk/send-pack
- Merge branch 'db/remote-builtin' into jk/send-pack
+ git-push: add documentation for the newly added --mirror mode
+ Add tests for git push'es mirror mode
+ Update the tracking references only if they were succesfully
updated on remote
+ Add a test checking if send-pack updated local tracking branches
correctly
+ git-push: plumb in --mirror mode
+ Teach send-pack a mirror mode
+ Merge master into aw/mirror-push
+ Merge branch 'jk/terse-push' into aw/mirror-push
+ send-pack: segfault fix on forced push
+ Reteach builtin-ls-remote to understand remotes
+ send-pack: require --verbose to show update of tracking refs
+ receive-pack: don't mention successful updates
+ more terse push output
+ Build in ls-remote
+ Build-in send-pack, with an API for other programs to call.
+ Use built-in send-pack.
+ Build-in peek-remote, using transport infrastructure.
+ Miscellaneous const changes and utilities
This three-patch series is built on top of four other topics and
is meant to fix issues in built-in send-pack. I dropped
individial topics from Alex, Daniel, Andy and another from Jeff
that this series depends on. IOW, they all will graduate to
"master" at the same time when this series proves to be stable.
Will wait for a few days to hear opinions from the list, and
then merge to "next" and start cooking.
* js/mingw-fallouts (Tue Nov 13 21:05:06 2007 +0100) 11 commits
+ Allow ETC_GITCONFIG to be a relative path.
+ Introduce git_etc_gitconfig() that encapsulates access of
ETC_GITCONFIG.
+ Allow a relative builtin template directory.
+ Close files opened by lock_file() before unlinking.
+ builtin run_command: do not exit with -1.
+ Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
util.h.
+ Use is_absolute_path() in sha1_file.c.
+ Skip t3902-quoted.sh if the file system does not support funny
names.
+ t5302-pack-index: Skip tests of 64-bit offsets if necessary.
+ t7501-commit.sh: Not all seds understand option -i
+ t5300-pack-object.sh: Split the big verify-pack test into smaller
parts.
A set of good general clean-up patches.
* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
+ Remove hint to use "git help -a"
+ Make the list of common commands more exclusive
Some people on the list may find the exact list of commands
somewhat debatable. We can fine-tune that in-tree ('pu' does
not count as "in-tree").
* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits
+ Reorder diff_opt_parse options more logically per topics.
+ Make the diff_options bitfields be an unsigned with explicit
masks.
+ Use OPT_BIT in builtin-pack-refs
+ Use OPT_BIT in builtin-for-each-ref
+ Use OPT_SET_INT and OPT_BIT in builtin-branch
+ parse-options new features.
Further code clean-ups.
----------------------------------------------------------------
[Approaching 'next']
* kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits
- builtin-commit: Clean up an unused variable and a debug fprintf().
- Call refresh_cache() when updating the user index for --only
commits.
- builtin-commit: Add newline when showing which commit was created
- builtin-commit: resurrect behavior for multiple -m options
- builtin-commit --s: add a newline if the last line was not a S-o-b
- builtin-commit: fix --signoff
- git status: show relative paths when run in a subdirectory
- builtin-commit: Refresh cache after adding files.
- builtin-commit: fix reflog message generation
- launch_editor(): read the file, even when EDITOR=:
- Port git commit to C.
- Export launch_editor() and make it accept ':' as a no-op editor.
- Add testcase for amending and fixing author in git commit.
Dscho fixed a few obvious glitches, but indicated he has a
handful more issues with the series. I have been hoping that
this series should be in "testable" shape now. Will need to
look at it again.
* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
- refactor fetch's ref matching to use refname_match()
- push: use same rules as git-rev-parse to resolve refspecs
- add refname_match()
- push: support pushing HEAD to real branch name
This changes the semantics slightly but I think it is a move in
the right direction.
* sb/clean (Mon Nov 12 21:13:05 2007 -0800) 2 commits
- git-clean: Fix error message if clean.requireForce is not set.
- Make git-clean a builtin
It has a subtle change in behaviour but it does not quite
qualify as a regression. Will merge to "next" shortly. We can
fix the corner case semantics in-tree. I also adjusted the
error message to match the fix from Hannes on 'master'.
----------------------------------------------------------------
[Stalled]
* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
- Do git reset --hard HEAD when using git rebase --skip
Some people on the list may find this debatable. Opinions?
* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
- Make builtin-tag.c use parse_options.
This changes the handling of multiple -m options without much
good reason. It should be a simple fix, once we know what we
want. I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.
* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
- Added diff hunk coloring to git-add--interactive
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
This series has improved quite a bit since the last round, but
another round was requested from the list. Waiting for
refinements.
* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
+ Add missing inside_work_tree setting in setup_git_directory_gently
There was an additional patch, which still had issues Dscho
pointed out. Waiting for refinements.
* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
- Make git-svn rebase --dirty pass along --dirty to git-rebase.
- Implement --dirty for git-rebase--interactive.
- Introduce --dirty option to git-rebase, allowing you to start from
a dirty state.
This seems to be optimized for the --dirty case too much. I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").
----------------------------------------------------------------
[Others]
* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
- git-branch --with=commit
I did this just for my own fun. --contains might be more
consistent with git-describe but --with is shorter to type ;-)
Besides, it needs documentation and tests.
* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
- test format-patch -s: make sure MIME content type is shown as
needed
- format-patch -s: add MIME encoding header if signer's name
requires so
This is to apply to 'maint' later; the equivalent fix is already
in 'master'.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
- handle renames using similarity engine
- introduce generic similarity library
- change hash table calling conventions
* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
- revert/cherry-pick: start refactoring call to merge_recursive
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-15 0:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7d43ptc.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch has these fixes since the last announcement.
Benoit Sigoure (1):
git-svn: prevent dcommitting if the index is dirty.
Christian Couder (1):
for-each-ref: fix off by one read.
Jeff King (1):
git-branch: remove mention of non-existent '-b' option
Jing Xue (1):
replace reference to git-rm with git-reset in git-commit doc
Jonas Fonseca (1):
Documentation: Fix man page breakage with DocBook XSL v1.72
Junio C Hamano (3):
t/t3404: fix test for a bogus todo file.
revert/cherry-pick: allow starting from dirty work tree.
git-clean: honor core.excludesfile
Sergei Organov (2):
core-tutorial.txt: Fix argument mistake in an example.
git-remote.txt: fix typo
Shawn O. Pearce (2):
Fix memory leak in traverse_commit_list
Don't allow fast-import tree delta chains to exceed maximum depth
Wincent Colaiuta (1):
Grammar fixes for gitattributes documentation
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix dependencies of parse-options test program
Andreas Ericsson (1):
Simplify strchrnul() compat code
Björn Steinbrink (3):
git-commit.sh: Fix usage checks regarding paths given when they do
not make sense
t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
git-commit: Add tests for invalid usage of -a/--interactive with
paths
Brian Gernhardt (2):
format-patch: Add configuration and off switch for --numbered
format-patch: Test --[no-]numbered and format.numbered
David Symonds (1):
Rearrange git-format-patch synopsis to improve clarity.
Emil Medve (1):
git-stash: Fix listing stashes
Eric Wong (1):
git-svn: support for funky branch and project names over HTTP(S)
Gordon Hopper (1):
git-cvsimport: fix handling of user name when it is not set in
CVSROOT
Johannes Schindelin (2):
rebase: operate on a detached HEAD
rebase: fix "rebase --continue" breakage
Johannes Sixt (2):
git-clean: Fix error message if clean.requireForce is not set.
Fix preprocessor logic that determines the availablity of
strchrnul().
Jonas Fonseca (1):
Documentation: Fix references to deprecated commands
Junio C Hamano (9):
stash: implement "stash create"
rebase: allow starting from a dirty tree.
Revert "rebase: allow starting from a dirty tree."
git-merge: no reason to use cpio anymore
ce_match_stat, run_diff_files: use symbolic constants for
readability
git-add: make the entry stat-clean after re-adding the same
contents
t2200: test more cases of "add -u"
Resurrect git-revert.sh example and add comment to builtin-revert.c
core.excludesfile clean-up
Mike Hommey (2):
Reuse previous annotation when overwriting a tag
Add tests for git tag
Nicolas Pitre (6):
fix display overlap between remote and local progress
sideband.c: ESC is spelled '\033' not '\e' for portability.
make display of total transferred more accurate
remove dead code from the csum-file interface
make display of total transferred fully accurate
nicer display of thin pack completion
Pierre Habouzit (1):
git-fetch: be even quieter.
René Scharfe (5):
Add strchrnul()
--pretty=format: on-demand format expansion
--pretty=format: parse commit message only once
add strbuf_adddup()
--format=pretty: avoid calculating expensive expansions twice
Robin Rosenberg (1):
cvsexportcommit: Add switch to specify CVS workdir
Rémi Vanicat (1):
Make GIT_INDEX_FILE apply to git-commit
Sergei Organov (2):
user-manual.txt: fix a few mistakes
user-manual: minor rewording for clarity.
Shawn O. Pearce (5):
git-fetch: Always fetch tags if the object they reference exists
run-command: Support sending stderr to /dev/null
rev-list: Introduce --quiet to avoid /dev/null redirects
git-fetch: avoid local fetching from alternate (again)
Handle broken vsnprintf implementations in strbuf
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-15 0:28 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
In-Reply-To: <18235.34578.886521.944550@lisa.zopyra.com>
Hi,
On Wed, 14 Nov 2007, Bill Lear wrote:
> On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:
> >...
> >I have a better idea:
> >
> >[the initial import, on another machine:]
> >% mkdir new_repo
> >% cd new_repo
> >% git init
> >[add content]
> >% git commit -a -m "Initial stuff"
> >% git remote add origin git://host/repo
> >% git push origin master
> >
> >If you do not want to be bothered with setting up the default
> >"remote" and "merge" config variables manually, it is reasonable to ask
> >for support to do that in "git remote".
>
> Um, ok, but the above means that this repo now differs from other
> repos, in that pushing now involves more than 'git push', i.e.,
> 'git push origin master'.
Nope. That is necessary only for the initial push.
Remember: "git push" defaults to pushing to the remote "origin", and _all_
local branches which the remote knows about.
And the latter is the reason why the initial push needs a special
handling: the local and the remote repository have no branches in common,
because the remote one does not have _any_ branch yet!
So, once you pushed the initial push, you can drop the "origin master"
from subsequent pushes!
> What's wrong with 'git init --mirror git://host/repo'?
It's highly unlikely that you have the same in mind as git when you say
"--mirror" in this context. Just have a look at git-push, which has
recently acquired that option.
Besides, we really have "clone" for "init + fetch".
> >(I actually think that it is another example of cvs/svn damage, where
> >you _need_ to clone first, or otherwise you will _never_ be able to
> >commit to the repository.)
>
> I think there is a tendency here to blame every shortcoming of git on
> someone else's supposedly unsanitary past rather than facing up to
> inherent problems in git itself.
I am not blaming here. I just try to see where it comes from.
In git, all repositories are equal. Provided you can connect two of them
(or not even that; think of bundles), you can push back and forth between
_all_ of them.
Since this is something I like about git, I had some problems finding out
where this "I have to clone from the same repository I want to push to"
idea comes from.
> We have several very senior, very dedicated software developers who
> LOVE git, and who loathe CVS, but who nevertheless find many vexing
> issues in git.
And I am thankful that you bring up the vexing issues so that we can
discuss (and hopefully fix) them.
> >BTW I am somewhat disgusted by your usage of git:// for pushing.
>
> Whatever. We went through this before on the list and push support was
> added to git://. We have SUCKY sysadmin support at our company and
> permissions were getting HOSED using ssh pushes. The git:// protocol
> makes everything clean on the repo side and no nasty surprises with
> permissions and no delays begging the support team to clean things up.
Hey, if it works for you, I am all the happier! (Of course, I am in a
better position than you, here; I _am_ the sysadmin, and my ssh setup Just
Works...)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Junio C Hamano @ 2007-11-15 0:30 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Alex Riesen, Guido Ostkamp, git
In-Reply-To: <20071115001756.GA25021@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> No, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05
>
> It's the "struct hack", ie. the incomplete array at the end of
> delta_index. Still looking for a fix/workaround.
Do you mean the "FLEX_ARRAY" thing?
You can ask for FLEX_ARRAY from the command line of your "make"
process.
There is this thing in git-compat-util.h
#ifndef FLEX_ARRAY
#if defined(__GNUC__) && (__GNUC__ < 3)
#define FLEX_ARRAY 0
#else
#define FLEX_ARRAY /* empty */
#endif
#endif
The sources are written this way:
struct foo {
... other members ...
char last_member_that_is_flexible[FLEX_ARRAY];
};
For older gcc, because we know about its lack of support, the
above turns into:
struct foo {
... other members ...
char last_member_that_is_flexible[0];
}
But for recent enough compilers that grok the "flexible array
members", the above expands to:
struct foo {
... other members ...
char last_member_that_is_flexible[];
}
Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Björn Steinbrink @ 2007-11-15 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Guido Ostkamp, git
In-Reply-To: <7v3av89wq7.fsf@gitster.siamese.dyndns.org>
On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > No, just tried with cc: Sun C 5.7 Patch 117837-06 2005/10/05
> >
> > It's the "struct hack", ie. the incomplete array at the end of
> > delta_index. Still looking for a fix/workaround.
>
> Do you mean the "FLEX_ARRAY" thing?
>
> You can ask for FLEX_ARRAY from the command line of your "make"
> process.
>
> There is this thing in git-compat-util.h
>
> #ifndef FLEX_ARRAY
> #if defined(__GNUC__) && (__GNUC__ < 3)
> #define FLEX_ARRAY 0
> #else
> #define FLEX_ARRAY /* empty */
> #endif
> #endif
>
> The sources are written this way:
>
> struct foo {
> ... other members ...
> char last_member_that_is_flexible[FLEX_ARRAY];
> };
>
> For older gcc, because we know about its lack of support, the
> above turns into:
>
> struct foo {
> ... other members ...
> char last_member_that_is_flexible[0];
> }
>
> But for recent enough compilers that grok the "flexible array
> members", the above expands to:
>
> struct foo {
> ... other members ...
> char last_member_that_is_flexible[];
> }
>
> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
Actually, I just created a test-case remotely on a Solaris box in my
university (see below) and didn't compile the actual git code. With the
FAM, cc complains about a redeclared identifier, with a zero-sized
array, it complains that an array cannot be zero-sized...
Seems to be a known bug in Sun Studio 10:
http://forum.java.sun.com/thread.jspa?threadID=5071896&messageID=9263771
Björn
#include <stdio.h>
struct foo;
void bar(const struct foo *, unsigned long);
struct bla {
unsigned long foo;
};
struct foo {
unsigned long val;
struct bla *blas[];
};
void bar(const struct foo *foo, unsigned long val)
{
printf("%lu %lu\n", foo->val, val);
}
int main()
{
struct foo foo;
foo.val = 10;
bar(&foo, 20);
return 0;
}
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Linus Torvalds @ 2007-11-15 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Alex Riesen, Guido Ostkamp, git
In-Reply-To: <7v3av89wq7.fsf@gitster.siamese.dyndns.org>
On Wed, 14 Nov 2007, Junio C Hamano wrote:
>
> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
Actually, for old pre-C99 compilers, you're probably better off using
-DFLEX_ARRAY=1, since a zero-sized array could be considered bogus by
some.
Linus
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Junio C Hamano @ 2007-11-15 0:46 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Alex Riesen, Guido Ostkamp, git
In-Reply-To: <20071115004404.GB25021@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:
>
>> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
>
> Actually, I just created a test-case remotely on a Solaris box in my
> university (see below) and didn't compile the actual git code. With the
> FAM, cc complains about a redeclared identifier, with a zero-sized
> array, it complains that an array cannot be zero-sized...
I think you can pass -DFLEX_ARRAY=1 as a workaround. It would
waste one array member in a flexible structure but that is
better than compiler choking.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-15 0:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxz89x9q.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> ----------------------------------------------------------------
> [Approaching 'next']
>
> * kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits
> - builtin-commit: Clean up an unused variable and a debug fprintf().
> - Call refresh_cache() when updating the user index for --only
> commits.
> - builtin-commit: Add newline when showing which commit was created
> - builtin-commit: resurrect behavior for multiple -m options
> - builtin-commit --s: add a newline if the last line was not a S-o-b
> - builtin-commit: fix --signoff
> - git status: show relative paths when run in a subdirectory
> - builtin-commit: Refresh cache after adding files.
> - builtin-commit: fix reflog message generation
> - launch_editor(): read the file, even when EDITOR=:
> - Port git commit to C.
> - Export launch_editor() and make it accept ':' as a no-op editor.
> - Add testcase for amending and fixing author in git commit.
>
> Dscho fixed a few obvious glitches, but indicated he has a
> handful more issues with the series. I have been hoping that
> this series should be in "testable" shape now. Will need to
> look at it again.
Well, it _is_ in testable shape. My working setup is using builtin-commit
since a week. One glitch is serious: "git add a1 && git commit b1" will
commit a1, too.
Another glitch is only mildly annoying to me (but I have not investigated
in detail yet): when you commit new files in a subsubdirectory, no summary
"created file" is printed for them.
Other than that, I am pretty happy with it, and the other issues I listed
should be easily fixable.
> ----------------------------------------------------------------
> [Stalled]
>
> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
> - Do git reset --hard HEAD when using git rebase --skip
>
> Some people on the list may find this debatable. Opinions?
I run with it, and like it. Sometimes when I rebase to 'next', a patch
has subtle differences compared to the patch which was applied, and then I
see in the conflict handling that it was applied already. So I do the
obvious: I --skip, and it Just Works.
But you _can_ mistakenly say "--skip". That's why I pushed for the
detached HEAD when rebasing.
> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
> - Make builtin-tag.c use parse_options.
>
> This changes the handling of multiple -m options without much good
> reason. It should be a simple fix, once we know what we want. I think
> the existing behaviour of refusing multiple -m is probably the most sane
> at this point.
Agree.
> * nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
> + Add missing inside_work_tree setting in setup_git_directory_gently
>
> There was an additional patch, which still had issues Dscho pointed out.
> Waiting for refinements.
This might be something pretty painful, though, speaking from my own
experience with the work-tree stuff.
> ----------------------------------------------------------------
> [Others]
>
> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
> - git-branch --with=commit
>
> I did this just for my own fun. --contains might be more
> consistent with git-describe but --with is shorter to type ;-)
--with might confuse people who know that you can use "git branch" to
create branches, but do not quite know how.
Besides, "--con" would be enough, and you can always add '-c'. Or use
completions.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: Björn Steinbrink @ 2007-11-15 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Guido Ostkamp, git
In-Reply-To: <7vy7d08her.fsf@gitster.siamese.dyndns.org>
On 2007.11.14 16:46:20 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > On 2007.11.14 16:30:08 -0800, Junio C Hamano wrote:
> >
> >> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
> >
> > Actually, I just created a test-case remotely on a Solaris box in my
> > university (see below) and didn't compile the actual git code. With the
> > FAM, cc complains about a redeclared identifier, with a zero-sized
> > array, it complains that an array cannot be zero-sized...
>
> I think you can pass -DFLEX_ARRAY=1 as a workaround. It would
> waste one array member in a flexible structure but that is
> better than compiler choking.
Yeah, that at least compiles (didn't do any further tests), forgot to
say that in the last email.
Björn
^ permalink raw reply
* [PATCH] Fix "identifier redeclared" compilation error with SUN cc.
From: Björn Steinbrink @ 2007-11-15 1:15 UTC (permalink / raw)
To: gitster; +Cc: raa.lkml, git, git, Björn Steinbrink
In-Reply-To: <7vy7d08her.fsf@gitster.siamese.dyndns.org>
Some versions of SUN's cc have a bug that causes them to complain about
a redeclared identifier when you use a function declaration that takes a
struct with a FAM and this struct has only been declared but not yet
defined.
IOW, this will fail:
struct foo;
void bar(struct foo *);
struct foo {
int v;
long *a[];
};
void bar(struct foo *foo) {} // SUN cc bug strikes here
So when we detect a SUN cc, we use an array size of 1 to workaround that
bug.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
Guido, could you please test this patch?
I have no clue which versions of SUN's cc are affected, so I simply enabled
the workaround for all versions. Someone with more knowledge about that
should probably limit the check to only do that for the broken versions.
git-compat-util.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index ede9408..c3ff4b4 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -6,6 +6,8 @@
#ifndef FLEX_ARRAY
#if defined(__GNUC__) && (__GNUC__ < 3)
#define FLEX_ARRAY 0
+#elif defined(sun) || defined(__SUN__)
+#define FLEX_ARRAY 1
#else
#define FLEX_ARRAY /* empty */
#endif
--
1.5.3.5.643.g40e25
^ permalink raw reply related
* Re: Integrating with hooks
From: Todd A. Jacobs @ 2007-11-15 1:18 UTC (permalink / raw)
To: git
In-Reply-To: <fhdane$kfs$1@ger.gmane.org>
On Wed, Nov 14, 2007 at 12:07:29AM +0100, Jakub Narebski wrote:
> Take a look at gitattributes(5), namely 'filter' attribute.
Thanks, I took a look at the man page you suggested. The "ident" feature
almost does what I want, but doesn't seem to take any sort of format
string. So, I thought I'd explore "filter," but can't really find any
examples of how to implement the smudge and clean commands, which seem
to be what I'm really trying to do here.
Is there an example somewhere that you can point me to? The man page
doesn't really show any examples of how to implement the filter
attribute, so I'm a little unsure how to proceed.
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: [PATCH] Fix Solaris Workshop Compiler issues
From: David Kastrup @ 2007-11-15 1:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Björn Steinbrink, Alex Riesen, Guido Ostkamp,
git
In-Reply-To: <alpine.LFD.0.9999.0711141640400.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 14 Nov 2007, Junio C Hamano wrote:
>>
>> Maybe your compiler needs -DFLEX_ARRAY=0 in CFLAGS?
>
> Actually, for old pre-C99 compilers, you're probably better off using
> -DFLEX_ARRAY=1, since a zero-sized array could be considered bogus by
> some.
Is that supposed to work? I would have thought that the only options
would be empty and 0. I am pretty sure I have seen size calculations in
the deltifying code that would break badly using FLEX_ARRAY=1. So _IFF_
-DFLEX_ARRAY=1 is supposed to be necessary for some compilers, I could
try seeing whether I find those locations again.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ 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