* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-30 8:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Jeff King
In-Reply-To: <20091230121325.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
>
> I use this patch myself, and it works really well.
I stopped promoting the patch after Peff mentioned he was planning a
rework of textconv, but now I re-read it, I think his rework would be
orthogonal to the patch.
Also Peff gives a good hint about borrowing how launch_editor() calls out
to the shell. I think the codepath we fork&exec user-defined commands
(not hooks, but filters like smudge/clean/textconv and EDITOR/PAGER that
take a command line) need to be first enumerated, then we need to see if
we can refactor what launch_editor() does into a common helper function.
I felt it was unclear what we would want to do with GIT_EXTERNAL_DIFF,
diff.external, and diff.<driver>.command trio, but I tend to agree that we
should run things the same way, honoring $IFS and shell everywhere.
http://thread.gmane.org/gmane.comp.version-control.git/135250/focus=135312
^ permalink raw reply
* Re: [PATCH] Makefile: determine the list of header files using a glob
From: Mike Hommey @ 2009-12-30 8:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7v7htbom95.fsf@alter.siamese.dyndns.org>
(Nanako's bunch of reminders reminded me of this thread)
On Fri, Nov 27, 2009 at 10:28:38AM -0800, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
>
> > On Fri, Nov 27, 2009 at 09:50:47AM +0100, Johannes Sixt wrote:
> >> Mike Hommey schrieb:
> >> > I don't know if the current Makefile works with Solaris' make,...
> >>
> >> No, it doesn't. You have to use GNU make anyway.
> >
> > Then it's fine. But shouldn't that be noted somewhere, like in the
> > INSTALL file ?
>
> Surely. Please make it so.
I had another idea in the interim. If GNU make is necessary, why not
make the Makefile an explicit GNU make only Makefile, by renaming it
GNUmakefile ?
That wouldn't remove the need to add a note in the INSTALL file, though.
Mike
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-12-30 7:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <20091230121319.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
See http://thread.gmane.org/gmane.comp.version-control.git/132983/focus=133414
In short, the particular way to call difftool this patch implements was
found to be inadequate to support existing external diff support by gitk
and a small difftool update will happen first, followed by a patch to gitk
to use the updated difftool, to avoid regression.
^ permalink raw reply
* Re: [PATCH v2] gitk: Honor TMPDIR when viewing diffs externally
From: Junio C Hamano @ 2009-12-30 7:45 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <20091230121314.6117@nanako3.lavabit.com>
If my recollection is correct, I think this approach was scrapped in favor
of using difftool to dispatch the external diff viewers.
^ permalink raw reply
* Re: [PATCH] Add completion for git-svn mkdirs,reset,and gc
From: Junio C Hamano @ 2009-12-30 7:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robert Zeh, git
In-Reply-To: <20091230005950.GC6914@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Robert Zeh <robert.a.zeh@gmail.com> wrote:
>>
>> Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
>> ---
>> contrib/completion/git-completion.bash | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> --
> Shawn.
Thanks.
Robert, if you are planning to be a regular contributor, please check your
MUA settings, and next time, please first send a patch to yourself and try
running "git am" on it to make sure it applies. Your patch was seriously
whitespace damaged (all the leading SP on the context lines were
stripped).
^ permalink raw reply
* Re: Question about 'branch -d' safety
From: Junio C Hamano @ 2009-12-30 6:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Nicolas Sebrecht, git
In-Reply-To: <20091230121238.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
>
>> The 30/12/09, Nanako Shiraishi wrote:
>>
>>> I think the safety feature should check if the branch to be deleted is merged to the remote tracking branch it was forked from, instead of checking the current branch.
>>>
>>> What do you think?
>>
>> I think we shouldn't. At first, every repository don't have a remote.
>> This may easily be passed by a "double check" with a logical OR between
>> the two statements.
>
> Sorry, I was unclear. What I meant was that checking with the branch the
> branch to be deleted was forked from, if and only if such a branch
> exists. Otherwise, we can keep using the old default behavior to check
> with the current branch.
Back when the original "safety valve" was added, there was no mechanical
"this branch _always_ merges from/rebases on that other one" settings.
The users were supposed to keep track of the correspondence, and the
canonical workflow was "checkout this && merge that && branch -d that".
But I actually think it is quite a natural thing to do in year 2010 to
change the safety valve as suggested.
A patch to do so would look like this.
-- >8 --
branch -d: base the "already-merged" safety on the branch it merges with
When a branch is marked to merge with another ref (e.g. local 'next' that
merges from and pushes back to origin's 'next', with 'branch.next.merge'
set to 'refs/heads/next'), it makes little sense to base the "branch -d"
safety, whose purpose is not to lose commits that are not merged to other
branches, on the current branch. It is much more sensible to check if it
is merged with the other branch it merges with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 64 ++++++++++++++++++++++++++++++++++++++++++++--------
t/t3200-branch.sh | 26 +++++++++++++++++++++
2 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index c87e63b..d2a35fe 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -93,9 +93,60 @@ static const char *branch_get_color(enum color_branch ix)
return "";
}
+static int branch_merged(int kind, const char *name,
+ struct commit *rev, struct commit *head_rev)
+{
+ /*
+ * This checks whether the merge bases of branch and HEAD (or
+ * the other branch this branch builds upon) contains the
+ * branch, which means that the branch has already been merged
+ * safely to HEAD (or the other branch).
+ */
+ struct commit *reference_rev = NULL;
+ const char *reference_name = NULL;
+ int merged;
+
+ if (kind == REF_LOCAL_BRANCH) {
+ struct branch *branch = branch_get(name);
+ unsigned char sha1[20];
+
+ if (branch &&
+ branch->merge &&
+ branch->merge[0] &&
+ branch->merge[0]->dst &&
+ (reference_name =
+ resolve_ref(branch->merge[0]->dst, sha1, 1, NULL)) != NULL)
+ reference_rev = lookup_commit_reference(sha1);
+ }
+ if (!reference_rev)
+ reference_rev = head_rev;
+
+ merged = in_merge_bases(rev, &reference_rev, 1);
+
+ /*
+ * After the safety valve is fully redefined to "check with
+ * upstream, if any, otherwise with HEAD", we should just
+ * return the result of the in_merge_bases() above without
+ * any of the following code, but during the transition period,
+ * a gentle reminder is in order.
+ */
+ if ((head_rev != reference_rev) &&
+ in_merge_bases(rev, &head_rev, 1) != merged) {
+ if (merged)
+ warning("deleting branch '%s' that has been merged to\n"
+ " '%s', but it is not yet merged to HEAD.",
+ name, reference_name);
+ else
+ warning("not deleting branch '%s' that is not yet merged to\n"
+ " '%s', even though it is merged to HEAD.",
+ name, reference_name);
+ }
+ return merged;
+}
+
static int delete_branches(int argc, const char **argv, int force, int kinds)
{
- struct commit *rev, *head_rev = head_rev;
+ struct commit *rev, *head_rev = NULL;
unsigned char sha1[20];
char *name = NULL;
const char *fmt, *remote;
@@ -148,15 +199,8 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
continue;
}
- /* This checks whether the merge bases of branch and
- * HEAD contains branch -- which means that the HEAD
- * contains everything in both.
- */
-
- if (!force &&
- !in_merge_bases(rev, &head_rev, 1)) {
- error("The branch '%s' is not an ancestor of "
- "your current HEAD.\n"
+ if (!force && !branch_merged(kinds, bname.buf, rev, head_rev)) {
+ error("The branch '%s' is not fully merged.\n"
"If you are sure you want to delete it, "
"run 'git branch -D %s'.", bname.buf, bname.buf);
ret = 1;
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index d59a9b4..e0b7605 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -468,4 +468,30 @@ test_expect_success 'detect misconfigured autosetuprebase (no value)' '
git config --unset branch.autosetuprebase
'
+test_expect_success 'attempt to delete a branch without base and unmerged to HEAD' '
+ git checkout my9 &&
+ git config --unset branch.my8.merge &&
+ test_must_fail git branch -d my8
+'
+
+test_expect_success 'attempt to delete a branch merged to its base' '
+ # we are on my9 which is the initial commit; traditionally
+ # we would not have allowed deleting my8 that is not merged
+ # to my9, but it is set to track master that already has my8
+ git config branch.my8.merge refs/heads/master &&
+ git branch -d my8
+'
+
+test_expect_success 'attempt to delete a branch merged to its base' '
+ git checkout master &&
+ echo Third >>A &&
+ git commit -m "Third commit" A &&
+ git branch -t my10 my9 &&
+ git branch -f my10 HEAD^ &&
+ # we are on master which is at the third commit, and my10
+ # is behind us, so traditionally we would have allowed deleting
+ # it; but my10 is set to track my9 that is further behind.
+ test_must_fail git branch -d my10
+'
+
test_done
^ permalink raw reply related
* Re: git fast-import not verifying commit author lines?
From: David Reiss @ 2009-12-30 6:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git@vger.kernel.org
In-Reply-To: <20091222150649.GI10687@spearce.org>
>> author <somename> 1261454209 +0000
>> committer <somename> 1261454209 +0000
> a foreign system where the data might not reasonably exist.
But shouldn't there still be an extra space? One to separate "author"
from the empty name, and one to separate the empty name from the email?
If not, then I think this change should be made. (I couldn't find any
authoritative documentation on what constitutes a valid commit object.)
(Sorry, this has been sitting in my outbox for a week.)
--David
diff --git i/Documentation/git-fast-import.txt w/Documentation/git-fast-import.txt
index 288032c..6917739 100644
--- i/Documentation/git-fast-import.txt
+++ w/Documentation/git-fast-import.txt
@@ -312,6 +312,6 @@ change to the project.
'commit' SP <ref> LF
mark?
- ('author' SP <name> SP LT <email> GT SP <when> LF)?
- 'committer' SP <name> SP LT <email> GT SP <when> LF
+ ('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
+ 'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
('from' SP <committish> LF)?
^ permalink raw reply related
* [PATCH v6 3/4] reset: add a few tests for "git reset --merge"
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
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>
---
t/t7110-reset-merge.sh | 159 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 159 insertions(+), 0 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
new file mode 100755
index 0000000..4c46083
--- /dev/null
+++ b/t/t7110-reset-merge.sh
@@ -0,0 +1,159 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Christian Couder
+#
+
+test_description='Tests for "git reset --merge"'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ for i in 1 2 3; do echo line $i; done >file1 &&
+ cat file1 >file2 &&
+ git add file1 file2 &&
+ test_tick &&
+ git commit -m "Initial commit" &&
+ git tag initial &&
+ echo line 4 >>file1 &&
+ cat file1 >file2 &&
+ test_tick &&
+ git commit -m "add line 4 to file1" file1 &&
+ git tag second
+'
+
+# 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)"
+'
+
+test_expect_success 'reset --merge is ok when switching back' '
+ git reset --merge second &&
+ grep 4 file1 &&
+ grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: B B C D --merge D D D
+# file2: C D D D --merge C D D
+test_expect_success 'reset --merge discards changes added to index (1)' '
+ git reset --hard second &&
+ cat file1 >file2 &&
+ echo "line 5" >> file1 &&
+ git add file1 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file1 &&
+ ! grep 5 file1 &&
+ grep 4 file2 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse initial)" &&
+ test -z "$(git diff --cached)"
+'
+
+test_expect_success 'reset --merge is ok again when switching back (1)' '
+ git reset --hard initial &&
+ echo "line 5" >> file2 &&
+ git add file2 &&
+ git reset --merge second &&
+ ! grep 4 file2 &&
+ ! grep 5 file1 &&
+ grep 4 file1 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ 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)"
+'
+
+test_expect_success 'reset --merge is ok again when switching back (2)' '
+ git reset --hard initial &&
+ git reset --merge second &&
+ ! grep 4 file2 &&
+ grep 4 file1 &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+ test -z "$(git diff --cached)"
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: A B B C --merge (disallowed)
+test_expect_success 'reset --merge fails with changes in file it touches' '
+ git reset --hard second &&
+ echo "line 5" >> file1 &&
+ test_tick &&
+ git commit -m "add line 5" file1 &&
+ sed -e "s/line 1/changed line 1/" <file1 >file3 &&
+ mv file3 file1 &&
+ test_must_fail git reset --merge HEAD^ 2>err.log &&
+ grep file1 err.log | grep "not uptodate"
+'
+
+test_expect_success 'setup 2 different branches' '
+ git reset --hard second &&
+ git branch branch1 &&
+ git branch branch2 &&
+ git checkout branch1 &&
+ echo "line 5 in branch1" >> file1 &&
+ test_tick &&
+ git commit -a -m "change in branch1" &&
+ git checkout branch2 &&
+ echo "line 5 in branch2" >> file1 &&
+ test_tick &&
+ git commit -a -m "change in branch2" &&
+ git tag third
+'
+
+# The next test will test the following:
+#
+# working index HEAD target working index HEAD
+# ----------------------------------------------------
+# file1: X U B C --merge (disallowed)
+test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD^ &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
+ test -n "$(git diff --cached)"
+'
+
+# 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' '
+ git reset --hard third &&
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD &&
+ test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
+ test -n "$(git diff --cached)"
+'
+
+test_done
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 2/4] Documentation: reset: add some tables to describe the different options
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
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>
---
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.
+
+ 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)
+
+ 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)
+
+ 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
+
+In these tables, A, B, C and D are some different states of a
+file. For example, the last line of the last table means that if a
+file is in state B in the working tree and the index, and in a
+different state C in HEAD and in the target, then "git reset
+--merge target" will put the file in state C in the working tree,
+in the index and in HEAD.
+
+The following tables show what happens when there are unmerged
+entries:
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge (disallowed)
+
+X means any state and U means an unmerged index.
+
Examples
--------
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 1/4] reset: improve mixed reset error message when in a bare repo
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
When running a "git reset --mixed" in a bare repository, the
message displayed is something like:
fatal: This operation must be run in a work tree
fatal: Could not reset index file to revision 'HEAD^'.
This message is a little bit misleading because a mixed reset is
ok in a git directory, so it is not absolutely needed to run it in
a work tree.
So this patch improves upon the above by changing the message to:
fatal: mixed reset is not allowed in a bare repository
And if "git reset" is ever sped up by using unpack_tree() directly
(instead of execing "git read-tree"), this patch will also make
sure that a mixed reset is still disallowed in a bare repository.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-reset.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 11d1c6e..3180c2b 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -291,6 +291,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
die("%s reset requires a work tree",
reset_type_names[reset_type]);
+ if (reset_type == MIXED && is_bare_repository())
+ die("%s reset is not allowed in a bare repository",
+ reset_type_names[reset_type]);
+
/* Soft reset does not touch the index file nor the working tree
* at all, but requires them in a good order. Other resets reset
* the index file to the tree object we are switching to. */
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 4/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This patch makes "reset_index_file()" call "unpack_trees()" directly
instead of forking and execing "git read-tree". So the code is more
efficient.
And it's also easier to see which unpack_tree() options will be used,
as we don't need to follow "git read-tree"'s command line parsing
which is quite complex.
As Daniel Barkalow found, there is a difference between this new
version and the old one. The old version gives an error for
"git reset --merge" with unmerged entries, and the new version does
not when we reset the entries to some states that differ from HEAD.
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".
The code comes from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 2 +-
builtin-reset.c | 41 ++++++++++++++++++++++++++++++-----------
t/t7110-reset-merge.sh | 12 +++++++-----
3 files changed, 38 insertions(+), 17 deletions(-)
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
working index HEAD target working index HEAD
----------------------------------------------------
diff --git a/builtin-reset.c b/builtin-reset.c
index 3180c2b..2c880a7 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -18,6 +18,8 @@
#include "tree.h"
#include "branch.h"
#include "parse-options.h"
+#include "unpack-trees.h"
+#include "cache-tree.h"
static const char * const git_reset_usage[] = {
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
@@ -54,27 +56,44 @@ static inline int is_merge(void)
static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet)
{
- int i = 0;
- const char *args[6];
+ int nr = 1;
+ int newfd;
+ struct tree_desc desc[2];
+ struct unpack_trees_options opts;
+ struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
- args[i++] = "read-tree";
+ memset(&opts, 0, sizeof(opts));
+ opts.head_idx = 1;
+ opts.src_index = &the_index;
+ opts.dst_index = &the_index;
+ opts.fn = oneway_merge;
+ opts.merge = 1;
if (!quiet)
- args[i++] = "-v";
+ opts.verbose_update = 1;
switch (reset_type) {
case MERGE:
- args[i++] = "-u";
- args[i++] = "-m";
+ opts.update = 1;
break;
case HARD:
- args[i++] = "-u";
+ opts.update = 1;
/* fallthrough */
default:
- args[i++] = "--reset";
+ opts.reset = 1;
}
- args[i++] = sha1_to_hex(sha1);
- args[i] = NULL;
- return run_command_v_opt(args, RUN_GIT_CMD);
+ newfd = hold_locked_index(lock, 1);
+
+ read_cache_unmerged();
+
+ if (!fill_tree_descriptor(desc + nr - 1, sha1))
+ return error("Failed to find tree of %s.", sha1_to_hex(sha1));
+ if (unpack_trees(nr, desc, &opts))
+ return -1;
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_locked_index(lock))
+ return error("Could not write new index file.");
+
+ return 0;
}
static void print_new_head_line(struct commit *commit)
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
index 4c46083..ff2875c 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -135,12 +135,14 @@ test_expect_success 'setup 2 different branches' '
#
# working index HEAD target working index HEAD
# ----------------------------------------------------
-# file1: X U B C --merge (disallowed)
-test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+# file1: X U B C --merge X C C
+test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
test_must_fail git merge branch1 &&
- test_must_fail git reset --merge HEAD^ &&
- test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
- test -n "$(git diff --cached)"
+ 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
'
# The next test will test the following:
--
1.6.6.rc2.5.g49666
^ permalink raw reply related
* [PATCH v6 0/4] "git reset --merge" related improvements
From: Christian Couder @ 2009-12-30 5:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
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"
Documentation/git-reset.txt | 66 ++++++++++++++++++
builtin-reset.c | 45 +++++++++---
t/t7110-reset-merge.sh | 161 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 261 insertions(+), 11 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
^ permalink raw reply
* Re: [PATCH v5 4/7] reset: add option "--keep" to "git reset"
From: Christian Couder @ 2009-12-30 5:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7viqcbn9w3.fsf@alter.siamese.dyndns.org>
On samedi 12 décembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
> > B B C D --keep (disallowed)
> > --merge C C C
>
> For --keep this is the same as the first case (except that the "partially
> updated the index" happened to be "100% pertially") and it makes sense to
> disallow it.
>
> However, I think --merge _should_ have D (target) in all of the three in
> the result in this case, as I mentioned in my response to [PATCH 3/7].
> Is that "the bug" you talked about there?
No it is not the bug I talked about. It was a bug in the documentation
patch. Thanks for finding it! I left some "C" on the merge line from an
earlier documentation patch but I should have changed them to "D" like
that:
B B C D --keep (disallowed)
--merge D D D
[...]
> It also is tempting to say that we should forbid "reset --merge" without
> an unmerged entry in the index, but that wouldn't work. A mergy
> operation would have left unmerged entries in the index initially before
> giving the control back to the user, but the user may have used "edit &&
> git add" to resolve them, and then decided that it is not worth
> committing. By the time "reset --merge" is run, there may not be any
> unmerged path left in the index.
>
> I am suggesting extra safety measures primarily because I am worried that
> people will get confused by these two similar looking options that are
> meant for entirely different use cases. An obvious alternative solution
> to avoid the confusion is not to add "--keep" in the first place. While
> I think that is rather a cop-out than a solution, it might make more
> sense. It is hopeless to educate users to pick the right one, if even the
> author of the new option mistakenly thinks that "--keep is merely a
> better version of --merge".
I just think it is better in some cases not always.
> My preference is at this point to first have patches [1/7] to [3/7] to
> update "reset --merge" (I am not sure about the "--mixed in $GIT_DIR"
> change, though), with a new follow-up patch [3.5/7] to fix "reset
> --merge" to reset paths that were cloberred by the merge to the target
> (not HEAD), and start cooking these changes in 'pu' and then 'next'.
Ok, I will send a patch series to do that except that I I don't understand
exactly what the follow up patch [3.5/7] shoud do. Perhaps you asked for
this additional patch because of the documentation bug above?
> That will lay groundwork of using unpack_trees() in "reset" and after
> they stabilize, build new modes like "--keep" on top of it.
Ok.
Thanks,
Christian.
^ permalink raw reply
* Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joey Korkames, git
In-Reply-To: <cone.1261179562.490491.4033.1000@toolshiner.phx1.kidfixit.com>
Junio, could you tell us what happened to this thread?
I think this is probably related to the "textconv" change.
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvdg9ceud.fsf@alter.siamese.dyndns.org>
Junio, could you tell us what happened to this thread?
I use this patch myself, and it works really well.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <1258341126-2108-1-git-send-email-davvid@gmail.com>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: [PATCH v2] gitk: Honor TMPDIR when viewing diffs externally
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, peff, sam, git, paulus
In-Reply-To: <1258680422-42179-1-git-send-email-davvid@gmail.com>
Junio, could you tell us what happened to this thread?
A patch to help running diff command from gitk in a read-only place.
^ permalink raw reply
* Re: [PATCH] Fix archive format with -- on the command line
From: Nanako Shiraishi @ 2009-12-30 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Miklos Vajna, Ilari Liusvaara, git
In-Reply-To: <4B23B019.40106@lsrfire.ath.cx>
Junio, could you tell us what happened to this thread?
"git archive HEAD non-existing-path" doesn't complain like "git
add" does, and the patch is to fix it. No discussion.
^ permalink raw reply
* Re: Question about 'branch -d' safety
From: Nanako Shiraishi @ 2009-12-30 3:12 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20091229223123.GA12965@vidovic>
Quoting Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
> The 30/12/09, Nanako Shiraishi wrote:
>
>> I think the safety feature should check if the branch to be deleted is merged to the remote tracking branch it was forked from, instead of checking the current branch.
>>
>> What do you think?
>
> I think we shouldn't. At first, every repository don't have a remote.
> This may easily be passed by a "double check" with a logical OR between
> the two statements.
Sorry, I was unclear. What I meant was that checking with the branch the branch to be deleted was forked from, if and only if such a branch exists. Otherwise, we can keep using the old default behavior to check with the current branch.
> But even with it, we would hit some foreign workflow. Think: Bob
> directly push to Alice and Alice does the same to Bob. I don't use this
> kind of workflow myself but I consider them to be sensible enough to
> have our attention.
Here is what I think about your scenario.
Bob directly pushes to Alice and Alice does the same to Bob, both to their refs/remotes/<other person>/ tracking branches, and their own local branches fork from the remote tracking branches that keep track of other person's work. You would still want the check based on that tracking branch, not based on 'master' that has no relationship with the branches they are exchanging.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Sebastian Schuberth @ 2009-12-30 1:16 UTC (permalink / raw)
To: kusmabite; +Cc: Johannes Sixt, git
In-Reply-To: <40aa078e0912291655m57ea0081vddf3b64bf27e1d02@mail.gmail.com>
On Wed, Dec 30, 2009 at 01:55, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>>> Why this? Compatibility with what? What's the problem with the status quo?
>>
>> I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit. h2du
>> depends on libpopt, and either of the two requires the uid_t type, I
>> do not recall which. And while adding the missing uid_t, I felt it
>> would be right to actually use uid_t / pid_t in the function
>> prototypes.
>
> Perhaps I'm missing something here... why do you need to modify the
> git-sources in order to include an external tool?
Because I'm building that external tool in the msysGit environment. As
you know, the way we include external tools (like vim, unzip etc.) to
the msysGit distribution is to create release.sh scripts that download
the sources, apply patches, and build the tool. Patching the original
hd2u sources to include compat/mingw.h was the best way that I saw to
get some required symbols, with only two symbols missing, and those
missing symbols are added by my patches.
Anyway, IMHO the correct declaration of e.g. getuid() is not "int
getuid()", but "uid_t getuid()" etc. So even if the uid_t type was not
required, it's a good change I think.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH] Add completion for git-svn mkdirs,reset,and gc
From: Shawn O. Pearce @ 2009-12-30 0:59 UTC (permalink / raw)
To: Robert Zeh; +Cc: git
In-Reply-To: <C065517F-C829-46D1-8D1A-88C18EE2112F@gmail.com>
Robert Zeh <robert.a.zeh@gmail.com> wrote:
>
> Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
> ---
> contrib/completion/git-completion.bash | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* [PATCH] Add completion for git-svn mkdirs,reset,and gc
From: Robert Zeh @ 2009-12-30 0:58 UTC (permalink / raw)
To: spearce; +Cc: git
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
---
contrib/completion/git-completion.bash | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index fbfa5f2..c65462c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2022,7 +2022,7 @@ _git_svn ()
init fetch clone rebase dcommit log find-rev
set-tree commit-diff info create-ignore propget
proplist show-ignore show-externals branch tag blame
- migrate
+ migrate mkdirs reset gc
"
local subcommand="$(__git_find_on_cmdline "$subcommands")"
if [ -z "$subcommand" ]; then
@@ -2069,7 +2069,7 @@ _git_svn ()
__gitcomp "--stdin $cmt_opts $fc_opts"
;;
create-ignore,--*|propget,--*|proplist,--*|show-ignore,--*|\
- show-externals,--*)
+ show-externals,--*|mkdirs,--*)
__gitcomp "--revision="
;;
log,--*)
@@ -2106,6 +2106,9 @@ _git_svn ()
--no-auth-cache --username=
"
;;
+ reset,--*)
+ __gitcomp "--revision= --parent"
+ ;;
*)
COMPREPLY=()
;;
--
1.6.6.rc3.dirty
^ permalink raw reply related
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Erik Faye-Lund @ 2009-12-30 0:55 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Johannes Sixt, git
In-Reply-To: <bdca99240912291649h1c727072q3b1e4099cab426df@mail.gmail.com>
On Wed, Dec 30, 2009 at 1:49 AM, Sebastian Schuberth
<sschuberth@gmail.com> wrote:
> On Tue, Dec 29, 2009 at 22:09, Johannes Sixt <j6t@kdbg.org> wrote:
>
>>> MinGW: Use pid_t more consequently, introduce uid_t for greater
>>> compatibility
>>
>> Why this? Compatibility with what? What's the problem with the status quo?
>
> I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit. h2du
> depends on libpopt, and either of the two requires the uid_t type, I
> do not recall which. And while adding the missing uid_t, I felt it
> would be right to actually use uid_t / pid_t in the function
> prototypes.
>
Perhaps I'm missing something here... why do you need to modify the
git-sources in order to include an external tool?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH 2/2] MinGW: Add missing file mode bit defines
From: Sebastian Schuberth @ 2009-12-30 0:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B3A702C.5040408@kdbg.org>
>> MinGW: Add missing file mode bit defines
>
> Why this? What's the problem with the status quo?
Same here as for the "Use pid_t more consequently" patch, hd2u
required one of the missing defines to compile for msysGit.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Sebastian Schuberth @ 2009-12-30 0:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B3A7000.4050308@kdbg.org>
On Tue, Dec 29, 2009 at 22:09, Johannes Sixt <j6t@kdbg.org> wrote:
>> MinGW: Use pid_t more consequently, introduce uid_t for greater
>> compatibility
>
> Why this? Compatibility with what? What's the problem with the status quo?
I wanted to include Hany's Dos2Unix tool (hd2u) into msysGit. h2du
depends on libpopt, and either of the two requires the uid_t type, I
do not recall which. And while adding the missing uid_t, I felt it
would be right to actually use uid_t / pid_t in the function
prototypes.
--
Sebastian Schuberth
^ 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