* What's in git.git (stable frozen)
@ 2008-01-17 3:01 Junio C Hamano
2008-01-17 12:56 ` Johannes Sixt
` (3 more replies)
0 siblings, 4 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-17 3:01 UTC (permalink / raw)
To: git
There are a good deal of bugfixes in 'master', the largest of
which is Brandon Casey's fix to builtin-commit and others'
misuse of lockfile API. A tentative fix for the issue was
pushed out last night but the approach has known issues for our
Windowsy friends, and this attempts to address them.
We've been taking pride that the tip of 'master' is always,
without regression, more stable than any released version, but
today's one might have uncovered glitches. Please help testing
it so that we do not have to leave it broken for a long time if
it indeed is.
I spent quite a lot of time trying to come up with a simple
reproduction recipe for the builtin-commit breakage, but I
couldn't. I also wanted to apply the patch to remove the use
(but not implementation) of repo-config along with a removal
notice in the release notes but haven't got around to.
Aside from obviously correct trivial fixes that may come from
the list, what currently is not in 'master' but should be in the
rc4 are very minimal. Brandon Casey's lockfile fix needs to be
tested for some time, repo-config deprecation notice needs to be
posted, and "\C-+" patch for gitk needs to be pulled from Paul.
I see French translation for git-gui in Shawn's repository, but
I do not know if it, along with other changes to git-gui, are
meant for 1.5.4 or not. If they are, I'd like to include them
all before tagging rc4.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Bill Lear (1):
Correct spelling in diff.c comment
Brandon Casey (3):
close_lock_file(): new function in the lockfile API
Improve use of lockfile API
refs.c: rework ref_locks by abstracting from underlying struct lock_file
Dan McGee (2):
Remove usage of git- (dash) commands from email hook
cvsimport: remove last use of repo-config from git standard tools
Dave Peticolas (1):
Documentation: fix and clarify grammar in git-merge docs.
Dmitry Potapov (1):
treat any file with NUL as binary
Jean-Luc Herren (1):
Make default pre-commit hook less noisy
Junio C Hamano (4):
Revert "builtin-commit.c: remove useless check added by faulty cut and
paste"
Fix git-rerere documentation
Squelch bogus progress output from git-rebase--interactive
Document lockfile API
Kristian Høgsberg (1):
git-commit: fix double close(2) that can close a wrong file descriptor
Linus Torvalds (3):
Make builtin-commit.c more careful about parenthood
Make 'git fsck' complain about non-commit branches
Be more careful about updating refs
Mark Drago (1):
hg-to-git: improve popen calls
Miklos Vajna (2):
Add using merge subtree How-To
ls-remote: add -t and -h options.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-17 3:01 What's in git.git (stable frozen) Junio C Hamano
@ 2008-01-17 12:56 ` Johannes Sixt
2008-01-17 16:58 ` [PATCH] fast-import.c: don't try to commit marks file if write failed Brandon Casey
` (2 subsequent siblings)
3 siblings, 0 replies; 32+ messages in thread
From: Johannes Sixt @ 2008-01-17 12:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano schrieb:
> There are a good deal of bugfixes in 'master', the largest of
> which is Brandon Casey's fix to builtin-commit and others'
> misuse of lockfile API. A tentative fix for the issue was
> pushed out last night but the approach has known issues for our
> Windowsy friends, and this attempts to address them.
>
> We've been taking pride that the tip of 'master' is always,
> without regression, more stable than any released version, but
> today's one might have uncovered glitches. Please help testing
> it so that we do not have to leave it broken for a long time if
> it indeed is.
Except for the NO_MMAP issue introduced by c3b0dec509f that kills
git-fast-import in t9301* as discussed in a parallel thread, all tests
pass on Windows (MinGW port). This is a good sign since most, if not all,
issues around the lockfile API have been discovered by the test suite in
the past.
-- Hannes
^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] fast-import.c: don't try to commit marks file if write failed
2008-01-17 3:01 What's in git.git (stable frozen) Junio C Hamano
2008-01-17 12:56 ` Johannes Sixt
@ 2008-01-17 16:58 ` Brandon Casey
2008-01-17 17:57 ` Junio C Hamano
2008-01-17 17:17 ` What's in git.git (stable frozen) Brandon Casey
2008-01-18 3:01 ` Shawn O. Pearce
3 siblings, 1 reply; 32+ messages in thread
From: Brandon Casey @ 2008-01-17 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
We also move the assignment of -1 to the lock file descriptor
up, so that rollback_lock_file() can be called safely after a
possible attempt to fclose(). This matches the contents of
the 'if' statement just above testing success of fdopen().
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Since we forget the lock file descriptor there is a chance
that we will leave the file open if a write error occurs. We'll
still delete the file. I don't think it's worth bending
over backwards to make sure the file is closed on this failure.
-brandon
fast-import.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 3609c24..4cf5092 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1545,19 +1545,27 @@ static void dump_marks(void)
return;
}
- dump_marks_helper(f, 0, marks);
- if (ferror(f) || fclose(f))
- failure |= error("Unable to write marks file %s: %s",
- mark_file, strerror(errno));
/*
- * Since the lock file was fdopen()'ed and then fclose()'ed above,
- * assign -1 to the lock file descriptor so that commit_lock_file()
+ * Since the lock file was fdopen()'ed, it should not be close()'ed.
+ * Assign -1 to the lock file descriptor so that commit_lock_file()
* won't try to close() it.
*/
mark_lock.fd = -1;
- if (commit_lock_file(&mark_lock))
- failure |= error("Unable to write commit file %s: %s",
+
+ dump_marks_helper(f, 0, marks);
+ if (ferror(f) || fclose(f)) {
+ rollback_lock_file(&mark_lock);
+ failure |= error("Unable to write marks file %s: %s",
mark_file, strerror(errno));
+ return;
+ }
+
+ if (commit_lock_file(&mark_lock)) {
+ rollback_lock_file(&mark_lock);
+ failure |= error("Unable to commit marks file %s: %s",
+ mark_file, strerror(errno));
+ return;
+ }
}
static int read_next_command(void)
--
1.5.4.rc3.17.gb63a4
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-17 3:01 What's in git.git (stable frozen) Junio C Hamano
2008-01-17 12:56 ` Johannes Sixt
2008-01-17 16:58 ` [PATCH] fast-import.c: don't try to commit marks file if write failed Brandon Casey
@ 2008-01-17 17:17 ` Brandon Casey
2008-01-17 17:57 ` Junio C Hamano
2008-01-18 3:01 ` Shawn O. Pearce
3 siblings, 1 reply; 32+ messages in thread
From: Brandon Casey @ 2008-01-17 17:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In lockfile.c:commit_locked_index()
You didn't include the portion of your patch that
assigned NULL to alternate_index_output before
attempting to close and rename.
Should that be included?
-brandon
Junio C Hamano wrote:
@@ -185,9 +198,15 @@ void set_alternate_index_output(const char *name)
int commit_locked_index(struct lock_file *lk)
{
if (alternate_index_output) {
- int result = rename(lk->filename, alternate_index_output);
- lk->filename[0] = 0;
- return result;
+ const char *newname = alternate_index_output;
+ alternate_index_output = NULL;
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-17 17:17 ` What's in git.git (stable frozen) Brandon Casey
@ 2008-01-17 17:57 ` Junio C Hamano
0 siblings, 0 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-17 17:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
Brandon Casey <casey@nrlssc.navy.mil> writes:
> In lockfile.c:commit_locked_index()
>
> You didn't include the portion of your patch that
> assigned NULL to alternate_index_output before
> attempting to close and rename.
>
> Should that be included?
You are right, but that is a separate topic and should be a
separate patch, so I dropped the hunk from that commit.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] fast-import.c: don't try to commit marks file if write failed
2008-01-17 16:58 ` [PATCH] fast-import.c: don't try to commit marks file if write failed Brandon Casey
@ 2008-01-17 17:57 ` Junio C Hamano
2008-01-18 2:09 ` Shawn O. Pearce
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-17 17:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List, Brandon Casey
Brandon Casey <casey@nrlssc.navy.mil> writes:
> We also move the assignment of -1 to the lock file descriptor
> up, so that rollback_lock_file() can be called safely after a
> possible attempt to fclose(). This matches the contents of
> the 'if' statement just above testing success of fdopen().
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
Shawn, could you lend an extra set of eyeballs on this one
please? It looks sane to me but obviously you are more familiar
with the code.
> Since we forget the lock file descriptor there is a chance
> that we will leave the file open if a write error occurs. We'll
> still delete the file. I don't think it's worth bending
> over backwards to make sure the file is closed on this failure.
>
> -brandon
>
>
> fast-import.c | 24 ++++++++++++++++--------
> 1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index 3609c24..4cf5092 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1545,19 +1545,27 @@ static void dump_marks(void)
> return;
> }
>
> - dump_marks_helper(f, 0, marks);
> - if (ferror(f) || fclose(f))
> - failure |= error("Unable to write marks file %s: %s",
> - mark_file, strerror(errno));
> /*
> - * Since the lock file was fdopen()'ed and then fclose()'ed above,
> - * assign -1 to the lock file descriptor so that commit_lock_file()
> + * Since the lock file was fdopen()'ed, it should not be close()'ed.
> + * Assign -1 to the lock file descriptor so that commit_lock_file()
> * won't try to close() it.
> */
> mark_lock.fd = -1;
> - if (commit_lock_file(&mark_lock))
> - failure |= error("Unable to write commit file %s: %s",
> +
> + dump_marks_helper(f, 0, marks);
> + if (ferror(f) || fclose(f)) {
> + rollback_lock_file(&mark_lock);
> + failure |= error("Unable to write marks file %s: %s",
> mark_file, strerror(errno));
> + return;
> + }
> +
> + if (commit_lock_file(&mark_lock)) {
> + rollback_lock_file(&mark_lock);
> + failure |= error("Unable to commit marks file %s: %s",
> + mark_file, strerror(errno));
> + return;
> + }
> }
>
> static int read_next_command(void)
> --
> 1.5.4.rc3.17.gb63a4
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] fast-import.c: don't try to commit marks file if write failed
2008-01-17 17:57 ` Junio C Hamano
@ 2008-01-18 2:09 ` Shawn O. Pearce
0 siblings, 0 replies; 32+ messages in thread
From: Shawn O. Pearce @ 2008-01-18 2:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Brandon Casey
Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
> > We also move the assignment of -1 to the lock file descriptor
> > up, so that rollback_lock_file() can be called safely after a
> > possible attempt to fclose(). This matches the contents of
> > the 'if' statement just above testing success of fdopen().
> >
> > Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> > ---
>
> Shawn, could you lend an extra set of eyeballs on this one
> please? It looks sane to me but obviously you are more familiar
> with the code.
I agree.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-17 3:01 What's in git.git (stable frozen) Junio C Hamano
` (2 preceding siblings ...)
2008-01-17 17:17 ` What's in git.git (stable frozen) Brandon Casey
@ 2008-01-18 3:01 ` Shawn O. Pearce
3 siblings, 0 replies; 32+ messages in thread
From: Shawn O. Pearce @ 2008-01-18 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano <gitster@pobox.com> wrote:
> I see French translation for git-gui in Shawn's repository, but
> I do not know if it, along with other changes to git-gui, are
> meant for 1.5.4 or not. If they are, I'd like to include them
> all before tagging rc4.
I have a few changes queued for 0.9.2, which I'd like to get done
and included before 1.5.4, plus I'd like to get Mark Levedahl's
DESTDIR issue resolved before then too.
.... changes since 0.9.1 ....
Christian Couder (2):
git-gui: Initial french translation
git-gui: add french glossary: glossary/fr.po
Christian Stimming (4):
git-gui: Update glossary: add term "hunk"
git-gui: Update German translation
git-gui: Fix broken revert confirmation.
git-gui: Improve German translation.
Peter Karlsson (1):
git-gui: Updated Swedish translation after mailing list review.
Shawn O. Pearce (2):
git-gui: Allow 'Create New Repository' on existing directories
git-gui: Refresh file status description after hunk application
--
Shawn.
^ permalink raw reply [flat|nested] 32+ messages in thread
* What's in git.git (stable frozen)
@ 2008-01-30 8:32 Junio C Hamano
0 siblings, 0 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-30 8:32 UTC (permalink / raw)
To: git
There shouldn't be anything eye-popping. Hopefully we can do
the final soonish, perhaps this weekend.
I may have made small touch-ups to a few commits, so please
check them over.
Thanks.
* The 'master' branch has these since v1.5.4-rc5
Brandon Casey (1):
git-relink: avoid hard linking in objects/info directory
Bruno Ribas (1):
gitweb: Make use of the $git_dir variable at sub
git_get_project_description
Christian Couder (3):
Documentation: config: add "browser.<tool>.path".
Documentation: help: specify supported html browsers.
instaweb: use 'browser.<tool>.path' config option if it's set.
Jakub Narebski (1):
gitweb: Add info about $projectroot and $projects_list to gitweb/README
Jeff King (1):
t9001: add missing && operators
Jim Meyering (1):
fix doc typos
Johannes Schindelin (1):
Add test for rebase -i with commits that do not pass pre-commit
Junio C Hamano (1):
reflog-expire: Avoid creating new files in a directory inside readdir(3)
loop
Yasushi SHOJI (1):
gitweb: Convert generated contents to utf8 in commitdiff_plain
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-07 22:05 ` Christian Stimming
@ 2008-01-07 22:14 ` Junio C Hamano
0 siblings, 0 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-07 22:14 UTC (permalink / raw)
To: Christian Stimming; +Cc: Paul Mackerras, git
Christian Stimming <stimming@tuhh.de> writes:
> Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
>> I'd like you to do a pull from the gitk.git master branch, but it
>> looks to me like there will be a conflict on the Makefile.
>> Unfortunately the Makefile that Christian Stimming gave me along with
>> the i18n changes is quite different from the one you currently have in
>> the gitk-git subdirectory. I'm not quite sure what to suggest since
>> it isn't clear to me exactly what Christian's Makefile (which doesn't
>> actually work) is trying to do.
>
> The Makefile from me was merely a placeholder where the i18n programs should
> work, but it was clear that the installation rules need to be defined
> differently anyway.
>
>> I guess the best thing would be to
>> copy your Makefile over and then add the i18n stuff.
>
> Yes. I've just sent you a patch that does exactly this - that was what I
> thought, too.
Thanks both of you.
>> Apart from the i18n changes, there is one more commit (b039f0a6) that
>> improves the appearance slightly when running under Tk8.5.
>
> Are you going to release a i18n-enabled gitk sometime soon? If yes, you should
> consider notifying the translator(s) a few days in advance so that they can
> finalize their translations, in case they want to avoid a half-translated
> program to be shipped. Thanks a lot.
If I understand correctly, what Paul told me to pull contains
the i18n stuff, so assuming your adjustment to gitk Makefile
makes things cleanly merge and build inside git.git repository,
upcoming 1.5.4-rc3 will ship with the infrastructure and
existing translations, and updates to po/ files can be made
between -rc3 and the final (I do not mean there won't be -rc4.
That is also "between -rc3 and final").
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-07 21:58 ` Paul Mackerras
@ 2008-01-07 22:05 ` Christian Stimming
2008-01-07 22:14 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Christian Stimming @ 2008-01-07 22:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
> I'd like you to do a pull from the gitk.git master branch, but it
> looks to me like there will be a conflict on the Makefile.
> Unfortunately the Makefile that Christian Stimming gave me along with
> the i18n changes is quite different from the one you currently have in
> the gitk-git subdirectory. I'm not quite sure what to suggest since
> it isn't clear to me exactly what Christian's Makefile (which doesn't
> actually work) is trying to do.
The Makefile from me was merely a placeholder where the i18n programs should
work, but it was clear that the installation rules need to be defined
differently anyway.
> I guess the best thing would be to
> copy your Makefile over and then add the i18n stuff.
Yes. I've just sent you a patch that does exactly this - that was what I
thought, too.
> Apart from the i18n changes, there is one more commit (b039f0a6) that
> improves the appearance slightly when running under Tk8.5.
Are you going to release a i18n-enabled gitk sometime soon? If yes, you should
consider notifying the translator(s) a few days in advance so that they can
finalize their translations, in case they want to avoid a half-translated
program to be shipped. Thanks a lot.
Christian
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-07 8:27 ` Junio C Hamano
@ 2008-01-07 21:58 ` Paul Mackerras
2008-01-07 22:05 ` Christian Stimming
0 siblings, 1 reply; 32+ messages in thread
From: Paul Mackerras @ 2008-01-07 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, stimming
Junio C Hamano writes:
> Subsystem people (except Shawn, whose git-gui 0.9.1 is already
> in) are requested to tell me to pull from them, if they have
> accumulated changes that should be in the final release. I am
> hoping that I can tag -rc3 in a few days (say by the end of my
> Wednesday).
I'd like you to do a pull from the gitk.git master branch, but it
looks to me like there will be a conflict on the Makefile.
Unfortunately the Makefile that Christian Stimming gave me along with
the i18n changes is quite different from the one you currently have in
the gitk-git subdirectory. I'm not quite sure what to suggest since
it isn't clear to me exactly what Christian's Makefile (which doesn't
actually work) is trying to do. I guess the best thing would be to
copy your Makefile over and then add the i18n stuff.
Apart from the i18n changes, there is one more commit (b039f0a6) that
improves the appearance slightly when running under Tk8.5.
Paul.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-05 10:46 ` Junio C Hamano
` (2 preceding siblings ...)
2008-01-06 4:24 ` Jeff King
@ 2008-01-07 8:27 ` Junio C Hamano
2008-01-07 21:58 ` Paul Mackerras
3 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-07 8:27 UTC (permalink / raw)
To: git
Cc: Paul Mackerras, Eric Wong, J. Bruce Fields, Shawn O. Pearce,
Theodore Ts'o
I've applied all the leftover bits I mentioned in yesterday's
message and 'master' tonight is pretty much where I want it to
be in 1.5.4-rc3 (and in 1.5.4 final).
Subsystem people (except Shawn, whose git-gui 0.9.1 is already
in) are requested to tell me to pull from them, if they have
accumulated changes that should be in the final release. I am
hoping that I can tag -rc3 in a few days (say by the end of my
Wednesday).
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 21:22 ` Junio C Hamano
@ 2008-01-07 1:48 ` Jeff King
0 siblings, 0 replies; 32+ messages in thread
From: Jeff King @ 2008-01-07 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Jan 06, 2008 at 01:22:57PM -0800, Junio C Hamano wrote:
> Yes, to a certain extent with Perl (I think if you make the same
> typo twice you won't get much help, and that is quite easy to
> trigger with variable name autocompletion and cut-and-paste).
Yes, and a static checking language would be a little less error-prone.
But who can live without "eval <STDIN>"? :)
> I suspect "if (!$menu_use_color)" might need to be refined in
> sub "highlight_prefix". It should be tied with $prompt_color
> somehow (i.e. either it is undef or the "plain" color),
> shouldn't it?
I'm not sure. It avoids printing the brackets in "[p]atch". If you say
"use color, but make the color plain" does that mean you want brackets
or not (right now it will not show brackets)?
> But other than that the result looks quite nice. I shuffled the
> patches around and the resulting series consists of three patches:
Great. That is the order I would have chosen as well (and hopefully I
gave you enough material in the commit messages to cut and paste
something sensible).
-Peff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 20:59 ` Jeff King
@ 2008-01-06 21:22 ` Junio C Hamano
2008-01-07 1:48 ` Jeff King
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 21:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> Yes, I considered making a %palette, as well, but it just seemed a
> little gratuitous (and the nice thing about using variables is that they
> catch typos better).
Yes, to a certain extent with Perl (I think if you make the same
typo twice you won't get much help, and that is quite easy to
trigger with variable name autocompletion and cut-and-paste).
I suspect "if (!$menu_use_color)" might need to be refined in
sub "highlight_prefix". It should be tied with $prompt_color
somehow (i.e. either it is undef or the "plain" color),
shouldn't it?
But other than that the result looks quite nice. I shuffled the
patches around and the resulting series consists of three patches:
- "remove unused diff colors";
- "color.diff" colors diff, "color.interactive" colors
interaction (squashed the original with change to the "sub
colored" to use palette setting instead of $use_color as the
cue);
- documentation update to redefine the color.interactive
semantics;
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 12:32 ` Junio C Hamano
@ 2008-01-06 20:59 ` Jeff King
2008-01-06 21:22 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Jeff King @ 2008-01-06 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Jan 06, 2008 at 04:32:15AM -0800, Junio C Hamano wrote:
> Yeah, I like that much better, especially the renaming of
> $use_color to more descriptive (but is it really about "menu", I
> wonder?).
I thought that, too, but I didn't know what better word to use
(something like "display" doesn't make it clear that it doesn't involve
the diff).
> I might consider rewriting this part
>
> > +my $menu_use_color = $repo->get_colorbool('color.interactive');
> > +my ($prompt_color, $header_color, $help_color) =
> > + $menu_use_color ? (
> > + $repo->get_color('color.interactive.prompt', 'bold blue'),
> > + $repo->get_color('color.interactive.header', 'bold'),
> > + $repo->get_color('color.interactive.help', 'red bold'),
> > + ) : ();
>
> like this:
>
> my ($prompt_color, $header_color, $help_color, $fraginfo_color);
> if ($colored_prompt) {
> $prompt_color = ...;
> $header_color = ...;
> }
> if ($colored_diff) {
> $fraginfo_color = ...;
> }
Actually, that's more or less how it's written before my patch (in fact,
you could eliminate that part of my patch and just move $normal_color
outside of the conditional). However I didn't like having the
declaration and the assignment so far apart (and duplicated). But I will
admit my version is a little nested. Please feel free to switch it when
you apply.
> or even like this:
>
> my (%palette);
> if ($colored_prompt) {
> my %default = (
> prompt => 'bold blue',
> header => 'bold',
> ...
> );
> while (my ($k,$v) = each %default) {
> $palette{$k} = $repo->get_color("color.interactive.$k",$v);
> }
> }
>
> But I realize that's going overboard. Certainly the last one is
> doing unnecessary generalization for generalization's sake.
Yes, I considered making a %palette, as well, but it just seemed a
little gratuitous (and the nice thing about using variables is that they
catch typos better).
-Peff
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 11:17 ` Jeff King
@ 2008-01-06 12:32 ` Junio C Hamano
2008-01-06 20:59 ` Jeff King
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> Something like this (instead of my last patch):
Yeah, I like that much better, especially the renaming of
$use_color to more descriptive (but is it really about "menu", I
wonder?).
I might consider rewriting this part
> +my $menu_use_color = $repo->get_colorbool('color.interactive');
> +my ($prompt_color, $header_color, $help_color) =
> + $menu_use_color ? (
> + $repo->get_color('color.interactive.prompt', 'bold blue'),
> + $repo->get_color('color.interactive.header', 'bold'),
> + $repo->get_color('color.interactive.help', 'red bold'),
> + ) : ();
like this:
my ($prompt_color, $header_color, $help_color, $fraginfo_color);
if ($colored_prompt) {
$prompt_color = ...;
$header_color = ...;
}
if ($colored_diff) {
$fraginfo_color = ...;
}
or even like this:
my (%palette);
if ($colored_prompt) {
my %default = (
prompt => 'bold blue',
header => 'bold',
...
);
while (my ($k,$v) = each %default) {
$palette{$k} = $repo->get_color("color.interactive.$k",$v);
}
}
But I realize that's going overboard. Certainly the last one is
doing unnecessary generalization for generalization's sake.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 10:51 ` Junio C Hamano
@ 2008-01-06 11:17 ` Jeff King
2008-01-06 12:32 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Jeff King @ 2008-01-06 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sun, Jan 06, 2008 at 02:51:24AM -0800, Junio C Hamano wrote:
> It may make more sense to:
>
> * unset $prompt_color and friends when color.interactive says
> "not to color the menus";
>
> * unset $fraginfo_color and diff related ones when color.diff
> says "diff is monochrome";
>
> upfront, and then change "sub colored" to just check if $color
> is unset, instead of checking $use_color.
Something like this (instead of my last patch):
-- >8 --
add--interactive: fix "colored" function semantics
Since color.interactive is just for the menus, the "colored"
function can't use it to determine whether to show colors
(this was visible as a bug in which the headers of split
hunks were not colored if color.diff was set but
color.interactive was not).
The new semantics are:
- colors which are unused are set to undef; the "colored"
function knows not to do anything with them
- menu colors are set only when color.interactive is true
- diff colors are set only when color.diff is true
Signed-off-by: Jeff King <peff@peff.net>
---
git-add--interactive.perl | 39 +++++++++++++++------------------------
1 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..17ca5b8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -3,38 +3,29 @@
use strict;
use Git;
-# Prompt colors:
-my ($prompt_color, $header_color, $help_color, $normal_color);
-# Diff colors:
-my ($fraginfo_color);
-
-my ($use_color, $diff_use_color);
my $repo = Git->repository();
-$use_color = $repo->get_colorbool('color.interactive');
-
-if ($use_color) {
- # Set interactive colors:
+my $menu_use_color = $repo->get_colorbool('color.interactive');
+my ($prompt_color, $header_color, $help_color) =
+ $menu_use_color ? (
+ $repo->get_color('color.interactive.prompt', 'bold blue'),
+ $repo->get_color('color.interactive.header', 'bold'),
+ $repo->get_color('color.interactive.help', 'red bold'),
+ ) : ();
- # Grab the 3 main colors in git color string format, with sane
- # (visible) defaults:
- $prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
- $header_color = $repo->get_color("color.interactive.header", "bold");
- $help_color = $repo->get_color("color.interactive.help", "red bold");
- $normal_color = $repo->get_color("", "reset");
-}
+my $diff_use_color = $repo->get_colorbool('color.diff');
+my ($fraginfo_color) =
+ $diff_use_color ? (
+ $repo->get_color('color.diff.frag', 'cyan'),
+ ) : ();
-# Do we also set diff colors?
-$diff_use_color = $repo->get_colorbool('color.diff');
-if ($diff_use_color) {
- $fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
-}
+my $normal_color = $repo->get_color("", "reset");
sub colored {
my $color = shift;
my $string = join("", @_);
- if ($use_color) {
+ if (defined $color) {
# Put a color code at the beginning of each line, a reset at the end
# color after newlines that are not at the end of the string
$string =~ s/(\n+)(.)/$1$color$2/g;
@@ -300,7 +291,7 @@ sub highlight_prefix {
return "$prefix$remainder";
}
- if (!$use_color) {
+ if (!$menu_use_color) {
return "[$prefix]$remainder";
}
--
1.5.4.rc2.1148.gf9fe3-dirty
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 4:29 ` Jeff King
@ 2008-01-06 10:51 ` Junio C Hamano
2008-01-06 11:17 ` Jeff King
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 10:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> This is a little uglier than it could be because the "colored" function
> does two things: correctly colorize a string, and check the global
> $use_color.
That fallout is a logical consequence of the semantics change of
color.interactive, which used to color the whole user experience
but now only covers about menus and stuff. $use_color is still
tied to the former semantics.
It may make more sense to:
* unset $prompt_color and friends when color.interactive says
"not to color the menus";
* unset $fraginfo_color and diff related ones when color.diff
says "diff is monochrome";
upfront, and then change "sub colored" to just check if $color
is unset, instead of checking $use_color.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 3:08 ` Dan McGee
@ 2008-01-06 10:33 ` Junio C Hamano
0 siblings, 0 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 10:33 UTC (permalink / raw)
To: Dan McGee
Cc: Junio C Hamano, git, Tsugikazu Shibata, Marco Costalba,
Jeff King, Dmitry Potapov
"Dan McGee" <dpmcgee@gmail.com> writes:
>> Ah, I spoke too fast. I think I need to first do a clean-up
>> patch to fix "gitlink::foobar[1]" that should have been spelled
>> as "gitlink:foobar[1]" in a few places, and your change is good.
>
> It looks like I still blew it and forgot the changes in asciidoc.conf
> in the second patch, sorry about that. Let me know if you need
> anything more,...
I think I got all of what you wanted to do now, although my tree
still is not in a shape I can push it out yet (I have to whip
other parts that does not have anything to do with this
documentation fix into shape first).
Thanks.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 4:24 ` Jeff King
@ 2008-01-06 4:29 ` Jeff King
2008-01-06 10:51 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Jeff King @ 2008-01-06 4:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sat, Jan 05, 2008 at 11:24:09PM -0500, Jeff King wrote:
> > * Jeff's git-add--interactive change to always honor color.diff
> > regardless of color.interactive.
> >
> > I'd probably apply this, along with the patch to redefine
> > what color.interactive means. "git am -i" could also learn
> > to use colors in the future.
>
> Here is the palette cleanup patch, on top of my others (it should still
And while tracking down the $fraginfo usage, I noticed that my original
patches introduce a bug. Fix is below (it is on top of palette cleanup).
I can also resubmit these in a more sensible order (palette cleanup,
then the other three squashed together) if you prefer.
-- >8 --
add--interactive: colorize split hunk fragment headers
The only diff element which we still color in perl is the
"fraginfo" for the split hunks. When honoring color.diff
without color.interactive, we were failing to actually color
this because the "colored" function checks for interactive
color. Instead, let's just color it by hand (the simple
approach is OK because we know we have a single line
string).
Signed-off-by: Jeff King <peff@peff.net>
---
This is a little uglier than it could be because the "colored" function
does two things: correctly colorize a string, and check the global
$use_color. We could do something like:
local $use_color = 1;
$display_head = colored($fraginfo_color, $head);
which is arguably less ugly. Or we could refactor "colored", which is a
larger change.
git-add--interactive.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5bdcca8..76dc4e6 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -21,8 +21,8 @@ if ($use_color) {
$prompt_color = $repo->get_color("color.interactive.prompt", "bold blue");
$header_color = $repo->get_color("color.interactive.header", "bold");
$help_color = $repo->get_color("color.interactive.help", "red bold");
- $normal_color = $repo->get_color("", "reset");
}
+$normal_color = $repo->get_color("", "reset");
# Do we also set diff colors?
$diff_use_color = $repo->get_colorbool('color.diff');
@@ -648,7 +648,8 @@ sub split_hunk {
my $display_head = $head;
unshift @{$hunk->{TEXT}}, $head;
if ($diff_use_color) {
- $display_head = colored($fraginfo_color, $head);
+ $display_head = join('', $fraginfo_color, $head,
+ $normal_color, "\n");
}
unshift @{$hunk->{DISPLAY}}, $display_head;
}
--
1.5.4.rc2.1147.gaecdf-dirty
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-05 10:46 ` Junio C Hamano
2008-01-05 21:21 ` Dan McGee
[not found] ` <e5bfff550801050507x369976b7sd5e112451bc90331@mail.gmail.com>
@ 2008-01-06 4:24 ` Jeff King
2008-01-06 4:29 ` Jeff King
2008-01-07 8:27 ` Junio C Hamano
3 siblings, 1 reply; 32+ messages in thread
From: Jeff King @ 2008-01-06 4:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Sat, Jan 05, 2008 at 02:46:07AM -0800, Junio C Hamano wrote:
> * Jeff's git-add--interactive change to always honor color.diff
> regardless of color.interactive.
>
> I'd probably apply this, along with the patch to redefine
> what color.interactive means. "git am -i" could also learn
> to use colors in the future.
>
> Incidentally I noticed that many of the color.diff.* palette
> options are read by "git-add -i" but never used by the
> script. We might want to fix this while we are at it.
Here is the palette cleanup patch, on top of my others (it should still
be done even if the other patches aren't taken, but backporting it
should be fairly obvious).
-- >8 --
add--interactive: remove unused diff colors
When color support was added, we colored the diffs
ourselves. However, 4af756f3 changed this to simply run
"git diff-files" twice, keeping the colored output
separately.
This makes the internal diff color variables obsolete with
one exception: when splitting hunks, we have to manually
recreate the fragment for each part of the split. Thus we
keep $fraginfo_color around to do that correctly.
Signed-off-by: Jeff King <peff@peff.net>
---
git-add--interactive.perl | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index aaa9b24..5bdcca8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -6,7 +6,7 @@ use Git;
# Prompt colors:
my ($prompt_color, $header_color, $help_color, $normal_color);
# Diff colors:
-my ($new_color, $old_color, $fraginfo_color, $metainfo_color, $whitespace_color);
+my ($fraginfo_color);
my ($use_color, $diff_use_color);
my $repo = Git->repository();
@@ -27,11 +27,7 @@ if ($use_color) {
# Do we also set diff colors?
$diff_use_color = $repo->get_colorbool('color.diff');
if ($diff_use_color) {
- $new_color = $repo->get_color("color.diff.new", "green");
- $old_color = $repo->get_color("color.diff.old", "red");
$fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
- $metainfo_color = $repo->get_color("color.diff.meta", "bold");
- $whitespace_color = $repo->get_color("color.diff.whitespace", "normal red");
}
sub colored {
--
1.5.4.rc2.1147.gaecdf-dirty
^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 3:06 ` Junio C Hamano
@ 2008-01-06 3:08 ` Dan McGee
2008-01-06 10:33 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Dan McGee @ 2008-01-06 3:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Tsugikazu Shibata, Marco Costalba, Jeff King, Dmitry Potapov
On Jan 5, 2008 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> >> I've updated the patch a bit as I noticed I completely missed the
> >> user-manual.txt and a handful of other files that weren't named
> >> git-*.txt. The new version is attached (gzipped).
> >
> > The asciidoc.conf change I resurrected from the earlier one but
> > it appears this breaks build with asciidoc 7.1.2 for some reason
> > (I haven't looked into that myself yet, and I won't be for the
> > next 12 hours or so).
>
> Ah, I spoke too fast. I think I need to first do a clean-up
> patch to fix "gitlink::foobar[1]" that should have been spelled
> as "gitlink:foobar[1]" in a few places, and your change is good.
It looks like I still blew it and forgot the changes in asciidoc.conf
in the second patch, sorry about that. Let me know if you need
anything more, although this patch is pretty straightforward (once I
spent 3 hours trying to figure out why it was broken in the first
place and attempting to find a more sane way around it).
-Dan
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-06 2:56 ` Junio C Hamano
@ 2008-01-06 3:06 ` Junio C Hamano
2008-01-06 3:08 ` Dan McGee
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 3:06 UTC (permalink / raw)
To: Dan McGee
Cc: git, Tsugikazu Shibata, Marco Costalba, Jeff King, Dmitry Potapov
Junio C Hamano <gitster@pobox.com> writes:
>> I've updated the patch a bit as I noticed I completely missed the
>> user-manual.txt and a handful of other files that weren't named
>> git-*.txt. The new version is attached (gzipped).
>
> The asciidoc.conf change I resurrected from the earlier one but
> it appears this breaks build with asciidoc 7.1.2 for some reason
> (I haven't looked into that myself yet, and I won't be for the
> next 12 hours or so).
Ah, I spoke too fast. I think I need to first do a clean-up
patch to fix "gitlink::foobar[1]" that should have been spelled
as "gitlink:foobar[1]" in a few places, and your change is good.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-05 21:21 ` Dan McGee
@ 2008-01-06 2:56 ` Junio C Hamano
2008-01-06 3:06 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2008-01-06 2:56 UTC (permalink / raw)
To: Dan McGee
Cc: git, Tsugikazu Shibata, Marco Costalba, Jeff King, Dmitry Potapov
"Dan McGee" <dpmcgee@gmail.com> writes:
> On Jan 5, 2008 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> We are not at -rc3 yet, but we will be soon. What we have
>> accumulated in 'master' are mostly fixes, and the official
>> git-gui 0.9.1 is also included tonight.
>> * Dan McGee's workaround to breakage caused by changes in
>> AsciiDoc 8.2.3.
>>
>> I have to do my usual "before-and-after comparison" with
>> copies of AsciiDoc versions that should not be affected by
>> the breakage, which I did not have time to do so far. But
>> this is probably a must-have before the release.
>
> I've updated the patch a bit as I noticed I completely missed the
> user-manual.txt and a handful of other files that weren't named
> git-*.txt. The new version is attached (gzipped).
The asciidoc.conf change I resurrected from the earlier one but
it appears this breaks build with asciidoc 7.1.2 for some reason
(I haven't looked into that myself yet, and I won't be for the
next 12 hours or so).
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
[not found] ` <e5bfff550801050507x369976b7sd5e112451bc90331@mail.gmail.com>
@ 2008-01-05 22:11 ` Junio C Hamano
0 siblings, 0 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-05 22:11 UTC (permalink / raw)
To: Marco Costalba
Cc: Junio C Hamano, git, Tsugikazu Shibata, Jeff King, Dan McGee,
Dmitry Potapov
"Marco Costalba" <mcostalba@gmail.com> writes:
> I understand the patch series is too intrusive now, but if you want I
> can send a simplified one that just fixes the off by one bug for now.
How about the one that fixes first and see how bad the remainder
looks again? I recall that Réne were not entirely unhappy with
his last round. And I do not think that change does not have to
be "a series" but can be a single change. At least it did not
look so complicated, but I may be misremembering it.
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2008-01-05 10:46 ` Junio C Hamano
@ 2008-01-05 21:21 ` Dan McGee
2008-01-06 2:56 ` Junio C Hamano
[not found] ` <e5bfff550801050507x369976b7sd5e112451bc90331@mail.gmail.com>
` (2 subsequent siblings)
3 siblings, 1 reply; 32+ messages in thread
From: Dan McGee @ 2008-01-05 21:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Tsugikazu Shibata, Marco Costalba, Jeff King, Dmitry Potapov
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Jan 5, 2008 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We are not at -rc3 yet, but we will be soon. What we have
> accumulated in 'master' are mostly fixes, and the official
> git-gui 0.9.1 is also included tonight.
> * Dan McGee's workaround to breakage caused by changes in
> AsciiDoc 8.2.3.
>
> I have to do my usual "before-and-after comparison" with
> copies of AsciiDoc versions that should not be affected by
> the breakage, which I did not have time to do so far. But
> this is probably a must-have before the release.
I've updated the patch a bit as I noticed I completely missed the
user-manual.txt and a handful of other files that weren't named
git-*.txt. The new version is attached (gzipped). I also included
instructions on how to regenerate it in the commit message, which may
be a wise idea to ensure no Documentation changes add a gitlink: call
between now and when you apply the patch.
-Dan
[-- Attachment #2: 0001-Documentation-rename-gitlink-macro-to-linkgit.patch.gz --]
[-- Type: application/x-gzip, Size: 50243 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* What's in git.git (stable frozen)
2007-12-23 9:21 ` Junio C Hamano
@ 2008-01-05 10:46 ` Junio C Hamano
2008-01-05 21:21 ` Dan McGee
` (3 more replies)
0 siblings, 4 replies; 32+ messages in thread
From: Junio C Hamano @ 2008-01-05 10:46 UTC (permalink / raw)
To: git
Cc: Tsugikazu Shibata, Marco Costalba, Jeff King, Dan McGee, Dmitry Potapov
We are not at -rc3 yet, but we will be soon. What we have
accumulated in 'master' are mostly fixes, and the official
git-gui 0.9.1 is also included tonight.
I have to apologize that tonight I got a bit carried away
enjoying arguing for the sake of arguing. Some patches that
might be worthy even though they are late in the cycle are not
in tonight's 'master', mostly because I have to sleep on them,
and partly because I am running out of time tonight.
* Tsugikazu Shibata's git-diff hunk header change.
I have a counterproposal that I think is more in line with
the other parts of the system. As the kernel project has
ja_JP, ko_KR and zh_CN directories under Documentation these
days, the issue this patch addresses is already real, and we
would want to have a solution in 1.5.4, even though the topic
was raised too late in the cycle. I think my first two
patches could be a good starting point for that. I'd exclude
the last patch in the series that acts on gitattributes for
now.
* Marco's git-stash changes to output to stdout.
I'd probably apply this, with a slightly toned down commit
log message. Marco says some practice is standard, I
disagreed, but that is not a reason to say "this practice is
nonstandard and bad". Simply saying "some do this and it is
better to be helpful to them because there is no strong
reason not to" would be good enough.
* Jeff's git-add--interactive change to always honor color.diff
regardless of color.interactive.
I'd probably apply this, along with the patch to redefine
what color.interactive means. "git am -i" could also learn
to use colors in the future.
Incidentally I noticed that many of the color.diff.* palette
options are read by "git-add -i" but never used by the
script. We might want to fix this while we are at it.
* Dan McGee's workaround to breakage caused by changes in
AsciiDoc 8.2.3.
I have to do my usual "before-and-after comparison" with
copies of AsciiDoc versions that should not be affected by
the breakage, which I did not have time to do so far. But
this is probably a must-have before the release.
* My patch to error out "git stash clear foobar".
This should be applied; it is a good safety measure
regardless of where that "git stash drop" thing would go.
An issue worth addressing before the release is still in limbo.
* Dmitry's git-filter-branch fix to disambiguate the refs being
rewritten.
Addition of "git-rev-parse --symbolic-full" may solve this
more cleanly than the patches in the discussion, but we
haven't reached the conclusion of this thread yet.
Anything I missed?
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
Allow selection of different cleanup modes for commit messages
Arjen Laarhoven (1):
Fix "git log --diff-filter" bug
Bernt Hansen (1):
git-gui: Make commit log messages end with a newline
Eric Wong (2):
git-svn: allow dcommit --no-rebase to commit multiple, dependent changes
git-svn: unlink index files that were globbed, too
Grégoire Barbier (1):
Fix double-free() in http-push.c:remote_exists()
Gustaf Hendeby (2):
shortlog manpage documentation: work around asciidoc markup issues
Documentation/user-manual.txt: fix typo
J. Bruce Fields (1):
Documentation: fix remote.<name>.skipDefaultUpdate description
Jeff King (6):
cvsimport: die on cvsps errors
config: handle lack of newline at end of file better
git-reset: refuse to do hard reset in a bare repository
add a "basic" diff config callback
diff: load funcname patterns in "basic" config
diff: remove lazy config loading
Jim Meyering (2):
Fix grammar nits in documentation and in code comments.
Don't access line[-1] for a zero-length "line" from fgets.
Johannes Schindelin (1):
Optimize prefixcmp()
Johannes Sixt (1):
git-gui: Move frequently used commands to the top of the context menu.
Junio C Hamano (20):
t7005: do not exit inside test.
builtin-commit: fix amending of the initial commit
builtin-commit: avoid double-negation in the code.
Fix documentation of --first-parent in git-log and copy it to
git-rev-list
combine-diff: Fix path quoting
Fix rewrite_diff() name quoting.
contrib: resurrect scripted git-revert.
GIT 1.5.4-rc2
Documentation/git-submodule.txt: typofix
"git pull --tags": error out with a better message.
git-rebase -i behaves better on commits with incomplete messages
git-rebase -i: clean-up error check codepath.
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Update callers of check_ref_format()
Uninline prefixcmp()
git-clean: make "Would remove ..." path relative to cwd again
t/t7600: avoid GNUism in grep
t/t{3600,3800,5401}: do not use egrep when grep would do
t/t3800: do not use a temporary file to hold expected result.
Update draft release notes for 1.5.4
Marco Costalba (1):
Document git-reset defaults to HEAD if no commit is given
Mark Levedahl (1):
git-gui: Unconditionally use absolute paths with Cygwin
Martin Koegler (2):
receive-pack: check object type of sha1 before using them as commits
receive-pack: reject invalid refnames
Michael Stefaniuc (1):
git-am: Run git gc only once and not for every patch.
Miklos Vajna (2):
git-sh-setup: document git_editor() and get_author_ident_from_commit()
t/t7001: avoid unnecessary ERE when using grep
Peter Karlsson (1):
Added Swedish translation.
René Scharfe (1):
Make "--pretty=format" parser a bit more careful.
Shawn O. Pearce (2):
git-gui: Handle file mode changes (644->755) in diff viewer
Improve error messages when int/long cannot be parsed from config
^ permalink raw reply [flat|nested] 32+ messages in thread
* What's in git.git (stable frozen)
2007-12-17 8:40 ` Junio C Hamano
@ 2007-12-23 9:21 ` Junio C Hamano
2008-01-05 10:46 ` Junio C Hamano
0 siblings, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2007-12-23 9:21 UTC (permalink / raw)
To: git
Stabilization cycle towards -rc2 continues.
The main point of -rc cycle is regression fixes and general
bugfixes, although a few new features managed to slip in.
- diff.external configuration variable serves the same purpose
as GIT_EXTERNAL_DIFF environment;
- "git diff --src-prefix=l/ --dst-prefix=k/" can be used to
change the usual prefix (i.e. a/foo vs. b/foo).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Jeff King (2):
clone: correctly report http_fetch errors
git-send-email: avoid duplicate message-ids
* The 'master' branch has these since the last announcement
in addition to the above.
Charles Bailey (2):
Fix git-instaweb breakage on MacOS X due to the limited sed functionality
Remove old generated files from .gitignore.
Eric Wong (3):
git-svn: avoid leaving leftover committer/author info in rebase
git-svn: workaround a for broken symlinks in SVN
git-svn: avoid warning when run without arguments
Finn Arne Gangstad (1):
Improved submodule merge support
Gustaf Hendeby (1):
Make git send-email accept $EDITOR with arguments
H.Merijn Brand (1):
the use of 'tr' in the test suite isn't really portable
Jakub Narebski (1):
gitweb: fix whitespace in config_to_multi (indent with tab)
Jeff King (2):
test "git clone -o"
clean up 1.5.4 release notes
Jim Meyering (2):
git-filter-branch.sh: more portable tr usage: use \012, not \n.
Don't dereference NULL upon lookup failure.
Johannes Schindelin (6):
Support config variable diff.external
Document diff.external and mergetool.<tool>.path
rebase -p -i: handle "no changes" gracefully
git show <tag>: show the tagger
Teach diff machinery to display other prefixes than "a/" and "b/"
Mention git-shell's "cvs" substitution in the RelNotes
Johannes Sixt (3):
Plug a resource leak in threaded pack-objects code.
Clean up documentation that references deprecated 'git peek-remote'.
filter-branch: Remove broken and unnecessary summary of rewritten refs.
Junio C Hamano (8):
builtin-blame.c: remove unneeded memclr()
GIT 1.5.4-rc1
t4024: fix test script to use simpler sed pattern
fix git commit --amend -m "new message"
shell-scripts usage(): consistently exit with non-zero
Documentation: ls-files -v is about "assume unchanged".
Fix $EDITOR regression introduced by rewrite in C.
Documentation: describe 'union' low-level merge driver
Linus Torvalds (2):
unpack-trees: FLEX_ARRAY fix
Re(-re)*fix trim_common_tail()
Marco Roeland (1):
clone: fix options '-o' and '--origin' to be recognised again
Miklos Vajna (1):
everyday: replace 'prune' and 'repack' with 'gc'
Nicolas Pitre (2):
fix style of a few comments in diff-delta.c
make 'git describe --all --contains' work
Pierre Habouzit (4):
Fix segfault in diff-delta.c when FLEX_ARRAY is 1
git-tag: fix -l switch handling regression.
Force the sticked form for options with optional arguments.
parse-options: Add a gitcli(5) man page.
Ralf Wildenhues (1):
Fix some documentation typos.
Sam Vilain (1):
Clarify error response from 'git fetch' for bad responses
Sean Estabrooks (1):
Fix interactive rebase to preserve author email address
Shawn O. Pearce (3):
Avoid update hook during git-rebase --interactive
Catch and handle git-commit failures in git-rebase --interactive
Reallow git-rebase --interactive --continue if commit is unnecessary
Stefan Sperling (1):
Small comment fix for git-cvsimport.
Wincent Colaiuta (1):
Emit helpful status for accidental "git stash" save
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: What's in git.git (stable frozen)
2007-12-13 2:47 ` What's in git.git (stable frozen) Junio C Hamano
2007-12-17 8:40 ` Junio C Hamano
@ 2007-12-17 21:52 ` Steffen Prohaska
1 sibling, 0 replies; 32+ messages in thread
From: Steffen Prohaska @ 2007-12-17 21:52 UTC (permalink / raw)
To: Git Mailing List, msysGit
On Dec 13, 2007, at 3:47 AM, Junio C Hamano wrote:
> The tip of 'master' is now tagged as 1.5.4-rc0. Tarballs are found in
> the usual places:
A fresh msysgit self-contained Windows setup is available from
http://msysgit.googlecode.com/files/Git-1.5.4-rc0-preview20071217.exe
Steffen
^ permalink raw reply [flat|nested] 32+ messages in thread
* What's in git.git (stable frozen)
2007-12-13 2:47 ` What's in git.git (stable frozen) Junio C Hamano
@ 2007-12-17 8:40 ` Junio C Hamano
2007-12-23 9:21 ` Junio C Hamano
2007-12-17 21:52 ` Steffen Prohaska
1 sibling, 1 reply; 32+ messages in thread
From: Junio C Hamano @ 2007-12-17 8:40 UTC (permalink / raw)
To: git
Sorry for the "\No newline at the end" brown paper bag bug, which
happened soon after -rc0 but now fixed. Thanks Jeff.
"git diff --check" was inconsistent with the highlighting of whitespace
problems and was harder to use from scripts (which makes it a usability
bug). Both have been fixed. Thanks Wincent.
A handful "gitweb" fixes I forgot to apply earlier are now in. Thanks
Jakub.
A "git commit" regression has been noticed --- the post-commit summary
was inconsistent with what is shown by git-status before making the
commit. Thanks Daniel.
A workaround for massive commit that exceeds command line limit when
issuing "cvs status list-of-files" has been added. Thanks Jeff.
Hopefully the final round of clean-up until 1.5.4 in whitespace area has
been applied. Thanks Wincent and Bruce.
I am reasonably happy that we are finding and fixing bugs. Please keep
the fixes, including documentation updates, flowing in.
* "git -p ls-tree HEAD" in a bare repository is still not fixed.
http://thread.gmane.org/gmane.comp.version-control.git/68209?focus=68221
http://thread.gmane.org/gmane.comp.version-control.git/68209?focus=68338
* Hannes says "thread pack-objects" improvements needs a follow-up
patch; it hasn't been applied here yet.
* option parser regression fix really needs to be in by -rc1, but I
just applied the initial round of Pierre's patches today. See
"What's cooking" for the list.
I need to coordinate with subsystem people and pull in changes for
gitk, git-gui, user manual and git-svn.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Whitcroft (1):
git-svn: expand handling of From: and Signed-off-by:
Christian Couder (1):
git-help: add "help.format" config variable.
David S. Miller (1):
fast-import: fix unalinged allocation and access
Eric Wong (2):
git-svn: unlink internal index files after operations
git-svn: handle our top-level path being deleted and later re-added
J. Bruce Fields (8):
whitespace: fix off-by-one error in non-space-in-indent checking
whitespace: reorganize initial-indent check
whitespace: minor cleanup
whitespace: fix initial-indent checking
whitespace: more accurate initial-indent highlighting
whitespace: fix config.txt description of indent-with-non-tab
builtin-apply: minor cleanup of whitespace detection
builtin-apply: stronger indent-with-on-tab fixing
Jakub Narebski (2):
gitweb: disambiguate heads and tags withs the same name
gitweb: Teach "a=blob" action to be more lenient about blob/file mime
type
Jeff King (4):
cvsexportcommit: fix massive commits
trim_common_tail: brown paper bag fix.
teach bash completion to treat commands with "--" as a helper
rename git-browse--help to git-help--browse
Johannes Sixt (1):
threaded pack-objects: Use condition variables for thread communication.
Junio C Hamano (15):
git-commit: squelch needless message during an empty merge
xdl_diff: identify call sites.
xdi_diff: trim common trailing lines
diff --check: minor fixups
xdiff tail trimming: use correct type.
commit: allow --amend to reuse message from another commit
remote: Fix bogus make_branch() call in configuration reader.
Rename git-browse-help helper to git-browse--help
Retire git-runstatus for real.
Start preparing the API documents.
Update draft release notes for 1.5.4
Re-re-re-fix common tail optimization
builtin-commit: fix summary output.
builtin-commit: make summary output consistent with status
Documentation/git-submodule: refer to gitmodules(5)
Kristian Høgsberg (1):
Use a strbuf for building up section header and key/value pair strings.
Li Hong (1):
Fix a memory leak
Mike Hommey (8):
Fix some more memory leaks in http-push.c
Fix random sha1 in error message in http-fetch and http-push
Remove the default_headers variable from http-push.c
Remove a CURLOPT_HTTPHEADER (un)setting
Avoid redundant declaration of missing_target()
Use strbuf in http code
Fix various memory leaks in http-push.c and http-walker.c
Move fetch_ref from http-push.c and http-walker.c to http.c
Nicolas Pitre (1):
provide advance warning of some future pack default changes
Petr Baudis (1):
gitweb: Make config_to_multi return [] instead of [undef]
Shawn Bohrer (1):
Fix spelling mistakes in user manual
Wincent Colaiuta (6):
"diff --check" should affect exit status
Unify whitespace checking
Make "diff --check" output match "git apply"
Add tests for "git diff --check" with core.whitespace options
Use shorter error messages for whitespace problems
Test interaction between diff --check and --exit-code
anonymous (1):
Documentation: describe pack idx v2
^ permalink raw reply [flat|nested] 32+ messages in thread
* What's in git.git (stable frozen)
2007-12-09 10:32 ` Junio C Hamano
@ 2007-12-13 2:47 ` Junio C Hamano
2007-12-17 8:40 ` Junio C Hamano
2007-12-17 21:52 ` Steffen Prohaska
0 siblings, 2 replies; 32+ messages in thread
From: Junio C Hamano @ 2007-12-13 2:47 UTC (permalink / raw)
To: git
The tip of 'master' is now tagged as 1.5.4-rc0. Tarballs are found in
the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc0.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc0.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc0.tar.{gz,bz2} (preformatted docs)
I've also built a set of preview RPM packages. They are found in:
http://www.kernel.org/pub/software/scm/git/testing/
I am not an RPM person. It would be really appreciated if experts help
out finding and fixing any bug in the packaging. I do not want to
repeat the firefighting we needed with 1.5.3.1.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alex Riesen (1):
Fix git-fast-export for zero-sized blobs
Alexandre Julliard (1):
git.el: Added a menu for git-status-mode.
Charles Bailey (1):
Fix clone not to ignore depth when performing a local clone
Christian Couder (5):
git-help: add -i|--info option to display info page.
Documentation: describe -i/--info option to "git-help"
git-help: add -w|--web option to display html man page in a browser.
Use {web,instaweb,help}.browser config options.
Documentation: describe -w/--web option to "git-help".
Daniel Barkalow (1):
Add more checkout tests
Eric Wong (2):
git-svn: replace .rev_db with a more space-efficient .rev_map format
git-svn: reinstate old rev_db optimization in new rev_map
Eyvind Bernhardsen (1):
Fix mis-markup of the -p, --patch option in git-add(1)
Gerrit Pape (1):
Don't cache DESTDIR in perl/perl.mak.
Jakub Narebski (1):
autoconf: Check asciidoc version to automatically set ASCIIDOC8
Jeff King (6):
don't mention index refreshing side effect in git-status docs
Add git-browse-help to .gitignore
Support GIT_PAGER_IN_USE environment variable
git-svn: get color config from --get-colorbool
shortlog: document -e option
git-clone: print an error message when trying to clone empty repo
Johannes Sixt (1):
Fix a typo in checkout.sh and cleanup one-line help messages
Junio C Hamano (18):
git-shortlog -e: show e-mail address as well
Re-fix ls-remote
Update draft Release Notes for 1.5.4
Documentation: add gitman.info target
git-help -i: invoke info with document and node name
git-help -i: show info documentation from matching version of git
send-email: do not muck with initial-reply-to when unset.
commit: do not add extra LF at the end of the summary.
Support a merge with conflicting gitlink change
blame: drop blob data after passing blame to the parent
shortlog: default to HEAD when the standard input is a tty
git-diff --numstat -z: make it machine readable
disable t9119 for now.
Documentation: rename git.texi to user-manual.texi
git.spec.in: remove python_path
git-help -w: do not require to be in git repository
RPM spec: Adjust htmldir
GIT 1.5.4-rc0
Linus Torvalds (1):
"git tag -u keyname" broken
Mike Hommey (4):
git-send-email.perl: Really add angle brackets to In-Reply-To if
necessary
Cleanup variables in http.[ch]
Fix small memory leaks induced by diff_tree_setup_paths
Fix XML parser leaks in http-push
Nguyễn Thái Ngọc Duy (1):
Remove repo version check from setup_git_directory
Nicolas Pitre (1):
pack-objects: more threaded load balancing fix with often changed paths
Pierre Habouzit (1):
Invert numbers and names in the git-shortlog summary mode.
Wincent Colaiuta (5):
Interactive editor tests for commit-msg hook
Style fixes for pre-commit hook tests
Use "whitespace" consistently
Documentation: minor grammar fix for "git apply"
Fix "diff --check" whitespace detection
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2008-01-30 8:33 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-17 3:01 What's in git.git (stable frozen) Junio C Hamano
2008-01-17 12:56 ` Johannes Sixt
2008-01-17 16:58 ` [PATCH] fast-import.c: don't try to commit marks file if write failed Brandon Casey
2008-01-17 17:57 ` Junio C Hamano
2008-01-18 2:09 ` Shawn O. Pearce
2008-01-17 17:17 ` What's in git.git (stable frozen) Brandon Casey
2008-01-17 17:57 ` Junio C Hamano
2008-01-18 3:01 ` Shawn O. Pearce
-- strict thread matches above, loose matches on Subject: below --
2008-01-30 8:32 Junio C Hamano
2007-10-22 6:11 What's in git/spearce.git (stable) Shawn O. Pearce
2007-11-01 5:39 ` What's in git.git (stable) Junio C Hamano
2007-11-04 3:52 ` Junio C Hamano
2007-11-08 8:06 ` Junio C Hamano
2007-11-12 7:06 ` Junio C Hamano
2007-11-15 0:20 ` Junio C Hamano
2007-11-17 21:00 ` Junio C Hamano
2007-11-25 20:45 ` Junio C Hamano
2007-12-01 2:05 ` Junio C Hamano
2007-12-04 8:43 ` Junio C Hamano
2007-12-05 10:57 ` Junio C Hamano
2007-12-07 9:50 ` Junio C Hamano
2007-12-09 10:32 ` Junio C Hamano
2007-12-13 2:47 ` What's in git.git (stable frozen) Junio C Hamano
2007-12-17 8:40 ` Junio C Hamano
2007-12-23 9:21 ` Junio C Hamano
2008-01-05 10:46 ` Junio C Hamano
2008-01-05 21:21 ` Dan McGee
2008-01-06 2:56 ` Junio C Hamano
2008-01-06 3:06 ` Junio C Hamano
2008-01-06 3:08 ` Dan McGee
2008-01-06 10:33 ` Junio C Hamano
[not found] ` <e5bfff550801050507x369976b7sd5e112451bc90331@mail.gmail.com>
2008-01-05 22:11 ` Junio C Hamano
2008-01-06 4:24 ` Jeff King
2008-01-06 4:29 ` Jeff King
2008-01-06 10:51 ` Junio C Hamano
2008-01-06 11:17 ` Jeff King
2008-01-06 12:32 ` Junio C Hamano
2008-01-06 20:59 ` Jeff King
2008-01-06 21:22 ` Junio C Hamano
2008-01-07 1:48 ` Jeff King
2008-01-07 8:27 ` Junio C Hamano
2008-01-07 21:58 ` Paul Mackerras
2008-01-07 22:05 ` Christian Stimming
2008-01-07 22:14 ` Junio C Hamano
2007-12-17 21:52 ` Steffen Prohaska
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).