* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 23:10 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, git
In-Reply-To: <1260053972.22680.5.camel@denix>
At Sat Dec 05 17:59:32 -0500 2009, Sam Vilain wrote:
> Hi, I've just seen the series, looks like a good idea. Just a couple of
> questions then I'll review the code;
>
> - when a change is merged upstream with svk, you will get multiple log
> entries in a single commit message. What do you do with commits like
> that?
If the user edited the merge message and supplied their own message,
nothing. If the first line is an SVK merge line, it inserts a message
"Merged from /svn/path/to/trunk:12345\n\n" at the top.
> - there are quite a few repos which will have empty commits (ie, no
> changes), but with one or more of the above log entries, owing to a bug
> which I can't seem to find the details of right now.. how might those
> appear?
Without seeing an example, I'm not sure offhand -- but what you're
describing does ring a bell, so I'm sure I've seen the mismerges
you're talking about as well.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [PATCH] cvsserver: make the output of 'update' more compatible with cvs.
From: mmogilvi_git @ 2009-12-05 23:48 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, gitster
In-Reply-To: <87zl5z4y0w.fsf@osv.gnss.ru>
On Thu, Dec 03, 2009 at 11:12:47PM +0300, Sergei Organov wrote:
>
> + my $last_dirname = "///";
> +
> # foreach file specified on the command line ...
> foreach my $filename ( @{$state->{args}} )
> {
> $filename = filecleanup($filename);
> + my $cur_dirname = dirname($filename);
> + if ( $cur_dirname ne $last_dirname )
> + {
> + $last_dirname = $cur_dirname;
> + if ( $cur_dirname eq "" )
> + {
> + $cur_dirname = ".";
> + }
> + print "E cvs update: Updating $cur_dirname\n";
> + }
>
> $log->debug("Processing file $filename");
This should probably be conditional on the absense of the
global "cvs -q update" and "cvs -Q update" options, in case
other CVS clients depend on quiet operation when they specify
those options.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ permalink raw reply
* [PATCH] Allow --quiet option to git remote, particularly for `git remote update`
From: Alex Vandiver @ 2009-12-06 0:00 UTC (permalink / raw)
To: git
Signed-off-by: Alex Vandiver <alex@chmrr.net>
---
builtin-remote.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index a501939..a34006f 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,14 +8,14 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
+ "git remote [-v | --verbose] [-q | --quiet]",
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
"git remote set-head <name> (-a | -d | <branch>)",
"git remote [-v | --verbose] show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
+ "git remote [-v | --verbose] [-q | --quiet] update [-p | --prune] [group]",
NULL
};
@@ -58,7 +58,7 @@ static const char * const builtin_remote_update_usage[] = {
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
-static int verbose;
+static int verbosity;
static int show_all(void);
static int prune_remote(const char *remote, int dry_run);
@@ -84,9 +84,12 @@ static int opt_parse_track(const struct option *opt, const char *arg, int not)
static int fetch_remote(const char *name)
{
const char *argv[] = { "fetch", name, NULL, NULL };
- if (verbose) {
+ if (verbosity > 0) {
argv[1] = "-v";
argv[2] = name;
+ } else if (verbosity < 0) {
+ argv[1] = "-q";
+ argv[2] = name;
}
printf("Updating %s\n", name);
if (run_command_v_opt(argv, RUN_GIT_CMD))
@@ -1236,8 +1239,10 @@ static int update(int argc, const char **argv)
if (prune)
fetch_argv[fetch_argc++] = "--prune";
- if (verbose)
+ if (verbosity > 0)
fetch_argv[fetch_argc++] = "-v";
+ if (verbosity < 0)
+ fetch_argv[fetch_argc++] = "-q";
if (argc < 2) {
fetch_argv[fetch_argc++] = "default";
} else {
@@ -1301,7 +1306,7 @@ static int show_all(void)
sort_string_list(&list);
for (i = 0; i < list.nr; i++) {
struct string_list_item *item = list.items + i;
- if (verbose)
+ if (verbosity > 0)
printf("%s\t%s\n", item->string,
item->util ? (const char *)item->util : "");
else {
@@ -1318,7 +1323,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
+ OPT__VERBOSITY(&verbosity),
OPT_END()
};
int result;
--
1.6.6.rc0.360.gc408
^ permalink raw reply related
* Continued work on sr/vcs-helper and sr/gfi-options
From: Sverre Rabbelier @ 2009-12-06 0:53 UTC (permalink / raw)
To: Junio C Hamano, Git List
Heya,
I'm planning to start finishing up git-remote-hg this week, and for
that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
How can I best go about working on these? I _think_ what I want is to
merge sr/vcs-helper and sr/gfi-options, into either master or next
(with a three-way merge), but I'm not sure? Also, when I try to rebase
sr/vcs-helper onto master I get conflicts yet again, since these were
already resolved in next, what is the best way for me to proceed in
such a way that it is convenient for you (Junio) and the list, if
possible, without having to untangle those merge conflicts.
Thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Continued work on sr/vcs-helper and sr/gfi-options
From: Miklos Vajna @ 2009-12-06 1:05 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Git List
In-Reply-To: <fabb9a1e0912051653s77ba25e1g9ff1e21219cd06c9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Sun, Dec 06, 2009 at 01:53:03AM +0100, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
That part is fairly easy, just don't forget to enable rerere. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Continued work on sr/vcs-helper and sr/gfi-options
From: Junio C Hamano @ 2009-12-06 1:47 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0912051653s77ba25e1g9ff1e21219cd06c9@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I'm planning to start finishing up git-remote-hg this week, and for
> that I need both sr/vcs-helper (in next) and sr/gfi-options (in pu).
> How can I best go about working on these? I _think_ what I want is to
> merge sr/vcs-helper and sr/gfi-options, into either master or next
> (with a three-way merge), but I'm not sure? Also, when I try to rebase
> sr/vcs-helper onto master I get conflicts yet again, since these were
> already resolved in next, what is the best way for me to proceed in
> such a way that it is convenient for you (Junio) and the list, if
> possible, without having to untangle those merge conflicts.
Some observations.
- sr/vcs-helper seems to be near completion; I'd expect it to be among
the first batch of topics to go to 'master' after 1.6.6 final (some
fixes may happen between now and 1.6.6 final to make the series a bit
longer, though).
- sr/gfi-options started moving again and there could be a couple more
iterations before it would hit 'next'.
Until sr/gfi-options becomes more solid, one way we can manage
sr/remote-hg is (thinking aloud):
- Fork sr/remote-hg from today's sr/vcs-helper;
- Merge today's 'master' to sr/remote-hg (optional);
- Whenever any updates to vcs-helper topic appears, apply them to
sr/vcs-helper, and merge the result to sr/remote-hg;
- Create an unstable sr/pu-remote-hg branch that:
- is reset to the tip of sr/remote-hg at the beginning of the day;
- merges the day's sr/gfi-options on top;
- re-applies patches to implement Hg interoperation on top of the
result.
When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
patches we helpd in sr/pu-remote-hg to sr/remote-hg branch. We will merge
early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
and perhaps early parts of individual Hg interoperation patches as well)
to 'next', and remaining parts on the branch to 'pu' (and they can be
replaced).
^ permalink raw reply
* Re: [PATCH] Allow --quiet option to git remote, particularly for `git remote update`
From: Junio C Hamano @ 2009-12-06 2:04 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git
In-Reply-To: <1260057623-28960-1-git-send-email-alex@chmrr.net>
Alex Vandiver <alex@chmrr.net> writes:
> Signed-off-by: Alex Vandiver <alex@chmrr.net>
Sounds good as it makes the behaviour consistent with the underlying "git
fetch".
> ...
> "git remote prune [-n | --dry-run] <name>",
> - "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
> + "git remote [-v | --verbose] [-q | --quiet] update [-p | --prune] [group]",
We say "<name>" everywhere else except for "update" we call the parameter
"group" or "remote" using different typography. It is not the fault of
your patch, but has been this way since 1918278 (Allow git-remote to
update named groups of remotes, 2007-02-20).
Three issues to consider:
- shouldn't we use the same typography, i.e. <group>?
- should we say <name> _if_ we are not going to say <group>|<remote>?
- should we keep it as <group>|<remote> to make it clear that only this
subcommand allows the group nickname?
The first two are easy and I expect the answers to be both yes. The third
one needs some studying and further thought.
- is "remote update" the only one that takes group nickname?
- should "remote update" the only one? e.g. does "remote prune" also
take group? if not, shouldn't it?
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Jeff King @ 2009-12-06 4:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Maarten Lankhorst, git
In-Reply-To: <7vfx7pwa6p.fsf@alter.siamese.dyndns.org>
On Sat, Dec 05, 2009 at 10:24:46AM -0800, Junio C Hamano wrote:
> > ... The test already checks that the change won't break soft reset,
> > which is good, but it does not seem to check/specify what should happen in
> > the mixed reset in this case (I think it should be allowed).
>
> Heh, I was not thinking straight. A bare repository does not have the
> index, so allowing (cd .git && git reset) is Ok but mixed in a bare
> repository (cd bare.git && git reset) is not.
Hmm. I would have thought it would be allowed in a bare repository, to
explicitly let people treat the bare repo as a pseudo-database, just
pulling out the files when they want to. And I was all set to argue
against restricting it, but looking at your tests, it seems we already
disallow it. So I don't see a harm in verifying the current behavior.
-Peff
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Jeff King @ 2009-12-06 4:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Maarten Lankhorst, git
In-Reply-To: <7vocmdutph.fsf@alter.siamese.dyndns.org>
On Sat, Dec 05, 2009 at 11:06:02AM -0800, Junio C Hamano wrote:
> > Junio, I think the following should go to maint (I didn't bother
> > splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
> > we don't care about maint releases that far back).
>
> Although I'll apply your patch to 'maint' and will merge it for 1.6.6, I
> am not quite sure if this is the best fix in the longer run. Shouldn't we
> go back to the top of the work tree and running what was asked there?
I actually considered that, too, when writing the patch. But that would
be inconsistent with all of the other commands that use SETUP_WORK_TREE.
For example:
$ git init && cd .git && git clean
fatal: This operation must be run in a work tree
So I think we are better to be consistent with the other commands. If
somebody wants to make a separate patch to discover the work tree while
in the $GIT_DIR and chdir to it, that should then be applied to all
commands. I'm not opposed to it, but I also don't see it as a
particularly pressing need.
-Peff
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Jeff King @ 2009-12-06 4:22 UTC (permalink / raw)
To: James P. Howard, II; +Cc: git
In-Reply-To: <20091205230903.GA3816@thermopylae.local>
On Sat, Dec 05, 2009 at 06:09:03PM -0500, James P. Howard, II wrote:
> On Sat, Dec 05, 2009 at 11:28:27AM -0500, Jeff King wrote:
>
> > If the latter, I think we would be better served by an option to simply
> > turn off the template. Then that is also helpful for the case of people
> > using decent editors, but who don't want to waste the CPU time on
> > generating the template information (which can be substantial for things
> > like media repositories).
>
> Actually, I find this a reasonable solution for both cases and would be
> willing to reimplment my change this way, as it meets my needs and would
> be useful to others. The only question I have is, what should variable/
> command line option be called?
I would be tempted to call it "--no-template", but I think that is too
confusing. The "--template" option is not really about the git-generated
template, but about a user-defined template that goes on top of the
git-generated one (I would have expected --template=/dev/null to do what
you want, too, but it retains the git template).
Probably "--no-status" would be a good name, as the generated template
is the format generated by "git status".
-Peff
^ permalink raw reply
* clang static analyzer
From: Tomas Carnecky @ 2009-12-06 6:11 UTC (permalink / raw)
To: git list
There have been several attempts at running the clang static analyzer on the git source code, some even resulted in patches. I tried it, too, and among the many false positives I think clang found a few real issues. The results can be seen at [1].
Clang again found many dead assignments/increments, but in the earlier discussions you concluded that you want to keep those around. So I focussed on another class of potential bugs: Argument with 'nonnull' attribute passed null. There were a total of seven such issues. I then tried to look through the code and see if they are valid or false positives:
xdiff-interface.c:xdiff_set_find_func() - When 'value' is a string with no newline character in it, the loop at line 291 sets 'value' to NULL on its first iteration and then passes 'value' to strchr() in the second iteration.
utf8.c:utf8_strwidth() - 'string' may be set to NULL in utf8_width() which makes this one a false positive.
pretty.c:get_header() - if 'line' doesn't contain a newline character, line is set to NULL on first iteration and then passed to strchr() in the second itration.
attr.c:prepare_attr_stack() - bootstrap_attr_stack() sets attr_stack so this one is a false positive as well.
test-parse-options.c:length_callback() - if arg == NULL and unset == 0 then the function passes NULL to strlen().
builtin-pack-objects.c:check_pbase_path() - false positive, if done_pbase_paths == NULL then also done_pbase_paths_alloc == 0 and so step 4 can't take the false branch.
builtin-ls-files.c:verify_pathspec() - false positive, pathspec is not NULL when the function is called.
- Some of the issues might be purely hypothetical, for example I don't know if it's possible that get_header() can be passed a string with no newlines, maybe this is prevented earlier in the code path.
- Some of the false positives (such as the last one) could be avoided by giving clang a hint that a certain variable can't be NULL (by using assert() or if (!foo) return).
tom
[1] http://78.46.209.101/stuff/clang-static-analyzer/git/v1.6.6-rc1-32-g97f3d79/
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-06 6:37 UTC (permalink / raw)
To: David Aguilar, Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <20091205204455.GA49665@gmail.com>
Hi, yes..Cheetah has more feature set. Have to give a try once.
I really don't know the diff of Cheetah and Tortise. Want to know more
on Cheetah...any links would help. Some time back when googled all
resulted in Tortise.
On 12/6/09, David Aguilar <davvid@gmail.com> wrote:
> On Sat, Dec 05, 2009 at 10:02:08PM +0530, Dilip M wrote:
>> On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
>>
>> > As for "missing", do you refer to "paid service", or "yet another GUI"?
>>
>> Ahaha! I can say "a good gui" :)
>>
>> I was not knowing that this was "paid service". I saw the screenshot
>> and tried it. No doubt, it has a _great_ ui interface. While installation
>> I
>> realized that it is licensed.
>>
>> - SOFTWARE Non-Commercial License,
>> - SOFTWARE Commercial License,
>> - SOFTWARE Enterprise License.
>
>
> Aside from the other good GUIs out there, have you tried
> git-cola?
>
> http://cola.tuxfamily.org/
>
> It's GPL and not too shabby.
> The screenshots on the webpage are a bit out of date, though.
> I should probably get to writing the release announcment and
> updating the screenshots ;)
>
> It probably also depends on your platform of choice.
> I know some Windows users like explorer-integration, so stuff
> like git-cheetah make a lot of sense for them. I was a little
> sad to see that the tortoise-git guys didn't get the joke
> (who wants a tortoise when you have a cheetah?) and didn't
> just work on cheetah instead, but hey, it's all good.
>
> Another example: eclipse users like eclipse integration so for
> them egit makes perfect sense.
>
> Maybe that makes git-cola the poor man's smartgit?
> If that's the case then it looks like the poor man is still
> winning according to the feature matrix on the git wiki ;)
> I don't know.. I haven't used smartgit, but if there are
> any features that people are itching to have that git-cola
> doesn't then feel free to throw it on the backlog:
>
> http://github.com/davvid/git-cola/issues
>
> At first glance, the gitk-like history widget in smartgit
> is very nice. I've been thinking about how to implement that in
> PyQt for a while but haven't yet hammered it out.
>
>
> Have fun,
>
> --
> David
>
--
Sent from my mobile device
Dilip
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-06 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Maarten Lankhorst, git
In-Reply-To: <20091206041839.GB23983@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I actually considered that, too, when writing the patch. But that would
> be inconsistent with all of the other commands that use SETUP_WORK_TREE.
> For example:
>
> $ git init && cd .git && git clean
> fatal: This operation must be run in a work tree
>
> So I think we are better to be consistent with the other commands. If
> somebody wants to make a separate patch to discover the work tree while
> in the $GIT_DIR and chdir to it, that should then be applied to all
> commands. I'm not opposed to it, but I also don't see it as a
> particularly pressing need.
Yes, we would of course want to do this consistently. I haven't followed
the codepath yet, but I suspect this will end up being connected with
running "rev-parse --show-cdup" inside .git/ of a non-bare repository.
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Junio C Hamano @ 2009-12-06 8:01 UTC (permalink / raw)
To: Jeff King; +Cc: James P. Howard, II, git
In-Reply-To: <20091206042206.GC23983@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I would be tempted to call it "--no-template", but I think that is too
> confusing. The "--template" option is not really about the git-generated
> template, but about a user-defined template that goes on top of the
> git-generated one (I would have expected --template=/dev/null to do what
> you want, too, but it retains the git template).
>
> Probably "--no-status" would be a good name, as the generated template
> is the format generated by "git status".
I wonder which part is the most expensive in generating the status
output. Perhaps -suno is sufficient?
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.5
From: Junio C Hamano @ 2009-12-06 8:06 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.5.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.5.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.5-1.fc11.$arch.rpm (RPM)
This is primarily to help other distros with older xmlto to partially
revert the change in 1.6.5.4 to help distros with newer docbook
stylesheets, but I also merged some fixes that have already been cooking
and graduated to 'master' as well.
Git v1.6.5.5 Release Notes
==========================
Fixes since v1.6.5.4
--------------------
* Manual pages can be formatted with older xmlto again.
* GREP_OPTIONS exported from user's environment could have broken
our scripted commands.
* In configuration files, a few variables that name paths can begin with
~/ and ~username/ and they are expanded as expected. This is not a
bugfix but 1.6.6 will have this and without backporting users cannot
easily use the same ~/.gitconfig across versions.
* "git diff -B -M" did the same computation to hash lines of contents
twice, and held onto memory after it has used the data in it
unnecessarily before it freed.
* "git diff -B" and "git diff --dirstat" was not counting newly added
contents correctly.
* "git format-patch revisions... -- path" issued an incorrect error
message that suggested to use "--" on the command line when path
does not exist in the current work tree (it is a separate matter if
it makes sense to limit format-patch with pathspecs like that
without using the --full-diff option).
* "git grep -F -i StRiNg" did not work as expected.
* Enumeration of available merge strategies iterated over the list of
commands in a wrong way, sometimes producing an incorrect result.
* "git shortlog" did not honor the "encoding" header embedded in the
commit object like "git log" did.
* Reading progress messages that come from the remote side while running
"git pull" is given precedence over reading the actual pack data to
prevent garbled progress message on the user's terminal.
* "git rebase" got confused when the log message began with certain
strings that looked like Subject:, Date: or From: header.
* "git reset" accidentally run in .git/ directory checked out the
work tree contents in there.
Other minor documentation updates are included.
----------------------------------------------------------------
Changes since v1.6.5.4 are as follows:
Avery Pennarun (1):
builtin-merge.c: call exclude_cmds() correctly.
Brandon Casey (1):
t4201: use ISO8859-1 rather than ISO-8859-1
Brian Collins (1):
grep: Allow case insensitive search of fixed-strings
Felipe Contreras (2):
format-patch: fix parsing of "--" on the command line
format-patch: add test for parsing of "--"
Jeff King (4):
diffcore-break: free filespec data as we go
diffcore-break: save cnt_data for other phases
rerere: don't segfault on failure to open rr-cache
reset: improve worktree safety valves
Junio C Hamano (7):
diffcore-rename: reduce memory footprint by freeing blob data early
Documentation: avoid xmlto input error
Protect scripted Porcelains from GREP_OPTIONS insanity
Remove dead code from "git am"
Documentation: xmlto 0.0.18 does not know --stringparam
Prepare for 1.6.5.5
Git 1.6.5.5
Linus Torvalds (1):
Fix diff -B/--dirstat miscounting of newly added contents
Lukas Sandström (1):
git am/mailinfo: Don't look at in-body headers when rebasing
Matthew Ogilvie (1):
core.autocrlf documentation: mention the crlf attribute
Matthieu Moy (4):
Expand ~ and ~user in core.excludesfile, commit.template
expand_user_path: expand ~ to $HOME, not to the actual homedir.
merge-recursive: point the user to commit when file would be overwritten.
user-manual: Document that "git merge" doesn't like uncommited changes.
Nicolas Pitre (1):
give priority to progress messages
Philippe Bruhat (1):
Make sure $PERL_PATH is defined when the test suite is run.
Raman Gupta (1):
Add branch management for releases to gitworkflows
Ramsay Allan Jones (3):
Makefile: merge two Cygwin configuration sections into one
t9700-perl-git.sh: Fix a test failure on Cygwin
git-count-objects: Fix a disk-space under-estimate on Cygwin
René Scharfe (2):
mergetool--lib: simplify guess_merge_tool()
archive: clarify description of path parameter
Tim Henigan (2):
Update 'git remote update' usage string to match man page.
git remote: Separate usage strings for subcommands
Todd Zullinger (1):
Documentation: Avoid use of xmlto --stringparam
Uwe Kleine-König (1):
shortlog: respect commit encoding
^ permalink raw reply
* [PATCHv3 (resend) 0/3] git-gui: more robust handling of fancy repos
From: Giuseppe Bilotta @ 2009-12-06 8:06 UTC (permalink / raw)
To: git; +Cc: Markus Heidelberg, Shawn O. Pearce, Giuseppe Bilotta
This is a resend with the patches rebased on current 'next'.
The first patch allows git gui to work with respotiories for which
the worktree is not the parent of the gitdir.
The second patch refactors bare repository detection, improves the error
message if the bare support feature is disabled, and disabled
inapplicable menu entries.
The third patch allows git-gui to work properly when launched from the
.git directory itself, solving the issue Markus Heidelberg was having in
http://thread.gmane.org/gmane.comp.version-control.git/115044
Giuseppe Bilotta (3):
git-gui: handle non-standard worktree locations
git-gui: handle bare repos correctly
git-gui: work from the .git dir
git-gui/git-gui.sh | 88 +++++++++++++++++++++++++++++++++++++++++++---------
1 files changed, 73 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCHv3 (resend) 1/3] git-gui: handle non-standard worktree locations
From: Giuseppe Bilotta @ 2009-12-06 8:06 UTC (permalink / raw)
To: git; +Cc: Markus Heidelberg, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1260086801-4331-1-git-send-email-giuseppe.bilotta@gmail.com>
Don't rely on the git worktree being the updir of the gitdir, since it
might not be. Instead, define (and use) a new _gitworktree global
variable, setting it to $GIT_WORK_TREE if present, falling back to
core.worktree if defined, and finally to whatever we guess the correct
worktree is. Getting core.worktree requires the config from the alleged
git dir _gitdir to be loaded early.
Supporting non-standard worktree locations also breaks the git-gui
assumption (made when calling gitk) that the worktree was the dirname of
$_gitdir and that, by consequence, the git dir could be set to the tail
of $_gitdir once we changed to the worktree root directory. Therefore,
we need to export a GIT_DIR environment variable set to the full,
normalized path of $_gitdir instead. We also skip changing to the worktree
directory if it's empty (i.e. if we're working on a bare repository).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-gui/git-gui.sh | 37 ++++++++++++++++++++++++++++---------
1 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 037a1f2..fc766ca 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -121,6 +121,7 @@ unset oguimsg
set _appname {Git Gui}
set _gitdir {}
+set _gitworktree {}
set _gitexec {}
set _githtmldir {}
set _reponame {}
@@ -1090,13 +1091,25 @@ if {![file isdirectory $_gitdir]} {
error_popup [strcat [mc "Git directory not found:"] "\n\n$_gitdir"]
exit 1
}
+# _gitdir exists, so try loading the config
+load_config 0
+apply_config
+# try to set work tree from environment, falling back to core.worktree
+if {[catch { set _gitworktree $env(GIT_WORK_TREE) }]} {
+ set _gitworktree [get_config core.worktree]
+}
if {$_prefix ne {}} {
- regsub -all {[^/]+/} $_prefix ../ cdup
+ if {$_gitworktree eq {}} {
+ regsub -all {[^/]+/} $_prefix ../ cdup
+ } else {
+ set cdup $_gitworktree
+ }
if {[catch {cd $cdup} err]} {
catch {wm withdraw .}
error_popup [strcat [mc "Cannot move to top of working directory:"] "\n\n$err"]
exit 1
}
+ set _gitworktree [pwd]
unset cdup
} elseif {![is_enabled bare]} {
if {[lindex [file split $_gitdir] end] ne {.git}} {
@@ -1104,11 +1117,15 @@ if {$_prefix ne {}} {
error_popup [strcat [mc "Cannot use funny .git directory:"] "\n\n$_gitdir"]
exit 1
}
- if {[catch {cd [file dirname $_gitdir]} err]} {
+ if {$_gitworktree eq {}} {
+ set _gitworktree [file dirname $_gitdir]
+ }
+ if {[catch {cd $_gitworktree} err]} {
catch {wm withdraw .}
- error_popup [strcat [mc "No working directory"] " [file dirname $_gitdir]:\n\n$err"]
+ error_popup [strcat [mc "No working directory"] " $_gitworktree:\n\n$err"]
exit 1
}
+ set _gitworktree [pwd]
}
set _reponame [file split [file normalize $_gitdir]]
if {[lindex $_reponame end] eq {.git}} {
@@ -1921,6 +1938,7 @@ proc incr_font_size {font {amt 1}} {
set starting_gitk_msg [mc "Starting gitk... please wait..."]
proc do_gitk {revs} {
+ global _gitworktree
# -- Always start gitk through whatever we were loaded with. This
# lets us bypass using shell process on Windows systems.
#
@@ -1938,8 +1956,10 @@ proc do_gitk {revs} {
}
set pwd [pwd]
- cd [file dirname [gitdir]]
- set env(GIT_DIR) [file tail [gitdir]]
+ if { $_gitworktree ne {} } {
+ cd $_gitworktree
+ }
+ set env(GIT_DIR) [file normalize [gitdir]]
eval exec $cmd $revs &
@@ -1958,6 +1978,7 @@ proc do_gitk {revs} {
}
proc do_explore {} {
+ global _gitworktree
set explorer {}
if {[is_Cygwin] || [is_Windows]} {
set explorer "explorer.exe"
@@ -1967,7 +1988,7 @@ proc do_explore {} {
# freedesktop.org-conforming system is our best shot
set explorer "xdg-open"
}
- eval exec $explorer [list [file nativename [file dirname [gitdir]]]] &
+ eval exec $explorer $_gitworktree &
}
set is_quitting 0
@@ -2326,8 +2347,6 @@ proc show_less_context {} {
##
## ui construction
-load_config 0
-apply_config
set ui_comm {}
# -- Menu Bar
@@ -3365,7 +3384,7 @@ unset i
set file_lists($ui_index) [list]
set file_lists($ui_workdir) [list]
-wm title . "[appname] ([reponame]) [file normalize [file dirname [gitdir]]]"
+wm title . "[appname] ([reponame]) [file normalize $_gitworktree]"
focus -force $ui_comm
# -- Warn the user about environmental problems. Cygwin's Tcl
--
1.6.5.4
^ permalink raw reply related
* [PATCHv3 (resend) 3/3] git-gui: work from the .git dir
From: Giuseppe Bilotta @ 2009-12-06 8:06 UTC (permalink / raw)
To: git; +Cc: Markus Heidelberg, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1260086801-4331-1-git-send-email-giuseppe.bilotta@gmail.com>
When git-gui is run from a .git dir, _gitdir would be set to "." by
rev-parse, something that confuses the worktree detection.
Fix by expanding the value of _gitdir to pwd in this special case.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-gui/git-gui.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 99ca4c0..0497e38 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1102,6 +1102,8 @@ if {[catch {
set _prefix {}
}]
&& [catch {
+ # beware that from the .git dir this sets _gitdir to .
+ # and _prefix to the empty string
set _gitdir [git rev-parse --git-dir]
set _prefix [git rev-parse --show-prefix]
} err]} {
@@ -1110,6 +1112,14 @@ if {[catch {
choose_repository::pick
set picked 1
}
+
+# we expand the _gitdir when it's just a single dot (i.e. when we're being
+# run from the .git dir itself) lest the routines to find the worktree
+# get confused
+if {$_gitdir eq "."} {
+ set _gitdir [pwd]
+}
+
if {![file isdirectory $_gitdir] && [is_Cygwin]} {
catch {set _gitdir [exec cygpath --windows $_gitdir]}
}
--
1.6.5.4
^ permalink raw reply related
* [PATCHv3 (resend) 2/3] git-gui: handle bare repos correctly
From: Giuseppe Bilotta @ 2009-12-06 8:06 UTC (permalink / raw)
To: git; +Cc: Markus Heidelberg, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1260086801-4331-1-git-send-email-giuseppe.bilotta@gmail.com>
Refactor checking for a bare repository into its own proc, that relies
on git rev-parse --is-bare-repository if possible. For older versions of
git we fall back to a logic such that the repository is considered bare
if:
* either the core.bare setting is true
* or the worktree is not set and the directory name ends with .git
The error message for the case of an unhandled bare repository is also
updated to reflect the fact that the problem is not the funny name but
the bareness.
The new refactored proc is also used to disable the menu entry to
explore the working copy, and to skip changing to the worktree before
the gitk invocation.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
git-gui/git-gui.sh | 43 ++++++++++++++++++++++++++++++++++++-------
1 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index fc766ca..99ca4c0 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -122,6 +122,7 @@ unset oguimsg
set _appname {Git Gui}
set _gitdir {}
set _gitworktree {}
+set _isbare {}
set _gitexec {}
set _githtmldir {}
set _reponame {}
@@ -277,6 +278,32 @@ proc get_config {name} {
}
}
+proc is_bare {} {
+ global _isbare
+ global _gitdir
+ global _gitworktree
+
+ if {$_isbare eq {}} {
+ if {[catch {
+ set _bare [git rev-parse --is-bare-repository]
+ switch -- $_bare {
+ true { set _isbare 1 }
+ false { set _isbare 0}
+ default { throw }
+ }
+ }]} {
+ if {[is_config_true core.bare]
+ || ($_gitworktree eq {}
+ && [lindex [file split $_gitdir] end] ne {.git})} {
+ set _isbare 1
+ } else {
+ set _isbare 0
+ }
+ }
+ }
+ return $_isbare
+}
+
######################################################################
##
## handy utils
@@ -1112,9 +1139,9 @@ if {$_prefix ne {}} {
set _gitworktree [pwd]
unset cdup
} elseif {![is_enabled bare]} {
- if {[lindex [file split $_gitdir] end] ne {.git}} {
+ if {[is_bare]} {
catch {wm withdraw .}
- error_popup [strcat [mc "Cannot use funny .git directory:"] "\n\n$_gitdir"]
+ error_popup [strcat [mc "Cannot use bare repository:"] "\n\n$_gitdir"]
exit 1
}
if {$_gitworktree eq {}} {
@@ -1956,7 +1983,7 @@ proc do_gitk {revs} {
}
set pwd [pwd]
- if { $_gitworktree ne {} } {
+ if { ![is_bare] } {
cd $_gitworktree
}
set env(GIT_DIR) [file normalize [gitdir]]
@@ -2378,10 +2405,12 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
#
menu .mbar.repository
-.mbar.repository add command \
- -label [mc "Explore Working Copy"] \
- -command {do_explore}
-.mbar.repository add separator
+if {![is_bare]} {
+ .mbar.repository add command \
+ -label [mc "Explore Working Copy"] \
+ -command {do_explore}
+ .mbar.repository add separator
+}
.mbar.repository add command \
-label [mc "Browse Current Branch's Files"] \
--
1.6.5.4
^ permalink raw reply related
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Giuseppe Bilotta @ 2009-12-06 8:14 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Markus Heidelberg, Shawn O. Pearce
In-Reply-To: <36ca99e90910270435h69c1e983j78ff9ec49e7e8eae@mail.gmail.com>
On Tue, Oct 27, 2009 at 12:35 PM, Bert Wesarg
<bert.wesarg@googlemail.com> wrote:
>
> I would also suggest to always export GIT_DIR into the environment, so
> that guitools can relay on this.
I'm sorry I couldn't reply to this email earlier. I have never used
this feature, but if you can provide some example guitools
configuration I'll gladly move the environment export earlier and test
it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #02; Sat, 05)
From: Junio C Hamano @ 2009-12-06 8:17 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* "git send-email" won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* "git status" won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
* "git diff -w/-b" won't even produce "diff --git" header when all changes
are about whitespaces.
http://thread.gmane.org/gmane.comp.version-control.git/133256
--------------------------------------------------
[New Topics]
Note: Ilari's vcs-helper series hasn't been queued yet, as its first round
generated a healthy amount of discussion and he made it clear that the
second round is being prepared, addressing the comments given on the list.
Hopefully trivial coding style issues in the first round will also be
fixed (e.g. keyword "if" lacked a SP after it before opening parenthesis
of the condition) in the second round.
* jn/maint-pull-rebase-error-message (2009-11-27) 1 commit.
(merged to 'next' on 2009-12-03 at 2ced03c)
+ pull: clarify advice for the unconfigured error case
Replaces old 'jn/rfc-pull-rebase-error-message' topic.
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* mh/rebase-fixup (2009-12-05) 4 commits
- [squash to Add a command "fix"] Avoid "\(alternatives\|choices\)" in sed script
- Add a command "fix" to rebase --interactive.
- t3404: set a couple more tags in the original repository
- t3404: Better document the original repository layout
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* jh/notes (2009-12-02) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation
Rerolled (waiting for Acks).
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh. We won't have a
proper fix in 1.6.6.
* jc/grep-full-tree (2009-11-24) 1 commit.
- grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
--------------------------------------------------
[Cooking]
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
Rerolled.
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
Rerolled.
* tr/http-updates (2009-12-01) 3 commits
- Allow curl to rewind the RPC read buffer
- Add an option for using any HTTP authentication scheme, not only basic
- http: maintain curl sessions
There was a discussion on a better structure not to require rewinding in
the first place? I didn't follow it closely...
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This is to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens.
* sr/vcs-helper (2009-12-04) 13 commits
(merged to 'next' on 2009-12-03 at e45b562)
+ builtin-push: don't access freed transport->url
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
Should be among the first to graduate after 1.6.6 final.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
* nd/sparse (2009-11-25) 20 commits.
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
There were some test glitches reported and at least one test seems to
be broken in the sense that it is not testing what it is trying to.
Fix-up expected.
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-12-05) 9 commits.
(merged to 'next' on 2009-12-05 at 44dcefd)
+ status -s: obey color.status
+ builtin-commit: refactor short-status code into wt-status.c
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that will disappear soon.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
As the title says.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits.
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
--------------------------------------------------
[I have been too busy to purge these]
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
. git-pull.sh --rebase: overhaul error handling when no candidates are found
Replaced.
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
. git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. It appears nobody wants to have this, so I dropped it.
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: Continued work on sr/vcs-helper and sr/gfi-options
From: Sverre Rabbelier @ 2009-12-06 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vr5r8oov1.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Dec 6, 2009 at 02:47, Junio C Hamano <gitster@pobox.com> wrote:
> - sr/vcs-helper seems to be near completion; I'd expect it to be among
> the first batch of topics to go to 'master' after 1.6.6 final (some
> fixes may happen between now and 1.6.6 final to make the series a bit
> longer, though).
*nod*.
> - sr/gfi-options started moving again and there could be a couple more
> iterations before it would hit 'next'.
Yup, I'm hoping for a review by Shawn and the vcs list.
> Until sr/gfi-options becomes more solid, one way we can manage
> sr/remote-hg is (thinking aloud):
>
> - Fork sr/remote-hg from today's sr/vcs-helper;
That makes sense, this way I don't have to re-resolve those merge
conflicts either.
> - Merge today's 'master' to sr/remote-hg (optional);
I'm not sure why this is though? (no objections against it, I just
don't understand the motivation)
> - Whenever any updates to vcs-helper topic appears, apply them to
> sr/vcs-helper, and merge the result to sr/remote-hg;
*nod*
> - Create an unstable sr/pu-remote-hg branch that:
>
> - is reset to the tip of sr/remote-hg at the beginning of the day;
> - merges the day's sr/gfi-options on top;
> - re-applies patches to implement Hg interoperation on top of the
> result.
Ok, that does make sense, how would I send out patches for review from
this unstable branch though? (since others would not have the required
merges etc) I reckon it would be necessary to publish sr/pu-remote-hg
somewhere?
> When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
> get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
> patches we helpd in sr/pu-remote-hg to sr/remote-hg branch. We will merge
> early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
> and perhaps early parts of individual Hg interoperation patches as well)
> to 'next', and remaining parts on the branch to 'pu' (and they can be
> replaced).
Luckily the remote-hg patch is just that, a single patch. I've already
put all the other work that's needed into sr/vcs-helper and
sr/gfi-options.
Thank you for the detailed explanation :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Bert Wesarg @ 2009-12-06 12:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg, Shawn O. Pearce
In-Reply-To: <cb7bb73a0912060014p548884e0g8c4510a5b562901b@mail.gmail.com>
On Sun, Dec 6, 2009 at 09:14, Giuseppe Bilotta
<giuseppe.bilotta@gmail.com> wrote:
> On Tue, Oct 27, 2009 at 12:35 PM, Bert Wesarg
> <bert.wesarg@googlemail.com> wrote:
>>
>> I would also suggest to always export GIT_DIR into the environment, so
>> that guitools can relay on this.
>
> I'm sorry I couldn't reply to this email earlier. I have never used
> this feature, but if you can provide some example guitools
> configuration I'll gladly move the environment export earlier and test
> it.
Here it is:
[guitool "exclude/Ignore file"]
cmd = echo \"$FILENAME\" >> \"${GIT_DIR:=.git}/info/exclude\"
noconsole = yes
needsfile = yes
The purpose is simple: add the current file to the info/exclude file
in the git dir As you can see, I have a workaround for not having
GIT_DIR in the env, which should solve the issue. But it would be nice
to rely on this.
Bert
>
> --
> Giuseppe "Oblomov" Bilotta
>
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Jeff King @ 2009-12-06 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James P. Howard, II, git
In-Reply-To: <7v7ht0jzta.fsf@alter.siamese.dyndns.org>
On Sun, Dec 06, 2009 at 12:01:53AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I would be tempted to call it "--no-template", but I think that is too
> > confusing. The "--template" option is not really about the git-generated
> > template, but about a user-defined template that goes on top of the
> > git-generated one (I would have expected --template=/dev/null to do what
> > you want, too, but it retains the git template).
> >
> > Probably "--no-status" would be a good name, as the generated template
> > is the format generated by "git status".
>
> I wonder which part is the most expensive in generating the status
> output. Perhaps -suno is sufficient?
Speaking from my experience, it is doing break and rename detection on
large files, which there is currently no way to turn off (I hacked
around it with "$EDITOR msg && git commit --quiet -F msg").
Keep in mind this is one of my gigantic photo repositories, and the
commit in question made a minor change to almost 3G worth of files. So
it is not the end of the world for me to use the hack above on those
rare occasions. But since James wants it for other reasons, and it
should be a trivial patch, I think it would be nice for commit to
support it natively.
It would also make sense to me for "--quiet" to suppress the template,
but that is a behavior change that I suppose some people might not like.
-Peff
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Giuseppe Bilotta @ 2009-12-06 13:43 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, Markus Heidelberg, Shawn O. Pearce
In-Reply-To: <36ca99e90912060459u1073288bj2114f8ab56c7224b@mail.gmail.com>
On Sun, Dec 6, 2009 at 1:59 PM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> Here it is:
>
> [guitool "exclude/Ignore file"]
> cmd = echo \"$FILENAME\" >> \"${GIT_DIR:=.git}/info/exclude\"
> noconsole = yes
> needsfile = yes
>
> The purpose is simple: add the current file to the info/exclude file
> in the git dir As you can see, I have a workaround for not having
> GIT_DIR in the env, which should solve the issue. But it would be nice
> to rely on this.
Yup. I'm thinking about setting both $GIT_DIR and $GIT_WORK_TREE once
and for all at the end of the repo setup. This should also spare us
setting it up specifically for gitk (and then separately for the
tools). The question is: should it be done the way it's done for gitk
(i.e. normalizing the paths), or just use it as-is? In the latter
case, the question would be why is the path being normalized before
gitk is invoked.
Ideas?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox