* [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-06 6:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906064454.GA1643@coredump.intra.peff.net>
This message is designed to help new users understand what
has happened when refs fail to push. However, it does not
help experienced users at all, and significantly clutters
the output, frequently dwarfing the regular status table and
making it harder to see.
This patch introduces a general configuration mechanism for
optional messages, with this push message as the first
example.
Signed-off-by: Jeff King <peff@peff.net>
---
Probably "messages" is too vague a term to use in the code and config.
Maybe "advice.*"?
Documentation/config.txt | 16 ++++++++++++++++
Makefile | 2 ++
builtin-push.c | 3 ++-
cache.h | 1 +
config.c | 3 +++
messages.c | 28 ++++++++++++++++++++++++++++
messages.h | 15 +++++++++++++++
7 files changed, 67 insertions(+), 1 deletions(-)
create mode 100644 messages.c
create mode 100644 messages.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..ec308a6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1201,6 +1201,22 @@ mergetool.keepTemporaries::
mergetool.prompt::
Prompt before each invocation of the merge resolution program.
+message.all::
+ When set to 'true', display all optional help messages. When set
+ to 'false', do not display any. Defaults vary with individual
+ messages (see message.* below).
+
+message.*::
+ When set to 'true', display the given optional help message.
+ When set to 'false', do not display. The configuration variables
+ are:
++
+--
+ pushNonFastForward::
+ Help message shown when linkgit:git-push[1] refuses
+ non-fast-forward refs. Default: true.
+--
+
pack.window::
The size of the window used by linkgit:git-pack-objects[1] when no
window size is given on the command line. Defaults to 10.
diff --git a/Makefile b/Makefile
index a614347..0785977 100644
--- a/Makefile
+++ b/Makefile
@@ -424,6 +424,7 @@ LIB_H += ll-merge.h
LIB_H += log-tree.h
LIB_H += mailmap.h
LIB_H += merge-recursive.h
+LIB_H += messages.h
LIB_H += object.h
LIB_H += pack.h
LIB_H += pack-refs.h
@@ -506,6 +507,7 @@ LIB_OBJS += mailmap.o
LIB_OBJS += match-trees.o
LIB_OBJS += merge-file.o
LIB_OBJS += merge-recursive.o
+LIB_OBJS += messages.o
LIB_OBJS += name-hash.o
LIB_OBJS += object.o
LIB_OBJS += pack-check.o
diff --git a/builtin-push.c b/builtin-push.c
index 787011f..dceac9f 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -157,7 +157,8 @@ static int do_push(const char *repo, int flags)
continue;
error("failed to push some refs to '%s'", url[i]);
- if (nonfastforward) {
+ if (nonfastforward &&
+ messages[MESSAGE_PUSH_NONFASTFORWARD].preference) {
printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'non-fast forward'\n"
"section of 'git push --help' for details.\n");
diff --git a/cache.h b/cache.h
index 5fad24c..32d1a27 100644
--- a/cache.h
+++ b/cache.h
@@ -4,6 +4,7 @@
#include "git-compat-util.h"
#include "strbuf.h"
#include "hash.h"
+#include "messages.h"
#include SHA1_HEADER
#ifndef git_SHA_CTX
diff --git a/config.c b/config.c
index e87edea..aed1547 100644
--- a/config.c
+++ b/config.c
@@ -627,6 +627,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
if (!prefixcmp(var, "mailmap."))
return git_default_mailmap_config(var, value);
+ if (!prefixcmp(var, "message."))
+ return git_default_message_config(var, value);
+
if (!strcmp(var, "pager.color") || !strcmp(var, "color.pager")) {
pager_use_color = git_config_bool(var,value);
return 0;
diff --git a/messages.c b/messages.c
new file mode 100644
index 0000000..00fc196
--- /dev/null
+++ b/messages.c
@@ -0,0 +1,28 @@
+#include "cache.h"
+#include "messages.h"
+
+struct message_preference messages[] = {
+ { "pushnonfastforward", 1 },
+};
+
+int git_default_message_config(const char *var, const char *value)
+{
+ const char *k = skip_prefix(var, "message.");
+ int i;
+
+ if (!strcmp(k, "all")) {
+ int v = git_config_bool(var, value);
+ for (i = 0; i < ARRAY_SIZE(messages); i++)
+ messages[i].preference = v;
+ return 0;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(messages); i++) {
+ if (strcmp(k, messages[i].name))
+ continue;
+ messages[i].preference = git_config_bool(var, value);
+ return 0;
+ }
+
+ return 0;
+}
diff --git a/messages.h b/messages.h
new file mode 100644
index 0000000..f175747
--- /dev/null
+++ b/messages.h
@@ -0,0 +1,15 @@
+#ifndef MESSAGE_H
+#define MESSAGE_H
+
+#define MESSAGE_PUSH_NONFASTFORWARD 0
+
+struct message_preference {
+ const char *name;
+ int preference;
+};
+
+extern struct message_preference messages[];
+
+int git_default_message_config(const char *var, const char *value);
+
+#endif /* MESSAGE_H */
--
1.6.4.2.266.g981efc.dirty
^ permalink raw reply related
* [PATCH 2/4] push: re-flow non-fast-forward message
From: Jeff King @ 2009-09-06 6:47 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906064454.GA1643@coredump.intra.peff.net>
The extreme raggedness of the right edge make this jarring
to read. Let's re-flow the text to fill the lines in a more
even way.
Signed-off-by: Jeff King <peff@peff.net>
---
I am actually not all that fond of the particular wording, either, but I
didn't want to re-open a wording bikeshed debate.
builtin-push.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 8d72cc2..787011f 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -158,9 +158,9 @@ static int do_push(const char *repo, int flags)
error("failed to push some refs to '%s'", url[i]);
if (nonfastforward) {
- printf("To prevent you from losing history, non-fast-forward updates were rejected.\n"
- "Merge the remote changes before pushing again.\n"
- "See the 'non-fast forward' section of 'git push --help' for details.\n");
+ printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
+ "Merge the remote changes before pushing again. See the 'non-fast forward'\n"
+ "section of 'git push --help' for details.\n");
}
errs++;
}
--
1.6.4.2.266.g981efc.dirty
^ permalink raw reply related
* [PATCH 1/4] push: fix english in non-fast-forward message
From: Jeff King @ 2009-09-06 6:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906064454.GA1643@coredump.intra.peff.net>
We must use an article when referring to the section
because it is a non-proper noun, and it must be the definite
article because we are referring to a specific section.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 67f6d96..8d72cc2 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -160,7 +160,7 @@ static int do_push(const char *repo, int flags)
if (nonfastforward) {
printf("To prevent you from losing history, non-fast-forward updates were rejected.\n"
"Merge the remote changes before pushing again.\n"
- "See 'non-fast forward' section of 'git push --help' for details.\n");
+ "See the 'non-fast forward' section of 'git push --help' for details.\n");
}
errs++;
}
--
1.6.4.2.266.g981efc.dirty
^ permalink raw reply related
* [RFC/PATCH 0/4] make helpful messages optional
From: Jeff King @ 2009-09-06 6:44 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090811120313.6117@nanako3.lavabit.com>
On Tue, Aug 11, 2009 at 12:03:13PM +0900, Nanako Shiraishi wrote:
> error("failed to push some refs to '%s'", url[i]);
> + if (nonfastforward) {
> + printf("To prevent you from losing history, non-fast-forward updates were rejected.\n"
> + "Merge the remote changes before pushing again.\n"
> + "See 'non-fast forward' section of 'git push --help' for details.\n");
> + }
I saw this message in regular use for the first time today, and I
thought it was terribly ugly. The sheer number of lines, coupled with
the extremely ragged right edge made it much harder to pick out the
nicely formatted status table. And of course the information in the
message was totally worthless to me, as an experienced git user.
So rather than re-open the debate on whether this message should exist
or not, here is a patch series which tries to address the issue:
[1/4]: push: fix english in non-fast-forward message
Hopefully non-controversial.
[2/4]: push: re-flow non-fast-forward message
This makes it prettier, IMHO. I suspect the message was flowed as
it was originally on purpose so that each sentence began on its own
line. I think making it easier on the eyes is more important,
though.
[3/4]: push: make non-fast-forward help message configurable
I feel like we have had this exact sort of tension before: we want
one thing to help new users and experienced users want another
thing. We have resisted an "expert user" config variable in the past
because proposals usually involved a change of behavior, which could
lead to quite confusing results. However, I think the case of
"helpful messages" is much simpler. The message is meant purely for
human consumption and is redundant with information already given,
so an expert sitting at a novice's terminal (or vice versa) will not
encounter any surprises.
This actually introduces infrastructure for other, similar messages,
so that we can make existing ones optional, or build new ones as
appropriate.
[4/4]: status: make "how to stage" messages optional
This uses the infrastructure in 3/4 to lose the "use git add to add
untracked files" advice.
I think (1) and (2) are pretty straightforward. (3) and (4) are more
questionable, and I am undecided whether I am over-reacting to being
annoyed by the message. I do know this is not the first time I have had
the urge to write such a patch, so maybe others feel the same.
-Peff
^ permalink raw reply
* Re: [PATCH 0/9] War on blank-at-eof
From: Junio C Hamano @ 2009-09-06 6:13 UTC (permalink / raw)
To: Thell Fowler; +Cc: git
In-Reply-To: <alpine.WNT.2.00.0909051534380.7040@GWNotebook>
Thell Fowler <git@tbfowler.name> writes:
> While thinking about what appeared in:
>
> http://article.gmane.org/gmane.comp.version-control.git/124138
Oh, I forgot all about that one. The suggestion does include two very
good points, one being "git apply" which I did, and the other being what I
completely forgot. Introduction of blank-at-eol and blank-at-eof, and
make trailing-space a convenience synonym that triggers both.
Thanks for a reminder. The following patch can come on top of the
series.
-- >8 --
Subject: core.whitespace: split trailing-space into blank-at-{eol,eof}
People who configured trailing-space depended on it to catch both extra
white space at the end of line, and extra blank lines at the end of file.
Earlier attempt to introduce only blank-at-eof gave them an escape hatch
to keep the old behaviour, but it is a regression until they explicitly
specify the new error class.
This introduces a blank-at-eol that only catches extra white space at the
end of line, and makes the traditional trailing-space a convenient synonym
to catch both blank-at-eol and blank-at-eof. This way, people who used
trailing-space continue to catch both classes of errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 5 ++++-
cache.h | 5 +++--
ws.c | 24 +++++++++++++++---------
3 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 871384e..0e245a7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -382,7 +382,7 @@ core.whitespace::
consider them as errors. You can prefix `-` to disable
any of them (e.g. `-trailing-space`):
+
-* `trailing-space` treats trailing whitespaces at the end of the line
+* `blank-at-eol` treats trailing whitespaces at the end of the line
as an error (enabled by default).
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
@@ -391,11 +391,14 @@ core.whitespace::
space characters as an error (not enabled by default).
* `blank-at-eof` treats blank lines added at the end of file as an error
(enabled by default).
+* `trailing-space` is a short-hand to cover both `blank-at-eol` and
+ `blank-at-eof`.
* `cr-at-eol` treats a carriage-return at the end of line as
part of the line terminator, i.e. with it, `trailing-space`
does not trigger if the character before such a carriage-return
is not a whitespace (not enabled by default).
+
core.fsyncobjectfiles::
This boolean will enable 'fsync()' when writing object files.
+
diff --git a/cache.h b/cache.h
index 7152fea..ee12e74 100644
--- a/cache.h
+++ b/cache.h
@@ -841,12 +841,13 @@ void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, i
* whitespace rules.
* used by both diff and apply
*/
-#define WS_TRAILING_SPACE 01
+#define WS_BLANK_AT_EOL 01
#define WS_SPACE_BEFORE_TAB 02
#define WS_INDENT_WITH_NON_TAB 04
#define WS_CR_AT_EOL 010
#define WS_BLANK_AT_EOF 020
-#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB|WS_BLANK_AT_EOF)
+#define WS_TRAILING_SPACE (WS_BLANK_AT_EOL|WS_BLANK_AT_EOF)
+#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
extern unsigned whitespace_rule_cfg;
extern unsigned whitespace_rule(const char *);
extern unsigned parse_whitespace_rule(const char *);
diff --git a/ws.c b/ws.c
index d56636b..cd03bc0 100644
--- a/ws.c
+++ b/ws.c
@@ -15,6 +15,7 @@ static struct whitespace_rule {
{ "space-before-tab", WS_SPACE_BEFORE_TAB },
{ "indent-with-non-tab", WS_INDENT_WITH_NON_TAB },
{ "cr-at-eol", WS_CR_AT_EOL },
+ { "blank-at-eol", WS_BLANK_AT_EOL },
{ "blank-at-eof", WS_BLANK_AT_EOF },
};
@@ -101,9 +102,19 @@ unsigned whitespace_rule(const char *pathname)
char *whitespace_error_string(unsigned ws)
{
struct strbuf err;
+
strbuf_init(&err, 0);
- if (ws & WS_TRAILING_SPACE)
+ if ((ws & WS_TRAILING_SPACE) == WS_TRAILING_SPACE)
strbuf_addstr(&err, "trailing whitespace");
+ else {
+ if (ws & WS_BLANK_AT_EOL)
+ strbuf_addstr(&err, "trailing whitespace");
+ if (ws & WS_BLANK_AT_EOF) {
+ if (err.len)
+ strbuf_addstr(&err, ", ");
+ strbuf_addstr(&err, "new blank line at EOF");
+ }
+ }
if (ws & WS_SPACE_BEFORE_TAB) {
if (err.len)
strbuf_addstr(&err, ", ");
@@ -114,11 +125,6 @@ char *whitespace_error_string(unsigned ws)
strbuf_addstr(&err, ", ");
strbuf_addstr(&err, "indent with spaces");
}
- if (ws & WS_BLANK_AT_EOF) {
- if (err.len)
- strbuf_addstr(&err, ", ");
- strbuf_addstr(&err, "new blank line at EOF");
- }
return strbuf_detach(&err, NULL);
}
@@ -146,11 +152,11 @@ static unsigned ws_check_emit_1(const char *line, int len, unsigned ws_rule,
}
/* Check for trailing whitespace. */
- if (ws_rule & WS_TRAILING_SPACE) {
+ if (ws_rule & WS_BLANK_AT_EOL) {
for (i = len - 1; i >= 0; i--) {
if (isspace(line[i])) {
trailing_whitespace = i;
- result |= WS_TRAILING_SPACE;
+ result |= WS_BLANK_AT_EOL;
}
else
break;
@@ -266,7 +272,7 @@ int ws_fix_copy(char *dst, const char *src, int len, unsigned ws_rule, int *erro
/*
* Strip trailing whitespace
*/
- if ((ws_rule & WS_TRAILING_SPACE) &&
+ if ((ws_rule & WS_BLANK_AT_EOL) &&
(2 <= len && isspace(src[len-2]))) {
if (src[len - 1] == '\n') {
add_nl_to_tail = 1;
--
1.6.4.2.313.g0425f
^ permalink raw reply related
* [ANNOUNCE]TortoiseGit 1.0.2.0 release
From: Frank Li @ 2009-09-06 5:27 UTC (permalink / raw)
To: tortoisegit-dev, tortoisegit-users, tortoisegit-announce, git
Download:
http://tortoisegit.googlecode.com/files/TortoiseGit-1.0.2.0-64bit.msi
http://tortoisegit.googlecode.com/files/TortoiseGit-1.0.2.0-32bit.msi
= Release 1.0.2.0 =
== Bug Fix ==
* Fixed issue #155: Fix SVN Rebase sets upstream as remotes/trunk
* Fixed issue #157: Move progress dlg before rebase dialog SVN Rebase
doesn't fast-forward
= Release 1.0.1.0 =
== Features ==
* Improve Commit Dialog
Show line and column number
Add view/hide patch windows
* Improve Log Dialog
Bolad subject at log dialog
* Setting Config Dialog
Add core.autocrlf and core.safecrlf
* Add more option to resolve conflict
Add Resolve "Their" and Resolve "Mine" at conflict item.
* Improve Merge dialog
Add message box to allow input message when merge
* Improve Stash
Add Stash pop.
Add delete stash at logview.
== Bug Fix ==
* Fix don't show "push" after commit
* Fixed issue #133: Command fails on folder with leading dash And --
to separate file and git options
* Fixed issue #133: (mv\rename problem) Command fails on folder with
leading dash And -- to separate file and git options
* Fixed issue #140: Incorrect treatment of "Cancel" action on "Apply
patch serial" command
* Fixed Issue #135: Taskbar text says "TortoiseSVN"
* Fix Issue #142: TortoiseGit Clone of SVN repo does not use PuTTY
session for non-standard SSH port
* Fixed Issue #138: "Format patch" in "Show log" dialog doesn't work
* Fixed Issue #141: Bizarre ordering in commit dialog
* Fixed Issue #137: Proxy Authentification fails
* Fixed issue #131: Missing SVN DCommit Command
* Fixed issue #139: "Format patch" with a range of revisions doesn't
export the first revision in the range
* Fix Pathwatcher thread can't stop when commitdlg exit.
* Fixed issue #150: When pushing, 'remote' should default to the
tracked branch, or empty
^ permalink raw reply
* Re: [PATCH] make shallow repository deepening more network efficient
From: Junio C Hamano @ 2009-09-06 5:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, git
In-Reply-To: <alpine.LFD.2.00.0909031847520.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> First of all, I can't find any reason why thin pack generation is
> explicitly disabled when dealing with a shallow repository. The
> possible delta base objects are collected from the edge commits which
> are always obtained through history walking with the same shallow refs
> as the client, Therefore the client is always going to have those base
> objects available. So let's remove that restriction.
>
> Then we can make shallow repository deepening much more efficient by
> using the remote's unshallowed commits as edge commits to get preferred
> base objects for thin pack generation. On git.git, this makes the data
> transfer for the deepening of a shallow repository from depth 1 to depth 2
> around 134 KB instead of 3.68 MB.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
Dscho, this is your code from around ed09aef (support fetching into a
shallow repository, 2006-10-30) and f53514b (allow deepening of a shallow
repository, 2006-10-30). The latter disables thin pack transfer but the
log does not attempt to justify the change.
Have any comments?
> diff --git a/upload-pack.c b/upload-pack.c
> index f73e3c9..c77ab71 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -32,6 +32,7 @@ static int no_progress, daemon_mode;
> static int shallow_nr;
> static struct object_array have_obj;
> static struct object_array want_obj;
> +static struct object_array extra_edge_obj;
> static unsigned int timeout;
> /* 0 for no sideband,
> * otherwise maximum packet size (up to 65520 bytes).
> @@ -135,6 +136,10 @@ static int do_rev_list(int fd, void *create_full_pack)
> if (prepare_revision_walk(&revs))
> die("revision walk setup failed");
> mark_edges_uninteresting(revs.commits, &revs, show_edge);
> + if (use_thin_pack)
> + for (i = 0; i < extra_edge_obj.nr; i++)
> + fprintf(pack_pipe, "-%s\n", sha1_to_hex(
> + extra_edge_obj.objects[i].item->sha1));
> traverse_commit_list(&revs, show_commit, show_object, NULL);
> fflush(pack_pipe);
> fclose(pack_pipe);
> @@ -562,7 +567,6 @@ static void receive_needs(void)
> if (!prefixcmp(line, "shallow ")) {
> unsigned char sha1[20];
> struct object *object;
> - use_thin_pack = 0;
> if (get_sha1(line + 8, sha1))
> die("invalid shallow line: %s", line);
> object = parse_object(sha1);
> @@ -574,7 +578,6 @@ static void receive_needs(void)
> }
> if (!prefixcmp(line, "deepen ")) {
> char *end;
> - use_thin_pack = 0;
> depth = strtol(line + 7, &end, 0);
> if (end == line + 7 || depth <= 0)
> die("Invalid deepen: %s", line);
> @@ -657,6 +660,7 @@ static void receive_needs(void)
> NULL, &want_obj);
> parents = parents->next;
> }
> + add_object_array(object, NULL, &extra_edge_obj);
> }
> /* make sure commit traversal conforms to client */
> register_shallow(object->sha1);
^ permalink raw reply
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Eric Wong @ 2009-09-06 1:48 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1252140904.8992.6.camel@localhost>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> 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?
Yes.
--
Eric Wong
^ permalink raw reply
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Junio C Hamano @ 2009-09-06 0:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Aguilar, Christoph Haas, git
In-Reply-To: <7vab191dz1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Aguilar <davvid@gmail.com> writes:
>
>> Does anyone else on the list have any insights?
>
> Yes; the problem does not have anything to do with renames but
> unfortunately is much deeper. See $gmane/127783.
>
> Here is a reproduction recipe for the lowest-level ingredient of the
> breakage in "git read-tree -m"that needs to be fixed, before we can start
> looking at what "git merge-recursive" does incorrectly (if any) and what
> "git merge" does incorrectly (again, if any).
To summarize the expected failure in this test, we merge these three trees:
$ git ls-tree -t -r ONE
040000 tree fd43cc879db368e808a98b81005d6f21a8852a15 t
100644 blob d00491fd7e5bb6fa28c517a0bb32b8b506539d4d t/f
$ git ls-tree -t -r TWO
100644 blob 0cfbf08886fca9a91cb753ec8734c84fcbe52c9f t
100644 blob 0cfbf08886fca9a91cb753ec8734c84fcbe52c9f t-f
$ git ls-tree -t -r THREE
100644 blob 00750edc07d6415dcc07ae0351e9397b0222b7ba t-f
040000 tree 5b372f88770ab124f5149bc6eae19714b16ee363 t
100644 blob 00750edc07d6415dcc07ae0351e9397b0222b7ba t/f
while the index matches TWO. The callback to unpack_trees() wants to get
"t" fed by the tree-walk API in a single call, but it is hard to arrange,
as in tree TWO the name "t-f" comes after name "t" and in tree THREE it
comes before "t". When other trees want to yield "t", somebody in the
callchain needs to notice the situation, and yield "t" from tree THREE,
and then later yield "t-f", to meet the expectation of unpack_trees().
I was staring at this a bit more until my head started aching, and my
tentative conclusion is that the cleanest solution would be to change
tree-walk API so that it returns the entries in the order as if everything
were blobs. E.g. even though in tree THREE, a subtree "t" is stored after
blob "t-f", we return "t". Later, when told to update_tree_entry(), skip
back and yield "t-f". After that when told to update_tree_entry(), notice
we have already given "t" back and skip to finish traversing THREE.
This would be necessary because unpack_callback() in unpack-trees.c wants
to see if the entry of the same name happens to be at the o->pos in the
index. What it means is if all trees being merged (including TWO, that is
supposed to be similar to the index) had "t" as tree and "t-f" as blob, if
the index had "t-f" and "t" both as blobs, we would not be able to match
up the "t" (tree) entries from the merged trees with "t" (blob) entry
taken from the index.
Unfortunately, the callers of tree-walk API checks desc->size to see if
the traversal reached at the end before calling update_tree_entry(), so
the safest and simplest fix might end up to be sorting the tree buffer in
init_tree_desc().
What do you think? Am I completely off the track?
> t/t1004-read-tree-m-u-wf.sh | 23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
> index f19b4a2..055bb00 100755
> --- a/t/t1004-read-tree-m-u-wf.sh
> +++ b/t/t1004-read-tree-m-u-wf.sh
> @@ -238,4 +238,27 @@ test_expect_success 'D/F recursive' '
>
> '
>
> +################################################################
> +
> +test_expect_failure 'D/F D-F' '
> + git reset --hard &&
> + git rm -f -r . &&
> +
> + mkdir t && echo 1 >t/f && git add t &&
> + git tag ONE $(git write-tree) &&
> +
> + echo 3 >t-f && echo 3 >t/f && git add t-f t &&
> + git tag THREE $(git write-tree) &&
> +
> + git rm -f -r t &&
> + echo 2 >t && echo 2 >t-f && git add t t-f &&
> + git tag TWO $(git write-tree) &&
> + git commit -a -m TWO &&
> +
> + test_must_fail git read-tree -m -u ONE TWO THREE &&
> + git ls-files -u >actual &&
> + grep t/f actual &&
> + grep t-f actual
> +'
> +
> test_done
^ permalink raw reply
* Re: 'add -u' without path is relative to cwd
From: Junio C Hamano @ 2009-09-05 21:46 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905184508.GA20124@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> I can only guess that you mean the "sane way for script writers to defeat
> the configuration without much pain" part. But I'm not sure how that's a
> problem. If you want the script to continue to work as before you either
> configure "workdir scope", or you add a '.' to the affected commands.
One who writes the script and lends it to you may be using different
`scope` from what the recipient uses, so that is not an escape hatch at
all.
One crudest form of workaround may be for your code to notice an
environment variable to override that `scope` configuration setting, so
that you can advise the script writers to set it in their script. But
that is so ugly I'd rather not go there if we do not absolutely have to.
That is why in general we should be very careful and avoid any magic that
makes the same command behave completely differently depending on how a
repository is configured.
^ permalink raw reply
* Re: [PATCH 0/9] War on blank-at-eof
From: Thell Fowler @ 2009-09-05 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1252061718-11579-1-git-send-email-gitster@pobox.com>
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Patch 5 corrects the definition of blank-at-eof. If a patch adds an
> non-empty line that consists solely of whitespaces at the end of file, we
> should diagnose and strip it just line a new empty line. After all, both
> are blank lines.
>
Thank you. Thank you, thank you. Thank you! And did I mention thank you?
Tested this out after cherry-picking:
3b5ef0e xutils: Fix xdl_recmatch() on incomplete lines
78ed710 xutils: Fix hashing an incomplete line with whitespaces at the end
It worked as nicely! I'm throwing away the --allow-whitelines-at-eof
patch! :D Converting a _real_ dirty whitespace branch into an 'almost'
whitespace policy compliant branch with validation of the diffs was
able to be done like so:
git diff -b DIRTY CLEAN
git diff DIRTY^ CLEAN > diff1
git diff CLEAN^ DIRTY > diff2
git diff -b diff1 diff2
I mention 'almost' above because unfortunately this type of conversion
leaves extra line-spaces at the end of some files that you might not want
to have in a whitespace policy.
While thinking about what appeared in:
http://article.gmane.org/gmane.comp.version-control.git/124138
Junio C Hamano <gitster <at> pobox.com> writes:
>Bruno Haible <bruno <at> clisp.org> writes:
>> In some GNU projects, there are file types for which trailing spaces in a line
>> ...
>> Currently the user has to turn off the 'trailing-space' whitespace attribute
>> in order for 'git diff --check' to not complain about such files. This has
>> the drawback that trailing spaces are not detected.
>Very good problem description. Thanks.
I thought it might be interesting to throw this out there... What do you
think of an additional attribute value like
core.whitespace blank-at-eof-min-<some 0 to N #>
core.whitespace blank-at-eof-max-<some 0 to N #>
that could be read in when core.whitespace blank-at-eof is set.
If neither are present then use current. (No new eof blanks).
If min but not max is set then allow new blanks and ensure at least min.
If max but not min is set then only allow max blanks at eof.
If both then treat it as a boundary.
This could ensure a whitespace policy without the repository maintainer
having to correct this type of minutia and without having to nit-pick
contributors into submission.
Then perhaps diff could also recognize an in range blank-at-eof so a diff
using one of the ignore whitespace options would ignore eof whitelines
that are in range?
> The series applies to v1.6.0.6-87-g82d97da; merging the result to 'master'
> needs some conflict resolution.
>
--
Thell
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Clemens Buchacher @ 2009-09-05 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7veiql1etz.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 10:28:08AM -0700, Junio C Hamano wrote:
> But notice that the above is qualified with "personally". An alternative
> would be to declare that in 1.8.0, all commands run without path argument
> will work on the whole tree and you have to give an explicit '.' when you
> want to limit their effect to the cwd.
That's fine by me.
[...]
>
> Please also see:
>
> Message-ID: <7vy6ot4x61.fsf@alter.siamese.dyndns.org> ($gmane/127795)
>
> think about the three questions there, and help us move the discussion
> forward.
The patch is my way of saying that I'm not just whining, but that I'm
willing to put some effort into getting this done. I am aware of the issues
you raised in the above message and I was hoping that my patch would help us
as a starting point to move the discussion forward.
> The first part of the message has some comments related to your patch, by
> the way.
I can only guess that you mean the "sane way for script writers to defeat
the configuration without much pain" part. But I'm not sure how that's a
problem. If you want the script to continue to work as before you either
configure "workdir scope", or you add a '.' to the affected commands.
Clemens
^ permalink raw reply
* Re: tracking branch for a rebase
From: Junio C Hamano @ 2009-09-05 17:59 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Jeff King, Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090905140127.GA29037@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> For me, the confusion would arise from the fact that "git rebase"
> (without args) would seem like a "pull --rebase" without the fetch, but
> isn't.
It is true that one popular way to explain 'git pull' is:
'git pull' is 'git fetch' followed by 'git merge'.
These three command names in the sentence merely refer to the concepts of
what they do.
It is left up to the readers to extend the concepts to concrete command
line to suit the needs for their situation. For example you would
restate the above general explanation into this form:
'git pull git.git master' is 'git fetch git.git master' followed by
'git merge FETCH_HEAD'
when updating your tree with the master branch of upstream git.git
repository.
Don't confuse the general concept with concrete syntax.
'git pull --rebase' is 'git fetch' followed by 'git rebase'
is exactly the same deal.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jakub Narebski @ 2009-09-05 17:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, Jeff King, SZEDER Gabor, git
In-Reply-To: <7veiql1etz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > "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.
>
> Limit the scope of what you see in "ls" (no argument) output, shorten the
> paths you must type to non-git commands. They are the kind of "limit the
> scope" I meant, and they are totally versioning-unrelated. In other
> words, cwd-centric default helps the users (especially the new ones) by
> making git behave consistently with other commands.
Well, there is still complication that some commands are considered
whole-tree in absence of pathspec, like "git commit".
>
> So if anything, I personally think it would be much less surprising if all
> git commands worked relative to the cwd (not whole tree root) when run
> without path argument, at least from the newbie's point of view [*1*].
I think it would be very suprising if "git commit" in subdirectory was
limited to changes affecting given subdirectory...
>
> But notice that the above is qualified with "personally". An alternative
> would be to declare that in 1.8.0, all commands run without path argument
> will work on the whole tree and you have to give an explicit '.' when you
> want to limit their effect to the cwd.
>
> This may be slightly less intuitive to newbies than the "relative to cwd",
> but nevertheless that is the course I would suggest us taking, because of
> the following observations:
>
> (1) if the commands work on the whole tree when run without paths, it is
> easy to limit to the cwd with "git frotz ." when you want to.
>
> (2) if the commands work on the cwd when run without paths, you have to
> always be aware how deep you are, and say "git frotz ../../.." when
> you want to extend their effects to the whole tree.
>
> The latter is much more irritating.
Well, we can always invent some magic notation meaning either "up to
top directory", e.g. make
$ git frotz ...
more or less equivalent to
$ git frotz "$(git rev-parse --show-cdup)"
(The other solution of having "git frotz /" to refer to top directory
is slightly worse, because there are git commands that work without
git repository, and "/" is legitimate parameter, like e.g. for
"git diff --no-index").
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Junio C Hamano @ 2009-09-05 17:46 UTC (permalink / raw)
To: David Aguilar; +Cc: Christoph Haas, git
In-Reply-To: <20090904234552.GA43797@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Does anyone else on the list have any insights?
Yes; the problem does not have anything to do with renames but
unfortunately is much deeper. See $gmane/127783.
Here is a reproduction recipe for the lowest-level ingredient of the
breakage in "git read-tree -m"that needs to be fixed, before we can start
looking at what "git merge-recursive" does incorrectly (if any) and what
"git merge" does incorrectly (again, if any).
t/t1004-read-tree-m-u-wf.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh
index f19b4a2..055bb00 100755
--- a/t/t1004-read-tree-m-u-wf.sh
+++ b/t/t1004-read-tree-m-u-wf.sh
@@ -238,4 +238,27 @@ test_expect_success 'D/F recursive' '
'
+################################################################
+
+test_expect_failure 'D/F D-F' '
+ git reset --hard &&
+ git rm -f -r . &&
+
+ mkdir t && echo 1 >t/f && git add t &&
+ git tag ONE $(git write-tree) &&
+
+ echo 3 >t-f && echo 3 >t/f && git add t-f t &&
+ git tag THREE $(git write-tree) &&
+
+ git rm -f -r t &&
+ echo 2 >t && echo 2 >t-f && git add t t-f &&
+ git tag TWO $(git write-tree) &&
+ git commit -a -m TWO &&
+
+ test_must_fail git read-tree -m -u ONE TWO THREE &&
+ git ls-files -u >actual &&
+ grep t/f actual &&
+ grep t-f actual
+'
+
test_done
^ permalink raw reply related
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 17:28 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905084641.GA24865@darc.dnsalias.org>
Clemens Buchacher <drizzd@aon.at> writes:
> "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.
Limit the scope of what you see in "ls" (no argument) output, shorten the
paths you must type to non-git commands. They are the kind of "limit the
scope" I meant, and they are totally versioning-unrelated. In other
words, cwd-centric default helps the users (especially the new ones) by
making git behave consistently with other commands.
So if anything, I personally think it would be much less surprising if all
git commands worked relative to the cwd (not whole tree root) when run
without path argument, at least from the newbie's point of view [*1*].
But notice that the above is qualified with "personally". An alternative
would be to declare that in 1.8.0, all commands run without path argument
will work on the whole tree and you have to give an explicit '.' when you
want to limit their effect to the cwd.
This may be slightly less intuitive to newbies than the "relative to cwd",
but nevertheless that is the course I would suggest us taking, because of
the following observations:
(1) if the commands work on the whole tree when run without paths, it is
easy to limit to the cwd with "git frotz ." when you want to.
(2) if the commands work on the cwd when run without paths, you have to
always be aware how deep you are, and say "git frotz ../../.." when
you want to extend their effects to the whole tree.
The latter is much more irritating.
Please also see:
Message-ID: <7vy6ot4x61.fsf@alter.siamese.dyndns.org> ($gmane/127795)
think about the three questions there, and help us move the discussion
forward.
The first part of the message has some comments related to your patch, by
the way.
[Footnote]
*1* Except for the ones that cannot make any sense to limit their
operation to a subdirectory you happen to be in (e.g. it would be insane
if "git am" run to accept somebody's patch ignored paths outside your
cwd).
^ permalink raw reply
* Re: Use case I don't know how to address
From: Johannes Sixt @ 2009-09-05 17:23 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <4AA20CEC.8060408@chandlerfamily.org.uk>
On Samstag, 5. September 2009, Alan Chandler wrote:
> The problem comes when I want to now merge back further work that I did
> on the master branch (the 5-6 transition) to the fan club site
>
>
> 2' - 2a - 3' - 4' ----------------- 6' SITE
> / / / /
> 1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
> \ /
> 5 ------ 6 MASTER
> \ \
> 5''- 5a- 6'' DEMO
>
>
> What will happen is the changes made in 4->5 will get applied to the
> (now) Test branch as part of the 6->6'' merge, and I will be left having
> to add a new commit, 6a, to undo them all again. Given this is likely
> to be quite a substantial change I want to try and avoid it if possible.
>
> Is there any way I could use git to remember the 4->5 transition,
> reverse it and apply it back to the Test branch before hand.
Basically, your mistake was to rename master to test and continue development
on the demo branch. So what you should do instead is this:
2' - 2a - 3' - 4' ------ 6' SITE
/ / / /
1 - 2 ------ 3 - 4 ------- 6 MASTER
\ \
5 - 5a - 6'' DEMO
IOW, you keep developing on master, and merge that into the two deployment
branches.
In practice, it may be easier to develop commit 6 on DEMO (because you can
debug it more easily, or for similar reasons), but then you should rebase it
back to MASTER, reset DEMO back to 5a, and finally merge MASTER into DEMO.
-- Hannes
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-05 16:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Douglas Campos, Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <200909051825.49619.robin.rosenberg.lists@dewire.com>
Haven't counted it, but I will check it.
Please note that for running the tests previously in 'exttest' you have to activate the tck profile:
$> mvn test -Ptck
And yes, we currently only run *Test.java. Any other patterns/files to include?
txs and LieGrue,
strub
--- On Sat, 9/5/09, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Douglas Campos" <douglas@theros.info>, "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Saturday, September 5, 2009, 6:25 PM
> fredag 04 september 2009 19:28:39
> skrev Mark Struberg <struberg@yahoo.de>:
> > Hi!
> >
> > Work has been done at
> >
> > http://github.com/sonatype/JGit/tree/mavenize
> >
> > Please feel free to pull/fork and share your changes!
> I'd be happy to pull it in.
> >
>
> Why does this new mvn test only execute 1024 tests here,
> while the old maven setup
> does 1108 ones? It seems the classes that don't match
> *Test.java are omitted.
>
> In both cases I invoke with "mvn clean test"
>
> -- robin
>
^ permalink raw reply
* Re: [JGIT] Request for help
From: Robin Rosenberg @ 2009-09-05 16:25 UTC (permalink / raw)
To: Mark Struberg; +Cc: Douglas Campos, Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <658028.86274.qm@web27804.mail.ukl.yahoo.com>
fredag 04 september 2009 19:28:39 skrev Mark Struberg <struberg@yahoo.de>:
> Hi!
>
> Work has been done at
>
> http://github.com/sonatype/JGit/tree/mavenize
>
> Please feel free to pull/fork and share your changes! I'd be happy to pull it in.
>
Why does this new mvn test only execute 1024 tests here, while the old maven setup
does 1108 ones? It seems the classes that don't match *Test.java are omitted.
In both cases I invoke with "mvn clean test"
-- robin
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: demerphq @ 2009-09-05 14:58 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, Tim Visher, Git Mailing List
In-Reply-To: <20090905081726.GA7109@coredump.intra.peff.net>
2009/9/5 Jeff King <peff@peff.net>:
> 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).
It would be useful in for instance prompt status line. At $work we
have a number of people using a prompt that includes the result of
parsing git-status, but something --left-right-count would be much
nicer, and if i understand it, more efficient (although maybe im
wrong). In the prompt they use a number of different unicode arrows to
show what has happened, with a Y type thing for diverged.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-05 14:28 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090905140127.GA29037@atjola.homenet>
On Sat, Sep 05, 2009 at 04:01:27PM +0200, Björn Steinbrink wrote:
> > And by automating the shorthand we reduce the chance of errors. For
> > example, I usually base my topic branches from origin/master. But the
> > other day I happened to be building a new branch, jk/date, off of
> > lt/approxidate, salvaged from origin/pu. I did "git rebase -i
> > origin/master" and accidentally rewrote the early part of
> > lt/approxidate.
>
> Hm, I'd prefer a shorthand for "upstream for this branch", instead of
> magic defaults.
The more I think about, the more I think that is the right solution.
Because magic defaults for "rebase -i" don't help when you want to do
"gitk $UPSTREAM..".
The previous discussion on the topic seems to be here:
http://article.gmane.org/gmane.comp.version-control.git/113666
And apparently you and I both participated in the discussion, which I
totally forgot about.
Looks like the discussion ended with people liking the idea but not
knowing what the specifier should look like. Maybe tightening the ref
syntax a bit to allow more extensible "special" refs is a good v1.7.0
topic? I dunno.
> > That wouldn't help me, because you can't "pull -i". :)
>
> I probably shouldn't tell anyone, as it's a crude hack, but "git pull
> --rebase -s -i" does the trick... *hides*
OK, that's just sick. :)
-Peff
^ permalink raw reply
* Re: tracking branch for a rebase
From: Björn Steinbrink @ 2009-09-05 14:01 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090905061250.GA29863@coredump.intra.peff.net>
On 2009.09.05 02:12:50 -0400, Jeff King wrote:
> On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:
>
> > "git pull --rebase" is not the same as:
> > "git fetch origin && git rebase origin/foo", but:
> >
> > git fetch origin && git rebase --onto origin/foo $reflog_merge_base
> >
> > Where $reflog_merge_base is the first merge base is found between the
> > current branch head, and the reflog entries for origin/foo.
>
> Thanks, I didn't know about the trick (not being, as I mentioned, a pull
> --rebase user). I can see arguments for or against a rebase-default
> using that feature. On one hand, it simplifies the explanation for
> people going between "pull --rebase" and "fetch && rebase". And I think
> it should generally Do What You Mean in the case that upstream hasn't
> rebased. Are there cases you know of where it will do the wrong thing?
>
> I don't know if people would be confused that "git rebase" does not
> exactly default to "git rebase $upstream", which is at least easy to
> explain.
For me, the confusion would arise from the fact that "git rebase"
(without args) would seem like a "pull --rebase" without the fetch, but
isn't. And to reducing the difference to just the fetch would require a
quite change in bahaviour.
Currently, when branch.<name>.merge is set:
"git rebase <upstream>" ==> Can't really be done with "pull --rebase"
"git pull --rebase [...]" ==> Can't be done with "rebase" alone.
Currently, "pull" is a convenience thing, and thus may do more magic,
while "rebase" is dumb, and needs arguments. Starting to add _different_
magic to rebase seems wrong to me.
> And by automating the shorthand we reduce the chance of errors. For
> example, I usually base my topic branches from origin/master. But the
> other day I happened to be building a new branch, jk/date, off of
> lt/approxidate, salvaged from origin/pu. I did "git rebase -i
> origin/master" and accidentally rewrote the early part of
> lt/approxidate.
Hm, I'd prefer a shorthand for "upstream for this branch", instead of
magic defaults.
> > Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> > its idea could be taken, so we get "git pull --local" to just skip the
> > fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> > explicit arguments.
>
> That wouldn't help me, because you can't "pull -i". :)
I probably shouldn't tell anyone, as it's a crude hack, but "git pull
--rebase -s -i" does the trick... *hides*
Björn
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #01; Sat, 05)
From: Nicolas Pitre @ 2009-09-05 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocpp3i2l.fsf@alter.siamese.dyndns.org>
On Sat, 5 Sep 2009, Junio C Hamano wrote:
> 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.
Just to make sure you didn't miss the last 2 patches I posted:
Date: Thu, 03 Sep 2009 19:08:33 -0400 (EDT)
Subject: [PATCH] make shallow repository deepening more network efficient
Date: Thu, 03 Sep 2009 21:54:03 -0400 (EDT)
Subject: [PATCH] pack-objects: free preferred base memory after usage
Nicolas
^ permalink raw reply
* [PATCH 2/2 v2] add 'scope' config option
From: Clemens Buchacher @ 2009-09-05 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <20090905123304.GB3099@darc.dnsalias.org>
On Sat, Sep 05, 2009 at 02:33:04PM +0200, Clemens Buchacher wrote:
> - if ((addremove || take_worktree_changes) && !argc) {
> + if (!scope_global && (addremove || take_worktree_changes) && !argc) {
> static const char *here[2] = { ".", NULL };
> argc = 1;
> argv = here;
Ok, scrape that. Seems validate_pathspec does that implicitly already. So
this code was redundant. The attached patch should now work (I tested it
this time...).
It also seems that "git add -A" doesn't work without a pathspec any more?
Was that intentional?
Clemens
--o<--
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/config.txt | 6 ++++++
builtin-add.c | 12 +++++-------
builtin-grep.c | 2 +-
cache.h | 1 +
config.c | 8 ++++++++
environment.c | 1 +
6 files changed, 22 insertions(+), 8 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..737b155 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -285,14 +285,9 @@ 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) {
- static const char *here[2] = { ".", NULL };
- argc = 1;
- argv = here;
- }
add_new_files = !take_worktree_changes && !refresh_only;
- require_pathspec = !take_worktree_changes;
+ require_pathspec = !addremove && !take_worktree_changes;
newfd = hold_locked_index(&lock_file, 1);
@@ -308,7 +303,10 @@ int cmd_add(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Maybe you wanted to say 'git add .'?\n");
return 0;
}
- pathspec = validate_pathspec(argc, argv, prefix);
+ if (scope_global && !argc)
+ pathspec = NULL;
+ else
+ pathspec = validate_pathspec(argc, argv, prefix);
if (read_cache() < 0)
die("index file corrupt");
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.266.gbaa17
^ permalink raw reply related
* 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
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