* 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: 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: 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: [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: '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: 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: 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: [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
* [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 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
* [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
* [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
* [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 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 4/4] status: make "how to stage" messages optional
From: Jeff King @ 2009-09-06 6:50 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906064454.GA1643@coredump.intra.peff.net>
These messages are nice for new users, but experienced git
users know how to manipulate the index, and these messages
waste a lot of screen real estate.
Signed-off-by: Jeff King <peff@peff.net>
---
This also actually cuts out the blank line after the instructions, so:
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: file
#
becomes:
# Changed but not updated:
# modified: file
#
Arguably the blank should be left in.
Documentation/config.txt | 4 ++++
messages.c | 1 +
messages.h | 1 +
wt-status.c | 8 ++++++++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec308a6..cadbfc9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1215,6 +1215,10 @@ message.*::
pushNonFastForward::
Help message shown when linkgit:git-push[1] refuses
non-fast-forward refs. Default: true.
+ statusAdvice::
+ Directions on how to stage/unstage/add shown in the
+ output of linkgit:git-status[1] and the template shown
+ when writing commit messages. Default: true.
--
pack.window::
diff --git a/messages.c b/messages.c
index 00fc196..d2785b2 100644
--- a/messages.c
+++ b/messages.c
@@ -3,6 +3,7 @@
struct message_preference messages[] = {
{ "pushnonfastforward", 1 },
+ { "statusadvice", 1 },
};
int git_default_message_config(const char *var, const char *value)
diff --git a/messages.h b/messages.h
index f175747..8edd08e 100644
--- a/messages.h
+++ b/messages.h
@@ -2,6 +2,7 @@
#define MESSAGE_H
#define MESSAGE_PUSH_NONFASTFORWARD 0
+#define MESSAGE_STATUS_ADVICE 1
struct message_preference {
const char *name;
diff --git a/wt-status.c b/wt-status.c
index 85f3fcb..716d8cc 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -48,6 +48,8 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Unmerged paths:");
+ if (!messages[MESSAGE_STATUS_ADVICE].preference)
+ return;
if (!s->is_initial)
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
else
@@ -60,6 +62,8 @@ static void wt_status_print_cached_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changes to be committed:");
+ if (!messages[MESSAGE_STATUS_ADVICE].preference)
+ return;
if (!s->is_initial) {
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
} else {
@@ -73,6 +77,8 @@ static void wt_status_print_dirty_header(struct wt_status *s,
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changed but not updated:");
+ if (!messages[MESSAGE_STATUS_ADVICE].preference)
+ return;
if (!has_deleted)
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to update what will be committed)");
else
@@ -85,6 +91,8 @@ static void wt_status_print_untracked_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Untracked files:");
+ if (!messages[MESSAGE_STATUS_ADVICE].preference)
+ return;
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to include in what will be committed)");
color_fprintf_ln(s->fp, c, "#");
}
--
1.6.4.2.266.g981efc.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-06 7:09 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906064816.GC28941@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Probably "messages" is too vague a term to use in the code and config.
> Maybe "advice.*"?
I hate to start off with a digression, but one expression from Japanese I
have long been frustrated with, because I cannot find a good counterpart
in English, is "大きなお世話".
J-E dictionaries often translate this phrase as "none of your business",
and it indeed is meant to be thrown at somebody who gives an unsolicited
and an unwanted advice to you, but at the same time it strongly implies
that the reason why such an advice is unwanted is because you very well
knows the issue and does not _need_ (not want) the help on the topic at
all. It is not about _who_ gives the unwanted advice (which I think the
expression "none of YOUR business" talks about---if the same advice came
from somebody else, it might be appreciated), but it is all about on what
topic the advice is about, and you feel that you know about the topic very
well yourself and do not need any advice from anybody.
Enough digression.
I have always felt that many of the messages we have added since the
"newbie friendliness" drive around 1.3.0 deserve to be labeled with the
expression 大きなお世話.
Of course, "unsolicited-unneeded-advice.*" is too long as a variable name,
but I personally would very much welcome changes along this line and I
think "advice.*" is a good name for the category.
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-06 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7v8wgsk0rw.fsf@alter.siamese.dyndns.org>
On Sun, Sep 06, 2009 at 12:09:07AM -0700, Junio C Hamano wrote:
> I hate to start off with a digression, but one expression from Japanese I
> have long been frustrated with, because I cannot find a good counterpart
> in English, is "大きなお世話".
>
> J-E dictionaries often translate this phrase as "none of your business",
> and it indeed is meant to be thrown at somebody who gives an unsolicited
> and an unwanted advice to you, but at the same time it strongly implies
> that the reason why such an advice is unwanted is because you very well
> knows the issue and does not _need_ (not want) the help on the topic at
> all. It is not about _who_ gives the unwanted advice (which I think the
> expression "none of YOUR business" talks about---if the same advice came
> from somebody else, it might be appreciated), but it is all about on what
> topic the advice is about, and you feel that you know about the topic very
> well yourself and do not need any advice from anybody.
The best related English phrase I can think of is that the person is a
"back seat driver". The phrase "armchair $X" also comes to mind (e.g.,
"armchair critic"), though that is usually to indicate that the armchair
critic is giving _bad_ advice, not being well-versed in the field they
are advising about. And I think you are not so much saying the advice is
wrong as much as it is unwanted because you already know it.
I can't think of a noun that describes the advice itself, though
(nagging? ;) ).
> I have always felt that many of the messages we have added since the
> "newbie friendliness" drive around 1.3.0 deserve to be labeled with the
> expression 大きなお世話.
>
> Of course, "unsolicited-unneeded-advice.*" is too long as a variable name,
> but I personally would very much welcome changes along this line and I
> think "advice.*" is a good name for the category.
Git config files are utf8, right? You can always internationalize this
feature. :)
Thinking on it more, I think "advice" is the right word. It is not about
arbitrary messages; it is about particular messages which try to advise.
You would never want this feature to cover messages that are
informational about a particular state or action that has occurred. Only
"maybe you should try this" messages.
I'll re-roll 3 and 4 based on that, but I will wait a bit to see any
more comments. Probably you should consider patches 1 and 2 as a
potential series for 'maint', and 3 and 4 should be spun off into their
own series (they really only rely textually on the first two).
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-06 7:30 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906072322.GA29949@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'll re-roll 3 and 4 based on that, but I will wait a bit to see any
> more comments. Probably you should consider patches 1 and 2 as a
> potential series for 'maint', and 3 and 4 should be spun off into their
> own series (they really only rely textually on the first two).
Yeah, thanks.
And no need to hurry. I've decided to queue 1 and 2 to 'master' (was
Nana's reroll of Matthieu's patch on 'maint'???) and 3 and 4 merged to
'pu', but I seem to be having a problem ssh'ing into k.org, and it appears
that no pushout will happen tonight.
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-06 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7vocpoh6nt.fsf@alter.siamese.dyndns.org>
On Sun, Sep 06, 2009 at 12:30:14AM -0700, Junio C Hamano wrote:
> And no need to hurry. I've decided to queue 1 and 2 to 'master' (was
> Nana's reroll of Matthieu's patch on 'maint'???) and 3 and 4 merged to
It was on 'maint', which surprised me, too. But v1.6.4.1 got it.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-06 7:52 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906072322.GA29949@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Thinking on it more, I think "advice" is the right word. It is not about
> arbitrary messages; it is about particular messages which try to advise.
> You would never want this feature to cover messages that are
> informational about a particular state or action that has occurred. Only
> "maybe you should try this" messages.
Speaking of which, has anybody felt annoyed by this message?
$ git reset --hard HEAD^^
HEAD is now at 3fb9d58 Do not scramble password read from .cvspass
This is not "maybe you should try this", but I would consider that it
falls into the same "I see you are trying to be helpful, but I know what I
am doing, and you are stealing screen real estate from me without helping
me at all, thank you very much" category.
Besides, if you want to use "where you are" to your next command, you can
just say HEAD without knowing exactly where you are.
It might be slightly more useful if the message said this instead:
$ git reset --hard HEAD^^
HEAD was at d1fe49f push: re-flow non-fast-forward message
Resetting is done because I want to build an alternate history starting
from an earlier point, and when I am done, I may want to feed this to "git
diff" or whatever to sanity check the result, without having to go through
the reflog.
^ permalink raw reply
* Re: Use case I don't know how to address
From: Junio C Hamano @ 2009-09-06 8:03 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <4AA20CEC.8060408@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> 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.
I presume 6'''-6a has the revert of 4-5? If so, the next merge should
work just fine.
You have arranged TEST->SITE transition correctly to limiting the SITE
customization to 2a and never merging SITE back to TEST, so we can ignore
SITE branch altogether from now on. Similarly we can ignore DEMO branch,
since its customization is limited to 5a and it never gets merged back to
MASTER.
1 - 2 ------ 3 - 4 ------------6'''- 6a-----7a??? TEST
\ / /
5 ------ 6------------7 MASTER
Now, 6-7 is a new feature built on MASTER. What would happen when it is
merged to TEST to produce 7a?
The merge base for this merge is 6, and since that commit to the tip of
the TEST branch 6a, there is a "skin from vanilla to FanClub" change and
nothing else. On the other hand, since the merge base to the tip of the
MASTER branch 7, there is a "feature enhancement" but no skin related
changes.
So bog-standard three-way merge should say:
- One branch, MASTER, added these features, but TEST branch did not do
anything with these feature changes since the merge base. We'll use
the feature change done on MASTER.
- The other branch, TEST, changed the skin from the merge base, but
MASTER branch did not change any skinning. We'll keep the skin change
done on TEST.
And everything should be fine.
^ permalink raw reply
* Re: [PATCH/RFC 2/6] docs: note that status configuration affects only long format
From: Junio C Hamano @ 2009-09-06 8:04 UTC (permalink / raw)
To: Jeff King; +Cc: David Aguilar, Johannes Sixt, bill lam, git
In-Reply-To: <20090905085218.GB13157@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Combined with the --short/--porcelain distinction introduced later in
> the series, should short perhaps respect status.relativePaths and
> status.submoduleSummary?
I think that makes sense.
^ permalink raw reply
* Re: [PATCH/RFC 3/6] status: refactor short-mode printing to its own function
From: Junio C Hamano @ 2009-09-06 8:05 UTC (permalink / raw)
To: Jeff King; +Cc: David Aguilar, Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905085348.GC13157@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
Earlier in the series when "git commit --dry-run" and "git status" still
were the same thing, I checked if the above was feasible and then decided
against it, because they needed to share the option parsing and the index
preparation, and exporting these functions inherently internal to "git
commit" only to use them in "git status" did not make much sense.
But once "git status" does not have anything to do with "git commit", I
think such a separation would become much more sensible.
^ permalink raw reply
* Re: Strange merge failure (would be overwritten by merge / cannot merge)
From: Junio C Hamano @ 2009-09-06 8:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vzl98vrmt.fsf@alter.siamese.dyndns.org>
I was looking at this loop in traverse_trees() from tree-walk.c
for (i = 0; i < n; i++) {
if (!t[i].size)
continue;
entry_extract(t+i, entry+i);
if (last >= 0) {
int cmp = entry_compare(entry+i, entry+last);
/*
* Is the new name bigger than the old one?
* Ignore it
*/
if (cmp > 0)
continue;
/*
* Is the new name smaller than the old one?
* Ignore all old ones
*/
if (cmp < 0)
mask = 0;
}
mask |= 1ul << i;
if (S_ISDIR(entry[i].mode))
dirmask |= 1ul << i;
last = i;
}
The logic to update last breaks down while merging these three trees:
Tree #1: tree "t"
Tree #2: blob "t"
blob "t-f"
Tree #3: blob "t-f"
tree "t"
When looking at Tree #3, "last" points at "t" (blob) from Tree #2
and we decide "t-f" comes later than that to ignore it because "cmp > 0".
We instead somehow need to look ahead and find "t", while remembering to
revisit "t-f" from it in the later rounds (of an outer loop that has this
loop inside).
Also the second comparison to update last breaks down while merging these:
Tree #1: blob "t-f"
tree "t"
Tree #2: blob "t"
Tree #3: blob "t"
blob "t-f"
When looking at Tree #2, "last" points at "t-f" (blob) from Tree #1 and we
decide to use "t" because it sorts earlier. We will match "t" from Tree #3
but we somehow need to go back to Tree #1 and look beyond "t-f" to find
the matchig "t" from there as well, while remembering that we need to
revisit "t-f" from it in the later rounds..
I am thinking about changing the function this way.
(0) take an optional "candidate for the earliest name" from the caller,
in a new member in traverse_info structure. unpack_callback() would
give the path of the index entry it is looking at after stripping the
leading paths as necessary.
(1) find the "earliest name" N among the given trees (and the optional
additional candidate from the above). The "earliest" is computed by
comparing names as if everything were a blob;
(2) for each tree t[i], if the current entry entry[i] compares
differently with N between the cases where the N were a blob and
where N were a tree, and if entry[i] is a blob, a tree with the name
N might be hidden behind it. remember the current position so we can
come back, and scan forward to find such tree (this does not have to
run to the end of the tree), and if we do find one, then instead of
saying "we do not have an entry with that name", use that tree in
entry[i]. This will collect entries with name N from all trees in
the entry[] array;
(3) make the callback as usual; unpack_callback(), after processing this
round with entries with name N, may or may not advance o->pos but if
it did so, it would also update the "candidate for the earliest name"
field passed back in the traverse_info structure to prepare for the
next round.
(4) traverse_trees() will go back to step (0).
The tricky part is step (1) and the latter half of step (2) to skip,
rewind, and avoid re-processing what was processed already after
rewinding, and the progress is much slower than I would like.
^ permalink raw reply
* [PATCH] githooks.txt: put hooks into subsections
From: Bert Wesarg @ 2009-09-06 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Bert Wesarg
All hooks are currently in its own section. Which may confuse users,
because the section name serves as the hook file name and sections are
all caps for man pages. Putting them into a new HOOKS section and each
hook into a subsection keeps the case to lower case.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Documentation/githooks.txt | 33 ++++++++++++++++++---------------
1 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 1c73673..acc408d 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -26,8 +26,11 @@ executable by default.
This document describes the currently defined hooks.
+HOOKS
+-----
+
applypatch-msg
---------------
+~~~~~~~~~~~~~~
This hook is invoked by 'git-am' script. It takes a single
parameter, the name of the file that holds the proposed commit
@@ -43,7 +46,7 @@ The default 'applypatch-msg' hook, when enabled, runs the
'commit-msg' hook, if the latter is enabled.
pre-applypatch
---------------
+~~~~~~~~~~~~~~
This hook is invoked by 'git-am'. It takes no parameter, and is
invoked after the patch is applied, but before a commit is made.
@@ -58,7 +61,7 @@ The default 'pre-applypatch' hook, when enabled, runs the
'pre-commit' hook, if the latter is enabled.
post-applypatch
----------------
+~~~~~~~~~~~~~~~
This hook is invoked by 'git-am'. It takes no parameter,
and is invoked after the patch is applied and a commit is made.
@@ -67,7 +70,7 @@ This hook is meant primarily for notification, and cannot affect
the outcome of 'git-am'.
pre-commit
-----------
+~~~~~~~~~~
This hook is invoked by 'git-commit', and can be bypassed
with `\--no-verify` option. It takes no parameter, and is
@@ -84,7 +87,7 @@ variable `GIT_EDITOR=:` if the command will not bring up an editor
to modify the commit message.
prepare-commit-msg
-------------------
+~~~~~~~~~~~~~~~~~~
This hook is invoked by 'git-commit' right after preparing the
default log message, and before the editor is started.
@@ -109,7 +112,7 @@ The sample `prepare-commit-msg` hook that comes with git comments
out the `Conflicts:` part of a merge's commit message.
commit-msg
-----------
+~~~~~~~~~~
This hook is invoked by 'git-commit', and can be bypassed
with `\--no-verify` option. It takes a single parameter, the
@@ -126,7 +129,7 @@ The default 'commit-msg' hook, when enabled, detects duplicate
"Signed-off-by" lines, and aborts the commit if one is found.
post-commit
------------
+~~~~~~~~~~~
This hook is invoked by 'git-commit'. It takes no
parameter, and is invoked after a commit is made.
@@ -135,14 +138,14 @@ This hook is meant primarily for notification, and cannot affect
the outcome of 'git-commit'.
pre-rebase
-----------
+~~~~~~~~~~
This hook is called by 'git-rebase' and can be used to prevent a branch
from getting rebased.
post-checkout
------------
+~~~~~~~~~~~~~
This hook is invoked when a 'git-checkout' is run after having updated the
worktree. The hook is given three parameters: the ref of the previous HEAD,
@@ -160,7 +163,7 @@ differences from the previous HEAD if different, or set working dir metadata
properties.
post-merge
------------
+~~~~~~~~~~
This hook is invoked by 'git-merge', which happens when a 'git-pull'
is done on a local repository. The hook takes a single parameter, a status
@@ -175,7 +178,7 @@ for an example of how to do this.
[[pre-receive]]
pre-receive
------------
+~~~~~~~~~~~
This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository.
@@ -204,7 +207,7 @@ for the user.
[[update]]
update
-------
+~~~~~~
This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository.
@@ -247,7 +250,7 @@ unannotated tags to be pushed.
[[post-receive]]
post-receive
-------------
+~~~~~~~~~~~~
This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository.
@@ -277,7 +280,7 @@ emails.
[[post-update]]
post-update
------------
+~~~~~~~~~~~
This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository.
@@ -308,7 +311,7 @@ Both standard output and standard error output are forwarded to
for the user.
pre-auto-gc
------------
+~~~~~~~~~~~
This hook is invoked by 'git-gc --auto'. It takes no parameter, and
exiting with non-zero status from this script causes the 'git-gc --auto'
--
1.6.4.GIT
^ permalink raw reply related
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