* [ANNOUNCE] Git User's Survey 2009 has been closed
From: Jakub Narebski @ 2009-09-16 23:13 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hi all,
Git User's Survey 2009 ended at the end of Wednesday, 16 October 2008,
around 23:45 CEST (GMT+0200).
Beginnings of survey summary should be available soon at
http://git.or.cz/gitwiki/GitSurvey2009
Currently you can get there raw data (individual responses) in CSV and
XLS formats (compressed). One can find there also link to online
analysis (on Survs.com) and beginnings of partial survey summaries
(send to git mailing list in the duration of the survey).
Thanks to all who participated in this survey!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Junio C Hamano @ 2009-09-16 23:15 UTC (permalink / raw)
To: Julian Phillips; +Cc: git, Junio C Hamano
In-Reply-To: <20090916225350.45746.85139.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> When trying to get a list of remote tags to see if we need to fetch
> any we were doing a linear search for the matching tag ref for the
> tag^{} commit entries. This proves to be incredibly slow for large
> numbers of tags. Rewrite the function so that we can do lookup in
> string_lists instead.
>
> For a repository with 50000 tags (and just a single commit on a single
> branch), a fetch that does nothing goes from ~ 1m50s to ~4.2s.
>
> Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
> ---
>
> Not only does this not require a custom hash table, it is also slightly
> faster than the last version (~4.2s vs ~4.5s).
I am just curious. How would a "just one item lookbehind" code perform
compared to this one?
^ permalink raw reply
* Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags
From: Junio C Hamano @ 2009-09-16 23:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Julian Phillips, git
In-Reply-To: <20090916230350.GC14660@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> Also, you might not have noticed, but my illustration patch was merely
>> using it as a hint to optimize, and if the last ref we saw was not X when
>> it is turn to handle X^{}, it simply falled back to the original logic,
>> iow, the patch never compromised the correctness.
>
> Oh, I missed that. JGit I think flat out panics and disconnects
> if the remote does this to us. What is the incentive in supporting
> a broken server with a slower client?
There is none.
I think the original logic, being written in shell, run grep in the
output, and the C code we are seeing is a literal translation of that.
In other words, I think it is simply a historical accident.
^ permalink raw reply
* Git Hooks
From: daicoden @ 2009-09-16 23:24 UTC (permalink / raw)
To: git
Hi,
I have a git repo host at /home/git/blog.git. I have a copy checked out at
/var/www/blog. I have a script as follows:
cd /var/www/blog
thin -s 2 -C config.yml -R config.ru stop
git pull origin master
thin -s 2 -C config.yml -R config.ru start
>From a local machine I can commit to the repo, push, and then run this
script and the server will update just fine. I wanted to make this
automatic so I wrote the following post-receive hook.
if git log -n1 | grep -q "#publish" || git log -n1 | grep -q "#Publish"
then
~/bin/update-blog
fi
If #publish is in the commit message then it runs the first script. I found
through trial and error that when you use the command git from within a git
hook it needs to be executed in a .git directory, so I changed the first
script to.
cd /var/www/blog
thin -s 2 -C config.yml -R config.ru stop
cd .git
git pull origin master
cd ..
thin -s 2 -C config.yml -R config.ru start
Everything executes, I see the messages of the server stopping, the new info
being pulled, then the server starts again, but the server does not reflect
any changes. If I then manually stop the server, use git reset --hard, and
then start the server again it works fine.
My only thought is that the cause of this has something to do with git
operating differently when you call it from within a hook. Unfortunately, I
don't have any thoughts on how to fix it.
--
View this message in context: http://www.nabble.com/Git-Hooks-tp25482688p25482688.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.4.4
From: Junio C Hamano @ 2009-09-16 23:26 UTC (permalink / raw)
To: git
The latest maintenance release GIT 1.6.4.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.4.4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.4.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.4.4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.4.4-1.fc9.$arch.rpm (RPM)
This is primarily to fix a http regression introduced by 1.6.4.3
GIT v1.6.4.4 Release Notes
==========================
Fixes since v1.6.4.4
--------------------
* The workaround for Github server that sometimes gave 500 (Internal server
error) response to HEAD requests in 1.6.4.3 introduced a regression that
caused re-fetching projects over http to segfault in certain cases due
to uninitialized pointer being freed.
* "git pull" on an unborn branch used to consider anything in the work
tree and the index discardable.
* "git diff -b/w" did not work well on the incomplete line at the end of
the file, due to an incorrect hashing of lines in the low-level xdiff
routines.
* "git checkout-index --prefix=$somewhere" used to work when $somewhere is
a symbolic link to a directory elsewhere, but v1.6.4.2 broke it.
* "git unpack-objects --strict", invoked when receive.fsckobjects
configuration is set in the receiving repository of "git push", did not
properly check the objects, especially the submodule links, it received.
Other minor documentation updates are included.
^ permalink raw reply
* Re: Git Hooks
From: Junio C Hamano @ 2009-09-16 23:31 UTC (permalink / raw)
To: daicoden; +Cc: git
In-Reply-To: <25482688.post@talk.nabble.com>
daicoden <daicoden@copypastel.com> writes:
> cd /var/www/blog
> thin -s 2 -C config.yml -R config.ru stop
> cd .git
> git pull origin master
> cd ..
> thin -s 2 -C config.yml -R config.ru start
Unless you have a strange configuration in which you have work tree files
inside a .git directory of another repository, running "git pull" after
going into .git directory does not make any sense.
Perhaps add this
unset GIT_DIR
at the very beginning of your original script would make it work better?
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Julian Phillips @ 2009-09-16 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiq6wkfu.fsf@alter.siamese.dyndns.org>
On Wed, 16 Sep 2009, Junio C Hamano wrote:
> Julian Phillips <julian@quantumfyre.co.uk> writes:
>
>> When trying to get a list of remote tags to see if we need to fetch
>> any we were doing a linear search for the matching tag ref for the
>> tag^{} commit entries. This proves to be incredibly slow for large
>> numbers of tags. Rewrite the function so that we can do lookup in
>> string_lists instead.
>>
>> For a repository with 50000 tags (and just a single commit on a single
>> branch), a fetch that does nothing goes from ~ 1m50s to ~4.2s.
>>
>> Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
>> ---
>>
>> Not only does this not require a custom hash table, it is also slightly
>> faster than the last version (~4.2s vs ~4.5s).
>
> I am just curious. How would a "just one item lookbehind" code perform
> compared to this one?
The code you wrote ealier is almost the same as the string_list version,
~4.3s, so very marginally slower but a lot less code change. Personally
I'd be happy with any of the three, so long as I don't have to wait 30s to
find out that nothing's happened at $dayjob anymore ;)
--
Julian
---
QOTD:
If it's too loud, you're too old.
^ permalink raw reply
* [PATCH] Remove unused sha1 parameter from pprint_tag function.
From: Thiago Farina @ 2009-09-17 0:12 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-cat-file.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 5906842..626c6a7 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -13,7 +13,7 @@
#define BATCH 1
#define BATCH_CHECK 2
-static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long size)
+static void pprint_tag(const char *buf, unsigned long size)
{
/* the parser in tag.c is useless here. */
const char *endp = buf + size;
@@ -126,7 +126,7 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
if (!buf)
die("Cannot read object %s", obj_name);
if (type == OBJ_TAG) {
- pprint_tag(sha1, buf, size);
+ pprint_tag(buf, size);
return 0;
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: obnoxious CLI complaints
From: Brendan Miller @ 2009-09-17 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Dmitry Potapov, Jakub Narebski, git
In-Reply-To: <7v3a6r5znq.fsf@alter.siamese.dyndns.org>
On Sun, Sep 13, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> John Tapsell <johnflux@gmail.com> writes:
>
>> Ah, the manpage examples specifically give the --format=tar though.
>
> So what?
That looks like a manpage bug. In the version I have 1.6.4 the format
for archive is given like this:
git archive --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-i
sh>
[path...]
So --format isn't marked as optional. Later in the manpage it mentions
tar as the default, but that contradicts this, and the examples use
--format=tar, so it's easy to miss.
>
>> Why not have --format=tgz then or something? Or better yet, give
>> the filename on the command line and detect the format from the file
>> extension.
>
> That is an interesting enhancement and sounds like a useful feature.
>
I do like that idea.
git archive --output=myarchive.tar.gz HEAD is a bit more
straightforward, and still lets people pipe in the old way if they
want to.
I think someone mentioned we're already linking the requisite library?
Otherwise, you can always open up a pipe programmatically within git.
Don't you guys do something like that for ssh? I seem to recall it
complaining that ssh couldn't be found on windows, but maybe it was
just the library.
Prefix could be myarchive. I guess some people have more specific
requirements, but I usually just want it to be *sometime* so it
doesn't spew out tons of files into the directory I decompress it
into.
Brendan
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Junio C Hamano @ 2009-09-17 1:27 UTC (permalink / raw)
To: Brendan Miller; +Cc: John Tapsell, Dmitry Potapov, Jakub Narebski, git
In-Reply-To: <ef38762f0909161748u32ad56bcya3314fe28fd06ffe@mail.gmail.com>
Brendan Miller <catphive@catphive.net> writes:
> On Sun, Sep 13, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Tapsell <johnflux@gmail.com> writes:
>>
>>> Ah, the manpage examples specifically give the --format=tar though.
>>
>> So what?
>
> That looks like a manpage bug. In the version I have 1.6.4 the format
> for archive is given like this:
>
> git archive --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
> [--output=<file>] [--worktree-attributes]
> [--remote=<repo> [--exec=<git-upload-archive>]] <tree-i
> sh>
> [path...]
>
> So --format isn't marked as optional.
Ahh, that would indeed be a documentation bug.
82d97da (Documentation: git-archive: mark --format as optional in summary,
2009-08-27) fixed it already, so upcoming 1.6.5 should have that fix.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH v2] fetch: Speed up fetch by rewriting find_non_local_tags
From: Julian Phillips @ 2009-09-17 1:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0909170039410.14993@reaper.quantumfyre.co.uk>
On Thu, 17 Sep 2009, Julian Phillips wrote:
> On Wed, 16 Sep 2009, Junio C Hamano wrote:
>
>> I am just curious. How would a "just one item lookbehind" code perform
>> compared to this one?
>
> The code you wrote ealier is almost the same as the string_list version,
> ~ 4.3s, so very marginally slower but a lot less code change. Personally
> I'd be happy with any of the three, so long as I don't have to wait 30s to
> find out that nothing's happened at $dayjob anymore ;)
FWIW: I've Just modified my v2 patch to make use of the requirement that
the peeled ref immediately follow the base ref, and it's now ~4.1s and
should use less memory than the original too. I won't bother posting it
unless someone thinks it worth it though.
--
Julian
---
Taxes, n.:
Of life's two certainties, the only one for which you can get
an extension.
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Josh Triplett @ 2009-09-17 1:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster
In-Reply-To: <4AB0C7DE.7030109@viscovery.net>
On Wed, Sep 16, 2009 at 01:11:26PM +0200, Johannes Sixt wrote:
> Josh Triplett schrieb:
> > I considered adding a -f/--force option, like gzip has, but writing an
> > archive to a tty seems like a sufficiently insane use case that I'll let
> > whoever actually needs that write the patch for it. ;)
>
> How about '--output -' instead?
Yeah, that seems significantly better than --force. Though I don't
particularly care for the '-' convention to mean 'stdout'; in principle
that ought to create a file named '-' in the current directory.
/dev/stdout makes more sense, and doesn't require any work on git's
part beyond this patch.
- Josh Triplett
^ permalink raw reply
* [PATCH v2] Update the usage bundle string.
From: Thiago Farina @ 2009-09-17 2:13 UTC (permalink / raw)
To: git; +Cc: Thiago Farina
Currently the usage bundle string is not well formatted.
Now it is formatted and the user can read the string much more easily.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin-bundle.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin-bundle.c b/builtin-bundle.c
index 9b58152..bade253 100644
--- a/builtin-bundle.c
+++ b/builtin-bundle.c
@@ -9,7 +9,11 @@
* bundle supporting "fetch", "pull", and "ls-remote".
*/
-static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
+static const char builtin_bundle_usage[] = "\
+ git bundle create <file> <git-rev-list args>\n\
+ git bundle verify <file>\n\
+ git bundle list-heads <file> [refname...]\n\
+ git bundle unbundle <file> [refname...]";
int cmd_bundle(int argc, const char **argv, const char *prefix)
{
@@ -19,8 +23,8 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
int bundle_fd = -1;
char buffer[PATH_MAX];
- if (argc < 3)
- usage(bundle_usage);
+ if (argc < 3)
+ usage(builtin_bundle_usage);
cmd = argv[1];
bundle_file = argv[2];
@@ -59,5 +63,5 @@ int cmd_bundle(int argc, const char **argv, const char *prefix)
return !!unbundle(&header, bundle_fd) ||
list_bundle_refs(&header, argc, argv);
} else
- usage(bundle_usage);
+ usage(builtin_bundle_usage);
}
--
1.6.5.rc0.dirty
^ permalink raw reply related
* Re: [PATCH v2 3/4] reset: add option "--merge-safe" to "git reset"
From: Christian Couder @ 2009-09-17 3:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds, Paolo Bonzini
In-Reply-To: <7vfxamzqga.fsf@alter.siamese.dyndns.org>
On Wednesday 16 September 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > From: Stephan Beyer <s-beyer@gmx.net>
> >
> > This option is nearly like "--merge" except that it is
> > safer. The table below show the differences between these
> > options.
> >
> > working index HEAD target working index HEAD
> > B B A A --m-s B A A
> > --merge A A A
> > B B A C --m-s (disallowed)
> > --merge C C C
> >
> > In this table, A, B and C are some different states of
> > a file. For example the first 2 lines of the table mean
> > 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 --merge-safe target" will
> > put the file in state B in the working tree and in
> > state A in the index and HEAD.
>
> At first, I had to spend a few minutes guessing what you meant by
> "target" in the table. All the other words are well known and do not
> need to be explained, but you can make it even easier to understand by
> updating the sentence before the table, perhaps like:
>
> When running "git reset --option target" to reset the HEAD to another
> commit (as a special case "target" could be the same as HEAD), here
> is what happens to paths in various state.
Ok, I will update the sentence like this.
> As you mentioned in the proposed commit log message of the other entry,
> you have a different behaviour for unmerged case. Can you add that case
> to the table as well?
The behavior is not different between --merge and --merge-safe, the behavior
is different between --merge before patch 2/4 and --merge after patch 2/4.
I will add a test case to show this.
> The original use case of Linus's "reset --merge" was:
>
> $ edit ... ;# you may have some local changes to the work tree
> $ git merge/pull ...
> ... (1) it merges cleanly;
> ... (2) you see conflicts and do not commit, or
> ... (3) you resolve conflicts and commit, while leaving the earlier
> ... modified paths alone.
> ... In any of the three cases, you inspect the result, and say
> ... "ah, crap!"
> ... You want to go back to the state before the merge, i.e.
> ... target = HEAD^ in (1) or (3) above and target = HEAD in (2).
> $ git reset --merge $target
I think that Daniel found out that the above "reset --merge" command did not
worked well in case (2) before patch 2/4.
> Recall that "git merge/pull ..." step does not even touch anything if you
> have a dirty index (i.e. "diff --cached" is non-empty), so any difference
> between the index and HEAD to reset the failed merge away must come from
> the merge itself
>
> Immediately before you run "reset --merge" in the above sequence, you can
> categorize the paths in various states this way:
>
> work index HEAD how that path got into this state...
> A A A not involved in this merge.
> B A A not involved in this merge, originally modified.
> B B A cleanly merged.
> B B B cleanly merged (and committed if (1) or (3)).
> C U A merge left conflicts
>
> where U denotes unmerged path in the index, and C is a file in the work
> tree with conflict markers. The path had content A in HEAD before the
> start of the merge that you are resetting away.
>
> Note that the target is A in all cases in the above table.
>
> We would want to go back to HEAD == index == target for all of these
> cases, and discarding B in "cleanly merged" entries is absolutely the
> right thing to do. Clearly, --merge-safe is _not_ designed to work in
> this scenario.
Yes.
> Don't get me wrong. I am not saying --merge-safe is unsafe nor useless.
>
> I am trying to show a way with an intended use-case (and the mechanical
> notation you and Daniel wrote up, which is very nice to illustrate what
> exactly happens) to explain how --merge works, and more importantly why
> it works that way.
>
> That is because I would like to see an intended use case of this new
> feature in a bigger picture. With the table, I can see what it does (or
> at least what you wanted it to do), but it does not clearly explain what
> this new mode of operation is good for, in what context it is designed
> to be used, and what problem it intends to solve. I think you find it
> very clear, by reading my explanation above, what Linus's --merge is
> intended to solve:
>
> After a (possibly conflicted) merge modified my index and my work
> tree, "reset --hard" to the commit before I started the merge
> will discard the local modifications I had in the work tree before the
> merge. "reset --merge" was invented to let me go back to the state
> before the merge, without discarding such local changes I had before the
> merge.
>
> I want to be able to explain to others what --merge-safe is for in a
> similar way myself before I have it in my tree, and I can't (yet).
I understand, and I think that Stephan designed the "allow_dirty" feature
(that became --merge-safe in this patch series) because he wanted to let
the user do a cherry-pick or an improved cherry-pick (or even run the
sequencer) with a dirty working tree or index without the risk of losing
some work.
But I think that it can be usefull in case like:
$ "hack something"
$ git commit ...
$ "hack something else"
$ git add "some of the files"
$ "find out previous commit was crap"
$ git reset --merge-safe HEAD^
Here using "--merge-safe" can be usefull because you don't want to lose
stuff in your current index and work tree.
Best regards,
Christian.
^ permalink raw reply
* [PATCH v3 0/4] "git reset --merge" related improvements
From: Christian Couder @ 2009-09-17 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In this new version, some test cases have been added to show that the
behavior of "git reset --merge" when there is a pending merge is changed
by patch 2/4.
And some commit messages have been improved, thanks to Junio.
There is no documentation yet but I am working on it.
Christian Couder (2):
reset: add a few tests for "git reset --merge"
reset: add test cases for "--merge-safe" option
Stephan Beyer (2):
reset: use "unpack_trees()" directly instead of "git read-tree"
reset: add option "--merge-safe" to "git reset"
builtin-reset.c | 81 ++++++++++++++++++++++------
t/t7110-reset-merge.sh | 142 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 207 insertions(+), 16 deletions(-)
create mode 100755 t/t7110-reset-merge.sh
^ permalink raw reply
* [PATCH v3 2/4] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Christian Couder @ 2009-09-17 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090917040835.4048.51057.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.
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 | 7 ++++-
2 files changed, 45 insertions(+), 13 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 8a28553..6211096 100755
--- a/t/t7110-reset-merge.sh
+++ b/t/t7110-reset-merge.sh
@@ -79,9 +79,12 @@ test_expect_success 'setup 2 different branches' '
git commit -a -m "change in branch2"
'
-test_expect_success 'reset --merge fails with pending merge' '
+test_expect_success 'reset --merge is ok with pending merge' '
test_must_fail git merge branch1 &&
- test_must_fail git reset --merge HEAD^
+ git reset --merge HEAD^ &&
+ test -z "$(git diff --cached)" &&
+ test -n "$(git diff)" &&
+ git reset --hard HEAD@{1}
'
test_done
--
1.6.5.rc0.150.g38fe6
^ permalink raw reply related
* [PATCH v3 4/4] reset: add test cases for "--merge-safe" option
From: Christian Couder @ 2009-09-17 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090917040835.4048.51057.chriscool@tuxfamily.org>
This shows that with the "--merge-safe" 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.
And this shows that otherwise "--merge" and "--merge-safe" have the
same behavior.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t7110-reset-merge.sh | 54 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
index 6211096..794a506 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 --merge-safe'
. ./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 --merge-safe 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 --merge-safe HEAD^ &&
+ ! grep 4 file1 &&
+ grep 4 file2 &&
+ git reset --merge-safe 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 --merge-safe 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 --merge-safe HEAD^ &&
+ git reset --hard HEAD
+'
+
+test_expect_success 'reset --merge-safe keeps changes it does not touch' '
+ echo "line 4" >> file2 &&
+ git add file2 &&
+ git reset --merge-safe HEAD^ &&
+ grep 4 file2 &&
+ git reset --merge-safe 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 --merge-safe 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-safe 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,4 +131,12 @@ test_expect_success 'reset --merge is ok with pending merge' '
git reset --hard HEAD@{1}
'
+test_expect_success 'reset --merge-safe is ok with pending merge' '
+ test_must_fail git merge branch1 &&
+ git reset --merge-safe HEAD^ &&
+ test -z "$(git diff --cached)" &&
+ test -n "$(git diff)" &&
+ git reset --hard HEAD@{1}
+'
+
test_done
--
1.6.5.rc0.150.g38fe6
^ permalink raw reply related
* [PATCH v3 1/4] reset: add a few tests for "git reset --merge"
From: Christian Couder @ 2009-09-17 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090917040835.4048.51057.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 | 87 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 87 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..8a28553
--- /dev/null
+++ b/t/t7110-reset-merge.sh
@@ -0,0 +1,87 @@
+#!/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 fails with pending merge' '
+ test_must_fail git merge branch1 &&
+ test_must_fail git reset --merge HEAD^
+'
+
+test_done
--
1.6.5.rc0.150.g38fe6
^ permalink raw reply related
* [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Christian Couder @ 2009-09-17 4:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <20090917040835.4048.51057.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This option is nearly like "--merge" except that it is
safer.
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 "--merge-safe"
(abreviated --m-s) behave differently.
working index HEAD target working index HEAD
B B A A --m-s B A A
--merge A A A
B B A C --m-s (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 --merge-safe 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 "--merge-safe" does not.
A following patch will add some test cases for
"--merge-safe", where the differences between "--merge"
and "--merge-safe" can also be seen.
The "--merge-safe" 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:
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..78d42e6 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 | --merge-safe] [-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, MERGE_SAFE, NONE };
+static const char *reset_type_names[] = {
+ "mixed", "soft", "hard", "merge", "merge_safe", 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 MERGE_SAFE:
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 == MERGE_SAFE) {
+ unsigned char *head_sha1;
+ 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, "merge-safe", &reset_type,
+ "reset HEAD, index and working tree",
+ MERGE_SAFE),
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 == MERGE_SAFE)
+ 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.rc0.150.g38fe6
^ permalink raw reply related
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Junio C Hamano @ 2009-09-17 5:15 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Linus Torvalds
In-Reply-To: <20090917041440.4048.16353.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> From: Stephan Beyer <s-beyer@gmx.net>
>
> This option is nearly like "--merge" except that it is
> safer.
Do you still want to have this description after the last round?
> 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 "--merge-safe"
> (abreviated --m-s) behave differently.
>
> working index HEAD target working index HEAD
> B B A A --m-s B A A
> --merge A A A
> B B A C --m-s (disallowed)
> --merge C C C
I'd like to see at least the following rows filled as well.
X U A A --m-s ??? ??? ???
--merge ??? ??? ???
X U B A --m-s ??? ??? ???
--merge ??? ??? ???
> In this table, A, B and C are some different states of a file.
... and X is "don't care", and U is "unmerged index".
> The code comes from the sequencer GSoC project:
>
> 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.
If you need to have four lines worth of description here, is this still
Stephan's patch, or would it be more appropriate to say "This is based on
an earlier GSoC work by Stephan in git://repo.or.cz/git/sbeyer.git
repository." and you take all the credit and blame?
> static const char * const git_reset_usage[] = {
> - "git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
> + "git reset [--mixed | --soft | --hard | --merge | --merge-safe] [-q] [<commit>]",
> "git reset [--mixed] <commit> [--] <paths>...",
> NULL
> };
As we established in the previous round, this is _different_ from --merge,
but *not* in the sense that --merge is more dangerous and users should be
using this new option instead, but in the sense that --merge perfectly
works well for its intended use case, and this new option triggers a mode
of operation that is meant to be used in a completely different use case,
which is unspecified in this series without documentation.
In that light, is --merge-safe still a good name for the option, or merely
a misleading one?
As I said in the previous round, --merge discards the modified index state
when switching, and it is absolutely _the right thing to do_ in the use
case it was intended for. It is _not_ dangerous, and using --merge-safe
in that scenario is not being _safe_ but is actively a _wrong_ thing to do.
> @@ -95,6 +98,16 @@ static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet
>
> read_cache_unmerged();
>
> + if (reset_type == MERGE_SAFE) {
> + unsigned char *head_sha1;
> + 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;
> + }
get_sha1() takes an allocated buffer, does not allocate space on its own.
I think you meant "unsigned char head_sha1[20];" here.
^ permalink raw reply
* Re: [PATCH v2 3/4] reset: add option "--merge-safe" to "git reset"
From: Junio C Hamano @ 2009-09-17 5:23 UTC (permalink / raw)
To: Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds, Paolo Bonzini
In-Reply-To: <200909170554.49416.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> But I think that it can be usefull in case like:
>
> $ "hack something"
> $ git commit ...
> $ "hack something else"
> $ git add "some of the files"
> $ "find out previous commit was crap"
> $ git reset --merge-safe HEAD^
>
> Here using "--merge-safe" can be usefull because you don't want to lose
> stuff in your current index and work tree.
That depends on the reason why you are resetting away the "crap commit"
and what your next move is.
If you are going to run "git commit", perhaps after some further edit, in
order to fix what the "crap commit" did not quite do right, what your new
option does is actively a wrong thing to do. "Some of the files" you
added after that "crap commit" are about "hack something else", i.e. not
part of the work to fix the "crap commit", and their changes should not be
included in the amended commit, no?
In general, "reset" should be about matching the index entries to the
named commit, so that you can start from the clean, known slate to redo
the commit you wanted to make on top of it. You would need a very good
use case to deviate from it and leave the index entry different from that
of the commit you are switching to; otherwise you would greatly confuse
the end users.
^ permalink raw reply
* Re: [PATCH] archive: Refuse to write the archive to a terminal.
From: Johannes Sixt @ 2009-09-17 5:53 UTC (permalink / raw)
To: Josh Triplett; +Cc: git, gitster
In-Reply-To: <20090917014854.GD3274@feather>
Josh Triplett schrieb:
> On Wed, Sep 16, 2009 at 01:11:26PM +0200, Johannes Sixt wrote:
>> How about '--output -' instead?
>
> Yeah, that seems significantly better than --force. Though I don't
> particularly care for the '-' convention to mean 'stdout'; in principle
> that ought to create a file named '-' in the current directory.
> /dev/stdout makes more sense, and doesn't require any work on git's
> part beyond this patch.
Except that /dev/stdout is not portable. You can always say --output ./-
if you want an oddly named file in the current directory.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Update the usage bundle string.
From: Johannes Sixt @ 2009-09-17 6:12 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1253136011-12011-1-git-send-email-tfransosi@gmail.com>
Thiago Farina schrieb:
> @@ -11,6 +11,12 @@
>
> static const char *bundle_usage="git bundle (create <bundle> <git rev-list args> | verify <bundle> | list-heads <bundle> [refname]... | unbundle <bundle> [refname]... )";
Is this variable still used? Shouldn't it be removed?
> +static const char builtin_bundle_usage[] = "\
> + git bundle create <file> <git-rev-list args>\n\
> + git bundle verify <file>\n\
> + git bundle list-heads <file> [refname...]\n\
> + git bundle unbundle <file> [refname...]";
You indent the usage text. Do other commands do that, too? If you resend,
it may be worth using this style:
static const char builtin_bundle_usage[] =
"git bundle create <file> <git-rev-list args>\n"
"git bundle verify <file>\n"
...
i.e. not to use backslash-at-eol.
> - if (argc < 3)
> - usage(bundle_usage);
> + if (argc < 3)
> + usage(builtin_bundle_usage);
This re-indentation is an accident, isn't it?
-- Hannes
^ permalink raw reply
* What's cooking in git.git (Sep 2009, #04; Wed, 16)
From: Junio C Hamano @ 2009-09-17 6:12 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.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
We are in pre-release feature freeze. 'next' will hold topics meant for
1.6.6 and 1.7.0.
Except for possibly gfi-options series from Sverre, and updates to
subsystems (svn, gitk, gui, and gitweb) may still need to be merged in,
but otherwise 'master' is ready for -rc2. I am still hoping that I can
tag the final before I take a vacation starting on 24th for a week, but we
may have to give the final -rc a week to shake out any possible last
minute regressions and release 1.6.5 at the beginning of next month.
--------------------------------------------------
[Graduated to "master"]
* rc/maint-http-no-head-pack-check (2009-09-14) 2 commits.
+ http.c: avoid freeing an uninitialized pointer
+ http.c: remove verification of remote packs
Graduated to master and maint but then needed a small fixup.
--------------------------------------------------
[New Topics]
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'. It is a fix for longstanding bug and 1.6.5 will likely to ship
without this topic.
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests to covers 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"?)
* jh/cvs-helper (2009-08-18) 8 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
Replaced but I do not think this is ready for 'pu' yet.
--------------------------------------------------
[Cooking]
* db/vcs-helper-rest (2009-09-03) 6 commits
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged for 1.6.5.
* jh/notes (2009-09-12) 13 commits
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- notes.[ch] fixup: avoid old-style declaration
- Teach notes code to free its internal data structures on request.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
- Prepare 'traverse_trees()' for D/F conflict lookahead
Beginning of the fix to a rather nasty longstanding issue of merging trees
with ("a" "a-b"), ("a/b" "a-b") and just ("a-b"), but my reading of it is
that it is just the first step to demonstrate one-entry lookahead and not
a full solution yet.
I started writing a replacement series but the progress is a bit slower
than I would have liked.
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-09-15 at 9cbfa00)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
(merged to 'next' on 2009-09-07 at 165dc3c)
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
Will not be in 1.6.5.
* jn/gitweb-blame (2009-09-01) 5 commits
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-09-07 at 3622199)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* sr/gfi-options (2009-09-06) 6 commits
(merged to 'next' on 2009-09-07 at 5f6b0ff)
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: test the new feature command
+ fast-import: add feature command
+ fast-import: put marks reading in it's own function
+ fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ping?
* nd/sparse (2009-08-20) 19 commits
- 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
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-09-07 at 8a7c563)
+ 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".
* jc/1.7.0-status (2009-09-05) 4 commits
(merged to 'next' on 2009-09-06 at 19d4beb)
+ status: typo fix in usage
(merged to 'next' on 2009-08-22 at b3507bb)
+ 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-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
^ permalink raw reply
* Re: [PATCH v3 3/4] reset: add option "--merge-safe" to "git reset"
From: Johannes Sixt @ 2009-09-17 6:38 UTC (permalink / raw)
To: Junio C Hamano, Christian Couder
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski, Linus Torvalds
In-Reply-To: <7vk4zykv7o.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> As we established in the previous round, this is _different_ from --merge,
> but *not* in the sense that --merge is more dangerous and users should be
> using this new option instead, but in the sense that --merge perfectly
> works well for its intended use case, and this new option triggers a mode
> of operation that is meant to be used in a completely different use case,
> which is unspecified in this series without documentation.
>
> In that light, is --merge-safe still a good name for the option, or merely
> a misleading one?
Do I understand this correctly?
(1) The intended use-case of --merge is to "reset _a_ merge".
(2) The intended use-case of --merge-safe is to point the branch head to a
different commit, but to carry the changes that currently are in the index
and wd over to the new commit, similar to checkout --merge.
I had mistaken that --merge actually performs (2) because of the striking
similarity of the option's name to checkout's --merge. So, IMHO, whatever
the new option is named that performs (2) - it introduces an
inconsistency, because --merge is already taken.
-- Hannes
^ 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;
as well as URLs for NNTP newsgroup(s).