login
Search
I haven't tagged the tip of 'master' as -rc0 yet, this has more than 80%
of it. Graduated to 'master' tonight are:
* Wincent's "git add -p"
* "git commit in C" by Kristian and others
* Steffen Prohaska's clean-up of push/fetch refspec handling.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (2):
Do not generate full commit log message if it is not going to be used
Simplify crud() in ident.c
H.Merijn Brand (1):
Do not rely on the exit status of "unset" for unset variables
Jakub Narebski (1):
contrib: Make remotes2config.sh script more robust
Jeff King (3):
git-commit: clean up die messages
quote_path: fix collapsing of relative paths
t9600: require cvsps 2.1 to perform tests
Johannes Schindelin (8):
launch_editor(): read the file, even when EDITOR=:
builtin-commit: fix reflog message generation
git status: show relative paths when run in a subdirectory
builtin-commit: fix --signoff
builtin-commit --s: add a newline if the last line was not a S-o-b
builtin-commit: resurrect behavior for multiple -m options
builtin-commit: Add newline when showing which commit was created
Replace "runstatus" with "status" in the tests
Junio C Hamano (15):
file_exists(): dangling symlinks do exist
builtin-commit: do not color status output shown in the message template
builtin-commit: run commit-msg hook with correct message file
Export three helper functions from ls-files
Fix add_files_to_cache() to take pathspec, not user specified list of
files
builtin-commit: fix partial-commit support
git-add -i: allow multiple selection in patch subcommand
Add a few more tests for git-commit
builtin-add: fix command line building to call interactive
add -i: Fix running from a subdirectory
Fix --signoff in builtin-commit differently.
git-commit: Allow to amend a merge commit that does not change the tree
...Heavy merges to 'master' continues. We are almost there for -rc0.
Merged to 'master' are:
* Colorized "add -i" (Dan Zwell)
* Talk more about diff options in "git log" documentation (Miklos)
* git-gui 0.9.1 preview
* Make cvsserver act more like receive-pack (Michael Witten)
* "git-clean <paths>" limits the damage to named paths
* Use right Perl in Documentation/Makefile
Also people's favorite topic "squelching compilation warnings for iconv"
is included.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
David Symonds (1):
Change from using email.com to example.com as example domain, as per RFC
2606.
Junio C Hamano (2):
git grep shows the same hit repeatedly for unmerged paths
git-am -i: report rewritten title
Nguyễn Thái Ngọc Duy (3):
Add missing inside_work_tree setting in setup_git_directory_gently
Do check_repository_format() early
Do check_repository_format() early (re-fix)
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Björn Steinbrink (1):
git config: Don't rely on regexec() returning 1 on non-match
Brian M. Carlson (1):
git-gui: Reorder msgfmt command-line arguments
Christian Stimming (2):
Update git-gui.pot with latest (few) string additions and changes.
Update German translation. 100% completed.
Jakub Narebski (1):
autoconf: Add test for OLD_ICONV (squelching compiler warning)
Jeff King (1):
t7300: add test for clean with wildcard pathspec
Johannes Sixt (2):
git-gui: Improve the application icon on Windows.
for-each-ref: Fix quoting style constants.
Junio C Hamano (12):
Run the specified perl in Documentation/
git-cvsserver runs hooks/post-update
Revert "git-am: catch missing author date early."
Documentation: color.* = true means "auto"
git config --get-colorbool
Color support for "git-add ...One more topic remains in 'next' before 1.5.4-rc0 where "bugfix only"
freeze period begins. We have a handful regression fixes on 'master'
from the fallout from massive C-rewrite during this cycle.
People still following 'next' are requested to switch to 'master', and
spare a bit more time on finding and fixing regressions there instead of
coming up with new topics from now on.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Jim Meyering (1):
config.c:store_write_pair(): don't read the byte before a malloc'd
buffer.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (3):
wt-status.c:quote_path(): convert empty path to "./"
add status.relativePaths config variable
git-status: documentation improvements
Junio C Hamano (13):
War on whitespace: first, a bit of retreat.
git-diff: complain about >=8 consecutive spaces in initial indent
core.whitespace: add test for diff whitespace error highlighting
builtin-apply: rename "whitespace" variables and fix styles
builtin-apply: teach whitespace_rules
core.whitespace: documentation updates.
Use gitattributes to define per-path whitespace rule
git-bisect visualize: work in non-windowed environments better
mailmap: fix bogus for() loop that happened to be safe by accident
shortlog: code restructuring and clean-up
ls-remote: resurrect pattern limit support
Fix commit-msg hook to allow editing
Re-fix "builtin-commit: fix --signoff"
Nicolas Pitre (3):
pack-objects: fix delta cache size accounting
pack-objects: reverse the delta search sort list
pack-objects: fix threaded load balancing
Pini Reznik (1):
Open external merge tool with original file extensions for all three
files
Sergei Organov (1):
Let git-help prefer man-pages installed with this version of git
Wincent ...People might have noticed that I've been ignoring most of the new topics/enhancements for the past few days. Here is what I want to see happen until we declare v1.5.4. First, stabilize 'master' enough and tag v1.5.4-rc0 soon. * Among what's already in 'next', Christian's "git help -w" enhancement is the only candidate to be in v1.5.4. Johannes's "git remote" could also be, but I've seen it fail tests when run in my k.org private repository and haven't had chance to find time to diagnose it, so I'd rather leave it after v1.5.4. * Eric's sanely-compact mapping from SVN rev-ids to git commits saw a positive feedback. I haven't carefully read that patch but it seemed sane and I'd like to have it in v1.5.4. * Please, everybody, no more new features until v1.5.4 final ships, and please spend a bit more time on finding and fixing regressions than you would spend time cooking your favorite new features. I do not have infinite amount of time to comment on new feature patches while concentrating on fixes at the same time. There are outstanding issues that need to be resolved: * I'd like to see the pack-object's memory performance issue resolved before the release; two very capable people are looking into it and I am fairly optimistic. * We need to do something about "gc --aggressive". The documentation removal patch from Linus, if it ever materializes, would be better than nothing, but I have this nagging suspicion that the explosion is merely a bad interation between -A and -f option to the repack, which are not meant to be used together. * We have a handful deprecation notices in the draft release notes, but if I recall correctly, Nico wanted to add a few more. We need to come up with a wording that is easy to understand for the end users to decide which ancient versions will be affected. "git help -w" will want to have the HTML pages installed, which means we would need to add a new package to ...
A few regressions that you did not mention, but I think should be
addressed before 1.5.4:
- extra newline in builtin-commit output. You found a case that
needs it, but fixing it is non-trivial, and I wanted to get your
input before preparing a patch. See
http://mid.gmane.org/20071203075357.GB3614@sigill.intra.peff.net
- git-clean's handling of directory wildcards. I didn't get a response
to
http://mid.gmane.org/20071206043247.GC5499@coredump.intra.peff.net
I suspect there are still some bugs lurking in there, but it's hard
to say because I don't know what the behavior _should_ be (there are
some test cases in that email).
And perhaps not a regression, but I think we should bring git-svn's
handling of color.* in line with the changes to the rest of the code
before 1.5.4. I posted a "last resort" patch, but I think with your
changes to "git config --colorbool" it might be possible to use that.
I'll try to work up a new patch.
-Peff
-
I am actually becoming somewhat fond of the newline that makes the end of a session that led to a commit stand out ;-). IOW, I was wondering if we can have another for a merge commit case. But I suspect that it amounts to the change in the same area and of The last time I looked at the "directory" side of builtin-clean.c, I had to quickly reach for my barf bag. I never use "git clean" without "-n" and I never ever use "git clean" with "-d"; I do not have any idea what behaviour when given "-d" would be useful. AFAIU, the scripted version did not have clear semantics either. Another thing that irritates me is it talks about not removing a directory when run "git clean -n" (without -d). I did not ask it to remove directories, so I did not expect it to talk about it not doing Thanks for a reminder. Anything else? -
Subject: [PATCH 1/2] Support GIT_PAGER_IN_USE environment variable When deciding whether or not to turn on automatic color support, git_config_colorbool checks whether stdout is a tty. However, because we run a pager, if stdout is not a tty, we must check whether it is because we started the pager. This used to be done by checking the pager_in_use variable. This variable was set only when the git program being run started the pager; there was no way for an external program running git indicate that it had already started a pager. This patch allows a program to set GIT_PAGER_IN_USE to a true value to indicate that even though stdout is not a tty, it is because a pager is being used. Signed-off-by: Jeff King <peff@peff.net> --- A few notes: We could also just put the color.pager logic in git-svn, or in Git.pm, and have it impact the stdout_is_tty argument; but the whole point of --get-colorbool is to consolidate that logic. We convert pager_in_use to a function; we could also just set the variable early on, but I think this lazy evaluation is more robust. This might have uses besides --get-colorbool (e.g., wrapper scripts which start their own pager can still have git sub-commands understand whether to turn on color). cache.h | 2 +- color.c | 2 +- environment.c | 1 - pager.c | 15 ++++++++++++++- 4 files changed, 16 insertions(+), 4 deletions(-) diff --git a/cache.h b/cache.h index 1bcb3df..27d90fe 100644 --- a/cache.h +++ b/cache.h @@ -608,7 +608,7 @@ extern int write_or_whine_pipe(int fd, const void *buf, size_t count, const char /* pager.c */ extern void setup_pager(void); extern char *pager_program; -extern int pager_in_use; +extern int pager_in_use(void); extern int pager_use_color; extern char *editor_program; diff --git a/color.c b/color.c index 7bd424a..7f66c29 100644 --- a/color.c +++ b/color.c @@ -135,7 +135,7 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty) ...
git-config recently learned a --get-colorbool option. By
using it, we will get the same color=auto behavior that
other git commands have.
Specifically, this fixes the case where "color.diff = true"
meant "always" in git-svn, but "auto" in other programs.
Signed-off-by: Jeff King <peff@peff.net>
---
git-svn.perl | 35 ++---------------------------------
1 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 9f884eb..1c42c55 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3969,39 +3969,7 @@ sub cmt_showable {
}
sub log_use_color {
- return 1 if $color;
- my ($dc, $dcvar);
- $dcvar = 'color.diff';
- $dc = `git-config --get $dcvar`;
- if ($dc eq '') {
- # nothing at all; fallback to "diff.color"
- $dcvar = 'diff.color';
- $dc = `git-config --get $dcvar`;
- }
- chomp($dc);
- if ($dc eq 'auto') {
- my $pc;
- $pc = `git-config --get color.pager`;
- if ($pc eq '') {
- # does not have it -- fallback to pager.color
- $pc = `git-config --bool --get pager.color`;
- }
- else {
- $pc = `git-config --bool --get color.pager`;
- if ($?) {
- $pc = 'false';
- }
- }
- chomp($pc);
- if (-t *STDOUT || (defined $pager && $pc eq 'true')) {
- return ($ENV{TERM} && $ENV{TERM} ne 'dumb');
- }
- return 0;
- }
- return 0 if $dc eq 'never';
- return 1 if $dc eq 'always';
- chomp($dc = `git-config --bool --get $dcvar`);
- return ($dc eq 'true');
+ return $color || Git->repository->get_colorbool('color.diff');
}
sub git_svn_log_cmd {
@@ -4060,6 +4028,7 @@ sub config_pager {
} elsif (length $pager == 0 || $pager eq 'cat') {
$pager = undef;
}
+ $ENV{GIT_PAGER_IN_USE} = defined($pager);
}
sub run_pager {
--
1.5.3.7.2230.g796d07-dirty
-
I had the same feeling. I am tempted to leave it, then. The
non-intuitive behavior I managed to trigger was:
- _only_ when using git pathspec matching like "git clean -n '*.ext'"
- confusing in a safe way (trying to remove 'dir.ext' with '*.ext'
will accidentally not happen, rather than accidentally happening)
So unless somebody complains, it is probably not a big problem,
and I think fixing it will require mucking with pathspec and dir
matching internals, which would be nice not to do right before v1.5.4.
OTOH, leaving something that is broken and just hoping nobody will
complain feels kind of wrong. :)
-Peff
-
When you have a trash directory without any tracked files, clean will not by default descend into that directory and thus won't remove neither files nor directory. I frequently use one for automated testing, much like git's trash repository, but the only time I do "git clean -d" is when building things on a release-server with the repository checked out. It's faster than "make distclean", and not all of our projects have a Makefile to begin with. Tacking "git clean -d" at the end of test-scripts makes it simple to remove all excess cruft in one go. So in short, git clean -d can be useful. I have no idea when "git clean dir" would be though. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -
-- >8 --
[PATCH] commit: do not add extra LF at the end of the summary.
The scripted version relied on the nice "auto-strip the terminating LF"
behaviour shell gives to "var=$(cmd)" construct, but we have to roll
that ourselves.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index b6b81d5..e5a972c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,12 +660,17 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
rev.verbose_header = 1;
rev.show_root_diff = 1;
rev.commit_format = get_commit_format("format:%h: %s");
- rev.always_show_header = 1;
+ rev.always_show_header = 0;
printf("Created %scommit ", initial_commit ? "initial " : "");
- log_tree_commit(&rev, commit);
- printf("\n");
+ if (!log_tree_commit(&rev, commit)) {
+ struct strbuf buf = STRBUF_INIT;
+ pretty_print_commit(rev.commit_format, commit, &buf,
+ 0, NULL, NULL, 0, 0);
+ printf("%s\n", buf.buf);
+ strbuf_release(&buf);
+ }
}
int git_commit_config(const char *k, const char *v)
--
1.5.3.7-1149-g591a
-
This looks reasonable and generates the correct output as far as I can We are duplicating the "!shown && ..." conditional branch from log_tree_commit, which calls show_log. Why are we not calling show_log instead of pretty_print_commit (I understand that show_log should end up calling pretty_print_commit, but it is not immediately obvious that all of the extra code in show_log is going to be ignored). -Peff -
Exactly. I think show_log() has become too complex, and when we want a oneline userformat, pretty-print-commit is more appropriate to use. Actually, when I re-review the code, I think the part should use format_commit_message() which is more to the point without any of the other "more generic" parameter pretty-print-commit takes. -
Perhaps it would be even more readable to simply split the printing of the commit message and the diff. Tracking this bug was a bit confusing. Ideally, print_summary would just say: print_commit_message(commit); print_diff(commit, "^commit"); where obviously each of those takes a few lines to say properly. But the use of a combination "show the log and maybe the diff" function seems like a shell holdover, trying to avoid spawning too many processes. -Peff -
Perhaps, but that's post 1.5.4. There is no short-hand to call the
single commit diff-tree and not give any commit header afair.
Anyway, format-commit-message() makes it much more readable ;-)
diff --git a/builtin-commit.c b/builtin-commit.c
index b6b81d5..9cb7589 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -660,12 +660,16 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
rev.verbose_header = 1;
rev.show_root_diff = 1;
rev.commit_format = get_commit_format("format:%h: %s");
- rev.always_show_header = 1;
+ rev.always_show_header = 0;
printf("Created %scommit ", initial_commit ? "initial " : "");
- log_tree_commit(&rev, commit);
- printf("\n");
+ if (!log_tree_commit(&rev, commit)) {
+ struct strbuf buf = STRBUF_INIT;
+ format_commit_message(commit, "%h: %s", &buf);
+ printf("%s\n", buf.buf);
+ strbuf_release(&buf);
+ }
}
int git_commit_config(const char *k, const char *v)
-
This bugfix has been sitting in my repo for a few weeks. When it last appeared, you asked if the other code paths needed a similar fix, and I verified that they did not, so I think it is complete as-is. -- >8 -- git-clone: print an error message when trying to clone empty repo Previously, cloning an empty repository looked like this: $ (mkdir parent && cd parent && git --bare init) $ git-clone parent child Initialized empty Git repository in /home/peff/clone/child/.git/ $ cd child -bash: cd: child: No such file or directory $ echo 'wtf?' | mail git@vger.kernel.org Now we at least report that the clone was not successful. Signed-off-by: Jeff King <peff@peff.net> --- git-clone.sh | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/git-clone.sh b/git-clone.sh index ecf9d89..96a356d 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -297,7 +297,8 @@ yes) find objects -type f -print | sed -e 1q) # objects directory should not be empty because # we are cloning! - test -f "$repo/$sample_file" || exit + test -f "$repo/$sample_file" || + die "fatal: cannot clone empty repository" if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null then rm -f "$GIT_DIR/objects/sample" -- 1.5.3.7.2224.ge4a5 -
Well, with the gcc repo, simply using 'git repack -a -f' with current default window size does produce a 2.1GB pack, while changing the window size to 100 (keeping default delta depth) produces a 400MB pack for me. So this is really a matter of not having a sufficiently large window for This is still on my todo list. Nicolas -
Hi, So my dumb patch to simply default to window and depth 250 with aggressive was not _that_ dumb after all? Ciao, Dscho -
Probably not, although this might be rather wasteful on some repositories. But that's what expectations are for --aggressive. I wish we could find a way to set some good window default dynamically though. Or perhaps the filename hashing needs improvements. Nicolas -
We deprecated it from the very beginning, in the sense that we never wrote into it ourselves, but merely tried to pay attention to what others wrote there. So I am open to a bullet point that officially declares the deprecation. But we need to come up with a removal schedule. Say, the first feature release after June 2008? -
I wouldn't mind dropping this test for now. 100% output compatibility with SVN is too difficult to achieve and IMHO not worth it for commands like `info' and `log'. David: I also noticed some race-conditions on this test when running this on my Centrino laptop (my fastest box, but I rarely use it for git development) and having git on my USB thumb drive. I'm pretty sure these were caused by inconsistencies in handling timestamps on symlinks -- Eric Wong -
I actually saw that for the first time on my primary box during the nightly rebuild last night. I'll disable the test for now --- if we can spot and fix the race by the release, that's good, otherwise, shipping the test disabled is also fine, too. -
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 ...
When recording a merge that conflicted and ends up in no changes after
manual resolution, commit callchain looked like this:
cmd_commit() ->
prepare_log_message() ->
run_status() ->
wt_status_print()
This invocation of run_status() is asked to find out if there is a
committable change, but it unconditionally gave instructions such as
"use git-add" at the same time. When in merge, we do allow an empty
change to be recorded, so after showing this message the code still went
ahead and made a commit.
This introduces "nowarn" parameter to run_status() to avoid these
useless messages. If we are not allowed to create an empty commit, we
already call run_status() again in the original codepath, and the
message will be shown from that call anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 9 +++++----
wt-status.c | 2 ++
wt-status.h | 1 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9cb7589..ad9f921 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -280,7 +280,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)
return false_lock.filename;
}
-static int run_status(FILE *fp, const char *index_file, const char *prefix)
+static int run_status(FILE *fp, const char *index_file, const char *prefix, int nowarn)
{
struct wt_status s;
@@ -296,6 +296,7 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix)
s.untracked = untracked_files;
s.index_file = index_file;
s.fp = fp;
+ s.nowarn = nowarn;
wt_status_print(&s);
@@ -412,7 +413,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
saved_color_setting = wt_status_use_color;
wt_status_use_color = 0;
- commitable = run_status(fp, index_file, prefix);
+ commitable = run_status(fp, index_file, prefix, 1);
wt_status_use_color = saved_color_setting;
...Looks good to me. Acked-by: Jeff King <peff@peff.net> -Peff -
Hmpf. We don't need no double negations, no? -- Hannes -
