* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Christoph Haas @ 2009-09-05 13:07 UTC (permalink / raw)
To: git
In-Reply-To: <20090904234552.GA43797@gmail.com>
David Aguilar schrieb:
> On Fri, Sep 04, 2009 at 10:28:36PM +0200, Christoph Haas wrote:
>> Now I imported a new upstream version into the upstream branch. And then
>> tried to merge the 'upstream' branch into the 'master' branch to work on
>> it. And suddenly I get this error:
>>
>> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
>> Cannot merge.
>>
>> To reproduce my problem:
>>
>> $> git clone git://git.workaround.org/cream
>> $> cd cream
>> $> git merge origin/upstream
>> error: Entry 'cream-abbr-eng.vim' would be overwritten by merge.
>> Cannot merge.
>> fatal: merging of trees 70008c82f82a7985531aa2d039c03fdf944ea267 and
>> 78d3a35e300434d6369424dd873bb587beacfaa4 failed
>
> Very odd indeed!
>
> $ git version
> git version 1.6.4.2.264.g79b4f
>
> I was able to workaround it:
>
> $ rm *
> $ git add -u
> $ git merge origin/upstream
Thank you. I had to "rm -r addons", too, but the general hint helped me
a lot.
> I've never run into this before.
> I think it has to do with all the renamed files.
> It looks like you're running into ain unfortunate edge case.
Actually I'm not aware of any renames. But I don't claim that I always
know what I'm doing. :)
> Does anyone else on the list have any insights?
I'd be curious, too.
Kindly
Christoph
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Michael J Gruber @ 2009-09-05 12:51 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Howard Miller, git@vger.kernel.org
In-Reply-To: <40aa078e0909041011s7639cccbqa758f17a56c61863@mail.gmail.com>
Erik Faye-Lund venit, vidit, dixit 04.09.2009 19:11:
> On Fri, Sep 4, 2009 at 6:19 PM, Michael J
> Gruber<git@drmicha.warpmail.net> wrote:
>> Let's say "geesh" is the branch on which you committed by mistake, and
>> which you have reset.
>>
>> git reflog geesh
>
> That should be "git reflog show geesh", no?
>
Yes, sorry. "show" is default, but only without a branch arg :|
Michael
^ permalink raw reply
* [PATCH 2/2] add 'scope' config option
From: Clemens Buchacher @ 2009-09-05 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905123117.GA3099@darc.dnsalias.org>
Documentation/config.txt says it all.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/config.txt | 6 ++++++
builtin-add.c | 2 +-
builtin-grep.c | 2 +-
cache.h | 1 +
config.c | 8 ++++++++
environment.c | 1 +
6 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..f587cf1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -439,6 +439,12 @@ On some file system/operating system combinations, this is unreliable.
Set this config setting to 'rename' there; However, This will remove the
check that makes sure that existing object files will not get overwritten.
+core.scope::
+ By default, the commands 'git add -u', 'git add -A' and 'git grep'
+ are limited to files below the current working directory
+ (scope='workdir'). Set this variable to scope='global' to make these
+ commands act on the whole tree instead.
+
add.ignore-errors::
Tells 'git-add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
diff --git a/builtin-add.c b/builtin-add.c
index 006fd08..33ea3e4 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -285,7 +285,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if ((addremove || take_worktree_changes) && !argc) {
+ if (!scope_global && (addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
diff --git a/builtin-grep.c b/builtin-grep.c
index f6af3d4..447b195 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -861,7 +861,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (!scope_global && prefix) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
diff --git a/cache.h b/cache.h
index 5fad24c..85c5fee 100644
--- a/cache.h
+++ b/cache.h
@@ -523,6 +523,7 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
+extern int scope_global;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/config.c b/config.c
index e87edea..8dec019 100644
--- a/config.c
+++ b/config.c
@@ -503,6 +503,14 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.scope")) {
+ if (!strcasecmp(value, "global"))
+ scope_global = 1;
+ if (!strcasecmp(value, "worktree"))
+ scope_global = 0;
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5de6837..4d1c6e1 100644
--- a/environment.c
+++ b/environment.c
@@ -50,6 +50,7 @@ enum push_default_type push_default = PUSH_DEFAULT_MATCHING;
#endif
enum object_creation_mode object_creation_mode = OBJECT_CREATION_MODE;
int grafts_replace_parents = 1;
+int scope_global = 0;
/* Parallel index stat data preload? */
int core_preload_index = 0;
--
1.6.4.2.264.g79b4f
^ permalink raw reply related
* [PATCH 1/2] grep: accept relative paths outside current working directory
From: Clemens Buchacher @ 2009-09-05 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v3a717rgl.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:58:50AM -0700, Junio C Hamano wrote:
> >> If "git add -u ../.." (I mean "the grand parent directory", not "an
> >> unnamed subdirectory") did not work
I just noticed that this doesn't work with grep. In git.git:
$ cd t
$ git grep addremove -- ../
fatal: git grep: cannot generate relative filenames containing '..'
So here's a fix for that. And a configurable solution for add and grep's
scope as a follow-up. I did not look at any other commands yet.
Clemens
--o<--
Previously, "git grep" would bark at relative paths pointing outside
the current working directory (or subdirectories thereof). We already
have quote_path_relative(), which can handle such cases just fine. So
use that instead.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
builtin-grep.c | 44 ++++++++++++++------------------------------
grep.h | 1 +
2 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ad0e0a5..f6af3d4 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -13,6 +13,7 @@
#include "parse-options.h"
#include "userdiff.h"
#include "grep.h"
+#include "quote.h"
#ifndef NO_EXTERNAL_GREP
#ifdef __unix__
@@ -152,40 +153,27 @@ static int pathspec_matches(const char **paths, const char *name, int max_depth)
return 0;
}
-static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *name, int tree_name_len)
+static int grep_sha1(struct grep_opt *opt, const unsigned char *sha1, const char *path, int tree_name_len)
{
unsigned long size;
char *data;
enum object_type type;
- char *to_free = NULL;
int hit;
+ struct strbuf pathbuf = STRBUF_INIT;
data = read_sha1_file(sha1, &type, &size);
if (!data) {
- error("'%s': unable to read %s", name, sha1_to_hex(sha1));
+ error("'%s': unable to read %s", path, sha1_to_hex(sha1));
return 0;
}
if (opt->relative && opt->prefix_length) {
- static char name_buf[PATH_MAX];
- char *cp;
- int name_len = strlen(name) - opt->prefix_length + 1;
-
- if (!tree_name_len)
- name += opt->prefix_length;
- else {
- if (ARRAY_SIZE(name_buf) <= name_len)
- cp = to_free = xmalloc(name_len);
- else
- cp = name_buf;
- memcpy(cp, name, tree_name_len);
- strcpy(cp + tree_name_len,
- name + tree_name_len + opt->prefix_length);
- name = cp;
- }
+ quote_path_relative(path + tree_name_len, -1, &pathbuf, opt->prefix);
+ strbuf_insert(&pathbuf, 0, path, tree_name_len);
+ path = pathbuf.buf;
}
- hit = grep_buffer(opt, name, data, size);
+ hit = grep_buffer(opt, path, data, size);
+ strbuf_release(&pathbuf);
free(data);
- free(to_free);
return hit;
}
@@ -195,6 +183,7 @@ static int grep_file(struct grep_opt *opt, const char *filename)
int i;
char *data;
size_t sz;
+ struct strbuf buf = STRBUF_INIT;
if (lstat(filename, &st) < 0) {
err_ret:
@@ -219,8 +208,9 @@ static int grep_file(struct grep_opt *opt, const char *filename)
}
close(i);
if (opt->relative && opt->prefix_length)
- filename += opt->prefix_length;
+ filename = quote_path_relative(filename, -1, &buf, opt->prefix);
i = grep_buffer(opt, filename, data, sz);
+ strbuf_release(&buf);
free(data);
return i;
}
@@ -798,6 +788,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
};
memset(&opt, 0, sizeof(opt));
+ opt.prefix = prefix;
opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
opt.relative = 1;
opt.pathname = 1;
@@ -868,15 +859,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
verify_filename(prefix, argv[j]);
}
- if (i < argc) {
+ if (i < argc)
paths = get_pathspec(prefix, argv + i);
- if (opt.prefix_length && opt.relative) {
- /* Make sure we do not get outside of paths */
- for (i = 0; paths[i]; i++)
- if (strncmp(prefix, paths[i], opt.prefix_length))
- die("git grep: cannot generate relative filenames containing '..'");
- }
- }
else if (prefix) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
diff --git a/grep.h b/grep.h
index 28e6b2a..f6eecc6 100644
--- a/grep.h
+++ b/grep.h
@@ -59,6 +59,7 @@ struct grep_opt {
struct grep_pat *pattern_list;
struct grep_pat **pattern_tail;
struct grep_expr *pattern_expression;
+ const char *prefix;
int prefix_length;
regex_t regexp;
int linenum;
--
1.6.4.2.264.g79b4f
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Mark Brown @ 2009-09-05 11:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905090422.GA13221@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 05:04:22AM -0400, Jeff King wrote:
> On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:
> > My main wishlist would be to have the same control for the changes to be
> > committed for the big merge case, the use case being while resolving
> I think we need to be more concrete than that. What is the "big merge
> case"? If there are any unmerged paths?
The context was that this was done when explictly requested by the user
so all the time when enabled. In the context I'm thinking of this would
be used via the command line more than via the config file.
> What exactly should be cut out, and how can it be configured? Should you
> have "status.unmerged" to cut out certain things? Which things (of
> staged, unstaged, and untracked)? Or should it go the other way, with a
> status.showStaged variable which can be set to "always", "never", or
> "unmerged" (and probably adding an "unmerged" option to
> "status.showUntrackedFiles).
I'd been thinking of not showing anything in the index but keeping
everything else. In terms of a configuration variable I'd go with
specifying the things not to show rather than the things to show -
the noise to cut out.
^ permalink raw reply
* Re: [git-svn] [FEATURE-REQ] track merges from git
From: Jakub Narebski @ 2009-09-05 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <4A9565ED.4010608@cam.ac.uk>
Ximin Luo wrote:
> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,
> so if other people "git svn clone" from svn, or "git clone" from my git repo,
> they don't get the merge information.
In future version of git (I'm not sure if it is in master yet) there
would be refs/replace feature (grafts-like), which can be exported.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 9:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 04:48:09AM -0400, Jeff King wrote:
> On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:
>
> > I see. I still think you may want to improve "commit --dry-run" with a
> > plumbing format, though, instead of "git status". Then it would
> > automagically support "--amend", as well as other dry-run things (e.g.,
> > "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> > at the code, I would guess it is a one-liner patch to switch the "output
> > format" flag that commit passes to the wt-status.c code.
>
> OK, it was a bit more complex than that. But here is a series which does
> a few things. It is still missing a few bits, so is RFC.
BTW, in case it was not obvious from the context, these are built on top
of jc/1.7.0-status.
-Peff
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 9:04 UTC (permalink / raw)
To: Mark Brown; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090902183923.GA10581@rakim.wolfsonmicro.main>
On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:
> My main wishlist would be to have the same control for the changes to be
> committed for the big merge case, the use case being while resolving
> merges where those changes are those that have been dealt with and the
> remaining (hopefully much fewer) changes are those that still need
> attention.
I think we need to be more concrete than that. What is the "big merge
case"? If there are any unmerged paths?
What exactly should be cut out, and how can it be configured? Should you
have "status.unmerged" to cut out certain things? Which things (of
staged, unstaged, and untracked)? Or should it go the other way, with a
status.showStaged variable which can be set to "always", "never", or
"unmerged" (and probably adding an "unmerged" option to
"status.showUntrackedFiles).
-Peff
^ permalink raw reply
* [PATCH/RFC 6/6] commit: support alternate status formats
From: Jeff King @ 2009-09-05 8:59 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The status command recently grew "short" and "porcelain"
options for alternate output formats. Since status is no
longer "commit --dry-run", these formats are inaccessible to
people who do want to see a dry-run in a parseable form.
This patch makes those formats available to "git commit",
implying the "dry-run" option when they are used.
Signed-off-by: Jeff King <peff@peff.net>
---
This one is very RFC, as it has a few problems/questions:
- no tests yet, and it definitely should have some
- should alternate formats imply dry-run? It makes no sense to _not_ do
dry-run, since you would be putting cruft into the editor for the
user to see. But the other option would be barfing and complaining
about mismatched options.
- the "committable" flag is set in wt_status_print, which means it will
not be set correctly for short output. I can hack it into the short
output format, but I think it is probably a mistake for it to be
stuck with the printing routines in the first place (it is a
historical artifact, I suspect, from before we always had a "collect"
phase). So I think it should probably just be part of the "collect"
phase.
Documentation/git-commit.txt | 14 ++++++++++++++
builtin-commit.c | 39 ++++++++++++++++++++++++++++++++-------
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 64f94cf..c45fbe4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -75,6 +75,20 @@ OPTIONS
and paths that are untracked, similar to the one that is given
in the commit log editor.
+--short::
+ When doing a dry-run, give the output in the short-format. See
+ linkgit:git-status[1] for details. Implies `--dry-run`.
+
+--porcelain::
+ When doing a dry-run, give the output in a porcelain-ready
+ format. See linkgit:git-status[1] for details. Implies
+ `--dry-run`.
+
+-z::
+ When showing `short` or `porcelain` status output, terminate
+ entries in the status output with NUL, instead of LF. If no
+ format is given, implies the `--porcelain` output format.
+
-F <file>::
--file=<file>::
Take the commit message from the given file. Use '-' to
diff --git a/builtin-commit.c b/builtin-commit.c
index ffdee31..f2fd0a4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -72,6 +72,15 @@ static int use_editor = 1, initial_commit, in_merge;
static const char *only_include_assumed;
static struct strbuf message;
+static int null_termination;
+static enum {
+ STATUS_FORMAT_LONG,
+ STATUS_FORMAT_SHORT,
+ STATUS_FORMAT_PORCELAIN,
+} status_format = STATUS_FORMAT_LONG;
+
+static void short_print(struct wt_status *s, int null_termination);
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -105,6 +114,12 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN('o', "only", &only, "commit only specified files"),
OPT_BOOLEAN('n', "no-verify", &no_verify, "bypass pre-commit hook"),
OPT_BOOLEAN(0, "dry-run", &dry_run, "show what would be committed"),
+ OPT_SET_INT(0, "short", &status_format, "show status concisely",
+ STATUS_FORMAT_SHORT),
+ OPT_SET_INT(0, "porcelain", &status_format,
+ "show porcelain output format", STATUS_FORMAT_PORCELAIN),
+ OPT_BOOLEAN('z', "null", &null_termination,
+ "terminate entries with NUL"),
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
@@ -363,7 +378,18 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
wt_status_collect(s);
- wt_status_print(s);
+
+ switch (status_format) {
+ case STATUS_FORMAT_SHORT:
+ short_print(s, null_termination);
+ break;
+ case STATUS_FORMAT_PORCELAIN:
+ short_print(s, null_termination);
+ break;
+ case STATUS_FORMAT_LONG:
+ wt_status_print(s);
+ break;
+ }
return s->commitable;
}
@@ -821,6 +847,11 @@ static int parse_and_validate_options(int argc, const char *argv[],
else if (interactive && argc > 0)
die("Paths with --interactive does not make sense.");
+ if (null_termination && status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_PORCELAIN;
+ if (status_format != STATUS_FORMAT_LONG)
+ dry_run = 1;
+
return argc;
}
@@ -991,12 +1022,6 @@ static void short_print(struct wt_status *s, int null_termination)
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
- static int null_termination;
- static enum {
- STATUS_FORMAT_LONG,
- STATUS_FORMAT_SHORT,
- STATUS_FORMAT_PORCELAIN,
- } status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 5/6] status: add --porcelain output format
From: Jeff King @ 2009-09-05 8:55 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The "short" format was added to "git status" recently to
provide a less verbose way of looking at the same
information. This has two practical uses:
1. Users who want a more dense display of the information.
2. Scripts which want to parse the information and need a
stable, easy-to-parse interface.
For now, the "--short" format covers both of those uses.
However, as time goes on, users of (1) may want additional
format tweaks, or for "git status" to change its behavior
based on configuration variables. Those wishes will be at
odds with (2), which wants to stability for scripts.
This patch introduces a separate --porcelain option early to
avoid problems later on. Right now the --short and
--porcelain outputs are identical. However, as time goes on,
we will have the freedom to customize --short for human
consumption while keeping --porcelain stable.
Signed-off-by: Jeff King <peff@peff.net>
---
No tests. Does this really need them? At this point, it would be pure
duplication of the --short tests; I am inclined to leave such tests
until later when there is actually a difference between the two formats
(and then we will know _what_ to test).
Documentation/git-status.txt | 9 +++++++--
builtin-commit.c | 9 ++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index fd71a7a..58d35fb 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -27,6 +27,11 @@ OPTIONS
--short::
Give the output in the short-format.
+--porcelain::
+ Give the output in a stable, easy-to-parse format for scripts.
+ Currently this is identical to --short output, but is guaranteed
+ not to change in the future, making it safe for scripts.
+
-u[<mode>]::
--untracked-files[=<mode>]::
Show untracked files (Default: 'all').
@@ -45,8 +50,8 @@ used to change the default for when the option is not
specified.
-z::
- Terminate entries with NUL, instead of LF. This implies `-s`
- (short status) output format.
+ Terminate entries with NUL, instead of LF. This implies
+ the `--porcelain` output format if no other format is given.
OUTPUT
diff --git a/builtin-commit.c b/builtin-commit.c
index aa4a358..ffdee31 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -995,12 +995,16 @@ int cmd_status(int argc, const char **argv, const char *prefix)
static enum {
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
+ STATUS_FORMAT_PORCELAIN,
} status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
OPT_SET_INT('s', "short", &status_format,
"show status concisely", STATUS_FORMAT_SHORT),
+ OPT_SET_INT(0, "porcelain", &status_format,
+ "show porcelain output format",
+ STATUS_FORMAT_PORCELAIN),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1011,7 +1015,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
};
if (null_termination && status_format == STATUS_FORMAT_LONG)
- status_format = STATUS_FORMAT_SHORT;
+ status_format = STATUS_FORMAT_PORCELAIN;
wt_status_prepare(&s);
git_config(git_status_config, &s);
@@ -1032,6 +1036,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
short_print(&s, null_termination);
break;
+ case STATUS_FORMAT_PORCELAIN:
+ short_print(&s, null_termination);
+ break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
if (s.relative_paths)
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Daniele Segato @ 2009-09-05 8:55 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20090905061657.GC22272@dcvr.yhbt.net>
Il giorno ven, 04/09/2009 alle 23.16 -0700, Eric Wong ha scritto:
> It's unfortunate, but there's not yet an exclude/ignore directive
> when globbing. You'll have to change your $GIT_CONFIG to only
> have a list of branches you want, something like this:
>
> [svn-remote "svn"]
> url = svn://svn.mydomain.com
> fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
>
> ; have one "fetch" line for every branch except the one you want
> fetch = path/to/repo/BRANCHES/a/root:refs/remotes/svn/a
> fetch = path/to/repo/BRANCHES/b/root:refs/remotes/svn/b
> fetch = path/to/repo/BRANCHES/c/root:refs/remotes/svn/c
>
> ; you can do the same for tags if you have the same problem
> tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
>
> But you shouldn't have to worry about having "fetch" entries for
> stale/old branches/tags you've already imported.
I see...
That means that then I'll have to manually add new created branches,
right?
well... I tried to avoid this kind of configuration for weeks :) but
that's probably my best way with that repo....
thank you,
Daniele
^ permalink raw reply
* [PATCH/RFC 4/6] status: refactor format option parsing
From: Jeff King @ 2009-09-05 8:54 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
This makes it possible to have more than two formats.
Signed-off-by: Jeff King <peff@peff.net>
---
This would make a "--long" option trivial, but I'm not sure there is
much point.
builtin-commit.c | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 5b42179..aa4a358 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -991,12 +991,16 @@ static void short_print(struct wt_status *s, int null_termination)
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
- static int null_termination, shortstatus;
+ static int null_termination;
+ static enum {
+ STATUS_FORMAT_LONG,
+ STATUS_FORMAT_SHORT,
+ } status_format = STATUS_FORMAT_LONG;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
- OPT_BOOLEAN('s', "short", &shortstatus,
- "show status concisely"),
+ OPT_SET_INT('s', "short", &status_format,
+ "show status concisely", STATUS_FORMAT_SHORT),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
@@ -1006,8 +1010,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
OPT_END(),
};
- if (null_termination)
- shortstatus = 1;
+ if (null_termination && status_format == STATUS_FORMAT_LONG)
+ status_format = STATUS_FORMAT_SHORT;
wt_status_prepare(&s);
git_config(git_status_config, &s);
@@ -1024,9 +1028,11 @@ int cmd_status(int argc, const char **argv, const char *prefix)
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
wt_status_collect(&s);
- if (shortstatus)
+ switch (status_format) {
+ case STATUS_FORMAT_SHORT:
short_print(&s, null_termination);
- else {
+ break;
+ case STATUS_FORMAT_LONG:
s.verbose = verbose;
if (s.relative_paths)
s.prefix = prefix;
@@ -1035,6 +1041,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
if (diff_use_color_default == -1)
diff_use_color_default = git_use_color_default;
wt_status_print(&s);
+ break;
}
return 0;
}
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 3/6] status: refactor short-mode printing to its own function
From: Jeff King @ 2009-09-05 8:53 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
We want to be able to call it from multiple places.
Signed-off-by: Jeff King <peff@peff.net>
---
I am tempted to move all of the short-printing code to its own file, and
move "cmd_status" to its own builtin-status.c, as well. I don't know if
that is a cleanup that makes sense to others, as well, or if it is too
much churn for too little good.
builtin-commit.c | 45 +++++++++++++++++++++++++--------------------
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 812470e..5b42179 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -966,11 +966,32 @@ static void short_untracked(int null_termination, struct string_list_item *it,
}
}
+static void short_print(struct wt_status *s, int null_termination)
+{
+ int i;
+ for (i = 0; i < s->change.nr; i++) {
+ struct wt_status_change_data *d;
+ struct string_list_item *it;
+
+ it = &(s->change.items[i]);
+ d = it->util;
+ if (d->stagemask)
+ short_unmerged(null_termination, it, s);
+ else
+ short_status(null_termination, it, s);
+ }
+ for (i = 0; i < s->untracked.nr; i++) {
+ struct string_list_item *it;
+
+ it = &(s->untracked.items[i]);
+ short_untracked(null_termination, it, s);
+ }
+}
+
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
static int null_termination, shortstatus;
- int i;
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
@@ -1003,25 +1024,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
wt_status_collect(&s);
- if (shortstatus) {
- for (i = 0; i < s.change.nr; i++) {
- struct wt_status_change_data *d;
- struct string_list_item *it;
-
- it = &(s.change.items[i]);
- d = it->util;
- if (d->stagemask)
- short_unmerged(null_termination, it, &s);
- else
- short_status(null_termination, it, &s);
- }
- for (i = 0; i < s.untracked.nr; i++) {
- struct string_list_item *it;
-
- it = &(s.untracked.items[i]);
- short_untracked(null_termination, it, &s);
- }
- } else {
+ if (shortstatus)
+ short_print(&s, null_termination);
+ else {
s.verbose = verbose;
if (s.relative_paths)
s.prefix = prefix;
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 2/6] docs: note that status configuration affects only long format
From: Jeff King @ 2009-09-05 8:52 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The short format does not respect any of the usual status.*
configuration.
Signed-off-by: Jeff King <peff@peff.net>
---
Combined with the --short/--porcelain distinction introduced later in
the series, should short perhaps respect status.relativePaths and
status.submoduleSummary? Which would mean replacing this patch with ones
to make those things work. :)
Documentation/git-status.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b5939d6..fd71a7a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -109,13 +109,13 @@ compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
If the config variable `status.relativePaths` is set to false, then all
-paths shown are relative to the repository root, not to the current
-directory.
+paths shown in the long format are relative to the repository root, not
+to the current directory.
If `status.submodulesummary` is set to a non zero number or true (identical
-to -1 or an unlimited number), the submodule summary will be enabled and a
-summary of commits for modified submodules will be shown (see --summary-limit
-option of linkgit:git-submodule[1]).
+to -1 or an unlimited number), the submodule summary will be enabled for
+the long format and a summary of commits for modified submodules will be
+shown (see --summary-limit option of linkgit:git-submodule[1]).
SEE ALSO
--------
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 1/6] status: typo fix in usage
From: Jeff King @ 2009-09-05 8:50 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 6cb0e40..812470e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -975,7 +975,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
OPT_BOOLEAN('s', "short", &shortstatus,
- "show status concicely"),
+ "show status concisely"),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 8:48 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905062846.GD29863@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:
> I see. I still think you may want to improve "commit --dry-run" with a
> plumbing format, though, instead of "git status". Then it would
> automagically support "--amend", as well as other dry-run things (e.g.,
> "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> at the code, I would guess it is a one-liner patch to switch the "output
> format" flag that commit passes to the wt-status.c code.
OK, it was a bit more complex than that. But here is a series which does
a few things. It is still missing a few bits, so is RFC.
These first two are unrelated fixups that I noticed while working.
[1/6]: status: typo fix in usage
[2/6]: docs: note that status configuration affects only long format
These are the --porcelain patches we discussed. The first two are
obviously cleanup.
[3/6]: status: refactor short-mode printing to its own function
[4/6]: status: refactor format option parsing
[5/6]: status: add --porcelain output format
This brings the new formats to "commit --dry-run" to handle your case.
Conceptually, it could come before (or instead) of 4/6 and 5/6, but as
it adds both --short and --porcelain, there is an obvious dependency.
[6/6]: commit: support alternate status formats
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Clemens Buchacher @ 2009-09-05 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
> I personally find "add -u" that defaults to the current directory more
> natural than always going to the root; same preference for "grep".
> Besides, "add -u subdir" must add subdir relative to the cwd, without
> going to the root. Why should "add -u" sans argument behave drastically
> differently?
Sorry for stating the obvious here, but the following commands affect the
entire repository, even though they limit themselves to the current
directory, if passed a '.'.
git commit
git log
git diff
git checkout
git reset
Due to the frequent use of these commands, I believe many users (myself
included) expect "git add" and "git grep" to do the same. AFAICT the
following commands are the only non-plumbing ones that behave differently:
git add -u
git add -A
git grep
So I argue that _that_ is the real inconsistency.
> If "git add -u ../.." (I mean "the grand parent directory", not "an
> unnamed subdirectory") did not work, it would be unexcusable and we would
> want to devise an migration path, but otherwise I do not think it is such
> a big deal.
> I would say the commands that are used to incrementally build
> towards the next commit should be friendly to the practice of limiting the
> scope of the work by chdir.
"git add -u ." is friendly enough. Just like "git commit ." versus "git
commit -a", which is exactly the same concept and should therefore have the
same behavior.
You are assuming that people are in a subdirectory because they want to
limit the scope. But I am usually in a subdirectory for totally
versioning-unrelated reasons. Like running tests in git.git:t/ . I
mistakenly use "git add -u" in there all the time, because I think I don't
have to worry about which directory I'm in. Except in this instance I do.
In any case, I think it is better to have consistent behavior than to try
and read users' minds with defaults.
Clemens
^ permalink raw reply
* What's cooking in git.git (Sep 2009, #01; Sat, 05)
From: Junio C Hamano @ 2009-09-05 8:35 UTC (permalink / raw)
To: git
What's cooking in git.git (Sep 2009, #01; Sat, 05)
--------------------------------------------------
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.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
I will probably do 1.6.5-rc0 this weekend, leaving some topics still
cooking in 'next'.
--------------------------------------------------
[Graduated to "master"]
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
* mr/gitweb-snapshot (2009-08-25) 3 commits
(merged to 'next' on 2009-08-30 at e4edd0b)
+ gitweb: add t9501 tests for checking HTTP status codes
+ gitweb: split test suite into library and tests
+ gitweb: improve snapshot error handling
* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.
(merged to 'next' on 2009-08-26 at 4fc7784)
+ xutils: Fix xdl_recmatch() on incomplete lines
+ xutils: Fix hashing an incomplete line with whitespaces at the end
--------------------------------------------------
[New Topics]
* pk/fast-import-tars (2009-09-03) 1 commit
- import-tars: Allow per-tar author and commit message.
* jc/maint-1.6.0-blank-at-eof (2009-09-04) 9 commits.
- diff --color: color blank-at-eof
- diff --whitespace=warn/error: fix blank-at-eof check
- diff --whitespace=warn/error: obey blank-at-eof
- diff.c: the builtin_diff() deals with only two-file comparison
- apply --whitespace: warn blank but not necessarily empty lines at EOF
- apply --whitespace=warn/error: diagnose blank at EOF
- apply.c: split check_whitespace() into two
- apply --whitespace=fix: detect new blank lines at eof correctly
- apply --whitespace=fix: fix handling of blank lines at the eof
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- notes.c: Implement simple memory pooling of leaf nodes
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
I heard the cvs-helper series depends on this one. It seems that the
fan-out strategy is being rethought?
--------------------------------------------------
[Cooking]
* db/vcs-helper (2009-09-03) 16 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Use a clearer style to issue commands to remote helpers
- Make the "traditionally-supported" URLs a special case
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper)
Builds on db/vcs-helper. There is a re-roll planned.
* pk/fast-import-dirs (2009-09-03) 1 commit
- Add script for importing bits-and-pieces to Git.
With an updated key-value quoting rules, which I haven't carefully looked
at. Aren't there standard libraries to do this sort of thing without us
having to hand-roll these logic every time, I have to wonder...
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
- gitweb: Colorize 'blame_incremental' view during processing
- gitweb: Incremental blame (using JavaScript)
- gitweb: Add optional "time to generate page" info in footer
Ajax-y blame. The first part should be in 'next' shortly.
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-18) 10 commits.
(merged to 'next' on 2009-09-03 at d4f2ed7)
+ stash: simplify defaulting to "save" and reject unknown options
(merged to 'next' on 2009-08-27 at d314281)
+ Make test case number unique
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
DWIMmery of the two series tightened for safety. This should be ready for
1.6.5.
* jc/upload-pack-hook (2009-08-28) 2 commits
(merged to 'next' on 2009-08-31 at f9933a5)
+ upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
+ upload-pack: add a trigger for post-upload-pack hook
* jk/clone-b (2009-08-26) 1 commit
(merged to 'next' on 2009-08-30 at 10a68d1)
+ clone: add --branch option to select a different HEAD
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests to covers 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/mailinfo-scissors (2009-08-26) 5 commits
(merged to 'next' on 2009-08-30 at 5fc6248)
+ mailinfo.scissors: new configuration
+ am/mailinfo: Disable scissors processing by default
+ Documentation: describe the scissors mark support of "git am"
+ Teach mailinfo to ignore everything before -- >8 -- mark
+ builtin-mailinfo.c: fix confusing internal API to mailinfo()
I didn't pick up the patch to simplify the definition of scissors. I do
not have strong opinion on it either way, but the list would hopefully
decide it before too long.
* cc/sequencer-rebase-i (2009-08-28) 15 commits
- rebase -i: use "git sequencer--helper --cherry-pick"
- sequencer: add "--cherry-pick" option to "git sequencer--helper"
- sequencer: add "do_commit()" and related functions working on "next_commit"
- pick: libify "pick_help_msg()"
- revert: libify cherry-pick and revert functionnality
- rebase -i: use "git sequencer--helper --fast-forward"
- sequencer: let "git sequencer--helper" callers set "allow_dirty"
- sequencer: add "--fast-forward" option to "git sequencer--helper"
- sequencer: add "do_fast_forward()" to perform a fast forward
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
Migrating "rebase -i" bit by bit to C.
* sr/gfi-options (2009-09-02) 6 commits
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Re-rolled again.
* nd/sparse (2009-08-20) 19 commits
- 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
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-status (2009-08-15) 3 commits
(merged to 'next' on 2009-08-22 at b3507bb)
+ 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"
With this, "git status" is no longer "git commit --preview".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* 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/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
* ne/rev-cache (2009-08-21) 6 commits
. 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
Updated but seems to break upload-pack tests when merged to 'pu'; given
what this series touches, breakages in that area are expected.
May discard if a working reroll comes, to give it a fresh start.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 8:23 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905080249.GA8801@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I agree that we agreed to disagree. But there is still one open
> question: would you take a patch for a "full-tree" config variable that
> would impact add (and probably grep) for 1.7.0?
Unless there is a simple and sane way for script writers (and by "script",
I do not mean "Porcelain that is supposed to be written using only the
plumbing", but things like scripts you would give to "git bisect run",
which would freely use Porcelains like "git reset" etc.) to defeat the
configuration without much pain, I am fairly negative on adding any
configuration variable of that nature.
We could probably declare "In 1.X.0 everything will be relative to the
root and you have to give an explicit '.' if you mean the cwd".
Three questions:
#1 What are the commands that will be affected, other than "add -u" and
"grep"? Are there others?
#2 Do all the commands in the answer to #1 currently behave exactly the
same when run without any path parameter and when run with a single
'.'?
#3 Do all the commands that are already relative to the root currently
limit their action to the cwd when run with a single '.'?
If the number of commands in the answer to #1 is not too excessive, it is
a plus, but even if it is more than just several, we will be getting
consistency and sanity if #2 and #3 hold. However, if there are even a
single violator in #2 and #3, we would need to fix them first before we
can proceed. And the transition clock starts ticking after everything is
fixed (if such a fix is indeed needed). As usual, I'd prefer to keep the
clock running for at least 6 months, preferrably longer, and during that
time, we may need the usual "You invoked me without any paths, but this
command will start behaving differently in 1.X.0, you have been warned."
A command line option to explicitly ask full-tree can be added anytime
without waiting for 1.7.0. I do not think it will be ready for 1.6.5 but
we can always have 1.6.6 if needed.
^ permalink raw reply
* Re: git+http:// proof-of-concept (not using CONNECT)
From: Eric Wong @ 2009-09-05 8:23 UTC (permalink / raw)
To: Douglas Campos; +Cc: Tony Finch, Constantine Plotnikov, git
In-Reply-To: <ed88cb980908260734x78382052t30d4cdcf07451134@mail.gmail.com>
Douglas Campos <douglas@theros.info> wrote:
> Any news about this approach? I've heard some noise about a CGI
> implementation....
Hi Douglass,
I've been busy with other things. This approach is probably
too limited to get around HTTP-aware proxies to be useful for
non-git:// users anyways.
It also turns out the curl patch that made it into 7.19.6 was still
unsuitable for bidirectional tunneling, looks like I'll have to port
curl over to the curl_multi_* interface to get it working properly
instead...
--
Eric Wong
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905072017.GA5152@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 03:20:17AM -0400, Jeff King wrote:
> As I mentioned above, not only is that annoying to use, but the real
> problem is that I _expect_ the other behavior and it silently does the
> opposite of what I want. You can argue that my brain is defective (for
> not remembering, I mean -- we _know_ it's defective in other ways), but
> certainly a config option would be useful to me.
Bah. Even after this long thread, I _still_ forgot. I just now typed
"git add -u" from t/ and got annoyed that my changes in the root weren't
added.
-Peff
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Jeff King @ 2009-09-05 8:17 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <fabb9a1e0909020118m2fe2e6e1g79cc83ce941ac000@mail.gmail.com>
On Wed, Sep 02, 2009 at 10:18:54AM +0200, Sverre Rabbelier wrote:
> On Wed, Sep 2, 2009 at 09:57, Jeff King<peff@peff.net> wrote:
> > 2. Count the commits on each side that are not in the other.
>
> [...]
>
> > You can also do that by parsing the output of:
> > git rev-list --left-right $a...$b --
>
> Perhaps it is useful to introduce a --left-right-count or such?
I'm not opposed to that if it is something a lot of people found useful,
but I am not sure we have established that as the case (I am curious to
hear from Tim what his actual use case is).
-Peff
^ permalink raw reply
* Re: [git-svn] [FEATURE-REQ] track merges from git
From: Eric Wong @ 2009-09-05 8:03 UTC (permalink / raw)
To: Ximin Luo; +Cc: git
In-Reply-To: <4A9565ED.4010608@cam.ac.uk>
Ximin Luo <xl269@cam.ac.uk> wrote:
> Hi,
Hi, sorry for the late reply.
> I'm have 2 separate svn projects from googlecode imported into a single git
> repo. One is a semi-fork of the other, so I thought I'd be able to use git's
> merge feature to repeatedly merge from the mother project (and possibly vice
> versa too).
>
> However, this doesn't happen. I "git pull" and this works fine, but when I "git
> svn dcommit" back into svn, this rewrites my git history and it loses track of
> the merge (and next time I try to pull, the same conflicts appear).
You may want to try the "set-tree" function of git svn instead of
dcommit, it was originally named "commit" back in the day set-tree does
not rewrite any history.
It fell out of favor because you could end up with a lot of non-linear
history making it difficult for sharing diffs with SVN-using cow-orkers.
It is useful if you don't want to share your individual changesets, but
push your work upstream to the SVN repos as one big ugly change.
But if you want a staircase effect in gitk, set-tree can be used to make
individual commits where every change ends up as a merge (and you'll see
two commits for every change you made)
> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,
> so if other people "git svn clone" from svn, or "git clone" from my git repo,
> they don't get the merge information.
>
> It would be nice if git-svn saved the merge info somewhere instead of getting
> rid of it. #git tells me this is impossible at the moment, hence the mail.
> Relevant parts of the convo are pasted below.
It should actually get logged to the unhandled.log file, but right
now I'm not aware of any tools that reads that file (which is designed
to be machine parseable).
> I understand if this is a low priority, but I don't think it would be a major
> PITA to implement (some suggestions are listed in the convo log). And it'd be
> useful for people converting from svn to git.
I've considered stuffing git commit information in SVN properties,
but that information is likely to not even be useful to git users
other than yourself
> Thanks for your time.
>
> X
>
> P.S. please don't troll me.
Don't worry, despite my domain name, it's been a long time since I've
done any real trolling :)
> (17:13:14) infinity0: hi
> (17:13:21) infinity0: i've used git-svn to import two svn repo
> (17:13:23) infinity0: repos*
> (17:13:28) infinity0: and used git to merge the two
> (17:13:45) infinity0: the problem is, when i git-svn dcommit back to svn,
> git-svn rewrites my git history
> (17:13:50) infinity0: and loses the merge i just did
> (17:14:01) offby1: infinity0: of course
> (17:14:04) infinity0: how do i get it to retain knowledge of the merge?
> (17:14:11) offby1: infinity0: you don't. Next questions.
> (17:14:16) infinity0: why not?
> (17:14:29) offby1: svn is incapable of storing a merge, at least in the sense
> that we git people use the term "merge"
I'm not sure if that statement is still true with newer SVN versions;
I still haven't had the time to look too hard at newer SVN features.
On the other hand, SVN could be storing "merges" that git simply can't
track as merges; SVN branches and directories are interchangeable, so
SVN could be merging from places that git isn't tracking at all or
merging individual files.
> (17:14:46) Grum: you should be able to store the result of a merge as a commit
> (17:14:51) offby1: sure
> (17:14:57) infinity0: sure, but why does git-svn have to rewrite my *git*
> history to remove knowledge of the merge?
> (17:15:02) offby1: but not as a "merge commit", whatever that might mean in svn
> (17:15:35) Grum: because it has to be representative of the svn repo after you
> dcommit there obviously
> (17:15:42) offby1: infinity0: it's trying to mirror the svn repository in your
> git repository. I assume the original, un-rewritten commits are still in your
> git repository; they're just not pointed at by any branch. Poke around in the
> reflog; I imagine you'll find 'em in there
> (17:16:09) infinity0: ok, but that's not useful if they're dangling
> (17:16:26) infinity0: it's trying to mirror the svn repo yes... but as you
> said, svn doesn't know about merges
> (17:16:26) ***offby1 idly wonders if it'd be possible for git svn to indeed
> store merge commits, by applying the appropriate svn:mergeinfo properties
Some of should be mappable to git merges, it depends on the project and
the type of merge done. As I said earlier, SVN could be merging
from places git svn doesn't know about and can't track... SVN can
get extremely complicated :<
I'm not sure how widely used that feature is used in the SVN world,
either.
> (17:16:40) infinity0: i read a thread where it says those are different things
> (17:16:41) offby1: infinity0: I suspect you're using git svn for something for
> which it wasn't designed.
> (17:17:17) infinity0: would it be possible, in theory, to have git-svn store
> the git merge information in eg. the same way it stores the git-svn tag in the
> svn commit message
> (17:17:33) Grum: then just use svn?
> (17:17:37) Grum: and a postit?
I don't agree with having git-specific metadata on the SVN side itself.
Often times that git-specific metadata has SHA1s unique to the user that
committed it, so it wouldn't be useful to anyone else unless users are
merging from each others git repos (which is not an easy/natural
workflow if SVN is the mainline). Patch exchange is more
reliable/easier...
I've also worked in places where alternative tools are frowned upon, so
sending git-specific metadata over to SVN should always be optional.
The majority of folks I've worked with on SVN-hosted projects have never
known about my git usage (that is changing as git popularity increases,
however).
> (17:18:01) infinity0: i'm trying to link two separate svn repos together via git
> (17:18:17) Grum: and that is just what offby1 said
> (17:18:30) infinity0: "what" is
> (17:18:40) Grum: I suspect you're using git svn for something for which it
> wasn't designed.
> (17:18:42) infinity0: as you all are saying, git merges and svn "merges" are
> different things
> (17:18:58) infinity0: ok, but it would be possible to make git-svn have this
> functionality? or not
> (17:18:59) offby1: certainly
> (17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it
> were doable, I suspect he'd have done it already.
> (17:19:21) offby1: But then ... who knows, maybe he's busy.
I'm not smart but I am busy :)
Summary of the git svn merge tracking situation:
Mapping git <-> git merges to SVN:
* already doable for the committing user with set-tree,
but makes history ugly for:
a) yourself (with every commit set-tree'd individually)
b) SVN users (single set-tree with the newest commit)
c) all of the above (varying granularity)
* Pushing git metadata to SVN will annoy SVN-only users
* Putting git metadata in SVN may not be useful since SHA1s
may be specific to the user that made that commit.
Mapping SVN <-> SVN merges to SVN via git svn:
* most likely to be doable, they'll become plain SVN <-> SVN merges,
see problems with getting SVN <-> SVN merges back to git, however...
Mapping SVN <-> SVN merges to git:
* SVN can represent merges that git can't, SVN can be/is extremely
complicated when it comes to merges.
* I don't see many projects (I care about) use SVN merge tracking,
which projects actually use it? Maybe it's still too new and
distros/users are behind the upgrade curve...
I've probably missed some, I've been dozing off while replying to
emails...
--
Eric Wong
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v3a717rgl.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:58:50AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I assume you mean "ls-files". I have every once in a while been annoyed
> > by that, but given how infrequently I run ls-files, it is not a big
> > deal. :)
>
> I did mean ls-tree, but I misspelled the name of the escape hatch.
Oh, I never noticed that behavior before. For "ls-files", I think it is
at least a little sane, but it makes no sense whatsoever for ls-tree.
> At this moment (as my brain is not quite functioning), I can only say we
> agreed to disagree what feels more natural here.
I agree that we agreed to disagree. But there is still one open
question: would you take a patch for a "full-tree" config variable that
would impact add (and probably grep) for 1.7.0? You can sleep on it if
you want. ;)
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:58 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905072017.GA5152@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I assume you mean "ls-files". I have every once in a while been annoyed
> by that, but given how infrequently I run ls-files, it is not a big
> deal. :)
I did mean ls-tree, but I misspelled the name of the escape hatch.
Try this:
$ cd Documentation
$ git ls-tree HEAD
If I were designing this as a proper plumbing command from scratch, I
wouldn't have given it a cwd behaviour. ls-files is somewhat more
understandable, as it has other cruft relating the work tree, but ls-tree
is worse:
$ cd Documentation
$ git ls-tree origin/html
Whoa??? Yes, it tried to do what "git ls-tree origin/html:Documentation"
would have done if it were unaware of cwd. It's just crazy.
>> If "git add -u ../.." (I mean "the grand parent directory", not "an
>> unnamed subdirectory") did not work, it would be unexcusable and we would
>> want to devise an migration path, but otherwise I do not think it is such
>> a big deal. I would say the commands that are used to incrementally build
>
> As I mentioned above, not only is that annoying to use, but the real
> problem is that I _expect_ the other behavior and it silently does the
> opposite of what I want. You can argue that my brain is defective (for
> not remembering, I mean -- we _know_ it's defective in other ways), but
> certainly a config option would be useful to me.
At this moment (as my brain is not quite functioning), I can only say we
agreed to disagree what feels more natural here.
^ 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