* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-01 20:01 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <7vws01li4c.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I used "cat -e" to make it easier to see that "c file " not only has SP in
> it but it has trailing space. Let's try the result.
>
> $ git diff --cached | cat -e
> diff --git "a/a\001file" "b/a\001file"$
> new file mode 100644$
> index 0000000..e69de29$
> diff --git a/b file b/b file$
> new file mode 100644$
> index 0000000..e69de29$
> diff --git a/c file b/c file $
> new file mode 100644$
> index 0000000..e69de29$
> $ git diff --cached >P.diff
>
> And as you described, "b file" and "c file " are not quoted and they do
> not have ---/+++ lines.
>
> But observe this:
> ...
> We are now back in the state without any of these files, and P.diff records
> a patch to recreate these three files, one with quoting and the other two
> without.
>
> $ git apply --index P.diff
> $ git ls-files -s | cat -e
> 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 "a\001file"$
> 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 b file$
> 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 c file $
> 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 hello$
>
> This demonstrates that The claim below is false, doesn't it?
>
> > Not parseable:
> > diff --git a/baz b/baz
> > new file mode 100644
> > index 0000000..e69de29
>
> Both "b file" and "c file " are parsed by "git apply" perfectly fine.
Having said all that, I don't think we would mind a change to treat a
pathname with trailing SP a bit specially (iow, quoting "c file " in the
above failed attempt to reproduce the issue). A pathname with SP in it is
an eyesore but is a fact of life outside of sane world, but a quoted
pathname is an even worse eyesore. A pathname with trailing SP would be
much less common and is more likely to be corrupted by MUA and cut & paste;
with quoting we can protect them a bit better.
^ permalink raw reply
* Re: Filename quoting / parsing problem
From: Junio C Hamano @ 2010-01-01 19:50 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001011844.23571.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> Git quotes file names as documented in the git-diff manual page:
>
> TAB, LF, double quote and backslash characters in pathnames are represented
> as \t, \n, \" and \\, respectively. If there is need for such substitution
> then the whole pathname is put in double quotes.
>
> Spaces in file names currently do not trigger quoting. (And \r triggers
> quoting even though the man page doesn't say so).
Any control character is quoted; the documentation quoted above lists only
the common ones that have non-octal representation.
$ git init one
Initialized empty Git repository in /var/tmp/gomi/one/.git/
$ cd one
$ >hello && git add hello && git commit -m 'hello'
[master (root-commit) 5338884] hello
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 hello
$ >'a^Afile' ; >'b file' ; 'c file '
$ git add 'a^Afile' 'b file' 'c file '
In the above sequence that attempts to reproduce the issue, "^A" actually
is a byte with value \001 (typically you would type ^V^A to get it from
the terminal on the shell). "^G" seems to get "\a" even though it is not
in the list (that is why I said "only the common ones" above).
$ git ls-files -s | cat -e
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 "a\001file"$
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 b file$
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 c file $
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 hello$
I used "cat -e" to make it easier to see that "c file " not only has SP in
it but it has trailing space. Let's try the result.
$ git diff --cached | cat -e
diff --git "a/a\001file" "b/a\001file"$
new file mode 100644$
index 0000000..e69de29$
diff --git a/b file b/b file$
new file mode 100644$
index 0000000..e69de29$
diff --git a/c file b/c file $
new file mode 100644$
index 0000000..e69de29$
$ git diff --cached >P.diff
And as you described, "b file" and "c file " are not quoted and they do
not have ---/+++ lines.
But observe this:
$ git reset --hard
$ ls
P.diff hello
$ git ls-files -s
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 hello
We are now back in the state without any of these files, and P.diff records
a patch to recreate these three files, one with quoting and the other two
without.
$ git apply --index P.diff
$ git ls-files -s | cat -e
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 "a\001file"$
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 b file$
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 c file $
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 hello$
This demonstrates that The claim below is false, doesn't it?
> Not parseable:
> diff --git a/baz b/baz
> new file mode 100644
> index 0000000..e69de29
Both "b file" and "c file " are parsed by "git apply" perfectly fine.
^ permalink raw reply
* Filename quoting / parsing problem
From: Andreas Gruenbacher @ 2010-01-01 17:44 UTC (permalink / raw)
To: git
Git quotes file names as documented in the git-diff manual page:
TAB, LF, double quote and backslash characters in pathnames are represented
as \t, \n, \" and \\, respectively. If there is need for such substitution
then the whole pathname is put in double quotes.
Spaces in file names currently do not trigger quoting. (And \r triggers
quoting even though the man page doesn't say so). When there are no "---" and
"+++" lines, this can lead to a parsing problem: only the "diff --git" line
contains the file names, sometimes with insufficient quoting. The following
examples show the problem:
Parseable:
diff --git "a/foo \r" "b/foo \r"
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ "b/foo \r"
@@ -0,0 +1 @@
+foo
Parseable:
diff --git a/bar b/bar
new file mode 100644
index 0000000..5716ca5
--- /dev/null
+++ b/bar
@@ -0,0 +1 @@
+bar
Not parseable:
diff --git a/baz b/baz
new file mode 100644
index 0000000..e69de29
Could this please be changed so that filenames with spaces are also quoted, at
least in the "diff --git" line, and possibly also in the "---" and "+++"
lines? Alternatively, how about a new extended header with the file name in
this particular case?
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2010-01-01 10:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20100101045017.GA20769@coredump.intra.peff.net>
Jeff King schrieb:
> How should we proceed, then? The "DWIM with spaces" magic seems like
> something that can come later, so I am tempted to recommend taking my
> series now, fixing up msysgit as mentioned earlier (or just dropping the
> pager.c portion of my 2/6), and then implementing DWIM once Ilari's
> topic matures.
I think this procedure is fine. msysgit can resolve the conflict in
pager.c as suggested earlier.
> We might want to hold my 5/6 and 6/6 back from master until the DWIM
> (which would make both totally safe, I think).
Would make sense, too.
-- Hannes
^ permalink raw reply
* Re: 65c042d4 broke `remote update' without named group
From: Björn Gustavsson @ 2010-01-01 9:14 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: YONETANI Tomokazu, git
In-Reply-To: <be6fef0d1001010100u7ebf25beydd2ff11ef71a9d66@mail.gmail.com>
2010/1/1 Tay Ray Chuan <rctay89@gmail.com>:
> Björn (added to Cc list), you seem to have been the main author of
> 'bg/fetch-multi', do you have any idea on this?
Yes. I have fixed the problem and my correction is included in
the latest 'pu' (bg/maint-remote-update-default).
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: 65c042d4 broke `remote update' without named group
From: Tay Ray Chuan @ 2010-01-01 9:00 UTC (permalink / raw)
To: YONETANI Tomokazu; +Cc: Björn Gustavsson, git
In-Reply-To: <20091229234959.GA94644@les.ath.cx>
Hi,
On Wed, Dec 30, 2009 at 7:49 AM, YONETANI Tomokazu <qhwt+git@les.ath.cx> wrote:
> Hello.
> It seems that with 65c042d4 (and v1.6.6), git-remote update without
> specifying a group on the command line ends up with the following error
> message if you define remotes.default in the config file:
> $ git remote update
> fatal: 'default' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> The document still says that when you don't specify the named group,
> remotes.default in the configuration will get used, so this should work
> (and it used to work with v1.6.4).
>
> After the commit 65c042d4, the commands are translated as follows:
> $ git remote update
> ==> git-fetch default (with remotes.default defined) NG
> ==> git-fetch --all (without remotes.default defined) OK
>
> $ git remote update default
> ==> git-fetch --multiple default OK
>
> So just adding "--multiple" in front of "default" in the first case
> above should fix it.
Björn (added to Cc list), you seem to have been the main author of
'bg/fetch-multi', do you have any idea on this?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano @ 2010-01-01 7:03 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vtyv6o18q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> At least disallowing means that the user _is notified_ and has to manually
> deal with the situation. Pretending it succeeded by resetting only the
> index while still leaving the conflicted state in the work tree intact is
> a bit worse in that sense.
>
>> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
>> index c9044c9..b40999f 100644
>> --- a/Documentation/git-reset.txt
>> +++ b/Documentation/git-reset.txt
>> @@ -122,7 +122,7 @@ entries:
>> X U A B --soft (disallowed)
>> --mixed X B B
>> --hard B B B
>> - --merge (disallowed)
>> + --merge X B B
>
> IOW, I think the result should be "B B B" instead of "X B B" in this
> case.
A squashable fix-up on top of your patch to match the wish in the part you
quoted from 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) would
look like this, I think.
It does three things:
- Updates the documentation to match the wish of original "reset --merge"
better, namely, "An unmerged entry is a sign that the path didn't have
any local modification and can be safely resetted to whatever the new
HEAD records";
- Updates read_index_unmerged(), which reads the index file into the
cache while dropping any higher-stage entries down to stage #0, not to
copy the object name recorded in the cache entry. The code used to
take the object name from the highest stage entry ("theirs" if you
happened to have stage #3, or "ours" if they removed while you kept),
which essentially meant that you are getting random results and didn't
make sense.
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path. In order to
differentiate such an entry from ordinary cache entry, the cache entry
added by read_index_unmerged() records null sha1.
- Updates merged_entry() and deleted_entry() so that they pay attention to
cache entries with null sha1 (note that we _might_ want to use a new
in-core ce->ce_flags instead of using the null-sha1 hack). They are
previously unmerged entries, and the files in the work tree that
correspond to them are resetted away by oneway_merge() to the version
from the tree we are resetting to.
Please take this with a grain of salt as I am under slight influence of
CH3-CH2-OH while writing it, and I usually almost never drink.
---
Documentation/git-reset.txt | 4 ++--
read-cache.c | 2 +-
t/t7110-reset-merge.sh | 14 +++++++-------
unpack-trees.c | 19 ++++++++++++-------
4 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index cf2433d..dc73dca 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -122,14 +122,14 @@ entries:
X U A B --soft (disallowed)
--mixed X B B
--hard B B B
- --merge X B B
+ --merge B B B
working index HEAD target working index HEAD
----------------------------------------------------
X U A A --soft (disallowed)
--mixed X A A
--hard A A A
- --merge (disallowed)
+ --merge A A A
X means any state and U means an unmerged index.
diff --git a/read-cache.c b/read-cache.c
index 1bbaf1c..616dd03 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1606,7 +1606,7 @@ int read_index_unmerged(struct index_state *istate)
len = strlen(ce->name);
size = cache_entry_size(len);
new_ce = xcalloc(1, size);
- hashcpy(new_ce->sha1, ce->sha1);
+ /* don't copy sha1; this should not match anything */
memcpy(new_ce->name, ce->name, len);
new_ce->ce_flags = create_ce_flags(len, 0);
new_ce->ce_mode = ce->ce_mode;
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
index ff2875c..249df7c 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -135,27 +135,27 @@ test_expect_success 'setup 2 different branches' '
#
# working index HEAD target working index HEAD
# ----------------------------------------------------
-# file1: X U B C --merge X C C
+# file1: X U B C --merge C C C
test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
test_must_fail git merge branch1 &&
- cat file1 >orig_file1 &&
git reset --merge HEAD^ &&
test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
test -z "$(git diff --cached)" &&
- test_cmp file1 orig_file1
+ test -z "$(git diff)"
'
# The next test will test the following:
#
# working index HEAD target working index HEAD
# ----------------------------------------------------
-# file1: X U B B --merge (disallowed)
-test_expect_success '"reset --merge HEAD" fails with pending merge' '
+# file1: X U B B --merge B B B
+test_expect_success '"reset --merge HEAD" is ok with pending merge' '
git reset --hard third &&
test_must_fail git merge branch1 &&
- test_must_fail git reset --merge HEAD &&
+ git reset --merge HEAD &&
test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
- test -n "$(git diff --cached)"
+ test -z "$(git diff --cached)" &&
+ test -z "$(git diff)"
'
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index dd5999c..4a4d18c 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -666,7 +666,11 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
{
int update = CE_UPDATE;
- if (old) {
+ if (!old) {
+ if (verify_absent(merge, "overwritten", o))
+ return -1;
+ invalidate_ce_path(merge, o);
+ } else if (!is_null_sha1(old->sha1)) {
/*
* See if we can re-use the old CE directly?
* That way we get the uptodate stat info.
@@ -682,11 +686,12 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
return -1;
invalidate_ce_path(old, o);
}
- }
- else {
- if (verify_absent(merge, "overwritten", o))
- return -1;
- invalidate_ce_path(merge, o);
+ } else {
+ /*
+ * Previously unmerged entry left as an existence
+ * marker by read_index_unmerged();
+ */
+ invalidate_ce_path(old, o);
}
add_entry(o, merge, update, CE_STAGEMASK);
@@ -702,7 +707,7 @@ static int deleted_entry(struct cache_entry *ce, struct cache_entry *old,
return -1;
return 0;
}
- if (verify_uptodate(old, o))
+ if (!is_null_sha1(old->sha1) && verify_uptodate(old, o))
return -1;
add_entry(o, ce, CE_REMOVE, 0);
invalidate_ce_path(ce, o);
^ permalink raw reply related
* Magit and TRAMP issues
From: Dave Abrahams @ 2010-01-01 6:49 UTC (permalink / raw)
To: git
1. If shell-file-name points to a shell on the local machine but not
on the remote server, a remote magit-status fails. I had to
create a symlink from /bin/bash to /usr/local/bin/bash on my
FreeBSD server before it would work
2. Any attempt to stage changes fails for me. I get a "Git Failed."
message and see this in the *magit-process* buffer:
$ git --no-pager add -u .
fatal: Not a git repository (or any of the parent directories): .git
Any clues for me?
TIA,
--
Dave Abrahams Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [PATCH v6 3/4] reset: add a few tests for "git reset --merge"
From: Junio C Hamano @ 2010-01-01 5:15 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055448.4475.42383.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01),
> added the --merge option to git reset, but there were no test cases
> for it.
>
> This was not a big problem because "git reset" was just forking and
> execing "git read-tree", but this will change in a following patch.
>
> So let's add a few test cases to make sure that there will be no
> regression.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Looks good.
> +# The next test will test the following:
> +#
> +# working index HEAD target working index HEAD
> +# ----------------------------------------------------
> +# file1: C C C D --merge D D D
> +# file2: C D D D --merge C D D
> +test_expect_success 'reset --merge is ok with changes in file it does not touch' '
> + git reset --merge HEAD^ &&
> + ! grep 4 file1 &&
> + grep 4 file2 &&
> + test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
> + test -z "$(git diff --cached)"
> +'
> ...
> +# The next test will test the following:
> +#
> +# working index HEAD target working index HEAD
> +# ----------------------------------------------------
> +# file1: C C C D --merge D D D
> +# file2: C C D D --merge D D D
> +test_expect_success 'reset --merge discards changes added to index (2)' '
> + git reset --hard second &&
> + echo "line 4" >> file2 &&
> + git add file2 &&
> + git reset --merge HEAD^ &&
> + ! grep 4 file2 &&
> + test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
> + test -z "$(git diff)" &&
> + test -z "$(git diff --cached)"
> +'
These two seem to duplicate the same case for file1; is it necessary?
I am not pointing it out as something that needs to be removed; I am just
puzzled and wondering if there is some interaction between the ways two
paths are handled and the test is trying to check that (which I do not
think is the case).
^ permalink raw reply
* Re: [PATCH v6 2/4] Documentation: reset: add some tables to describe the different options
From: Junio C Hamano @ 2010-01-01 5:15 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055448.4475.83629.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> This patch adds a DISCUSSION section that contains some tables to
> show how the different "git reset" options work depending on the
> states of the files in the working tree, the index, HEAD and the
> target commit.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Much nicer.
> Documentation/git-reset.txt | 66 +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 66 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> index 2d27e40..c9044c9 100644
> --- a/Documentation/git-reset.txt
> +++ b/Documentation/git-reset.txt
> @@ -67,6 +67,72 @@ linkgit:git-add[1]).
> <commit>::
> Commit to make the current HEAD. If not given defaults to HEAD.
>
> +DISCUSSION
> +----------
> +
> +The tables below show what happens when running:
> +
> +----------
> +git reset --option target
> +----------
> +
> +to reset the HEAD to another commit (`target`) with the different
> +reset options depending on the state of the files.
Together with these "mechanical definitions", I think the readers would
benefit from reading why some are disallowed.
> + working index HEAD target working index HEAD
> + ----------------------------------------------------
> + A B C D --soft A B D
> + --mixed A D D
> + --hard D D D
> + --merge (disallowed)
"reset --merge" is meant to be used when resetting out of a conflicted
merge. Because any mergy operation guarantees that the work tree file
that is involved in the merge does not have local change wrt the index
before it starts, and that it writes the result out to the work tree, the
fact that we see difference between the index and the HEAD and also
between the index and the work tree means that we are not seeing a state
that a mergy operation left after failing with a conflict. That is why we
disallow --merge option in this case, and the next one.
> + working index HEAD target working index HEAD
> + ----------------------------------------------------
> + A B C C --soft A B C
> + --mixed A C C
> + --hard C C C
> + --merge (disallowed)
The same as above, but you are resetting to the same commit.
> + working index HEAD target working index HEAD
> + ----------------------------------------------------
> + B B C D --soft B B D
> + --mixed B D D
> + --hard D D D
> + --merge D D D
> + working index HEAD target working index HEAD
> + ----------------------------------------------------
> + B B C C --soft B B C
> + --mixed B C C
> + --hard C C C
> + --merge C C C
As this table is not only about "--merge" but to explain "reset", I think
other interesting cases should also be covered.
w=A i=B H=B t=B
This is "we had local change in the work tree that was unrelated to the
merge", and "reset --merge" should be a no-op for this path.
w=A i=B H=B t=C
This "reset --merge" is like "using checkout to switch to a commit that
has C but we have changes in the work tree", and should fail just like
"checkout branch" in such a situation fails without "-m" option.
^ permalink raw reply
* Re: [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces
From: Junio C Hamano @ 2010-01-01 5:15 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, Shawn O . Pearce, git
In-Reply-To: <905315640912301009x491f957al839f66de7aba56ed@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> One reason it's labeled RFC is that I'm not very confident in my
> ability to write portable shell script. It works for me with bash,
> but I'm not completely confident that is would work on ksh or dash.
> So it would be nice if you could specifically take a look at the new
> POST() and GET() and see if you notice anything obviously wrong there.
Looked Ok to me from a cursory reading, even though I wonder what the
first argument to run_backend function is good for...
^ permalink raw reply
* Re: [PATCH] builtin-config: add --path option doing ~ and ~user expansion.
From: Junio C Hamano @ 2010-01-01 5:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262191913-8340-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> 395de250 (Expand ~ and ~user in core.excludesfile, commit.template)
> introduced a C function git_config_pathname, doing ~/ and ~user/
> expansion. This patch makes the feature available to scripts with 'git
> config --get --path'.
Makes sense. Thanks.
^ permalink raw reply
* Re: [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano @ 2010-01-01 5:14 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Linus Torvalds, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Paolo Bonzini,
Johannes Sixt, Stephen Boyd
In-Reply-To: <20091230055448.4475.64716.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> But in 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) there is
> the following:
>
> "
> - if the index has unmerged entries, "--merge" will currently
> simply refuse to reset ("you need to resolve your current index
> first"). You'll need to use "--hard" or similar in this case.
>
> This is sad, because normally a unmerged index means that the
> working tree file should have matched the source tree, so the
> correct action is likely to make --merge reset such a path to
> the target (like --hard), regardless of dirty state in-tree or
> in-index. But that's not how read-tree has ever worked, so..
> "
>
> So the new behavior looks better according to the original
> implementation of "git reset --merge".
This is not really an improvement.. You are swapping an breakage with a
different breakage of a riskier kind.
At least disallowing means that the user _is notified_ and has to manually
deal with the situation. Pretending it succeeded by resetting only the
index while still leaving the conflicted state in the work tree intact is
a bit worse in that sense.
> diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
> index c9044c9..b40999f 100644
> --- a/Documentation/git-reset.txt
> +++ b/Documentation/git-reset.txt
> @@ -122,7 +122,7 @@ entries:
> X U A B --soft (disallowed)
> --mixed X B B
> --hard B B B
> - --merge (disallowed)
> + --merge X B B
IOW, I think the result should be "B B B" instead of "X B B" in this
case.
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Jeff King @ 2010-01-01 4:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <200912312316.47925.j6t@kdbg.org>
On Thu, Dec 31, 2009 at 11:16:47PM +0100, Johannes Sixt wrote:
> > > It does assume that we are able to detect execvp failure due to
> > > ENOENT which is currently proposed elsewhere by Ilari Liusvaara (and
> > > which is already possible on Windows).
> >
> > We could also simply do the path lookup ourselves, decide whether to use
> > the shell, and then exec.
>
> I tried to convince Ilari that this is the way to go, but...
How should we proceed, then? The "DWIM with spaces" magic seems like
something that can come later, so I am tempted to recommend taking my
series now, fixing up msysgit as mentioned earlier (or just dropping the
pager.c portion of my 2/6), and then implementing DWIM once Ilari's
topic matures.
We might want to hold my 5/6 and 6/6 back from master until the DWIM
(which would make both totally safe, I think).
-Peff
^ permalink raw reply
* Re: [PATCH] Reword -M, when in `git log`s documention, to suggest --follow
From: Junio C Hamano @ 2010-01-01 4:35 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git
In-Reply-To: <1261428059-31286-1-git-send-email-alex@chmrr.net>
Alex Vandiver <alex@chmrr.net> writes:
> The documentation for `git log` is sadly misleading when it comes
> to tracking renames. By far the most common option that users
> new to git want is the ability to view the history of a file
> across renames. Unfortunately, `git log --help` shows:
>
> NAME
> git-log - Show commit logs
> [...]
> OPTIONS
> [...]
> -M
> Detect renames.
>
> ...and most users stop reading there. Unfortunately, what
> they're generally looking for comes significantly later:
>
> [...]
> --follow
> Continue listing the history of a file beyond renames.
>
> Signed-off-by: Alex Vandiver <alex@chmrr.net>
> ---
> Documentation/diff-options.txt | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 8707d0e..bcbad88 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -175,7 +175,13 @@ endif::git-format-patch[]
> Break complete rewrite changes into pairs of delete and create.
>
> -M::
> +ifdef::git-log[]
> + Show renames in diff output. See `--follow` to track history
> + across renames.
With "s/history/history of a single file/", I think the new wording makes
more sense.
> +endif::git-log[]
> +ifndef::git-log[]
> Detect renames.
> +endif::git-log[]
Also we probably should do s/Detect renames/Show renames in diff output/
to match the earlier change.
>
> -C::
> Detect copies as well as renames. See also `--find-copies-harder`.
> --
> 1.6.6.rc0.363.g69d13.dirty
^ permalink raw reply
* [ANNOUNCE] git-cola 1.4.1.2
From: David Aguilar @ 2010-01-01 1:48 UTC (permalink / raw)
To: git
git-cola is a powerful GUI for Git written in Python/PyQt4
git-cola v1.4.1.2 has been tagged and released:
* git clone git://github.com/davvid/git-cola.git
* http://github.com/davvid/git-cola
* http://cola.tuxfamily.org/
I haven't sent an announcement in a long time but we've
been quite busy working on enhancements nonetheless.
The release notes below summarize all changes since 1.3.8
in case you haven't kept up with the latest cola.
NYE is fast approaching here on the west coast so I've got a
party to catch. Thus, this is the last git-cola for 2009 ;-)
Happy New Years everybody!
git-cola v1.4.1.2
=================
Usability, bells and whistles
-----------------------------
* It is now possible to checkout from the index as well
as from `HEAD`. This corresponds to the
`Removed Unstaged Changes` action in the `Repository Status` tool.
* The `remote` dialogs (fetch, push, pull) are now slightly
larger by default.
* Bookmarks can be selected when `git-cola` is run outside of a Git repository.
* Added more user documentation. We now include many links to
external git resources.
Fixes
-----
* Fixed a missing ``import`` when showing `right-click` actions
for unmerged files in the `Repository Status` tool.
* ``git update-index --refresh`` is no longer run everytime
``git cola version`` is run.
* Don't try to watch non-existant directories when using `inotify`.
Packaging
---------
* The ``Makefile`` will now conditionally include a ``config.mak``
file located at the root of the project. This allows for user
customizations such as changes to the `prefix` variable
to be stored in a file so that custom settings do not need to
be specified every time on the command-line.
* The build scripts no longer require a ``.git`` directory to
generate the ``builtin_version.py`` module. The release tarballs
now include a ``version`` file at the root of the project which
is used in lieu of having the Git repository available.
This allows for ``make clean && make`` to function outside of
a Git repository.
* Added maintainer's ``make dist`` target to the ``Makefile``.
* The built-in `simplejson` and `jsonpickle` libraries can be
excluded from ``make install`` by specifying the ``standalone=true``
`make` variable. For example, ``make standalone=true install``.
This corresponds to the ``--standalone`` option to ``setup.py``.
git-cola v1.4.1.1
=================
Usability, bells and whistles
-----------------------------
* We now use patience diff by default when it is available via
`git diff --patience`.
* Allow closing the `cola classic` tool with `Ctrl+W`.
* Update desktop menu entry to read `Cola Git GUI`.
Fixes
-----
* Fixed an unbound variable error in the `push` dialog.
Packaging
---------
* Don't include `simplejson` in MANIFEST.in.
* Update desktop entry to read `Cola Git GUI`.
git-cola v1.4.1
===============
This feature release adds two new features directly from
`git-cola`'s github issues backlog. On the developer
front, further work was done towards modularizing the code base.
Usability, bells and whistles
-----------------------------
* Dragging and dropping patches invokes `git-am`
http://github.com/davvid/git-cola/issues/closed#issue/3
* A dialog to allow opening or cloning a repository
is presented when `git-cola` is launched outside of a git repository.
http://github.com/davvid/git-cola/issues/closed/#issue/22
* Warn when `push` is used to create a new branch
http://github.com/davvid/git-cola/issues/closed#issue/35
* Optimized startup time by removing several calls to `git`.
Portability
-----------
* `git-cola` is once again compatible with PyQt 4.3.x.
Developer
---------
* `cola.gitcmds` was added to factor out git command-line utilities
* `cola.gitcfg` was added for interacting with `git-config`
* `cola.models.browser` was added to factor out repobrowser data
* Added more tests
git-cola v1.4.0.5
=================
Fixes
-----
* Fix launching external applications on Windows
* Ensure that the `amend` checkbox is unchecked when switching modes
* Update the status tree when amending commits
git-cola v1.4.0.4
=================
Packaging
---------
* Fix Lintian warnings
git-cola v1.4.0.3
=================
Fixes
-----
* Fix X11 warnings on application startup
git-cola v1.4.0.2
=================
Fixes
-----
* Added missing 'Exit Diff Mode' button for 'Diff Expression' mode
http://github.com/davvid/git-cola/issues/closed/#issue/31
* Fix a bug when initializing fonts on Windows
http://github.com/davvid/git-cola/issues/closed/#issue/32
git-cola v1.4.0.1
=================
Fixes
-----
* Keep entries in sorted order in the `cola classic` tool
* Fix staging untracked files
http://github.com/davvid/git-cola/issues/closed/#issue/27
* Fix the `show` command in the Stash dialog
http://github.com/davvid/git-cola/issues/closed/#issue/29
* Fix a typo when loading merge commit messages
http://github.com/davvid/git-cola/issues/closed/#issue/30
git-cola v1.4.0
===============
This release focuses on a redesign of the git-cola user interface,
a tags interface, and better integration of the `cola classic` tool.
A flexible interface based on configurable docks is used to manage the
various cola widgets.
Usability, bells and whistles
-----------------------------
* New GUI is flexible and user-configurable
* Individual widgets can be detached and rearranged arbitrarily
* Add an interface for creating tags
* Provide a fallback `SSH_ASKPASS` implementation to prompt for
SSH passwords on fetch/push/pull
* The commit message editor displays the current row/column and
warns when lines get too long
* The `cola classic` tool displays upstream changes
* `git cola --classic` launches `cola classic` in standalone mode
* Provide more information in log messages
Fixes
-----
* Inherit the window manager's font settings
* Miscellaneous PyQt4 bug fixes and workarounds
Developer
---------
* Removed all usage of Qt Designer `.ui` files
* Simpler model/view architecture
* Selection is now shared across tools
* Centralized notifications are used to keep views in sync
* The `cola.git` command class was made thread-safe
* Less coupling between model and view actions
* The status view was rewritten to use the MVC architecture
* Added more documentation and tests
git-cola v1.3.9
===============
Usability, bells and whistles
-----------------------------
* Added a `cola classic` tool for browsing the entire repository
* Handle diff expressions with spaces
* Handle renamed files
Portability
-----------
* Handle carat `^` characters in diff expressions on Windows
* Worked around a PyQt 4.5/4.6 QThreadPool bug
Documentation
-------------
* Added a keyboard shortcuts reference page
* Added developer API documentation
Fixes
-----
* Fix the diff expression used when reviewing branches
* Fix a bug when pushing branches
* Fix X11 warnings at startup
* Fix more interrupted system calls on Mac OS X
--
David
^ permalink raw reply
* Re: [PATCH] Reword -M, when in `git log`s documention, to suggest --follow
From: Alex Vandiver @ 2010-01-01 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <1261428059-31286-1-git-send-email-alex@chmrr.net>
At Mon Dec 21 15:40:59 -0500 2009, Alex Vandiver wrote:
> [snip]
Any thoughts on this doc patch? I saw someone get rather frustrated
at this particular failure mode, so I'd like to be able to reassure
them that it'll get fixed.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2010-01-01 0:34 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <4B3CF118.7080404@kdbg.org>
On Donnerstag, 31. Dezember 2009, Johannes Sixt wrote:
> Ilari Liusvaara schrieb:
> > The child process can't sanely print anything. Stderr would go to
> > who knows where.
>
> Wrong - because:
> > Parent process should have much better idea what to
> > do with errors.
>
> Very correct. For this reason, the parent process assigns a stderr channel
> to the child (or does not do so to inherit its own stderr), and the child
> is expected to use it. Errors due to execvp failures are no exception, IMO
> (except ENOENT, as always).
Actually, I changed my mind: execvp failures should go to the parent's stderr,
just as all errors before the exec happens.
How about this patch for a starter? Take it with a grain of salt - I coded it
after the New Year celebration ;) I was unable to find a case quickly that
exercises die_child().
--- 8< ---
From: Johannes Sixt <j6t@kdbg.org>
Date: Fri, 1 Jan 2010 01:22:05 +0100
Subject: [PATCH] start_command: report child process setup errors to the parent's stderr
When the child process's environment is set up in start_command(), error
messages were written to wherever the parent redirected the child's stderr
channel. However, even if the parent redirected the child's stderr, errors
during this setup process, including the exec itself, are usually an
indication of a problem in the parent's environment. Therefore, the error
messages should go to the parent's stderr.
Redirection of the child's error messages is usually only used to redirect
hook error messages during client-server exchanges such that stderr goes
to the client. In these cases, hook setup errors could be regarded as
information leak.
This patch makes a copy of stderr if necessary and uses a special
die routine that is used for all die() calls so that the errors are sent to
the parent's channel.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
run-command.c | 39 ++++++++++++++++++++++++++++++++++++---
1 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..2480a8c 100644
--- a/run-command.c
+++ b/run-command.c
@@ -15,6 +15,23 @@ static inline void dup_devnull(int to)
close(fd);
}
+#ifndef WIN32
+static int child_err;
+
+static NORETURN void die_child(const char *err, va_list params)
+{
+ char msg[4096];
+ int len = vsnprintf(msg, sizeof(msg), err, params);
+ if (len > sizeof(msg))
+ len = sizeof(msg);
+
+ write(child_err, "fatal: ", 7);
+ write(child_err, msg, len);
+ write(child_err, "\n", 1);
+ exit(128);
+}
+#endif
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -79,6 +96,21 @@ fail_pipe:
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
+ /*
+ * Redirect the channel to write syscall error messages to
+ * before redirecting the process's stderr so that all die()
+ * in subsequent call paths use the parent's stderr.
+ */
+ if (cmd->no_stderr || need_err) {
+ int flags;
+ child_err = dup(2);
+ flags = fcntl(child_err, F_GETFL);
+ if (flags < 0)
+ flags = 0;
+ fcntl(child_err, F_SETFL, flags | FD_CLOEXEC);
+ set_die_routine(die_child);
+ }
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -126,9 +158,10 @@ fail_pipe:
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
- strerror(errno));
- exit(127);
+ if (errno == ENOENT)
+ exit(127);
+ else
+ die_errno("exec '%s'", cmd->argv[0]);
}
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* Re: [PATCH v6 0/4] "git reset --merge" related improvements
From: Linus Torvalds @ 2010-01-01 0:25 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
On Wed, 30 Dec 2009, Christian Couder wrote:
>
> Another reroll with the following changes:
> - patches to add --keep option have been removed for now
> - documentation patch has been moved before the core code changes
> - commit messages have been improved
> - tests have been much improved thanks to Junio's suggestions
>
> Christian Couder (3):
> reset: improve mixed reset error message when in a bare repo
> Documentation: reset: add some tables to describe the different
> options
> reset: add a few tests for "git reset --merge"
>
> Stephan Beyer (1):
> reset: use "unpack_trees()" directly instead of "git read-tree"
FWIW, Ack on this version of the whole series - I don't think there is
anything controversial here, and I think avoiding the execve of read-tree
for something we have a library function for is a good thing (and the
change in behavior looks like a bug-fix to me).
And the whole "--keep" discussion can be resurrected later ;)
Linus
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #06; Thu, 31)
From: Junio C Hamano @ 2010-01-01 0:10 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
The tip of 'next' will soon be rebuilt on top of the current 'master'.
This will be the last "What's cooking" message in year 2009 ;-)
--------------------------------------------------
[New Topics]
* cc/reset-more (2009-12-30) 4 commits
- reset: use "unpack_trees()" directly instead of "git read-tree"
- reset: add a few tests for "git reset --merge"
- Documentation: reset: add some tables to describe the different options
- reset: improve mixed reset error message when in a bare repo
Resurrected from "Ejected" category. Haven't looked at it yet myself,
though...
* bg/maint-remote-update-default (2009-12-31) 1 commit
- Fix "git remote update" with remotes.defalt set
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
- Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
(merged to 'next' on 2009-12-30 at de97679)
+ reset: unbreak hard resets with GIT_WORK_TREE
* jk/push-to-delete (2009-12-30) 1 commit
- builtin-push: add --delete as syntactic sugar for :foo
* jk/run-command-use-shell (2009-12-30) 6 commits
- diff: run external diff helper with shell
- textconv: use shell to run helper
- editor: use run_command's shell feature
- run-command: optimize out useless shell calls
- run-command: convert simple callsites to use_shell
- run-command: add "use shell" option
* mm/config-path (2009-12-30) 1 commit
- builtin-config: add --path option doing ~ and ~user expansion.
* pm/cvs-environ (2009-12-30) 1 commit
- CVS Server: Support reading base and roots from environment
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
- archive: complain about path specs that don't match anything
* so/cvsserver-update (2009-12-07) 1 commit
- cvsserver: make the output of 'update' more compatible with cvs.
* tc/clone-v-progress (2009-12-26) 4 commits
- clone: use --progress to force progress reporting
- clone: set transport->verbose when -v/--verbose is used
- git-clone.txt: reword description of progress behaviour
- check stderr with isatty() instead of stdout when deciding to show progress
* tc/smart-http-restrict (2009-12-30) 3 commits
- Smart-http tests: Test http-backend without curl or a webserver
- Smart-http tests: Break test t5560-http-backend into pieces
- Smart-http: check if repository is OK to export before serving it
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
- bash completion: factor submodules into dirty state
--------------------------------------------------
[Cooking]
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
* js/filter-branch-prime (2009-12-15) 1 commit
- filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
- tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
- octopus: remove dead code
- octopus: reenable fast-forward merges
- octopus: make merge process simpler to follow
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2009-12-24 at ff4d1d4)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
* bg/maint-add-all-doc (2009-12-07) 4 commits
- squash! rm documentation--also mention add-u where we mention commit-a
- git-rm doc: Describe how to sync index & work tree
- git-add/rm doc: Consistently back-quote
- Documentation: 'git add -A' can remove files
I didn't like the existing documentation for "add -u" myself (especially
because I wrote the initial version) and this neatly fix it as well.
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
(merged to 'next' on 2009-12-29 at c89a730)
+ Add more testcases to test fast-import of notes
+ Rename t9301 to t9350, to make room for more fast-import tests
+ fast-import: Proper notes tree manipulation
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-28) 4 commits
(merged to 'next' on 2009-12-30 at e143bc9)
+ Remove http.authAny
(merged to 'next' on 2009-12-07 at f08d447)
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-30) 23 commits
(merged to 'next' on 2009-12-31 at 442ff22)
+ grep: do not do external grep on skip-worktree entries
(merged to 'next' on 2009-12-24 at 1fa9ff3)
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[Ejected]
* il/exec-error-report (2009-12-30) 2 commits
. Improve transport helper exec failure reporting
. Report exec errors from run-command
Freezes "git log" or anything that uses pager; J6t made quite a many good
suggestions. Expecting more rounds of reroll.
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong.
* jc/grep-full-tree (2009-11-24) 1 commit
. grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2010-01-01 0:09 UTC (permalink / raw)
To: git
Welcome to git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* IRC and Mailing list
Members of the development community can sometimes be found on #git
IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
The development is primarily done on the Git mailing list If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches. You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise. Please do not
hesitate to send a reminder message politely in such a case. Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one.
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man". The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state. The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.
The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has
links to documentation of older releases.
The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested. It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu". I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable. Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The last such
release was 1.6.6 done on Dec 23rd 2009. You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.6.5.7. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master". A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however. Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point. Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository. I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.
The quality of topic branches are judged primarily by the mailing list
discussions. Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience". Luckily, most of them start out in the latter, better
shape.
The "next" branch is to merge and test topic branches in the latter
category. In general, the branch always contains the tip of "master". It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage. I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out. The "next" branch is where new
and exciting things take place.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.
After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics. The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".
The "pu" (proposed updates) branch bundles all the remainder of topic
branches. The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general. By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.
When a topic that was in "pu" proves to be in testable shape, it graduates
to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version). Similarly to the above, I do it with
this:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release. There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from Shawn Pearce's git-gui project:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus on general design issues.
- Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
Scharfe, Jeff King and Johannes Sixt on general implementation
issues.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong on git-svn.
- Simon Hausmann on git-p4.
- Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields on documentation (and countless others for
proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- Charles Bailey for taking good care of git-mergetool (and Theodore
Ts'o for creating it in the first place).
- David Aguilar for git-difftool.
- Johannes Schindelin, Johannes Sixt and others for their effort to
move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on
portability; especially, Randal Schwartz, Theodore Ts'o, Jason
Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
countless others.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* Re: [PATCH] t9700-perl-git.sh: Fix a test failure on Cygwin
From: Junio C Hamano @ 2010-01-01 0:07 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT Mailing-list
In-Reply-To: <20100101090515.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Junio, could you tell us what happened to this thread?
>>
>> Hmph, I think we have it as 81f4026 (t9700-perl-git.sh: Fix a test failure
>> on Cygwin, 2009-11-19).
>
> Oh, my mistake. I'm very sorry for wasting your time.
That's Ok; your other reminders were all good ones and greatly
appreciated.
But let me slow down. I'll reply to the other messages next year ;-).
^ permalink raw reply
* Re: [PATCH 0/4] Makefile fixes
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <20091128112546.GA10059@progeny.tock>
Junio, could you tell us what happened to this thread?
Makefile improvements. No discussion.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20091127174558.GA3461@progeny.tock>
Junio, could you tell us what happened to this thread?
Makefile improvements. No discussion.
^ permalink raw reply
* Re: Client-side mirroring patches (v0)
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <1259143617-26580-1-git-send-email-sam@vilain.net>
Junio, could you tell us what happened to this thread?
^ 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