* Re: How do you best store structured data in git repositories?
From: David Aguilar @ 2009-12-08 7:14 UTC (permalink / raw)
To: Sebastian Setzer; +Cc: git
In-Reply-To: <1260220821.3545.12.camel@nord26-amd64>
On Mon, Dec 07, 2009 at 10:20:21PM +0100, Sebastian Setzer wrote:
> On Thursday, Dec 03 2009 at 16:14 -0800, David Aguilar wrote:
> > On Wed, Dec 02, 2009 at 04:17:10PM -0500, Avery Pennarun wrote:
> > > On Wed, Dec 2, 2009 at 4:08 PM, Sebastian Setzer
> > > <sebastianspublicaddress@googlemail.com> wrote:
> > > > Do you use XML for this purpose?
> > >
> > > XML is terrible for most data storage purposes.
> >
> > I agree 100%.
> >
> > JSON's not too bad for data structures and is known to
> > be friendly to XML expats.
> >
> Sorry, I didn't want to start a flamewar against XML. I'm no big friend
> of XML myself, but I don't know of an (open source) diff-/merge tool for
> any general purpose file format other than XML or plain text.
> When you mention other formats, I'd be interested in
> - why this format is good for storage in git
> - if there are merge tools available which ensure that, after a merge,
> the structure (and maybe additional contraints) is still valid.
>
> Thanks for your comments,
> Sebastian
Sorry, didn't mean to sound xml-flaming. The only reason for
mentioning json, yaml, etc. is that they're good data structure
formats. They're all plain text formats, so you can use existing
diff/merge tools.
I guess none of this has much to do with git aside from being
able to write custom merge drivers to operate on them as data.
If there's a diff/merge tool for xml that works well then
hooking it up to git-{diff,merge}tool might be something
to try too.
--
David
^ permalink raw reply
* Re: git-apply fails on creating a new file, with both -p and --directory specified
From: Junio C Hamano @ 2009-12-08 7:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, James Vega, git
In-Reply-To: <20091208060109.GB9951@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Dec 08, 2009 at 12:47:24AM -0500, Jeff King wrote:
>
>> There is a slightly different approach we could take, too: keep the
>> "deletion" hunk as a first-class hunk, and just meld the content hunk's
>> output into it. Then both cases would get the "Stage deletion" question
>> instead of the "Stage this hunk" you get now for non-empty files (which
>> just happens to trigger a deletion due to the headers).
>
> BTW, the code for this is the much smaller change below. If you prefer
> that, I can squash in the test and write up an appropriate commit
> message.
Doubly interesting, as I recall reading "That would take some refactoring,
though, as pulling the deletion hunk"
... goes and looks ...
Ah, Ok, the "refactoring" refers to the "header reordering weirdness".
That might be something we may want to fix someday, when we find ourselves
needing to add a feature to turn deletion into non-deletion or vice versa
during "add -p" [e]dit, as I suspect that the "hunk editing" codepath does
not keep track of what the user's patch is doing, to the point that it
does not even know how many lines there are supposed to be in the
resulting hunk that it asks "git apply" to recount. There is no way to
add/delete "deleted file" line if the logic does not know what the patch
is doing.
But someday is not today. I think this six-liner is preferable.
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 35f4ef1..02e97b9 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -1217,7 +1217,11 @@ sub patch_update_file {
> if (@{$mode->{TEXT}}) {
> unshift @hunk, $mode;
> }
> - if (@{$deletion->{TEXT}} && !@hunk) {
> + if (@{$deletion->{TEXT}}) {
> + foreach my $hunk (@hunk) {
> + push @{$deletion->{TEXT}}, @{$hunk->{TEXT}};
> + push @{$deletion->{DISPLAY}}, @{$hunk->{DISPLAY}};
> + }
> @hunk = ($deletion);
> }
>
^ permalink raw reply
* Re: git-apply fails on creating a new file, with both -p and --directory specified
From: Jeff King @ 2009-12-08 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Vega, git
In-Reply-To: <7vvdgindo3.fsf@alter.siamese.dyndns.org>
On Mon, Dec 07, 2009 at 11:11:08PM -0800, Junio C Hamano wrote:
> I was wondering about the same thing while bisecting. By the current
> definition of "diff --git", removing the "deleted file" or "new file" line
> makes the patch an invalid "git format diff". See the beginning of
> parse_git_header() where we say "we don't guess" and initialize both
> is_new and is_delete to false (and we flip them upon seeing "deleted file"
> and "new file", but never with "/dev/null").
Hmm. In that case, I think converting it to deletion is definitely
wrong; "diff --git" is about not guessing. So the only question is
whether it should be flagged as an error. I was somewhat worried that
you could produce a patch which would make apply complain by doing "git
diff /dev/null /your/file". But actually that already produces a "new
file" header (and the opposite produces a "deleted file" header).
So I think the patch below would notice both the new and deleted cases,
and is probably a good thing.
diff --git a/builtin-apply.c b/builtin-apply.c
index c8372a0..43a1535 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -673,8 +673,12 @@ static int gitdiff_hdrend(const char *line, struct patch *patch)
*/
static char *gitdiff_verify_name(const char *line, int isnull, char *orig_name, const char *oldnew)
{
- if (!orig_name && !isnull)
+ if (!orig_name && !isnull) {
+ if (!memcmp(line, "/dev/null\n", 10))
+ die("git apply: bad git-diff - expected filename, got /dev/null on line %d", linenr);
return find_name(line, NULL, p_value, TERM_TAB);
+ }
+
if (orig_name) {
int len;
> I think some recent other SCMs produce what they claim to be "diff --git",
> but I don't know if they implement the format correctly enough. I am not
> worried about their implemention of binary patches (if they do not
> implement it correctly they will most likely get garbage), but do they get
> the abbreviated hash on the "index" line correctly? You can put garbage
> on the line and most of the time it would work but it will break "am -3"
> by breaking "apply --build-fake-ancestor".
>
> I just checked "hg diff --git"; at least it shows "deleted file".
Ugh. A whole new source of problems. :) I am not too interested in
seeking out and evaluating other SCM's implementations; I think we
should wait for people who actually use those systems to find
interoperability bugs, determine whether they are or are not simply bugs
in the other people's implementations, and then report the bug to us.
> > That would take some refactoring, though, as pulling the deletion hunk
> > out means we are re-ordering the headers. So right now if you did that
> > your ($head, @hunk) output would be something like:
> >
> > diff --git a/foo b/foo
> > index 257cc56..0000000
> > --- a/foo
> > +++ /dev/null
> > deleted file mode 100644
> > @@ -1 +0,0 @@
> > -foo
> >
> > which is pretty weird.
>
> I agree it is weird.
Note that we already do this for mode changes which also have a content
change. They look like:
diff --git a/foo b/foo
index 257cc56..19c6cc1
--- a/foo
+++ b/foo
old mode 100644
new mode 100755
Stage mode change [y,n,q,a,d,/,j,J,g,?]?
@@ -1 +1,2 @@
foo
+content
Stage this hunk [y,n,q,a,d,/,K,g,e,?]?
> Interesting. Does "add -p" (especially its [e]dit codepath) know enough
> about what it is doing? If so, it should be able to add "deleted file" on
> its own (and remove it when the result of editing and picking hunks makes
> the patch a non-deletion). For example, if you have a two-liner in the
> index and have deleted one line in the work tree, and run "add -p":
No, it doesn't know enough now. That would be part of the refactoring I
mentioned. I'm not sure how useful it is to support this. I can see
going from "I had hunk A, but I really wanted to tweak it to hunk B". I
can't think of a single time I've wanted "I deleted the entire file, but
I really wanted to keep 2 lines". And if I did, I would probably just:
git checkout file
$EDITOR file
git add -p file
> Perhaps the "add -i" at the end should offer, after noticing that the
> chosen and edited hunks will make the postimage an empty file, a chance
> for the user to say "I not only want to remove the contents from the path,
> but want to remove the path itself" in such a case?
>
> I dunno.
I would not say no to such a patch, but I really have no interest in
writing it myself.
-Peff
^ permalink raw reply related
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-08 7:43 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Johannes Schindelin, Matthieu Moy,
Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091208150102.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Hmph, did you forget to retitle the message, or keep in-body "Subject:"?
>
> Sorry. Yes I did. Please amend it to -
>
> Subject: rebase -i --autosquash: auto-squash commits
Ok.
^ permalink raw reply
* Re: git-apply fails on creating a new file, with both -p and --directory specified
From: Jeff King @ 2009-12-08 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Vega, git
In-Reply-To: <7v3a3lorge.fsf@alter.siamese.dyndns.org>
On Mon, Dec 07, 2009 at 11:28:01PM -0800, Junio C Hamano wrote:
> That might be something we may want to fix someday, when we find ourselves
> needing to add a feature to turn deletion into non-deletion or vice versa
> during "add -p" [e]dit, as I suspect that the "hunk editing" codepath does
> not keep track of what the user's patch is doing, to the point that it
> does not even know how many lines there are supposed to be in the
> resulting hunk that it asks "git apply" to recount. There is no way to
> add/delete "deleted file" line if the logic does not know what the patch
> is doing.
>
> But someday is not today. I think this six-liner is preferable.
OK, here it is with the test and an amended commit message. You could
almost do an [e]dit on this and delete the "deleted" line, but you have
no way of fixing up the "+++ /dev/null" line. For now, we have
disabled [e]dit entirely for non-content hunks, so at least you cannot
get yourself into trouble creating a broken patch. :)
-- >8 --
Subject: [PATCH] add-interactive: fix deletion of non-empty files
Commit 24ab81a fixed the deletion of empty files, but broke
deletion of non-empty files. The approach it took was to
factor out the "deleted" line from the patch header into its
own hunk, the same way we do for mode changes. However,
unlike mode changes, we only showed the special "delete this
file" hunk if there were no other hunks. Otherwise, the user
would annoyingly be presented with _two_ hunks: one for
deleting the file and one for deleting the content.
This meant that in the non-empty case, we forgot about the
deleted line entirely, and we submitted a bogus patch to
git-apply (with "/dev/null" as the destination file, but not
marked as a deletion).
Instead, this patch combines the file deletion hunk and the
content deletion hunk (if there is one) into a single
deletion hunk which is either staged or not.
Signed-off-by: Jeff King <peff@peff.net>
---
git-add--interactive.perl | 6 +++++-
t/t3701-add-interactive.sh | 20 ++++++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 35f4ef1..02e97b9 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1217,7 +1217,11 @@ sub patch_update_file {
if (@{$mode->{TEXT}}) {
unshift @hunk, $mode;
}
- if (@{$deletion->{TEXT}} && !@hunk) {
+ if (@{$deletion->{TEXT}}) {
+ foreach my $hunk (@hunk) {
+ push @{$deletion->{TEXT}}, @{$hunk->{TEXT}};
+ push @{$deletion->{DISPLAY}}, @{$hunk->{DISPLAY}};
+ }
@hunk = ($deletion);
}
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index aa5909b..0926b91 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -215,6 +215,26 @@ test_expect_success 'add first line works' '
'
cat >expected <<EOF
+diff --git a/non-empty b/non-empty
+deleted file mode 100644
+index d95f3ad..0000000
+--- a/non-empty
++++ /dev/null
+@@ -1 +0,0 @@
+-content
+EOF
+test_expect_success 'deleting a non-empty file' '
+ git reset --hard &&
+ echo content >non-empty &&
+ git add non-empty &&
+ git commit -m non-empty &&
+ rm non-empty &&
+ echo y | git add -p non-empty &&
+ git diff --cached >diff &&
+ test_cmp expected diff
+'
+
+cat >expected <<EOF
diff --git a/empty b/empty
deleted file mode 100644
index e69de29..0000000
--
1.6.5.1.g24ab.dirty
^ permalink raw reply related
* Re: git-apply fails on creating a new file, with both -p and --directory specified
From: Junio C Hamano @ 2009-12-08 7:53 UTC (permalink / raw)
To: Jeff King; +Cc: James Vega, git
In-Reply-To: <20091208074935.GB12049@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> OK, here it is with the test and an amended commit message. You could
> almost do an [e]dit on this and delete the "deleted" line, but you have
> no way of fixing up the "+++ /dev/null" line. For now, we have
> disabled [e]dit entirely for non-content hunks, so at least you cannot
> get yourself into trouble creating a broken patch. :)
;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] Add commit.status, --status, and --no-status
From: Jeff King @ 2009-12-08 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James P. Howard, II, git
In-Reply-To: <7vr5r6ndkz.fsf@alter.siamese.dyndns.org>
On Mon, Dec 07, 2009 at 11:13:00PM -0800, Junio C Hamano wrote:
> >> This commit provides support for commit.status, --status, and
> >> --no-status, which control whether or not the git status information
> >> is included in the commit message template when using an editor to
> >> prepare the commit message. It does not affect the effects of a
> >> user's commit.template settings.
> >
> > Thanks, this looks very cleanly done. The only complaint I would make is
> > that it should probably include a simple test case.
>
> Yes. Also I am a _bit_ worried about the name "status", as the longer
> term direction is to make "status" not "a preview of commit", may confuse
> people who do read Release Notes.
I thought about that, but what other name does it have? That text has
always been called "status", and we will continue to support that output
format as "git status" _and_ as "commit --dry-run". So I think
explaining it as "usually we stick the output of 'git status' into the
commit message, but this suppresses it" is not that hard (and that was
how I read the documentation in his patch).
The only trick is that it is not a vanilla "git status", but rather
"status after we have staged things for commit". But I think that is
fairly obvious since you are, after all, calling "commit".
But then again, I am probably way too deep in this topic to provide a
regular git user's perspective of what is obvious.
-Peff
^ permalink raw reply
* [PATCH v4 1/6] reset: add a few tests for "git reset --merge"
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.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 | 94 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 94 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..8190da1
--- /dev/null
+++ b/t/t7110-reset-merge.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Christian Couder
+#
+
+test_description='Tests for "git reset --merge"'
+
+. ./test-lib.sh
+
+test_expect_success 'creating initial files' '
+ echo "line 1" >> file1 &&
+ echo "line 2" >> file1 &&
+ echo "line 3" >> file1 &&
+ cp file1 file2 &&
+ git add file1 file2 &&
+ test_tick &&
+ git commit -m "Initial commit"
+'
+
+test_expect_success 'reset --merge is ok with changes in file it does not touch' '
+ echo "line 4" >> file1 &&
+ echo "line 4" >> file2 &&
+ test_tick &&
+ git commit -m "add line 4" file1 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file1 &&
+ grep 4 file2 &&
+ git reset --merge HEAD@{1} &&
+ grep 4 file1 &&
+ grep 4 file2
+'
+
+test_expect_success 'reset --merge discards changes added to index (1)' '
+ echo "line 5" >> file1 &&
+ git add file1 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file1 &&
+ ! grep 5 file1 &&
+ grep 4 file2 &&
+ echo "line 5" >> file2 &&
+ git add file2 &&
+ git reset --merge HEAD@{1} &&
+ ! grep 4 file2 &&
+ ! grep 5 file1 &&
+ grep 4 file1
+'
+
+test_expect_success 'reset --merge discards changes added to index (2)' '
+ echo "line 4" >> file2 &&
+ git add file2 &&
+ git reset --merge HEAD^ &&
+ ! grep 4 file2 &&
+ git reset --merge HEAD@{1} &&
+ ! grep 4 file2 &&
+ grep 4 file1
+'
+
+test_expect_success 'reset --merge fails with changes in file it touches' '
+ 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" &&
+ git reset --hard HEAD^
+'
+
+test_expect_success 'setup 2 different branches' '
+ 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"
+'
+
+test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD^ &&
+ git reset --hard HEAD
+'
+
+test_expect_success '"reset --merge HEAD" fails with pending merge' '
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD &&
+ git reset --hard HEAD
+'
+
+test_done
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 2/6] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.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. But this can be seen as a bug fix, because "--merge" was the
only "git reset" option with this behavior and this behavior was
not documented.
In fact there is still an error with unmerge entries if we reset
the unmerge entries to the same state as HEAD. So the bug is not
completely fixed.
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>
---
builtin-reset.c | 51 +++++++++++++++++++++++++++++++++++++----------
t/t7110-reset-merge.sh | 8 ++++--
2 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 73e6022..ddb81f3 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>]",
@@ -52,29 +54,56 @@ static inline int is_merge(void)
return !access(git_path("MERGE_HEAD"), F_OK);
}
+static int parse_and_init_tree_desc(const unsigned char *sha1,
+ struct tree_desc *desc)
+{
+ struct tree *tree = parse_tree_indirect(sha1);
+ if (!tree)
+ return 1;
+ init_tree_desc(desc, tree->buffer, tree->size);
+ return 0;
+}
+
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 (parse_and_init_tree_desc(sha1, desc + nr - 1))
+ 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 8190da1..6afaf73 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -79,10 +79,12 @@ test_expect_success 'setup 2 different branches' '
git commit -a -m "change in branch2"
'
-test_expect_success '"reset --merge HEAD^" fails with pending merge' '
+test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
test_must_fail git merge branch1 &&
- test_must_fail git reset --merge HEAD^ &&
- git reset --hard HEAD
+ git reset --merge HEAD^ &&
+ test -z "$(git diff --cached)" &&
+ test -n "$(git diff)" &&
+ git reset --hard HEAD@{1}
'
test_expect_success '"reset --merge HEAD" fails with pending merge' '
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 0/6] "git reset --merge" related improvements
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
This is a reroll of a previous series from last september:
http://thread.gmane.org/gmane.comp.version-control.git/128706/focus=128707
The changes in this reroll are the following:
- new option was renamed "--keep-local-changes" instead of "--merge-safe",
- some test cases have been added,
- a bug was fixed (head_sha1 is now "unsigned char head_sha1[20]"),
- I took ownership of the third patch,
- some commit messages were improved,
- there are 2 new documentation patches at the end,
- the last documentation patch adds some tables about what all the reset
options are doing in the different cases.
The new option name is "--keep-local-changes" because that's what
Junio used in the last email of the previous discussion, but my
opinion is that it is a bit long and so I'd like to rename it "--keep"
or another such short name.
Christian Couder (5):
reset: add a few tests for "git reset --merge"
reset: add option "--keep-local-changes" to "git reset"
reset: add test cases for "--keep-local-changes" option
Documentation: reset: describe new "--keep-local-changes" option
Documentation: reset: add some tables to describe the different
options
Stephan Beyer (1):
reset: use "unpack_trees()" directly instead of "git read-tree"
Documentation/git-reset.txt | 80 ++++++++++++++++++++++-
builtin-reset.c | 81 ++++++++++++++++++-----
t/t7110-reset-merge.sh | 156 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 300 insertions(+), 17 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
^ permalink raw reply
* [PATCH v4 3/6] reset: add option "--keep-local-changes" to "git reset"
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.chriscool@tuxfamily.org>
The purpose of this new option is to discard some of the
last commits but to keep current changes in the work tree
and the index.
The table below shows what happens when running
"git reset --option target" to reset the HEAD to another
commit (as a special case "target" could be the same as
HEAD) in the cases where "--merge" and
"--keep-local-changes" (abreviated --k-l-c) behave
differently.
working index HEAD target working index HEAD
----------------------------------------------------
B B A A --k-l-c B A A
--merge A A A
B B A C --k-l-c (disallowed)
--merge C C C
In this table, A, B and C are some different states of
a file. For example the first line of the table means
that if a file is in state B in the working tree and
the index, and in a different state A in HEAD and in
the target, then "git reset --keep-local-changes target"
will put the file in state B in the working tree and in
state A in the index and HEAD.
So as can be seen in the table, "--merge" discards changes
in the index, while "--keep-local-changes" does not. So
if one wants to avoid using "git stash" before and after
using "git reset" to save current changes, it is better to
use "--keep-local-changes" rather than "--merge".
The following table shows what happens on unmerged entries:
working index HEAD target working index HEAD
----------------------------------------------------
X U A B --k-l-c X B B
--merge X B B
X U A A --k-l-c X A A
--merge (disallowed)
In this table X can be any state and U means an unmerged
entry.
A following patch will add some test cases for
"--keep-local-changes", where the differences between
"--merge" and "--keep-local-changes" can also be seen.
The "--keep-local-changes" option is implemented by doing
a 2 way merge between HEAD and the reset target, and if
this succeeds by doing a mixed reset to the target.
The code comes from the sequencer GSoC project, where
such an option was developed by Stephan Beyer:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
But in the sequencer project the "reset" flag was set
in the "struct unpack_trees_options" passed to
"unpack_trees()". With this flag the changes in the
working tree were discarded if the file was different
between HEAD and the reset target.
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>
---
builtin-reset.c | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index ddb81f3..3cbc4fd 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -22,13 +22,15 @@
#include "cache-tree.h"
static const char * const git_reset_usage[] = {
- "git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
+ "git reset [--mixed | --soft | --hard | --merge | --keep-local-changes] [-q] [<commit>]",
"git reset [--mixed] <commit> [--] <paths>...",
NULL
};
-enum reset_type { MIXED, SOFT, HARD, MERGE, NONE };
-static const char *reset_type_names[] = { "mixed", "soft", "hard", "merge", NULL };
+enum reset_type { MIXED, SOFT, HARD, MERGE, KEEP_LOCAL_CHANGES, NONE };
+static const char *reset_type_names[] = {
+ "mixed", "soft", "hard", "merge", "keep_local_changes", NULL
+};
static char *args_to_str(const char **argv)
{
@@ -81,6 +83,7 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
if (!quiet)
opts.verbose_update = 1;
switch (reset_type) {
+ case KEEP_LOCAL_CHANGES:
case MERGE:
opts.update = 1;
break;
@@ -95,6 +98,16 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
read_cache_unmerged();
+ if (reset_type == KEEP_LOCAL_CHANGES) {
+ unsigned char head_sha1[20];
+ if (get_sha1("HEAD", head_sha1))
+ return error("You do not have a valid HEAD.");
+ if (parse_and_init_tree_desc(head_sha1, desc))
+ return error("Failed to find tree of HEAD.");
+ nr++;
+ opts.fn = twoway_merge;
+ }
+
if (parse_and_init_tree_desc(sha1, desc + nr - 1))
return error("Failed to find tree of %s.", sha1_to_hex(sha1));
if (unpack_trees(nr, desc, &opts))
@@ -238,6 +251,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
"reset HEAD, index and working tree", HARD),
OPT_SET_INT(0, "merge", &reset_type,
"reset HEAD, index and working tree", MERGE),
+ OPT_SET_INT(0, "keep-local-changes", &reset_type,
+ "reset HEAD but keep local changes",
+ KEEP_LOCAL_CHANGES),
OPT_BOOLEAN('q', NULL, &quiet,
"disable showing new HEAD in hard reset and progress message"),
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
@@ -324,9 +340,13 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
if (reset_type == SOFT) {
if (is_merge() || read_cache() < 0 || unmerged_cache())
die("Cannot do a soft reset in the middle of a merge.");
+ } else {
+ int err = reset_index_file(sha1, reset_type, quiet);
+ if (reset_type == KEEP_LOCAL_CHANGES)
+ err = err || reset_index_file(sha1, MIXED, quiet);
+ if (err)
+ die("Could not reset index file to revision '%s'.", rev);
}
- else if (reset_index_file(sha1, reset_type, quiet))
- die("Could not reset index file to revision '%s'.", rev);
/* Any resets update HEAD to the head being switched to,
* saving the previous head in ORIG_HEAD before. */
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 4/6] reset: add test cases for "--keep-local-changes" option
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.chriscool@tuxfamily.org>
This shows that with the "--keep-local-changes" option, changes that
are both in the work tree and the index are kept in the work tree
after the reset (but discarded in the index). As with the "--merge"
option, changes that are in both the work tree and the index are
discarded after the reset.
In the case of unmerged entries, we can see that
"git reset --merge HEAD" is disallowed while it works using
"--keep-local-changes" instead.
And this shows that otherwise "--merge" and "--keep-local-changes"
have the same behavior.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7110-reset-merge.sh | 62 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
index 6afaf73..c8f72cd 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2009 Christian Couder
#
-test_description='Tests for "git reset --merge"'
+test_description='Tests for "git reset" with --merge and --keep-local-changes'
. ./test-lib.sh
@@ -30,6 +30,20 @@ test_expect_success 'reset --merge is ok with changes in file it does not touch'
grep 4 file2
'
+test_expect_success 'reset --keep-local-changes is ok with changes in file it does not touch' '
+ git reset --hard HEAD^ &&
+ echo "line 4" >> file1 &&
+ echo "line 4" >> file2 &&
+ test_tick &&
+ git commit -m "add line 4" file1 &&
+ git reset --keep-local-changes HEAD^ &&
+ ! grep 4 file1 &&
+ grep 4 file2 &&
+ git reset --keep-local-changes HEAD@{1} &&
+ grep 4 file1 &&
+ grep 4 file2
+'
+
test_expect_success 'reset --merge discards changes added to index (1)' '
echo "line 5" >> file1 &&
git add file1 &&
@@ -55,6 +69,25 @@ test_expect_success 'reset --merge discards changes added to index (2)' '
grep 4 file1
'
+test_expect_success 'reset --keep-local-changes fails with changes in index in files it touches' '
+ echo "line 4" >> file2 &&
+ echo "line 5" >> file1 &&
+ git add file1 &&
+ test_must_fail git reset --keep-local-changes HEAD^ &&
+ git reset --hard HEAD
+'
+
+test_expect_success 'reset --keep-local-changes keeps changes it does not touch' '
+ echo "line 4" >> file2 &&
+ git add file2 &&
+ git reset --keep-local-changes HEAD^ &&
+ grep 4 file2 &&
+ git reset --keep-local-changes HEAD@{1} &&
+ grep 4 file2 &&
+ grep 4 file1 &&
+ git reset --hard HEAD
+'
+
test_expect_success 'reset --merge fails with changes in file it touches' '
echo "line 5" >> file1 &&
test_tick &&
@@ -66,6 +99,17 @@ test_expect_success 'reset --merge fails with changes in file it touches' '
git reset --hard HEAD^
'
+test_expect_success 'reset --keep-local-changes fails with changes in file it touches' '
+ 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 --keep-local-changes HEAD^ 2>err.log &&
+ grep file1 err.log | grep "not uptodate" &&
+ git reset --hard HEAD^
+'
+
test_expect_success 'setup 2 different branches' '
git branch branch1 &&
git branch branch2 &&
@@ -87,10 +131,26 @@ test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
git reset --hard HEAD@{1}
'
+test_expect_success '"reset --keep-local-changes HEAD^" is ok with pending merge' '
+ test_must_fail git merge branch1 &&
+ git reset --keep-local-changes HEAD^ &&
+ test -z "$(git diff --cached)" &&
+ test -n "$(git diff)" &&
+ git reset --hard HEAD@{1}
+'
+
test_expect_success '"reset --merge HEAD" fails with pending merge' '
test_must_fail git merge branch1 &&
test_must_fail git reset --merge HEAD &&
git reset --hard HEAD
'
+test_expect_success '"reset --keep-local-changes HEAD" is ok with pending merge' '
+ test_must_fail git merge branch1 &&
+ git reset --keep-local-changes HEAD &&
+ test -z "$(git diff --cached)" &&
+ test -n "$(git diff)" &&
+ git reset --hard HEAD
+'
+
test_done
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 6/6] Documentation: reset: add some tables to describe the different options
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.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 | 73 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index a6c080e..8bc8808 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -72,6 +72,79 @@ 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 (`--keep-local-changes` is abreviated --k-l-c)
+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)
+ --k-l-c (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)
+ --k-l-c A C C
+
+ 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
+ --k-l-c (disallowed)
+
+ 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
+ --k-l-c B 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
+--keep-local-changes target" will put the file in state B in the
+working tree and in state C in the index and HEAD.
+
+The following tables show what happens when there are unmerged
+entries:
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A B --k-l-c X B B
+ --merge X B B
+ --hard B B B
+ --mixed X B B
+ --soft (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A A --k-l-c X A A
+ --merge (disallowed)
+ --hard A A A
+ --mixed X A A
+ --soft (disallowed)
+
+X means any state and U means an unmerged index.
+
Examples
--------
--
1.6.5.1.gaf97d
^ permalink raw reply related
* [PATCH v4 5/6] Documentation: reset: describe new "--keep-local-changes" option
From: Christian Couder @ 2009-12-08 7:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-reset.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 2d27e40..a6c080e 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -8,7 +8,7 @@ git-reset - Reset current HEAD to the specified state
SYNOPSIS
--------
[verse]
-'git reset' [--mixed | --soft | --hard | --merge] [-q] [<commit>]
+'git reset' [--mixed | --soft | --hard | --merge | --keep-local-changes] [-q] [<commit>]
'git reset' [-q] [<commit>] [--] <paths>...
'git reset' --patch [<commit>] [--] [<paths>...]
@@ -52,6 +52,11 @@ OPTIONS
and updates the files that are different between the named commit
and the current commit in the working tree.
+--keep-local-changes::
+ This does the same thing as --merge, but it keeps changes in
+ the working tree and the index or it aborts if it is not
+ possible.
+
-p::
--patch::
Interactively select hunks in the difference between the index
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: help: bisect single file from repos
From: Christian Couder @ 2009-12-08 8:17 UTC (permalink / raw)
To: wharms; +Cc: Michael J Gruber, git
In-Reply-To: <4B1D27B6.7010900@bfs.de>
Hi,
On lundi 07 décembre 2009, walter harms wrote:
> Michael J Gruber schrieb:
> > walter harms venit, vidit, dixit 07.12.2009 13:59:
> >> Hi list,
> >> i am new to git (using: git version 1.6.0.2).
> >
> > though your git is not that new ;)
> >
> >> I would like to bisect a single file but i have only commit id, no
> >> tags.
> >>
> >> Background:
> >> I have a copy of the busybox git repos, and i know there is (perhaps)
> >> a bug in ash.c.
> >>
> >> how can i do that ?
> >
> > You don't need any tags for bisecting. The man page of git-bisect has
> > several examples on how to use it. Do you have a test script which
> > exposes the bug?
>
> unfortunately no, the error shows up very nicely when booting my
> embdedded system but not else (this is the reason i would to bisect that
> file only and not busybox completely). And from the man pages i got the
> impression that it is only possible the start with a tag.
The man page says:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
and then:
"This command uses git rev-list --bisect to help drive the binary search
process to find which change introduced a bug, given an old "good" commit
object name and a later "bad" commit object name."
> i already had the hint that i need to do:
> git bisect start bad_commit_id good_commit_id -- ash.c
So did you try that?
> Ntl, there is one more question, how can i make sure that
> i use the right version ?
If you mean the right git version, then I think any 1.6.X should be enough.
> first i toughed that cherry-pick is the right
> idea but it seems that that will apply onyl certain patches ?
If you want to find the commit that introduced a bug, then you should not
need cherry-pick.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v4 0/6] "git reset --merge" related improvements
From: Junio C Hamano @ 2009-12-08 8:29 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt
In-Reply-To: <20091208075005.4475.26582.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The new option name is "--keep-local-changes" because that's what
> Junio used in the last email of the previous discussion, but my
> opinion is that it is a bit long and so I'd like to rename it "--keep"
> or another such short name.
I vaguely recall that I mentioned something like "I still don't know what
you are going to use this for, even though I think I am starting to
understand it a bit better than before. In any case, it sounds like 'keep
local changes' rather than 'safe'".
Please don't take that as a serious suggestion of a better name.
IOW, don't mind me---come up with a name that describes what you
are doing better. But please don't blame me either ;-)
^ permalink raw reply
* Re: [PATCH v4 2/6] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Stephen Boyd @ 2009-12-08 8:45 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
In-Reply-To: <20091208075616.4475.46720.chriscool@tuxfamily.org>
On Tue, 2009-12-08 at 08:56 +0100, Christian Couder wrote:
> +static int parse_and_init_tree_desc(const unsigned char *sha1,
> + struct tree_desc *desc)
> +{
> + struct tree *tree = parse_tree_indirect(sha1);
> + if (!tree)
> + return 1;
> + init_tree_desc(desc, tree->buffer, tree->size);
> + return 0;
> +}
> +
>
Is there a reason why you use this function instead of
fill_tree_descriptor()?
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-08 9:24 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Matthieu Moy, Michael J Gruber,
Michael Haggerty, git
In-Reply-To: <20091208121314.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> @@ -519,6 +521,43 @@ get_saved_options () {
> test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
> }
>
> +# Rearrange the todo list that has both "pick sha1 msg" and
> +# "pick sha1 !fixup/!squash msg" appears in it so that the latter
> +# comes immediately after the former, and change "pick" to
> +# "fixup"/"squash".
> +rearrange_squash () {
> + sed -n -e 's/^pick \([0-9a-f]*\) !\(squash\) /\1 \2 /p' \
> + -e 's/^pick \([0-9a-f]*\) !\(fixup\) /\1 \2 /p' \
> + "$1" >"$1.sq"
> + test -s "$1.sq" || return
> +
> + sed -e '/^pick [0-9a-f]* !squash /d' \
> + -e '/^pick [0-9a-f]* !fixup /d' \
> + "$1" |
> + (
> + used=
> + while read pick sha1 message
> + do
> + ...
> + done >"$1.rearranged"
> + )
> + cat "$1.rearranged" >"$1"
> + rm -f "$1.sq"
> +}
The logic to move the lines seem to have been improved since the last
round, which is good. I've amended this to remove "$1.rearranged" as well.
Unlike the very initial round, but like the second round, this feature is
controlled by an explicit command line option, so it should be reasonably
safe.
I hate bikeshedding but somehow
git commit -m "fixup! commit with this message"
feels much more natural than having to write
git commit -m "!fixup commit with this message".
^ permalink raw reply
* Re: [PATCHv3 1/2] t3404: Use test_commit to set up test repository
From: Junio C Hamano @ 2009-12-08 9:25 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, git, Johannes.Schindelin, bgustavsson
In-Reply-To: <1b82a55c2a45b8f40ac0fe42d4ce2a55e72a2557.1260177312.git.mhagger@alum.mit.edu>
Thanks; will re-queue [2/2] as [1/2] seems to be unchanged.
^ permalink raw reply
* Re: [RFC/PATCHv10 00/11] git notes
From: Junio C Hamano @ 2009-12-08 9:25 UTC (permalink / raw)
To: Johan Herland; +Cc: git, spearce
In-Reply-To: <1260185254-1523-1-git-send-email-johan@herland.net>
Thanks; will re-queue.
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #03; Tue, 08)
From: Junio C Hamano @ 2009-12-08 9:25 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.
--------------------------------------------------
[New Topics]
* 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-06) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from external protocol helpers
- 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
(this branch is related to sr/vcs-helper.)
Under active discussion and review; another round expected.
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jk/maint-add-p-delete-fix (2009-12-08) 1 commit.
(merged to 'next' on 2009-12-08 at 3c2c08a)
+ add-interactive: fix deletion of non-empty files
Fixes a regression in 1.6.5.3.
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* ns/rebase-auto-squash (2009-12-08) 1 commit
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
--------------------------------------------------
[Stalled]
* 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
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jc/checkout-merge-base (2009-11-20) 2 commits
- "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
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* 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. Sigh. We won't have a
proper fix in 1.6.6.
* 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.
--------------------------------------------------
[Cooking]
* 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
- 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
Rerolled and under discussion.
* jn/maint-pull-rebase-error-message (2009-11-27) 1 commit.
(merged to 'next' on 2009-12-03 at 2ced03c)
+ pull: clarify advice for the unconfigured error case
Replaces old 'jn/rfc-pull-rebase-error-message' topic.
* 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
* 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".
* 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
Rerolled.
* 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
Rerolled.
* tr/http-updates (2009-12-01) 3 commits
(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
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This was to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens, but I think we should drop it.
Comments?
* sr/vcs-helper (2009-12-07) 14 commits
(merged to 'next' on 2009-12-07 at 8f041bc)
+ tests: handle NO_PYTHON setting
(merged to 'next' on 2009-12-03 at e45b562)
+ builtin-push: don't access freed transport->url
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
(this branch is related to il/vcs-helper.)
Should be among the first to graduate after 1.6.6 final.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
Comments?
* nd/sparse (2009-11-25) 20 commits.
(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
There were some test glitches reported and at least one test seems to
be broken in the sense that it is not testing what it is trying to.
Fix-up expected.
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-12-07) 11 commits.
(merged to 'next' on 2009-12-07 at 7723acf)
+ status: reduce duplicated setup code
+ status: disable color for porcelain format
(merged to 'next' on 2009-12-05 at 44dcefd)
+ status -s: obey color.status
+ builtin-commit: refactor short-status code into wt-status.c
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that will disappear soon.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
As the title says.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
As I am contemplating of dropping jc/diff-whitespace-prepare, this should
also be dropped as well.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits.
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Jeff King @ 2009-12-08 9:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Johannes Schindelin, Matthieu Moy,
Michael J Gruber, Michael Haggerty, git
In-Reply-To: <7viqchhl7h.fsf@alter.siamese.dyndns.org>
On Tue, Dec 08, 2009 at 01:24:50AM -0800, Junio C Hamano wrote:
> I hate bikeshedding but somehow
>
> git commit -m "fixup! commit with this message"
>
> feels much more natural than having to write
>
> git commit -m "!fixup commit with this message".
Also:
$ bash
$ echo "!fixup commit"
bash: !fixup: event not found
$ echo "fixup! commit"
fixup! commit
-Peff
^ permalink raw reply
* [PATCH 0/2] Add a few more status tests
From: Michael J Gruber @ 2009-12-08 10:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
Here are a few more tests for git status. The first one makes sure that
--porcelain uses paths based on the root, it makes sense on top of
14ed05d (t7508-status.sh: Add tests for status -s, 2009-11-27) or later.
The second one checks long, short and porcelain with color. It makes
sense on top of 3fe2a89 (status -s: obey color.status, 2009-12-05),
although one test will fail without the later 8661768 (status: reduce
duplicated setup code, 2009-12-07) and predecessor.
Remarks:
- There's not a single merge related status test so far.
- There's no test with -z because I don't know what it's suppoded to
(besides the obvious thing): should it turn off color automatically
but not relativePaths? Or should it switch to --porcelain -z?
Depending on the answer to the latter I have to do one more fixup to
wt-status.c (and write another test).
Thanks:
to J6t for pointing me to decrypt_color()
Michael J Gruber (2):
t7508-status: status --porcelain ignores relative paths setting
t7508-status: test all modes with color
t/t7508-status.sh | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 137 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 2/2] t7508-status: test all modes with color
From: Michael J Gruber @ 2009-12-08 10:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <cover.1260266027.git.git@drmicha.warpmail.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t7508-status.sh | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8e7727e..50554a0 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -31,6 +31,15 @@ test_expect_success 'setup' '
git add dir2/added
'
+decrypt_color () {
+ sed \
+ -e 's/.\[1m/<WHITE>/g' \
+ -e 's/.\[31m/<RED>/g' \
+ -e 's/.\[32m/<GREEN>/g' \
+ -e 's/.\[34m/<BLUE>/g' \
+ -e 's/.\[m/<RESET>/g'
+}
+
test_expect_success 'status (1)' '
grep "use \"git rm --cached <file>\.\.\.\" to unstage" output
@@ -315,6 +324,115 @@ test_expect_success 'status --porcelain ignores relative paths setting' '
'
+test_expect_success 'setup unique colors' '
+
+ git config status.color.untracked blue
+
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# <GREEN>new file: dir2/added<RESET>
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+# (use "git checkout -- <file>..." to discard changes in working directory)
+#
+# <RED>modified: dir1/modified<RESET>
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# <BLUE>dir1/untracked<RESET>
+# <BLUE>dir2/modified<RESET>
+# <BLUE>dir2/untracked<RESET>
+# <BLUE>expect<RESET>
+# <BLUE>output<RESET>
+# <BLUE>untracked<RESET>
+EOF
+
+test_expect_success 'status with color.ui' '
+
+ git config color.ui always &&
+ git status | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+test_expect_success 'status with color.status' '
+
+ git config --unset color.ui &&
+ git config color.status always &&
+ git status | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+cat > expect << \EOF
+ <RED>M<RESET> dir1/modified
+<GREEN>A<RESET> dir2/added
+<BLUE>??<RESET> dir1/untracked
+<BLUE>??<RESET> dir2/modified
+<BLUE>??<RESET> dir2/untracked
+<BLUE>??<RESET> expect
+<BLUE>??<RESET> output
+<BLUE>??<RESET> untracked
+EOF
+
+test_expect_success 'status -s with color.ui' '
+
+ git config --unset color.status &&
+ git config color.ui always &&
+ git status -s | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+test_expect_success 'status -s with color.status' '
+
+ git config --unset color.ui &&
+ git config color.status always &&
+ git status -s | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+cat > expect << \EOF
+ M dir1/modified
+A dir2/added
+?? dir1/untracked
+?? dir2/modified
+?? dir2/untracked
+?? expect
+?? output
+?? untracked
+EOF
+
+test_expect_success 'status --porcelain ignores color.ui' '
+
+ git config --unset color.status &&
+ git config color.ui always &&
+ git status --porcelain | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+test_expect_success 'status --porcelain ignores color.status' '
+
+ git config --unset color.ui &&
+ git config color.status always &&
+ git status --porcelain | decrypt_color > output &&
+ test_cmp expect output
+
+'
+
+# recover unconditionally from color tests
+git config --unset color.status
+git config --unset color.ui
+
cat > expect << \EOF
# On branch master
# Changes to be committed:
@@ -339,6 +457,7 @@ cat > expect << \EOF
# untracked
EOF
+
test_expect_success 'status without relative paths' '
git config status.relativePaths false
--
1.6.6.rc1.292.gd8fe
^ permalink raw reply related
* [PATCH 1/2] t7508-status: status --porcelain ignores relative paths setting
From: Michael J Gruber @ 2009-12-08 10:12 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <cover.1260266027.git.git@drmicha.warpmail.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t7508-status.sh | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 99a74bd..8e7727e 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -298,6 +298,24 @@ test_expect_success 'status -s with relative paths' '
'
cat > expect << \EOF
+ M dir1/modified
+A dir2/added
+?? dir1/untracked
+?? dir2/modified
+?? dir2/untracked
+?? expect
+?? output
+?? untracked
+EOF
+
+test_expect_success 'status --porcelain ignores relative paths setting' '
+
+ (cd dir1 && git status --porcelain) > output &&
+ test_cmp expect output
+
+'
+
+cat > expect << \EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
--
1.6.6.rc1.292.gd8fe
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox