* Re: Gitweb: Provide Git links in project list?
From: Boyd Lynn Gerber @ 2008-07-30 16:41 UTC (permalink / raw)
To: J.H.; +Cc: Robert Richter, git
In-Reply-To: <1217432970.2884.8.camel@localhost.localdomain>
On Wed, 30 Jul 2008, J.H. wrote:
> That is a kernel.org specific change - if the community at large wants
> it I can dig the patch out (I likely didn't do it as it's own patch when
> I did it, being young, naive and stupid at the time - I'm now slightly
> older and slightly less naive now ;-)
>
> But yeah - if people feel that's interesting I'm happy to rip it out
> later today and submit it to the mailing list.
I would like to see the patch. I think it would be good to get it
included.
Thanks,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* [PATCH] Add testcase to ensure merging an early part of a branch is done properly
From: Miklos Vajna @ 2008-07-30 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabfz7puk.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Jul 30, 2008 at 01:12:19AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> In addition, the message forgot to skip "refs/heads/" it prefixed from
> the
> output.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * It is a bit surprising that after beating merge-in-C to death, we
> still find a minor breakage like this.
Uh-oh. Here is a testcase that fails with master, but passes with your
patch.
Thanks for catching this.
t/t7607-merge-early.sh | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100755 t/t7607-merge-early.sh
diff --git a/t/t7607-merge-early.sh b/t/t7607-merge-early.sh
new file mode 100755
index 0000000..9dd3ac5
--- /dev/null
+++ b/t/t7607-merge-early.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing merging an early part of a branch.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2 &&
+ git reset --hard c0 &&
+ echo c3 > c3.c &&
+ git add c3.c &&
+ git commit -m c3 &&
+ git tag c3
+'
+
+cat >expected <<EOF
+Merge branch 'c2' (early part)
+EOF
+
+test_expect_success 'merge early part of c2' '
+ git merge c2~1 &&
+ git show -s --pretty=format:%s HEAD > actual &&
+ test_cmp actual expected
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-30 17:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabg09rye.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
On Tue, Jul 29, 2008 at 04:43:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, this eval shows why "theirs" cannot be a symmetric operation
> of "ours". You are taking the last remote HEAD even when you are merging
> more than one remote into the current branch at once. "ours" can be
> sensibly defined for an octopus, but "theirs" has this "which theirs"
> problem ;-)
Oh, well, sure. But _if_ it turns out there is a demand for that kind of
git-merge-theirs, then I suppose we could still give up if we are given
two or more remotes, just like merge-resolve and others do.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] Add a second testcase for handling invalid strategies in git-merge
From: Miklos Vajna @ 2008-07-30 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhca89s02.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
On Tue, Jul 29, 2008 at 04:42:53PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> True, but with the old code that might blindly have executed
> git-merge-index the test would also have failed, and you would want to
> tell two cases apart, wouldn't you?
Hmm, I wonder what is the right approach to test it. Should I exit with
a different error code with the strategy is invalid?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Replace uses of "git-var" with "git var"
From: Todd Zullinger @ 2008-07-30 17:48 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
I noticed while reading the git send-email documentation that it mentioned
git-var -l. I have hopefully fixed up all the places where git-var is used and
not broken anything.
Documentation/git-send-email.txt | 2 +-
contrib/examples/git-commit.sh | 6 +++---
contrib/examples/git-tag.sh | 2 +-
git-am.sh | 2 +-
ident.c | 2 +-
perl/Git.pm | 2 +-
var.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index afbb294..e2437f3 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -56,7 +56,7 @@ The --cc option must be repeated for each user you want on the cc list.
--from::
Specify the sender of the emails. This will default to
- the value GIT_COMMITTER_IDENT, as returned by "git-var -l".
+ the value GIT_COMMITTER_IDENT, as returned by "git var -l".
The user will still be prompted to confirm this entry.
--in-reply-to::
diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh
index 2c4a406..5c72f65 100755
--- a/contrib/examples/git-commit.sh
+++ b/contrib/examples/git-commit.sh
@@ -443,7 +443,7 @@ fi | git stripspace >"$GIT_DIR"/COMMIT_EDITMSG
case "$signoff" in
t)
- sign=$(git-var GIT_COMMITTER_IDENT | sed -e '
+ sign=$(git var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
s/^/Signed-off-by: /
')
@@ -535,8 +535,8 @@ esac
case "$no_edit" in
'')
- git-var GIT_AUTHOR_IDENT > /dev/null || die
- git-var GIT_COMMITTER_IDENT > /dev/null || die
+ git var GIT_AUTHOR_IDENT > /dev/null || die
+ git var GIT_COMMITTER_IDENT > /dev/null || die
git_editor "$GIT_DIR/COMMIT_EDITMSG"
;;
esac
diff --git a/contrib/examples/git-tag.sh b/contrib/examples/git-tag.sh
index e9f3a22..2c15bc9 100755
--- a/contrib/examples/git-tag.sh
+++ b/contrib/examples/git-tag.sh
@@ -164,7 +164,7 @@ git check-ref-format "tags/$name" ||
object=$(git rev-parse --verify --default HEAD "$@") || exit 1
type=$(git cat-file -t $object) || exit 1
-tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1
+tagger=$(git var GIT_COMMITTER_IDENT) || exit 1
test -n "$username" ||
username=$(git config user.signingkey) ||
diff --git a/git-am.sh b/git-am.sh
index 6aa8192..8f91a97 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -291,7 +291,7 @@ fi
ws=`cat "$dotest/whitespace"`
if test "$(cat "$dotest/sign")" = t
then
- SIGNOFF=`git-var GIT_COMMITTER_IDENT | sed -e '
+ SIGNOFF=`git var GIT_COMMITTER_IDENT | sed -e '
s/>.*/>/
s/^/Signed-off-by: /'
`
diff --git a/ident.c b/ident.c
index b35504a..09cf0c9 100644
--- a/ident.c
+++ b/ident.c
@@ -204,7 +204,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git-var -l" */
+ env_hint = NULL; /* warn only once, for "git var -l" */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
diff --git a/perl/Git.pm b/perl/Git.pm
index d99e778..087d3d0 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -730,7 +730,7 @@ This suite of functions retrieves and parses ident information, as stored
in the commit and tag objects or produced by C<var GIT_type_IDENT> (thus
C<TYPE> can be either I<author> or I<committer>; case is insignificant).
-The C<ident> method retrieves the ident information from C<git-var>
+The C<ident> method retrieves the ident information from C<git var>
and either returns it as a scalar string or as an array with the fields parsed.
Alternatively, it can take a prepared ident string (e.g. from the commit
object) and just parse it.
diff --git a/var.c b/var.c
index 724ba87..f1eb314 100644
--- a/var.c
+++ b/var.c
@@ -5,7 +5,7 @@
*/
#include "cache.h"
-static const char var_usage[] = "git-var [-l | <variable>]";
+static const char var_usage[] = "git var [-l | <variable>]";
struct git_var {
const char *name;
--
1.6.0.rc1
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am not young enough to know everything.
-- Oscar Wilde (1854-1900)
^ permalink raw reply related
* [PATCH v3] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-30 17:53 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Anders Melchiorsen
In-Reply-To: <20080730051059.GA4497@sigill.intra.peff.net>
An empty commit message is now treated as a normal situation, not an error.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
So, I decided that I find it wrong to promote functionality
that results in an error. The error is now changed into a
normal exit (with status code 1.)
builtin-commit.c | 4 +++-
t/t7502-commit.sh | 7 ++++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..bc59718 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
+ "# To abort the commit, use an empty commit message.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
fprintf(fp, "not be included)\n");
@@ -1003,7 +1004,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ fprintf(stderr, "Aborting commit due to empty commit message.\n");
+ exit(1);
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 4f2682e..f111263 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -142,6 +142,7 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
# Please enter the commit message for your changes.
+# To abort the commit, use an empty commit message.
# (Comment lines starting with '#' will not be included)" >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
@@ -149,7 +150,7 @@ test_expect_success 'cleanup commit messages (strip,-F,-e)' '
echo >>negative &&
{ echo;echo sample;echo; } >text &&
git commit -e -F text -a &&
- head -n 4 .git/COMMIT_EDITMSG >actual &&
+ head -n 5 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -162,7 +163,7 @@ test_expect_success 'author different from committer' '
echo >>negative &&
git commit -e -m "sample"
- head -n 7 .git/COMMIT_EDITMSG >actual &&
+ head -n 8 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -181,7 +182,7 @@ test_expect_success 'committer is automatic' '
# must fail because there is no change
test_must_fail git commit -e -m "sample"
) &&
- head -n 8 .git/COMMIT_EDITMSG | \
+ head -n 9 .git/COMMIT_EDITMSG | \
sed "s/^# Committer: .*/# Committer:/" >actual &&
test_cmp expect actual
'
--
1.5.6.4
^ permalink raw reply related
* Re: cvs diff -l equivalent?
From: Johannes Schindelin @ 2008-07-30 18:18 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080730155853.GA27166@cuci.nl>
Hi,
On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> Johannes Schindelin wrote:
> >On Wed, 30 Jul 2008, Stephen R. van den Berg wrote:
> >> Someone popped this question on me.
>
> >I do not know cvs that well anymore. So I do not know what -l does. Care
> >to explain?
>
> Usage: cvs diff [-lR] [-k kopt] [format_options]
> [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...]
> -l Local directory only, not recursive
>
> It shows the diff for all files in the current directory, nothing
> deeper, nothing higher.
Okay. This is my version of a solution:
$ find . -maxdepth 1 -type f -print0 | xargs -0 git diff
And no, there is not an easier way. Probably since Git has a snapshot
based idea of the contents, i.e. it does not think that the files in a
revision are decoupled. Not even the ones in different directories.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Johannes Schindelin @ 2008-07-30 18:21 UTC (permalink / raw)
To: Steve Haslam; +Cc: git, Johannes Sixt
In-Reply-To: <48909396.3080500@lastminute.com>
Hi,
On Wed, 30 Jul 2008, Steve Haslam wrote:
> I think that once git-upload-pack.c et al get the argv[0] path over to
> setup_path() then there's nothing more to do; setup_path() already uses
> argv0_path in its list of paths to try. I'm confused to the reference to
> PATH, though: we're avoiding the PATH environment variable completely.
There is an issue in setting up the argv0_path when Git is called as "git"
and resolved via the PATH: argv[0] then is literally "git".
And we need argv0_path for other things than just calling programs:
relative etc/gitconfig and libexecdir.
Ciao,
Dscho
^ permalink raw reply
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-30 18:27 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: git list
In-Reply-To: <20080730132044.GF17649@jukie.net>
Bart Trojanowski <bart@jukie.net> writes:
> Could you let me know what the biggest inaccuracies were? I would like
> to correct my mistakes and update the slides.
The one I offhand can recall was in your spoken part not on slides ("git
add -u" does not notice new files but does notice removed ones). Nothing
major, really.
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 18:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, peff, Junio C Hamano
In-Reply-To: <alpine.LSU.1.00.0807301624410.3486@wbgn129.biozentrum.uni-wuerzburg.de>
On Jul 30, 2008, at 7:29 AM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Kevin Ballard wrote:
>
>> MIME defines the encapsulation boundary as including the preceding
>> CRLF (or in
>
> This line will still be too long in git log's output, as well as in
> git
> shortlog's output. I thought we had a suggestion to use at most 76
> characters per line in SubmittingPatches, but apparently we don't.
Good point. I'll send another re-wrapped patch.
>> The second change is to always write the line termination character
>> (default: newline) even when using --inline or --attach. This is
>> simply
>> to improve the aesthetics of the resulting message. When using --
>> inline
>> an email client should render the resulting message identically to
>> the
>> non-inline version. And when using --attach this adds a blank line
>> preceding the attachment in the email, which is visually attractive.
>
> It appears that your patch has one uncontroversial and one
> controversial
> part, then.
Is this controversial? Nobody's objected so far. My goal with this
change is to make the --inline output render exactly the same as the
default output in a mail client. I can't think of any downside.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-30 18:33 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Eyvind Bernhardsen, Dmitry Potapov, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <80518F08-A9A9-4190-9AC4-D24DD6A1188B@zib.de>
On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
> On Jul 29, 2008, at 11:17 PM, Eyvind Bernhardsen wrote:
> > I think the real penalty is that with autocrlf enabled, Git no longer
> > stores exactly what I committed.
>
> Git does *never* exactly store what you committed. Git compresses
> your data and creates packs containing many of your individual
> files in a single pack.
This is not really an argument; making perfectly reversible changes as
part of the storage process, then reversing them as part of the
retrieval process, doesn't count as not storing what I committed.
> What matters is that git gives you exactly back what you committed. It
> does so with core.autocrlf=true, unless you check out with a different
> setting for autocrlf.
You can tell that this statement isn't quite true because if you have
a file with mixed LF and CRLF line endings, which I do (thanks,
Windows!) then CRLF->LF conversion is not a reversible operation.
Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
have a bare LF, and on such a subset of files, CRLF->LF is
reversible).
Also note that core.autocrlf=input is *definitely* not a perfectly
reversible operation.
And so here's the problem: svn hands you a file. It may or may not
have CRLFs in it, and the line endings may actually be a random mix of
LF and CRLF, as I am actually experiencing at the moment in a
particular repository at work. If core.autocrlf is anything other
than "false", git will modify the file, and git-svn won't be apply the
diff on the next revision.
It's conceivable that core.autocrlf=true will work if your svn
repository is pure and svn hands you files only with CRLF endings.
It's somewhat unlikely that most svn repositories are in that state
(remember: it has to be perfect in *every revision* for git-svn to
work).
So anyway, I can't see how git-svn can possibly work in the general
case if core.autocrlf is anything other than false *at git-svn fetch
time*. And that's what I do, and it works great, modulo a bunch of
stupid CRLFs that sneak into the repo via svn, but those can be fixed.
Someday we'll stop using svn, and git-filter-branch can fix them all
retroactively so that "blame" will work right.
Perhaps git-svn needs to actually ignore the core.autocrlf setting?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Junio C Hamano @ 2008-07-30 18:35 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <bb6f213e0807300210r205846b4qffa9fc71d4aa6533@mail.gmail.com>
"Alexander Gavrilov" <angavrilov@gmail.com> writes:
>> If you see a copied or renamed entry, you emit "this old path to that old
>> path" first, and then say that same path got modified. It appears from my
>> quick glance of fast-import that touching the same path more than once in
>> a same commit like this sequence does would work fine (it will involve two
>> calls to tree_content_set() for the same path but that is not something it
>> has to forbid, and the function doesn't).
>
> I'm sorry, but I don't quite understand what are you suggesting by
> this paragraph.
Sorry for the unmarked remark --- this was not a question, suggestion nor
complaint, but just a plain observation. I should have ended the
paragraph with "--- I think it's all good." to avoid confusion.
>>> +export GIT_AUTHOR_NAME='A U Thor'
>>> +export GIT_COMMITTER_NAME='C O Mitter'
>>> +
>>> +test_expect_success 'setup copies' '
>>> +
>>> + git config --unset i18n.commitencoding &&
>>
>> These are somewhat unusual. Was there any reason for these exports and
>> config?
>>
>
> t9301-fast-export.sh earlier changes these parameters to test
> automatic conversion to utf8.
Yeah, I noticed that while looking at wider context, after I sent the
message you are responding to.
Anyway, thanks for the patch. Applied and pushed out.
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Kevin Ballard @ 2008-07-30 18:37 UTC (permalink / raw)
Cc: Johannes Schindelin, git, peff, Junio C Hamano
In-Reply-To: <B805BDA1-6C22-4488-B5F5-6DA8CC729C06@sb.org>
On Jul 30, 2008, at 11:30 AM, Kevin Ballard wrote:
>> Hi,
>>
>> On Tue, 29 Jul 2008, Kevin Ballard wrote:
>>
>>> MIME defines the encapsulation boundary as including the preceding
>>> CRLF (or in
>>
>> This line will still be too long in git log's output, as well as in
>> git
>> shortlog's output. I thought we had a suggestion to use at most 76
>> characters per line in SubmittingPatches, but apparently we don't.
>
> Good point. I'll send another re-wrapped patch.
Nevermind, looks like the previous one was already applied.
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: [PATCH] format-patch: Produce better output with --inline or --attach
From: Junio C Hamano @ 2008-07-30 18:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kevin Ballard, git, peff
In-Reply-To: <alpine.LSU.1.00.0807301624410.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The second change is to always write the line termination character
>> (default: newline) even when using --inline or --attach. This is simply
>> to improve the aesthetics of the resulting message. When using --inline
>> an email client should render the resulting message identically to the
>> non-inline version. And when using --attach this adds a blank line
>> preceding the attachment in the email, which is visually attractive.
>
> It appears that your patch has one uncontroversial and one controversial
> part, then.
Could you elaborate what's controversial about this?
^ permalink raw reply
* Re: [PATCH] Glean libexec path from argv[0] for git-upload-pack and git-receive-pack.
From: Steve Haslam @ 2008-07-30 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Johannes Sixt
In-Reply-To: <alpine.LSU.1.00.0807302020300.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Jul 2008, Steve Haslam wrote:
>
>> I think that once git-upload-pack.c et al get the argv[0] path over to
>> setup_path() then there's nothing more to do; setup_path() already uses
>> argv0_path in its list of paths to try. I'm confused to the reference to
>> PATH, though: we're avoiding the PATH environment variable completely.
>>
>
> There is an issue in setting up the argv0_path when Git is called as "git"
> and resolved via the PATH: argv[0] then is literally "git".
>
> And we need argv0_path for other things than just calling programs:
> relative etc/gitconfig and libexecdir.
>
Ah, I see what you meant. And all setup_path() actually does is add to
the end of PATH. I should have understood before.
OK, I will split the patch up and tidy it.
SRH
^ permalink raw reply
* git citool/gui bug
From: Leandro Lucarella @ 2008-07-30 18:53 UTC (permalink / raw)
To: git
Hi! I think I've hit a really silly bug in citool/gui:
1) mkdir test; cd test
2) git init
3) vi test.txt # add content
4) cat test.txt
===============
Hello World!!!!
===============
5) git citool
6) add the test.txt file to the index
7) see test.txt index diff
git citool shows:
new file mode 100644 # black
@@ -0,0 +1,5 @@ # blue
+ # green
=============== # orange
+Hello World!!!! # green
=============== # orange
+ # green
Please Cc me, I'm not in the list.
Thank you!
--
Leandro Lucarella
Integratech S.A.
4571-5252
^ permalink raw reply
* Re: [PATCH v3] Advertise the ability to abort a commit
From: Brian Gernhardt @ 2008-07-30 19:01 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster, peff
In-Reply-To: <1217440391-13259-1-git-send-email-mail@cup.kalibalik.dk>
On Jul 30, 2008, at 1:53 PM, Anders Melchiorsen wrote:
> An empty commit message is now treated as a normal situation, not an
> error.
>
> Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
> ---
>
> So, I decided that I find it wrong to promote functionality
> that results in an error. The error is now changed into a
> normal exit (with status code 1.)
'git commit' should return with an error any time it does not commit.
Otherwise scripts could get confused, thinking everything went fine
when nothing actually got done. Here, the user decided something was
in error and canceled out, the same way using using ^C causes a non-
zero return status.
~~ Brian
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-30 19:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080730044855.GA7225@spearce.org>
* Shawn O. Pearce <spearce@spearce.org> wrote:
> > should i pack on both repos? I dont explicitly pack anything, but on
> > the server it goes into regular gc runs. (which will pack most
> > stuff, right?)
>
> git-gc automatically runs `git pack-refs --all --prune` like I
> recommended, unless you disabled it with config gc.packrefs = false.
> So its probably already packed.
>
> What does `find .git/refs -type f | wc -l` give for the repository on
> the central server? If its more than a handful (~20) I would suggest
> running git-gc before testing again.
ah, you are right, it gave 275, then git-gc brought it down to two:
earth4:~/tip> find .git/refs -type f | wc -l
275
earth4:~/tip> git gc
earth4:~/tip> find .git/refs -type f | wc -l
2
i turned off auto-gc recently (two weeks ago) because it was
auto-triggering _way_ too frequently. (like on every fifth merge i was
doing or so)
alas, fetching still seems to be slow:
titan:~/tip> time git-fetch origin
real 0m5.112s
user 0m0.972s
sys 0m3.380s
(but the gc run has not finished yet on the central repo so this isnt
fully valid.)
> But I'm really suspecting that this is just our quadratic matching
> algorithm running up against a large number of branches, causing it to
> suck.
>
> jgit at least uses an O(N) algorithm here, but since it is written in
> Java its of course slow compared to C Git. Takes a while to get that
> JVM running.
>
> I'll try to find some time to reproduce the issue and look at the
> bottleneck here. I'm two days into a new job so my git time has been
> really quite short this week. :-|
fetching the -tip repo:
http://people.redhat.com/mingo/tip.git/README
and then running 'git remote update' will i think already show this
problem for you too. People have been complaining about how slow the
update is.
Ingo
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Junio C Hamano @ 2008-07-30 19:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: H.Merijn Brand, git
In-Reply-To: <20080730140523.GC31392@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> The proper fix is to let integer be an *INT* (long integer is bogus
> anyways) and to put the date in a long using static unsigned long date,
> and make OPT_DATE use this long.
I am still puzzled by the original report of the breakage, as H. Merijn
cannot be the first person to ever ran test-parse-options on 64-bit
machine. Maybe there is a bytesex issue involved as well?
In any case, this should work.
test-parse-options.c | 8 +++++---
t/t0040-parse-options.sh | 11 ++++++++++-
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index 2a79e72..6e18083 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -2,7 +2,8 @@
#include "parse-options.h"
static int boolean = 0;
-static unsigned long integer = 0;
+static int integer = 0;
+static unsigned long timestamp;
static int abbrev = 7;
static int verbose = 0, dry_run = 0, quiet = 0;
static char *string = NULL;
@@ -32,7 +33,7 @@ int main(int argc, const char **argv)
OPT_INTEGER('i', "integer", &integer, "get a integer"),
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
- OPT_DATE('t', NULL, &integer, "get timestamp of <time>"),
+ OPT_DATE('t', NULL, ×tamp, "get timestamp of <time>"),
OPT_CALLBACK('L', "length", &integer, "str",
"get length of <str>", length_callback),
OPT_GROUP("String options"),
@@ -56,7 +57,8 @@ int main(int argc, const char **argv)
argc = parse_options(argc, argv, options, usage, 0);
printf("boolean: %d\n", boolean);
- printf("integer: %lu\n", integer);
+ printf("integer: %u\n", integer);
+ printf("timestamp: %lu\n", timestamp);
printf("string: %s\n", string ? string : "(not set)");
printf("abbrev: %d\n", abbrev);
printf("verbose: %d\n", verbose);
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 03dbe00..e38241c 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -47,6 +47,7 @@ test_expect_success 'test help' '
cat > expect << EOF
boolean: 2
integer: 1729
+timestamp: 0
string: 123
abbrev: 7
verbose: 2
@@ -63,6 +64,7 @@ test_expect_success 'short options' '
cat > expect << EOF
boolean: 2
integer: 1729
+timestamp: 0
string: 321
abbrev: 10
verbose: 2
@@ -88,6 +90,7 @@ test_expect_success 'missing required value' '
cat > expect << EOF
boolean: 1
integer: 13
+timestamp: 0
string: 123
abbrev: 7
verbose: 0
@@ -108,6 +111,7 @@ test_expect_success 'intermingled arguments' '
cat > expect << EOF
boolean: 0
integer: 2
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -135,6 +139,7 @@ test_expect_success 'ambiguously abbreviated option' '
cat > expect << EOF
boolean: 0
integer: 0
+timestamp: 0
string: 123
abbrev: 7
verbose: 0
@@ -161,6 +166,7 @@ test_expect_success 'detect possible typos' '
cat > expect <<EOF
boolean: 0
integer: 0
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -177,7 +183,8 @@ test_expect_success 'keep some options as arguments' '
cat > expect <<EOF
boolean: 0
-integer: 1
+integer: 0
+timestamp: 1
string: default
abbrev: 7
verbose: 0
@@ -197,6 +204,7 @@ cat > expect <<EOF
Callback: "four", 0
boolean: 5
integer: 4
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
@@ -223,6 +231,7 @@ test_expect_success 'OPT_CALLBACK() and callback errors work' '
cat > expect <<EOF
boolean: 1
integer: 23
+timestamp: 0
string: (not set)
abbrev: 7
verbose: 0
^ permalink raw reply related
* [PATCH] Add NO_RSYNC to allow building without rsync
From: Aidan Van Dyk @ 2008-07-30 18:52 UTC (permalink / raw)
To: git
This is similar to NO_CURL.
Signed-off-by: Aidan Van Dyk <aidan@highrise.ca>
---
I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
rsync, so making it optional was an easy fix.
Makefile | 4 ++++
transport.c | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..b0a2985 100644
--- a/Makefile
+++ b/Makefile
@@ -789,6 +789,10 @@ else
CC_LD_DYNPATH = -R
endif
+ifdef NO_RSYNC
+ BASIC_CFLAGS += -DNO_RSYNC
+endif
+
ifdef NO_CURL
BASIC_CFLAGS += -DNO_CURL
else
diff --git a/transport.c b/transport.c
index 6eb65b8..867b01f 100644
--- a/transport.c
+++ b/transport.c
@@ -142,6 +142,7 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
}
}
+#ifndef NO_RSYNC
static struct ref *get_refs_via_rsync(struct transport *transport)
{
struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
@@ -232,6 +233,7 @@ static int fetch_objs_via_rsync(struct transport *transport,
return result;
}
+#endif
static int write_one_ref(const char *name, const unsigned char *sha1,
int flags, void *data)
@@ -276,6 +278,7 @@ static int write_refs_to_temp_dir(struct strbuf *temp_dir,
return 0;
}
+#ifndef NO_RSYNC
static int rsync_transport_push(struct transport *transport,
int refspec_nr, const char **refspec, int flags)
{
@@ -345,6 +348,7 @@ static int rsync_transport_push(struct transport *transport,
return result;
}
+#endif
/* Generic functions for using commit walkers */
@@ -731,10 +735,13 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->url = url;
if (!prefixcmp(url, "rsync://")) {
+#ifdef NO_RSYNC
+ error("git was compiled without rsync support.");
+#else
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
-
+#endif
} else if (!prefixcmp(url, "http://")
|| !prefixcmp(url, "https://")
|| !prefixcmp(url, "ftp://")) {
--
1.6.0.rc1.dirty
^ permalink raw reply related
* Compile fix for SCO OPenServer
From: Aidan Van Dyk @ 2008-07-30 18:49 UTC (permalink / raw)
To: git
In-Reply-To: <20071205172125.GF12636@yugib.highrise.ca>
SCO OpenServer also hides the definitions of (at least) u_short and
friends if _XOPEN_SOURCE is defined.
---
Same patch as last time, updated for current master.
git-compat-util.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cf89cdf..42e3e0b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -39,7 +39,7 @@
/* Approximation of the length of the decimal representation of this type. */
#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
-#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX)
+#if !defined(__APPLE__) && !defined(__FreeBSD__) && !defined(__USLC__) && !defined(_M_UNIX) && !defined(__OPENSERVER__)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
--
1.6.0.rc1.dirty
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-30 19:25 UTC (permalink / raw)
To: Avery Pennarun
Cc: Eyvind Bernhardsen, Dmitry Potapov, Johannes Schindelin,
Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807301133w4bfc8288oa2d15911b2317dca@mail.gmail.com>
On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:
> On 7/30/08, Steffen Prohaska <prohaska@zib.de> wrote:
>
>> What matters is that git gives you exactly back what you
>> committed. It
>> does so with core.autocrlf=true, unless you check out with a
>> different
>> setting for autocrlf.
>
> You can tell that this statement isn't quite true because if you have
> a file with mixed LF and CRLF line endings, which I do (thanks,
> Windows!) then CRLF->LF conversion is not a reversible operation.
> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
> have a bare LF, and on such a subset of files, CRLF->LF is
> reversible).
>
> Also note that core.autocrlf=input is *definitely* not a perfectly
> reversible operation.
You are absolutely right. The files your describe are modified by git,
because they are "invalid" text files, as git defines them. For git's
autocrlf mechanism to work, a text file is only allowed to have a
*single* type of line endings. Otherwise it is broken and git tries to
help you fixing it.
> And so here's the problem: svn hands you a file. It may or may not
> have CRLFs in it, and the line endings may actually be a random mix of
> LF and CRLF, as I am actually experiencing at the moment in a
> particular repository at work. If core.autocrlf is anything other
> than "false", git will modify the file, and git-svn won't be apply the
> diff on the next revision.
This sound like a specific problem with svn, not a general problem
of git's autocrlf concept. I work with a git-only workflow and I
never see the problems you describe.
> It's conceivable that core.autocrlf=true will work if your svn
> repository is pure and svn hands you files only with CRLF endings.
> It's somewhat unlikely that most svn repositories are in that state
> (remember: it has to be perfect in *every revision* for git-svn to
> work).
>
> So anyway, I can't see how git-svn can possibly work in the general
> case if core.autocrlf is anything other than false *at git-svn fetch
> time*.
That might be the case. Note though that I cannot contribute
much to this discussion because I never use git-svn.
> And that's what I do, and it works great, modulo a bunch of
> stupid CRLFs that sneak into the repo via svn, but those can be fixed.
> Someday we'll stop using svn, and git-filter-branch can fix them all
> retroactively so that "blame" will work right.
>
> Perhaps git-svn needs to actually ignore the core.autocrlf setting?
From what you describe, I get the impression that git-svn's handling
of line endings could certainly be improved.
Steffen
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-07-30 19:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Julian Phillips, Scott Chacon, Petr Baudis, git list
In-Reply-To: <alpine.LSU.1.00.0807301514280.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Note also that Markdown cannot create TOCs automatically, AFAICT. So
> probably it would be not all that easy to convert the User Manual to that
> format.
The use of markdown may mean updates to the User Manual won't be merged
back to his book without effort and manual porting on his side, and the
side porting in the other direction has the same issue as well, but the
contents and the way materials are presented will be vastly different in
future versions anyway; not being able to side-port new material verbatim
may not be an issue. Discussion with Scott seems to suggest that the
overall philosophy of his book is "this is a different book targetted for
different audiences; its initial text happens to heavily borrow from the
existing documents but expected to become vastly improved", in other
words, fork-and-never-return.
That's one valid approach. I or you might have taken a different avenue,
but after all, it's his book, not mine, not yours, nor git list's book.
As I am not in "graphics and screencast" camp, I may probably not be able
to offer much help improving his book, and I suspect some people on this
list might feel the same way. But that's is Ok --- we are not dumping the
User Manual.
We originally hoped (well, at least I did) that Scott's effort on his book
might help us in improving the User Manual as well, but the approach seems
to make it unlikely. But that is nothing to hold against him --- he is
doing his own thing in a way he feels is the best, and that's perfectly
fine. We lost nothing, perhaps except for a chance to cooperate a bit
better and to widen the community.
> If at all, I would have preferred a format switch to Wiki syntax so that
> we can use the same source on the Git wiki as in our Documentation/
> directory.
Yeah, that's also true. I seem to recall markdown was used in ikiwiki?
^ permalink raw reply
* Re: [PATCH] 64bit issue in test-parse-options.c
From: Pierre Habouzit @ 2008-07-30 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H.Merijn Brand, git
In-Reply-To: <7vej5b5grc.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Wed, Jul 30, 2008 at 07:11:35PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > The proper fix is to let integer be an *INT* (long integer is bogus
> > anyways) and to put the date in a long using static unsigned long date,
> > and make OPT_DATE use this long.
>
> I am still puzzled by the original report of the breakage, as H. Merijn
> cannot be the first person to ever ran test-parse-options on 64-bit
> machine. Maybe there is a bytesex issue involved as well?
Yes there is: I assume HP-UX works on big endian machines, else on
machines where longs are 64 bits, we put timestamps in it which are
probably current dates, which still fit on 31 (or 32) bits, hence do not
touch the most significant 32 bits hence work on 64 bits little endian
machines (like ... x86_64).
So when we parse an integer in it again, the 32 most significant bits
remain 0 hence the test passes.
> In any case, this should work.
>
> test-parse-options.c | 8 +++++---
> t/t0040-parse-options.sh | 11 ++++++++++-
> 2 files changed, 15 insertions(+), 4 deletions(-)
Ack. I wanted to write it but hadn't the time yet, I was just pointing
to the right fix. Thanks for writing the patch :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add NO_RSYNC to allow building without rsync
From: Linus Torvalds @ 2008-07-30 19:33 UTC (permalink / raw)
To: Aidan Van Dyk; +Cc: git
In-Reply-To: <20080730185225.GG10399@yugib.highrise.ca>
On Wed, 30 Jul 2008, Aidan Van Dyk wrote:
>
> I came about this because SCO OpenServer doesnt' have mkdtemp. But I never use
> rsync, so making it optional was an easy fix.
Hmm. Without mkdtemp(), maybe you could just do a trivial compat function
somethin glike
char *git_mkdtemp(char *template)
{
char *n = mktemp(template);
if (mkdir(n))
n = NULL;
return n;
}
instead?
Linus
^ 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