* Re: kha/safe updated
From: Catalin Marinas @ 2007-12-19 23:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071219224638.GB15119@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
>
> > And here it is!
>
> And with that, I don't see any reason to not recommend that you pull
> every patch I have. Which is:
Please rebase again when you have time since I already merged most of
this branch and added some patches that might conflict with yours.
--
Catalin
^ permalink raw reply
* Re: more than 20 commands in everyday.txt
From: Jakub Narebski @ 2007-12-19 23:23 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> this might seem to be a bit bikesheding, but i hope it isn't. today i
> teched git to someone who never used any scm so far. i showed him the
> "everyday with git" document, as i think it's a great start for newbies.
> actually i read it once but it was in the past, now i did it again and i
> think there are some commands listed there which is not something we use
> "every day". of course it may be only me, that's why i ask. here are the
> commands i rarely use and are in everyday.txt:
>
> - git-prune and git-repack: usually i use git-gc only. maybe prune and
> repack could be removed from everyday.txt?
I agree that git-repack should be removed (there is git-gc), and
git-prune should be replaced by mentioning --prune option to git-gc.
This document is for newbies, and they shouldn't need to run anything
other than git-gc.
Besides with new enough git the number of generated loose objects
should be greatly reduced: git now produces (small) packs if
possible.
I'm not sure if mentioning git-fsck at all, or at least this early is
a good idea for introductory tutorial. Running git-fsck should be
rare, very rare.
> - git-show-branch: what about mentioning gitk instead? i think it's much
> more used - compared to git-show-branch
I would replace git-show-branch by git-show as command to see where
you are. and add gitk (which has now manpage) to view history.
git-show-branch output is a bit cryptic...
Perhaps we could add git-reflog / "git log -g" somewhere around?
> what do you think about this? maybe i'm wrong, but if i'm right, then i
> would provide a patch to update everyday.txt according to these
> suggestions.
I'd like this. At least the first one is unambiguous.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] builtin-tag.c: allow arguments in $EDITOR
From: Luciano Rocha @ 2007-12-19 23:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
The previous sh version of git-commit evaluated the value of the defined
editor, thus allowing arguments.
Make the builtin version work the same, by adding an explicit check for
arguments in the editor command, and extract them to an additional argument.
Signed-off-by: Luciano Rocha <luciano@eurotux.com>
---
builtin-tag.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
I personally use EDITOR="gvim -f", thus this patch.
Created on top of ce85b053d827e2f7c2ee2683cc09393e4768cc22,
git-describe is now: v1.5.4-rc0-75-g5f791e5
diff --git a/builtin-tag.c b/builtin-tag.c
index 274901a..57dcfe0 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -46,7 +46,18 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
if (!editor)
editor = "vi";
- if (strcmp(editor, ":")) {
+ if (strstr(editor, " -")) {
+ char *editor_cmd = xstrdup(editor);
+ char *editor_sep = strstr(editor_cmd, " -");
+ const char *args[] = { editor_cmd, editor_sep + 1,
+ path, NULL };
+
+ *editor_sep = '\0';
+
+ if (run_command_v_opt_cd_env(args, 0, NULL, env))
+ die("There was a problem with the editor %s.",
+ editor_cmd);
+ } else if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
if (run_command_v_opt_cd_env(args, 0, NULL, env))
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: kha/safe updated
From: David Kågedal @ 2007-12-19 23:24 UTC (permalink / raw)
To: Catalin Marinas, Karl Hasselström; +Cc: git
In-Reply-To: <20071219224638.GB15119@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
>
>> And here it is!
>
> And with that, I don't see any reason to not recommend that you pull
> every patch I have. Which is:
The conflict series of patches from me works for me, but I know that I
don't use all the merging features that other users use, so I can't
guarantee that everything works. But it seems that Catalin has been
looking over it, so I guess it's ok.
--
David Kågedal
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-19 23:23 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, git
In-Reply-To: <57518fd10712191437s6f192feds50d006fdfc624444@mail.gmail.com>
Jonathan del Strother schrieb:
> On Dec 19, 2007 6:44 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
>> Could you try
>>
>> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
>>
>> (or any other problematic commit) and post its output here?
>
> You mean git cat-file commit ... ?
> I get the normal output, but the problematic commits don't show a
> newline character at the end of the cat-file output.
Just a shot in the dark: does this patch on top of master make a difference?
diff --git a/pretty.c b/pretty.c
index 9db75b4..5f95a59 100644
--- a/pretty.c
+++ b/pretty.c
@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
if (i == eol) {
state++;
/* strip empty lines */
- while (msg[eol + 1] == '\n')
+ while (msg[eol] == '\n' && msg[eol + 1] == '\n')
eol++;
} else if (!prefixcmp(msg + i, "author ")) {
context->author.off = i + 7;
^ permalink raw reply related
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-19 23:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <b0943d9e0712191517r6154f6c2g98068c8070275cb3@mail.gmail.com>
On 2007-12-19 23:17:42 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > And with that, I don't see any reason to not recommend that you
> > pull every patch I have. Which is:
>
> Please rebase again when you have time since I already merged most
> of this branch and added some patches that might conflict with
> yours.
You hadn't pushed any of it out when I last checked about two hours
ago ...
Will do, but not tonight. In fact, it may be a few days, I'm afraid.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: kha/safe updated
From: Catalin Marinas @ 2007-12-19 23:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071219232614.GA16246@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 23:17:42 +0000, Catalin Marinas wrote:
>
> > On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > And with that, I don't see any reason to not recommend that you
> > > pull every patch I have. Which is:
> >
> > Please rebase again when you have time since I already merged most
> > of this branch and added some patches that might conflict with
> > yours.
>
> You hadn't pushed any of it out when I last checked about two hours
> ago ...
I just pushed the changes a few minutes ago.
> Will do, but not tonight. In fact, it may be a few days, I'm afraid.
No problem. Anyway, if I don't here from you in the meantime, have a
good Christmas :-).
--
Catalin
^ permalink raw reply
* Re: Git-to-svn convert
From: Martin Langhoff @ 2007-12-19 23:54 UTC (permalink / raw)
To: Thomas Harning; +Cc: Junio C Hamano, git, Andrew McMillan
In-Reply-To: <476997C1.2080506@gmail.com>
Hi Thomas,
I think Andrew McMillan had written a few scripts to "export" a git
repo to SVN and CVS. Not sure whether the code is public. But at least
for a while, the Mahara project was using git with SVN and CVS
"readonly" exported repos, a bit like the BK->CVS of yore. He may have
been using git-svn though.
cheers,
martin
^ permalink raw reply
* Re: more than 20 commands in everyday.txt
From: Junio C Hamano @ 2007-12-20 0:15 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071219225618.GA7378@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> "every day". of course it may be only me, that's why i ask. here are the
> commands i rarely use and are in everyday.txt:
>
> - git-prune and git-repack: usually i use git-gc only. maybe prune and
> repack could be removed from everyday.txt?
>
> - git-show-branch: what about mentioning gitk instead? i think it's much
> more used - compared to git-show-branch
>
> what do you think about this? maybe i'm wrong, but if i'm right, then i
> would provide a patch to update everyday.txt according to these
> suggestions.
I think you would probably get unanimous yes for the former (I don't use
gc myself but "repack -a -d" or "repack -a -d -f" regularly, though ---
I am old fashioned and do not mind being counted as an oddball).
For the latter it all depends on whether you are in windowed environment
(I usually don't).
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Junio C Hamano @ 2007-12-20 0:21 UTC (permalink / raw)
To: Charles Bailey; +Cc: Wincent Colaiuta, Jeff King, Linus Torvalds, git
In-Reply-To: <20071219143712.GA3483@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
> ...
>> Somebody beat you to it. :) Can you confirm that the fix in
>>
>> <1198007158-27576-1-git-send-email-win@wincent.com>
>>
>> works for you?
>
> Ooh, the excitement, I've never had the opportunity to "git am"
> before.
Well, if Wincent had sent the patch as plain text without MIME
quoted-printable, you did not have to even have the excitement of
running "git am", but a simple "git apply" would have sufficed.
...
How about the following? This swaps in perl in place of sed, which we c=
an
hopefully rely upon to work across platforms.
Cheers,
Wincent
-------- 8< --------
=46ix tests for broken sed on Leopard
The newly-added common-tail-optimization test fails on Leopard because
the broken sed implementation bails with a spurious "unterminated
substitute pattern" error because of the length of one of the
arguments.
Just for future reference, I do not mind avoiding "top-post" style patch
using "-- >8 --" cut markers, but do not have three or more dashes in
the cut marker. "mailinfo" will split the message at that line and the
portion intended as the proposed commit log message will be taken as
part of garbage in front of the patch. Using "-- >8 --" (two dashes,
space, scissors, ...) keeps both the front matter and the log text
together so that "am -i" or "commit --amend" can work on both parts.
By the way, how does this rewrite look?
-- >8 --
t4024: fix test script to use simpler sed pattern
The earlier test stripped away expected number of 'z' but the output
would have been very hard to read once somebody broke the common tail
optimization. Instead, count the number of 'z' and show it, to help
diagnosing the problem better in the future.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4024-diff-optimize-common.sh | 158 ++++++++++++++++++++++++++++++---------
1 files changed, 123 insertions(+), 35 deletions(-)
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..3c66102 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -10,58 +10,146 @@ z="$z$z$z$z$z$z$z$z" ;# 512
z="$z$z$z$z" ;# 2048
z2047=$(expr "$z" : '.\(.*\)') ; #2047
-test_expect_success setup '
-
- echo "a$z2047" >file-a &&
- echo "b" >file-b &&
- echo "$z2047" >>file-b &&
- echo "c$z2047" | tr -d "\012" >file-c &&
- echo "d" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d &&
+x=zzzzzzzzzz ;# 10
+y="$x$x$x$x$x$x$x$x$x$x" ;# 100
+z="$y$y$y$y$y$y$y$y$y$y" ;# 1000
+z1000=$z
+z100=$y
+z10=$x
- git add file-a file-b file-c file-d &&
+zs() {
+ count="$1"
+ while test "$count" -ge 1000
+ do
+ count=$(($count - 1000))
+ printf "%s" $z1000
+ done
+ while test "$count" -ge 100
+ do
+ count=$(($count - 100))
+ printf "%s" $z100
+ done
+ while test "$count" -ge 10
+ do
+ count=$(($count - 10))
+ printf "%s" $z10
+ done
+ while test "$count" -ge 1
+ do
+ count=$(($count - 1))
+ printf "z"
+ done
+}
- echo "A$z2047" >file-a &&
- echo "B" >file-b &&
- echo "$z2047" >>file-b &&
- echo "C$z2047" | tr -d "\012" >file-c &&
- echo "D" >file-d &&
- echo "$z2047" | tr -d "\012" >>file-d
-
-'
+zc () {
+ sed -e "/^index/d" \
+ -e "s/$z1000/Q/g" \
+ -e "s/QQQQQQQQQ/Z9000/g" \
+ -e "s/QQQQQQQQ/Z8000/g" \
+ -e "s/QQQQQQQ/Z7000/g" \
+ -e "s/QQQQQQ/Z6000/g" \
+ -e "s/QQQQQ/Z5000/g" \
+ -e "s/QQQQ/Z4000/g" \
+ -e "s/QQQ/Z3000/g" \
+ -e "s/QQ/Z2000/g" \
+ -e "s/Q/Z1000/g" \
+ -e "s/$z100/Q/g" \
+ -e "s/QQQQQQQQQ/Z900/g" \
+ -e "s/QQQQQQQQ/Z800/g" \
+ -e "s/QQQQQQQ/Z700/g" \
+ -e "s/QQQQQQ/Z600/g" \
+ -e "s/QQQQQ/Z500/g" \
+ -e "s/QQQQ/Z400/g" \
+ -e "s/QQQ/Z300/g" \
+ -e "s/QQ/Z200/g" \
+ -e "s/Q/Z100/g" \
+ -e "s/000Z//g" \
+ -e "s/$z10/Q/g" \
+ -e "s/QQQQQQQQQ/Z90/g" \
+ -e "s/QQQQQQQQ/Z80/g" \
+ -e "s/QQQQQQQ/Z70/g" \
+ -e "s/QQQQQQ/Z60/g" \
+ -e "s/QQQQQ/Z50/g" \
+ -e "s/QQQQ/Z40/g" \
+ -e "s/QQQ/Z30/g" \
+ -e "s/QQ/Z20/g" \
+ -e "s/Q/Z10/g" \
+ -e "s/00Z//g" \
+ -e "s/z/Q/g" \
+ -e "s/QQQQQQQQQ/Z9/g" \
+ -e "s/QQQQQQQQ/Z8/g" \
+ -e "s/QQQQQQQ/Z7/g" \
+ -e "s/QQQQQQ/Z6/g" \
+ -e "s/QQQQQ/Z5/g" \
+ -e "s/QQQQ/Z4/g" \
+ -e "s/QQQ/Z3/g" \
+ -e "s/QQ/Z2/g" \
+ -e "s/Q/Z1/g" \
+ -e "s/0Z//g" \
+ ;
+}
-cat >expect <<\EOF
-diff --git a/file-a b/file-a
---- a/file-a
-+++ b/file-a
+expect_pattern () {
+ cnt="$1"
+ cat <<EOF
+diff --git a/file-a$cnt b/file-a$cnt
+--- a/file-a$cnt
++++ b/file-a$cnt
@@ -1 +1 @@
--aZ
-+AZ
-diff --git a/file-b b/file-b
---- a/file-b
-+++ b/file-b
+-Z${cnt}a
++Z${cnt}A
+diff --git a/file-b$cnt b/file-b$cnt
+--- a/file-b$cnt
++++ b/file-b$cnt
@@ -1 +1 @@
-b
+B
-diff --git a/file-c b/file-c
---- a/file-c
-+++ b/file-c
+diff --git a/file-c$cnt b/file-c$cnt
+--- a/file-c$cnt
++++ b/file-c$cnt
@@ -1 +1 @@
--cZ
+-cZ$cnt
\ No newline at end of file
-+CZ
++CZ$cnt
\ No newline at end of file
-diff --git a/file-d b/file-d
---- a/file-d
-+++ b/file-d
+diff --git a/file-d$cnt b/file-d$cnt
+--- a/file-d$cnt
++++ b/file-d$cnt
@@ -1 +1 @@
-d
+D
EOF
+}
+
+sample='1023 1024 1025 2047 4095'
+
+test_expect_success setup '
+
+ for n in $sample
+ do
+ ( zs $n ; echo a ) >file-a$n &&
+ ( echo b; zs $n; echo ) >file-b$n &&
+ ( printf c; zs $n ) >file-c$n &&
+ ( echo d; zs $n ) >file-d$n &&
+
+ git add file-a$n file-b$n file-c$n file-d$n &&
+
+ ( zs $n ; echo A ) >file-a$n &&
+ ( echo B; zs $n; echo ) >file-b$n &&
+ ( printf C; zs $n ) >file-c$n &&
+ ( echo D; zs $n ) >file-d$n &&
+
+ expect_pattern $n || break
+
+ done >expect
+'
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ for n in $sample
+ do
+ git diff -U0 file-?$n
+ done | zc >actual &&
diff -u expect actual
'
^ permalink raw reply related
* git rebase -i / git-gui bug
From: Bernt Hansen @ 2007-12-20 0:35 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Schindelin, Junio C Hamano; +Cc: git
Thanks for a great tool I use everyday!
I'm using the tip of master for my regular day job with git-gui to write
the commit messages. I've run into a little glitch with git rebase -i
and git-gui.
$ git --version
git version 1.5.4.rc0.73.gce85b
I haven't been able to automate the process of reproducing this but the
steps are fairly simple.
To show the problem you can create a test repository using the following
script:
--- t1.sh ---
#!/bin/sh
cd /tmp
mkdir t1
cd t1
git init
for F in f1 f2 f3 f4 f5 f6 f7 f8 f9 f10; do
echo $F >$F
git add $F
echo -n -e "Commit for $F\n\nThis is line one\nThis is line two" >/tmp/commitmsg.txt
git commit -F /tmp/commitmsg.txt
done
-------------
Now cd /tmp/t1 and do the following:
$ git rebase -i HEAD~9
Change all lines with 'pick' to 'edit'
For each of the 10 commits use git-gui to select 'Amend Last Commit' and
just hit the [Commit] button (you can change the text if you want but
it's not necessary to show the problem)
$ git rebase --continue
after each commit and repeat until the rebase is complete.
Now if you try to squash these commits the edit buffer commit text is a
little mangled.
$ git rebase -i HEAD~9
Change all but the first pick line to 'squash' and I get the following
text in the commit message edit window:
----[ /tmp/t1/.git/COMMIT_EDITMSG ]----
# This is a combination of 3 commits.
# The first commit's message is:
Commit for f2
This is line one
This is line two
# This is the 2nd commit message:
Commit for f3
This is line one
This is line two# This is the 3rd commit message:
Commit for f4
This is line one
This is line two# This is the 3rd commit message:
Commit for f5
This is line one
This is line two# This is the 3rd commit message:
Commit for f6
This is line one
This is line two# This is the 3rd commit message:
Commit for f7
This is line one
This is line two# This is the 3rd commit message:
Commit for f8
This is line one
This is line two# This is the 3rd commit message:
Commit for f9
This is line one
This is line two# This is the 3rd commit message:
Commit for f10
This is line one
This is line two
# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: f10
# new file: f2
# new file: f3
# new file: f4
# new file: f5
# new file: f6
# new file: f7
# new file: f8
# new file: f9
#
---------------------------------------
Notice after the 3rd commit the '# This is the 3rd commit message:' is
appended to the last line of the previous commit message and the counter
seems to be stuck on 3.
---
When I run into this during work I fix up the commit text by adding
newlines before the '# This is the 3rd commit message' and it works
fine.
This might be the lack of a newline after the last line in the commit
edit message when git-gui creates the commit -- maybe.
If I use git --amend instead of git-gui to update the commits on the
above test repository it works correctly.
I'm posting this because someone else can probably fix this faster than
me (I've never looked at the git source code). I'll post a patch when I
figure it out if nobody else beats me to it.
Regards,
Bernt
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Junio C Hamano @ 2007-12-20 1:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0712191334460.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/cache.h b/cache.h
> index 39331c2..83a2c31 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -225,6 +225,7 @@ extern char *get_index_file(void);
> extern char *get_graft_file(void);
> extern int set_git_dir(const char *path);
> extern const char *get_git_work_tree(void);
> +extern const char *get_current_prefix(void);
>
> #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
>
> diff --git a/setup.c b/setup.c
> index b59dbe7..fb9b680 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -3,6 +3,12 @@
>
> static int inside_git_dir = -1;
> static int inside_work_tree = -1;
> +static const char *current_prefix;
> +
> +const char *get_current_prefix()
> +{
> + return current_prefix;
> +}
Didn't you just make libification harder?
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Wincent Colaiuta @ 2007-12-20 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, Jeff King, Linus Torvalds, git
In-Reply-To: <7vy7bqrzat.fsf@gitster.siamese.dyndns.org>
El 20/12/2007, a las 1:21, Junio C Hamano escribió:
> Charles Bailey <charles@hashpling.org> writes:
>
>> On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
>> ...
>>> Somebody beat you to it. :) Can you confirm that the fix in
>>>
>>> <1198007158-27576-1-git-send-email-win@wincent.com>
>>>
>>> works for you?
>>
>> Ooh, the excitement, I've never had the opportunity to "git am"
>> before.
>
> Well, if Wincent had sent the patch as plain text without MIME
> quoted-printable, you did not have to even have the excitement of
> running "git am", but a simple "git apply" would have sufficed.
Well, I sent it using "git send-email", so I guess it didn't have MIME
quoted-printable.
Cheers,
Wincent
^ permalink raw reply
* Draft release notes for 1.5.4 as of -rc1
From: Junio C Hamano @ 2007-12-20 2:58 UTC (permalink / raw)
To: git
This one is as of v1.5.4-rc1 which I tagged tonight. It hints that a
set of big change is coming in 1.6.0 without saying if there will be
1.5.5 before that, nor committing to the schedule for 1.6.0 firmly.
Much of the text is unchanged since -rc0 as recent changes to 'master'
have mostly been fixes to regression introduced since 1.5.3. We did not
describe that we introduced regression on purpose, so it is confusing if
we described the regression fixes.
GIT v1.5.4 Release Notes
========================
Removal
-------
* "git svnimport" was removed in favor of "git svn". It is still there
in the source tree (contrib/examples) but unsupported.
* As git-commit and git-status have been rewritten, "git runstatus"
helper script lost all its users and has been removed.
Deprecation notices
-------------------
* Next feature release of git (this change is scheduled for v1.6.0)
will by default install dashed form of commands (e.g. "git-commit")
outside of users' normal $PATH, and will install only selected
commands ("git" itself, and "gitk") in $PATH. This implies:
- Using dashed form of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dashless form (e.g. "git commit") instead.
- Using dashed from from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed form with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this.
* The post-receive hook was introduced in March 2007 to supersede
post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
* "git lost-found" was deprecated in favor of "git fsck"'s --lost-found
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
and works for all transports, and will be removed in the future.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
to true, which will give denser packfile (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
* From v1.6.0, the pack.indexversion config option will default to 2,
which is slightly more efficient, and makes repacking more immune to
data corruptions. Git older than version 1.5.2 may revert to version 1
of the pack index with a manual "git index-pack" to be able to directly
access corresponding pack files.
Updates since v1.5.3
--------------------
* Comes with much improved gitk.
* Comes with "git gui" 0.9.1 with i18n.
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
* progress display from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
so lazily, which makes the usual case go much faster.
* Output processing for '--pretty=format:<user format>' has been
optimized.
* Rename detection of diff family, while detecting exact matches, has
been greatly optimized.
* Rename detection of diff family tries to make more naturally looking
pairing. Earlier if more than one identical rename sources were
found in the preimage, they were picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
This has been corrected to mean the same thing as "auto".
* "git diff" Porcelain now respects diff.external configuration, which
is another way to specify GIT_EXTERNAL_DIFF.
* HTTP proxy can be specified per remote repository using
remote.*.httpproxy configuration, or global http.proxy configuration
variable.
* Various Perforce importer updates.
* Example update and post-receive hooks have been improved.
* Any command that wants to take a commit object name can now use
":/string" syntax to name a commit.
* "git reset" is now built-in and its output can be squelched with -q.
* "git send-email" can optionally talk over ssmtp and use SMTP-AUTH.
* "git rebase" learned --whitespace option.
* In "git rebase", when you decide not to replay a particular change
after the command stopped with a conflict, you can say "git rebase
--skip" without first running "git reset --hard", as the command now
runs it for you.
* "git rebase --interactive" mode can now work on detached HEAD.
* Other minor to serious bugs in "git rebase -i" has been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
the current branch points at the commit before the rebase was
started.
* "git rebase -i" also triggers rerere to help your repeated merges.
* "git merge" can call the "post-merge" hook.
* "git pack-objects" can optionally run deltification with multiple
threads.
* "git archive" can optionally substitute keywords in files marked with
export-subst attribute.
* "git cherry-pick" made a misguided attempt to repeat the original
command line in the generated log message, when told to cherry-pick a
commit by naming a tag that points at it. It does not anymore.
* "git for-each-ref" learned %(xxxdate:<dateformat>) syntax to show the
various date fields in different formats.
* "git gc --auto" is a low-impact way to automatically run a variant of
"git repack" that does not lose unreferenced objects (read: safer
than the usual one) after the user accumulates too many loose
objects.
* "git clean" has been rewritten in C.
* You need to explicitly set clean.requireForce to "false" to allow
"git clean" without -f to do any damage (lack of the configuration
variable used to mean "do not require -f option to lose untracked
files", but we now use the safer default).
* The kinds of whitespace errors "git diff" and "git apply" notice (and
fix) can be controlled via 'core.whitespace' configuration variable
and 'whitespace' attribute in .gitattributes file.
* "git push" learned --dry-run option to show what would happen if a
push is run.
* "git push" does not update a tracking ref on the local side when the
remote refused to update the corresponding ref.
* "git push" learned --mirror option. This is to push the local refs
one-to-one to the remote, and deletes refs from the remote that do
not exist anymore in the repository on the pushing side.
* "git push" can remove a corrupt ref at the remote site with the usual
":ref" refspec.
* "git remote" knows --mirror mode. This is to set up configuration to
push into a remote repository to store local branch heads to the same
branch on the remote side, and remove branch heads locally removed
from local repository at the same time. Suitable for pushing into a
back-up repository.
* "git remote" learned "rm" subcommand.
* "git cvsserver" can be run via "git shell".
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
* "git am" and "git rebase" are far less verbose.
* "git pull" learned to pass --[no-]ff option to underlying "git
merge".
* "git pull --rebase" is a different way to integrate what you fetched
into your current branch.
* "git fast-export" produces datastream that can be fed to fast-import
to reproduce the history recorded in a git repository.
* "git add -i" takes pathspecs to limit the set of files to work on.
* "git add -p" is a short-hand to go directly to the selective patch
subcommand in the interactive command loop and to exit when done.
* "git add -i" UI has been colorized.
* "git commit --allow-empty" allows you to create a single-parent
commit that records the same tree as its parent, overriding the usual
safety valve.
* "git commit --amend" can amend a merge that does not change the tree
from its first parent.
* "git commit" has been rewritten in C.
* "git stash random-text" does not create a new stash anymore. It was
a UI mistake. Use "git stash save random-text", or "git stash"
(without extra args) for that.
* "git prune --expire <time>" can exempt young loose objects from
getting pruned.
* "git branch --contains <commit>" can list branches that are
descendants of a given commit.
* "git log" learned --early-output option to help interactive GUI
implementations.
* "git bisect" learned "skip" action to mark untestable commits.
* "git bisect visualize" learned a shorter synonym "git bisect view".
* "git bisect visualize" runs "git log" in a non-windowed
environments. It also can be told what command to run (e.g. "git
bisect visualize tig").
* "git format-patch" learned "format.numbered" configuration variable
to automatically turn --numbered option on when more than one commits
are formatted.
* "git ls-files" learned "--exclude-standard" to use the canned set of
exclude files.
* "git tag -a -f existing" begins the editor session using the existing
annotation message.
* "git tag -m one -m bar" (multiple -m options) behaves similarly to
"git commit"; the parameters to -m options are formatted as separate
paragraphs.
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
reasonable usability fix and people's script shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsexportcommit" learned -w option to specify and switch to the
CVS working directory.
* "git checkout" from a subdirectory learned to use "../path" to allow
checking out a path outside the current directory without cd'ing up.
* "git checkout" from and to detached HEAD leaves a bit more
information in the reflog.
* "git send-email --dry-run" shows full headers for easier diagnosis.
* "git merge-ours" is now built-in.
* "git svn" learned "info" and "show-externals" subcommands.
* "git svn" run from a subdirectory failed to read settings from the
.git/config.
* "git svn" learned --use-log-author option, which picks up more
descriptive name from From: and Signed-off-by: lines in the commit
message.
* "git svn" wasted way too much disk to record revision mappings
between svn and git; a new representation that is much more compact
for this information has been introduced to correct this.
* "git svn" left temporary index files it used without cleaning them
up; this was corrected.
* "git status" from a subdirectory now shows relative paths, which
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behaviour to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
configuration variable to true.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
* "git shortlog" learned to default to HEAD when the standard input is
a terminal and the user did not give any revision parameter.
* "git shortlog" learned "-e" option to show e-mail addresses as well as
authors' names.
* "git help" learned "-w" option to show documentation in browsers.
* In addition there are quite a few internal clean-ups. Notably
- many fork/exec have been replaced with run-command API,
brought from the msysgit effort.
- introduction and more use of the option parser API.
- enhancement and more use of the strbuf API.
Fixes since v1.5.3
------------------
All of the fixes in v1.5.3 maintenance series are included in
this release, unless otherwise noted.
These fixes are only in v1.5.4 and not backported to v1.5.3 maintenance
series.
* The way "git diff --check" behaves is much more consistent with the way
"git apply --whitespace=warn" works.
* "git svn" talking with the SVN over http will correctly quote branch
and project names.
* "git config" did not work correctly on platforms that define
REG_NOMATCH to an even number.
^ permalink raw reply
* Re: Draft release notes for 1.5.4 as of -rc1
From: Georgi Chorbadzhiyski @ 2007-12-20 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
On 12/20/07 04:58, Junio C Hamano wrote:
> * "git peek-remote" is deprecated, as "git ls-remote" was written in C
> and works for all transports, and will be removed in the future.
For me it is not clear from the above which command will be removed. If
I understand it correctly probably this should sound better:
* "git peek-remote" is deprecated and will be removed in the future.
The command was replaced by "git ls-remote" which works for all
transports.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ permalink raw reply
* [PATCH] fix git commit --amend -m "new message"
From: Junio C Hamano @ 2007-12-20 3:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
The prepare_log_message() function serves two purposes:
- Prepares the commit log message template, to be given to the end
user;
- Return true if there is something committable;
7168624c3530d8c7ee32f930f8fb2ba302b9801f (Do not generate full commit
log message if it is not going to be used) cheated to omit the former
when we know the log message template is not going to be used. However,
its replacement logic to see if there is something committable was
botched. When amending, it should compare the index with the parent of
the HEAD, not the current HEAD. Otherwise you cannot run --amend to
fix only the message without changing the tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I think the other cheat to return !!active_nr is checking if it is
the initial commit, and its test that appear in the context of this
patch should be replaced with "if (initial_commit)", but I wanted to
first fix the bug.
builtin-commit.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..96410de 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -375,6 +375,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (no_edit) {
struct rev_info rev;
unsigned char sha1[40];
+ const char *parent = "HEAD";
fclose(fp);
@@ -384,9 +385,12 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (get_sha1("HEAD", sha1) != 0)
return !!active_nr;
+ if (amend)
+ parent = "HEAD^1";
+
init_revisions(&rev, "");
rev.abbrev = 0;
- setup_revisions(0, NULL, &rev, "HEAD");
+ setup_revisions(0, NULL, &rev, parent);
DIFF_OPT_SET(&rev.diffopt, QUIET);
DIFF_OPT_SET(&rev.diffopt, EXIT_WITH_STATUS);
run_diff_index(&rev, 1 /* cached */);
^ permalink raw reply related
* git commit does not show all added files in subdirectories
From: Dan McGee @ 2007-12-20 3:47 UTC (permalink / raw)
To: git
The output below should help explain this bug better than words can.
This is with version 1.5.4.rc0.
Note that all files were added with git add before the below output begins.
dmcgee@dublin ~/projects/abs
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: abs
# new file: etc/abs/abs.conf
# new file: etc/abs/supfile.community
# new file: etc/abs/supfile.core
# new file: etc/abs/supfile.extra
# new file: etc/abs/supfile.testing
# new file: etc/abs/supfile.unstable
#
dmcgee@dublin ~/projects/abs
$ git commit -s
Created initial commit 5f5f8d3: Initial creation of abs git repository
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100755 abs
create mode 040000 etc
I assume that all files should be listed by git commit, but they are
not. I'm willing to look into fixing this if someone could point me in
the right direction.
-Dan
^ permalink raw reply
* Re: git commit does not show all added files in subdirectories
From: Junio C Hamano @ 2007-12-20 3:54 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <449c10960712191947y3125f782t6ce7ec7b25ded30f@mail.gmail.com>
Should be fixed already by 3eb2a15eb385749fbfe59b4e37fc754416275760
(builtin-commit: make summary output consistent with status).
^ permalink raw reply
* Re: git commit does not show all added files in subdirectories
From: Dan McGee @ 2007-12-20 4:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4peerpgi.fsf@gitster.siamese.dyndns.org>
On Dec 19, 2007 9:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Should be fixed already by 3eb2a15eb385749fbfe59b4e37fc754416275760
> (builtin-commit: make summary output consistent with status).
Darn, I looked through the log but must have looked right over that.
Thanks for the quick response.
-Dan
^ permalink raw reply
* Re: git rebase -i / git-gui bug
From: Bernt Hansen @ 2007-12-20 4:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87ve6ub3u7.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@alumni.uwaterloo.ca> writes:
> Now cd /tmp/t1 and do the following:
>
> $ git rebase -i HEAD~9
>
> Change all lines with 'pick' to 'edit'
>
> For each of the 10 commits use git-gui to select 'Amend Last Commit' and
> just hit the [Commit] button (you can change the text if you want but
> it's not necessary to show the problem)
>
> $ git rebase --continue
> after each commit and repeat until the rebase is complete.
>
I can't do this at all with
$ git --version
git version 1.5.4.rc1
If I
$ git rebase -i HEAD~9
and use git-gui to edit the commit then git-rebase --continue fails
$ git rebase --continue
Could not commit staged changes.
-Bernt
^ permalink raw reply
* Re: Git-to-svn convert
From: Andrew McMillan @ 2007-12-20 5:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Thomas Harning, Junio C Hamano, git
In-Reply-To: <46a038f90712191554t2c1adc79s7948c7002c145143@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
My code is an embarrasingly ugly, gruesome hack, but it (sort of)
works...
I use it to keep the SVN and CVS trees up to date on Sourceforge for
DAViCal ( http://rscds.sf.net/ ) from the Git tree.
Cheers,
Andrew.
On Thu, 2007-12-20 at 12:54 +1300, Martin Langhoff wrote:
> Hi Thomas,
>
> I think Andrew McMillan had written a few scripts to "export" a git
> repo to SVN and CVS. Not sure whether the code is public. But at least
> for a while, the Mahara project was using git with SVN and CVS
> "readonly" exported repos, a bit like the BK->CVS of yore. He may have
> been using git-svn though.
>
> cheers,
>
>
> martin
>
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Is this really happening?
-------------------------------------------------------------------------
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-20 6:38 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, git
In-Reply-To: <87r6hijmjo.fsf@lysator.liu.se>
On 2007-12-20 00:24:11 +0100, David Kågedal wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > And with that, I don't see any reason to not recommend that you
> > pull every patch I have. Which is:
>
> The conflict series of patches from me works for me, but I know that
> I don't use all the merging features that other users use, so I
> can't guarantee that everything works. But it seems that Catalin has
> been looking over it, so I guess it's ok.
I've been running it for quite some time too. And the criteria for
getting into kha/stable aren't _that_ onerous: I don't guarantee that
there are no bugs, just that the patches seem to be ready for
widespread testing.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-20 6:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <b0943d9e0712191529u5e54eca4rd0ab4ecd73217a7e@mail.gmail.com>
On 2007-12-19 23:29:13 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > You hadn't pushed any of it out when I last checked about two
> > hours ago ...
>
> I just pushed the changes a few minutes ago.
So I guessed. :-)
> > Will do, but not tonight. In fact, it may be a few days, I'm
> > afraid.
>
> No problem. Anyway, if I don't here from you in the meantime, have a
> good Christmas :-).
You too! (Or anything else you may prefer to celebrate this time of
year.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git svn dcommit -n rebuilds revmap w/ 1.5.4.rc0.1187.gc1e8d
From: Eric Wong @ 2007-12-20 6:55 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <784879.48443.qm@web55007.mail.re4.yahoo.com>
Bill Priest <priestwilliaml@yahoo.com> wrote:
> All,
> I had been experiencing commit slow downs (> 15
> seconds) so I decided to test it out on 1.5.4.rc0. I
> use committed a file and it too ~5 seconds which is
> slower than it used to be but much better (I'll need
> to do an apples to apples test to quantify it better;
> e.g. check in the same file w/ a repository in the
> same state). In the course of using 1.5.4.rc0 I did a
> git svn dcommit -n and observed the following:
Are these slowdowns for commits using git-commit? or for using git-svn
dcommit?
The new rev_map format is very space-efficient, but I haven't optimized
for performance, yet. It seems to do well enough on Linux that I
don't notice any performance penalty/improvement. I'm also network
I/O bound for real-world SVN usage, too.
I haven't benchmarked .rev_map much, but the binary search could
certainly be optimized to avoid extra seeks if needed.
> > git svn dcommit -n
> Rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> ...
> r2918 = 992aa04a75fffdbdb65bae815905f96d5e3ef6bd
> r2920 = e68e7f5aead05fc9e7a151e95f43b8283b0ed670
> Done rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git svn dcommit -n
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git --version
> git version 1.5.4.rc0.1187.gc1e8d
>
> Notice the Rebuilding doesn't seem to be honoring the
> -n "dry run" switch.
>
> I'm not sure of the implications. Is this something
> that I should worry about the .revmap being out of
> sync w/ what has actually been dcommit'ed?
--dry-run only means that it won't write to the SVN repository.
There's no need to worry about stuff that's out of sync, .rev_map only
stores information about commits already made to SVN, and is more of an
internal cache for most repositories.
All .rev_map and .rev_db files it replaces are safely deletable
unless you're using noMetadata or useSvmProps with git-svn.
--
Eric Wong
^ permalink raw reply
* [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Shawn O. Pearce @ 2007-12-20 7:12 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Bernt Hansen; +Cc: git
In-Reply-To: <87r6hias5s.fsf@gollum.intra.norang.ca>
During git-rebase --interactive's --continue implementation we used
to silently restart the rebase if the user had made the commit
for us. This is common if the user stops to edit a commit and
does so by amending it. My recent change to watch git-commit's
exit status broke this behavior.
Thanks to Bernt Hansen for catching it in 1.5.4-rc1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 47581ce..39f32b1 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -372,8 +372,9 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
- git commit --no-verify -F "$DOTEST"/message -e ||
+ if ! git commit --no-verify -F "$DOTEST"/message -e
die "Could not commit staged changes."
+ fi
require_clean_work_tree
do_rest
--
1.5.4.rc1.1090.gab2276
^ permalink raw reply related
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