* Re: [ANNOUNCE] GIT 1.5.6.2
From: Mikael Magnusson @ 2008-07-06 14:54 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <alpine.LNX.1.10.0807061444250.28765@fbirervta.pbzchgretzou.qr>
2008/7/6 Jan Engelhardt <jengelh@medozas.de>:
>
> On Sunday 2008-07-06 07:34, Junio C Hamano wrote:
>>Junio C Hamano (9):
>> Allow "git-reset path" when unambiguous
>> diff --check: do not discard error status upon seeing a good line
>> git-shell: accept "git foo" form
>> GIT 1.5.4.6
>> GIT 1.5.5.5
>> Start draft release notes for 1.5.6.2
>> Work around gcc warnings from curl headers
>> Fix executable bits in t/ scripts
>> GIT 1.5.6.2
>
> Three git versions?
I believe this is related to moving to the dash-less form of receive-pack et al.
--
Mikael Magnusson
^ permalink raw reply
* Re: Git, merging, and News/Relnotes files
From: Dmitry Potapov @ 2008-07-06 14:53 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <g4n7j6$359$1@ger.gmane.org>
On Sat, Jul 5, 2008 at 11:24 AM, Edward Z. Yang
<edwardzyang@thewritingpot.com> wrote:
> As a policy on a project that I manage, almost every commit warrants a
> change to our NEWS (changelog) file, which end-users can browse to get
> an in-depth idea of the changes that have happened from the last
> release. If it's an added feature, the changelog includes a description
> of how to use it; if it's a fixed bug, it briefly describes what
> happened. Internal changes may or may not get added, depending on the
> visibility of the APIs affected.
I believe it is better to put all this information directly to the commit
message using some special tagging, so you can extract it automatically
at the release time and generate the changelog file for users. You may
edit the generated changelog and commit it directly before release.
Having one file changed on almost every commit is not a good idea, and
not only because it will cause unnecessary conflicts but also it may
considerable increase the size of the whole repository. By default, the
delta compression has limit 50, which means that every 50 change of file
will become its full copy. If the changelog file is changed very often
and it is long, it may turn out that changelog alone takes as much space
as the rest of the source tree.
Dmitry
^ permalink raw reply
* [PATCH] Add a test for "git stash branch"
From: Abhijit Menon-Sen @ 2008-07-06 14:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.LSU.1.00.0807061453540.3486@wbgn129.biozentrum.uni-wuerzburg.de>
Make sure that applying the stash to a new branch after a conflicting
change doesn't result in an error when you try to commit.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
At 2008-07-06 14:54:44 +0200, Johannes.Schindelin@gmx.de wrote:
>
> AFAICS the previous version is in 'next' already:
> 656b50345239293929ad8c639c5f1941c6b867ad
Oh, I see, thanks. I misunderstood the request. Here's a separate patch
to just add the test.
Sorry for the noise.
-- ams
t/t3903-stash.sh | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
test 0 = $(git stash list | wc -l)
'
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+ echo foo > file &&
+ git commit file -m first
+ echo bar > file &&
+ git stash &&
+ echo baz > file &&
+ git commit file -m second &&
+ git stash branch stashbranch &&
+ git commit file -m alternate\ second &&
+ git diff master..stashbranch > output &&
+ test_cmp output expect &&
+ test 0 = $(git stash list | wc -l)
+'
+
test_done
--
1.5.6
^ permalink raw reply related
* [PATCH] Teach git-bundle to read revision arguments from stdin like
From: Adam Brewster @ 2008-07-06 14:28 UTC (permalink / raw)
To: git
Cc: gitster, mdl123, Johannes.Schindelin, jnareb, vmiklos,
Adam Brewster, Adam Brewster
In-Reply-To: <1215354538-1469-2-git-send-email-adambrewster@gmail.com>
This patch allows the caller to feed the revision parameters to
git-bundle from its standard input. This way, a script do not have to
worry about limitation of the length of command line.
Documentation/git-bundle.txt says that git-bundle takes arguments
acceptable to git-rev-list. Obviously some arguments that git-rev-list
handles don't make sense for git-bundle (e.g. --bisect) but --stdin is
pretty reasonable.
Signed-off-by: Adam Brewster <asb@bu.edu>
---
bundle.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/bundle.c b/bundle.c
index 0ba5df1..8d486f3 100644
--- a/bundle.c
+++ b/bundle.c
@@ -227,8 +227,14 @@ int create_bundle(struct bundle_header *header, const char *path,
/* write references */
argc = setup_revisions(argc, argv, &revs, NULL);
- if (argc > 1)
- return error("unrecognized argument: %s'", argv[1]);
+
+ for (i = 1; i < argc; i++) {
+ if (!strcmp(argv[i], "--stdin")) {
+ read_revisions_from_stdin(&revs);
+ continue;
+ }
+ return error("unrecognized argument: %s'", argv[i]);
+ }
for (i = 0; i < revs.pending.nr; i++) {
struct object_array_entry *e = revs.pending.objects + i;
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* [PATCH] git-rev-list: tolerate multiple --stdin options
From: Adam Brewster @ 2008-07-06 14:28 UTC (permalink / raw)
To: git
Cc: gitster, mdl123, Johannes.Schindelin, jnareb, vmiklos,
Adam Brewster, Adam Brewster
In-Reply-To: <1215354538-1469-1-git-send-email-adambrewster@gmail.com>
There's no reason to fail if the user asks for --stdin twice. Of course
there's only one stdin, and it can only be read once, and there's no
reason to ask for it twice, but --all --all doesn't make sense, and
that's accepted, so accept this too.
Also, with read_revisions_from_stdin in revision.c where it might be
called by other programs, it's better to check that stdin isn't at eof
before trying to read it.
Signed-off-by: Adam Brewster <asb@bu.edu>
---
builtin-rev-list.c | 3 ---
revision.c | 2 +-
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index b4a2c44..7f7c1a7 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -579,7 +579,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
int i;
- int read_from_stdin = 0;
int bisect_show_vars = 0;
int bisect_find_all = 0;
int quiet = 0;
@@ -616,8 +615,6 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--stdin")) {
- if (read_from_stdin++)
- die("--stdin given twice?");
read_revisions_from_stdin(&revs);
continue;
}
diff --git a/revision.c b/revision.c
index 0191160..c1550c4 100644
--- a/revision.c
+++ b/revision.c
@@ -914,7 +914,7 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
void read_revisions_from_stdin(struct rev_info *revs)
{
char line[1000];
-
+ if (feof(stdin)) return;
while (fgets(line, sizeof(line), stdin) != NULL) {
int len = strlen(line);
if (len && line[len - 1] == '\n')
--
1.5.5.1.211.g65ea3.dirty
^ permalink raw reply related
* Re: Teach git-bundle to read revision arguments from stdin like git-rev-list
From: Adam Brewster @ 2008-07-06 14:28 UTC (permalink / raw)
To: git; +Cc: gitster, mdl123, Johannes.Schindelin, jnareb, vmiklos
In-Reply-To: <7v63rjrfqz.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 5, 2008 at 8:57 PM, Junio C Hamano <gitster@pobox.com>
>> + if (read_from_stdin++)
>> + die("--stdin given twice?");
>
> Hmm, do we deeply care about this case? What bad things coulc happen
if
> you call read_revisions_from_stdin() twice?
>
Presently, it'll actually try to read stdin twice and that won't work.
Also, if you want git-bundle to deal with --stdin --stdin, I'd say that
git-rev-list should do the same. I don't really care how this
particular error case is handled, but I think git-rev-list and
git-bundle should do the same thing for any given input.
If you prefer to be liberal in what you accept, then you might like
these two patches that allow git-rev-list and git-bundle to deal with
--stdin --stdin.
By the way, I'm not exactly sure on the format of these guys. You said
you queued some changes yesterday, so these go on top of those. If
you want me to start from scratch and give you the whole chain again, I
can do that too.
^ permalink raw reply
* Re: remote does not support deleting refs
From: Dmitry Potapov @ 2008-07-06 13:29 UTC (permalink / raw)
To: Martin; +Cc: git
In-Reply-To: <486FE602.3060301@gmx.de>
On Sun, Jul 6, 2008 at 1:22 AM, Martin <html-kurs@gmx.de> wrote:
>
> To ssh://myserver.com/my/path/to/repository
> ! [rejected] testbranch (remote does not support deleting refs)
What version of Git do you use on the server? I think Git before v1.5 does
not support deleting remote refs. You have to upgrade Git on your server.
Dmitry
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Mark Levedahl @ 2008-07-06 13:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Ping Yin, git, Sylvain Joyeux
In-Reply-To: <7vhcb3o7q3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sylvain Joyeux <sylvain.joyeux@dfki.de> writes:
>
> People who rely on working submodule support, do you have any feedback on
> this patch? I do not use submodule myself, so it is hard for me to judge
> how much value (if any) this patch is adding to the real world use of the
> status subcommand.
>
The new format is changed from the old in an incompatible way (anything that
parses the old output will break), and the new output is very cryptic. I do not
think that I would remember the various symbols in use here (+-<>!M). While the
information may be useful, I would think a better way would be to append a more
descriptive annotation (similar to that provided after a checkout), probably on
a separate status line, definitely controlled by a "-v" option.
>
> This "fetch" feels very wrong. The user did not ask you to change the
> state of the repository, but this will silently change the remote tracking
> branches. The repository after all might be unreachable.
Status is a local operation, it must not try to access the net (which for me
will frequently fail). Status changing the remote branches is a definite no-no.
Mark
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-06 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Ping Yin, Mark Levedahl, git, Sylvain Joyeux
In-Reply-To: <7vhcb3o7q3.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Sylvain Joyeux <sylvain.joyeux@dfki.de> writes:
>
> > This patch makes the output of git-submodule more useful to handle the
> > management of a repository using multiple submodules. Namely, it
> > displays informations about how the current checked out version relates
> > to the registered one (i.e. direct parent, direct child, "just
> > different", registered revision does not exist), and displays if the
> > submodules contain uncommitted changes.
> >
> > This (among other things) allows to do git-submodule update while
> > knowing exactly what will happen.
> > --
> > Sylvain
> >
> >>>From 16553a9b210a956b0af961d55a9cf06f1b9b8114 Mon Sep 17 00:00:00 2001
> > From: Sylvain Joyeux <sylvain.joyeux@dfki.de>
> > Date: Tue, 1 Jul 2008 16:01:01 +0200
> > Subject: [PATCH] more information in git-submodule status output
> >
> > This commit adds more information in the 'status' output of
> > git-submodule. More specifically, it displays different flags if the
> > submodule and the registered revision are direct parents (> and <,
> > depending on which is the ancestor), if they are not direct parents (+)
> > or if the registered revision cannot be found (i.e. if submodule update
> > would fail, '!')
> >
> > Finally, it shows if the submodule contains uncommitted changes (M flag)
>
> Which one is the commit message ;-)?
I think it is clear that Sylvain has not read
Documentation/SubmittingPatches yet.
> People who rely on working submodule support, do you have any feedback
> on this patch?
Not yet. Will test/comment when the spurious "fetch" is fixed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3] Implement "git stash branch <newbranch> <stash>"
From: Johannes Schindelin @ 2008-07-06 12:54 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20080706112333.GA6477@toroid.org>
Hi,
On Sun, 6 Jul 2008, Abhijit Menon-Sen wrote:
> Restores the stashed state on a new branch rooted at the commit on which
> the stash was originally created, so that conflicts caused by subsequent
> changes on the original branch can be dealt with.
>
> (Thanks to Junio for this nice idea.)
>
> Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
> ---
> Reposting as requested with a new test included.
AFAICS the previous version is in 'next' already:
656b50345239293929ad8c639c5f1941c6b867ad
Hth,
Dscho
^ permalink raw reply
* Re: something like 'find' in revisions
From: Johannes Schindelin @ 2008-07-06 12:53 UTC (permalink / raw)
To: Ittay Dror; +Cc: git
In-Reply-To: <4870A700.8040205@gmail.com>
Hi,
On Sun, 6 Jul 2008, Ittay Dror wrote:
> How can I find files with a given name (or pattern) in my history (where
> I don't know the exact path and some files have been removed)?
I'd grep in the output of "git rev-list --objects". Then I'd have the
full name, and "git log --all -- <fullpath>" is my friend.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow cherry-picking root commits
From: Johannes Schindelin @ 2008-07-06 12:48 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Daniel Barkalow, Christian Couder
In-Reply-To: <20080706113548.GC6731@leksak.fem-net>
Hi,
On Sun, 6 Jul 2008, Stephan Beyer wrote:
> And yes, there may even be no use case for reverting root commits.
That weighs much heavier than that it would be hard to implement.
When writing the patch, I spent 2 minutes thinking about a possible case
where reverting a root commit would make sense. And I came up with none.
It can be sensible to undo _parts_ of it, but then it is no longer about
reverting the root commit, but about applying a partial patch with a new
commit message, and we support that quite nicely already.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.6.2
From: Jan Engelhardt @ 2008-07-06 12:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vy74fo9t4.fsf@gitster.siamese.dyndns.org>
On Sunday 2008-07-06 07:34, Junio C Hamano wrote:
>Junio C Hamano (9):
> Allow "git-reset path" when unambiguous
> diff --check: do not discard error status upon seeing a good line
> git-shell: accept "git foo" form
> GIT 1.5.4.6
> GIT 1.5.5.5
> Start draft release notes for 1.5.6.2
> Work around gcc warnings from curl headers
> Fix executable bits in t/ scripts
> GIT 1.5.6.2
Three git versions?
^ permalink raw reply
* Re: [PATCH 14/14] Build in merge
From: Johannes Schindelin @ 2008-07-06 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git, Olivier Marin
In-Reply-To: <7vej67jt1e.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 6 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > diff --git a/builtin-merge.c b/builtin-merge.c
> > new file mode 100644
> > index 0000000..b261993
> > --- /dev/null
> > +++ b/builtin-merge.c
> > @@ -0,0 +1,1158 @@
> > +/*
> > + * Builtin "git merge"
> > + *
> > + * Copyright (c) 2008 Miklos Vajna <vmiklos@frugalware.org>
> > + *
> > + * Based on git-merge.sh by Junio C Hamano.
> > + */
> > +
> > +#include "cache.h"
> > +#include "parse-options.h"
> > +#include "builtin.h"
> > +#include "run-command.h"
> > +#include "path-list.h"
> > +#include "diff.h"
> > +#include "refs.h"
> > +#include "commit.h"
> > +#include "diffcore.h"
> > +#include "revision.h"
> > +#include "unpack-trees.h"
> > +#include "cache-tree.h"
> > +#include "dir.h"
> > +#include "utf8.h"
> > +#include "log-tree.h"
> > +#include "color.h"
> > +
> > +enum strategy {
> > + DEFAULT_TWOHEAD = 1,
> > + DEFAULT_OCTOPUS = 2,
> > + NO_FAST_FORWARD = 4,
> > + NO_TRIVIAL = 8
> > +};
>
> Usually "enum foo" consists of possible values of "foo". But this is
> not a list of strategies. These are possible attributes to strategies.
My fault. I avoid ugly #defines, so I suggested using an enum.
> > +static const char * const builtin_merge_usage[] = {
> > + "git-merge [options] <remote>...",
> > + "git-merge [options] <msg> HEAD <remote>",
> > + NULL
> > +};
> > +
> > +static int show_diffstat = 1, option_log, squash;
> > +static int option_commit = 1, allow_fast_forward = 1;
> > +static int allow_trivial = 1, have_message;
> > +static struct strbuf merge_msg;
> > +static struct commit_list *remoteheads;
> > +static unsigned char head[20], stash[20];
> > +static struct path_list use_strategies;
> > +static const char *branch;
> > +
> > +static struct path_list_item strategy_items[] = {
> > + { "recur", (void *)NO_TRIVIAL },
> > + { "recursive", (void *)(DEFAULT_TWOHEAD | NO_TRIVIAL) },
> > + { "octopus", (void *)DEFAULT_OCTOPUS },
> > + { "resolve", (void *)0 },
> > + { "stupid", (void *)0 },
> > + { "ours", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
> > + { "subtree", (void *)(NO_FAST_FORWARD | NO_TRIVIAL) },
> > +};
> > +static struct path_list strategies = { strategy_items,
> > + ARRAY_SIZE(strategy_items), 0, 0 };
>
> This declaration is funnily line-wrapped.
>
> static struct path_list strategies = {
> strategy_items, ARRAY_SIZE(strategy_items), 0, 0,
> };
>
> But more problematic is that a path_list is inherently a dynamic data
> structure (you can add and it reallocs), and this use of relying on the
> knowledge that you happen to never add anything (nor subtract anything)
> from the list is a mere hack. If on the other hand you (and more
> importantly other people who touch this implementation later) will never
> add or remove items from this "strategies" array, you should make sure
> at the interface level that nobody can -- one way to do so is not to
> abuse path_list for something like this.
>
> Come to think of it, wasn't the reason why the earlier "Why do you need
> such distracting casts all over the place?" issue came up in another
> patch because of this kind of (ab)use of path_list, which is an
> inappropriate data structure for the job?
Well, it is not really an abuse if you think of path_list as a
string_list, which it really is, and which should have happened a long
time ago, but I gave up.
Anyway, the use of string_list here was originally to make lookup slightly
more convenient, using an API, instead of reinventing the wheel over and
over and over again, as can be seen nicely in some parts of Git's source
code.
Given that we want to be able to add other strategies, I would have rather
suggested fixing string_list to heed "alloc == 0" and _not_ realloc() in
that case.
But given that you seem so sick and tired of string_list, and rather have
a code duplication, I will not argue to that end anymore.
Tired,
Dscho
^ permalink raw reply
* [PATCH v2] git daemon: avoid calling syslog() from a signal handler
From: Johannes Schindelin @ 2008-07-06 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Foster, git
In-Reply-To: <7vmykvo87w.fsf@gitster.siamese.dyndns.org>
Signal handlers should never call syslog(), as that can raise signals
of its own.
Instead, call the syslog() from the master process.
To avoid waking up unnecessarily, a pipe is set up that is only ever
written to by child_handler(), when a child disconnects, as suggested
per Junio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Junio wrote:
> >> Another way would be to set up a pipe to ourself that is
> >> included in the poll() and write a byte to the pipe from the signal
> >> handler.
> >
> > It still would need to break out of the poll(), in which case
> > the effect would be _exactly_ the same,...
>
> I do not think so.
Okay.
Note that we still have to check for dead children in
check_max_connections(), and since child_handler() knows nothing
about that, it still will write to the pipe, waking up the loop
unnecessarily.
But that will be rare.
This is no longer as trivial as I wanted it to be, so I'd
appreciate a few eyeballs on this patch.
daemon.c | 69 +++++++++++++++++++++++++++++++++++++++++++------------------
1 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/daemon.c b/daemon.c
index 63cd12c..620a288 100644
--- a/daemon.c
+++ b/daemon.c
@@ -16,6 +16,7 @@
static int log_syslog;
static int verbose;
static int reuseaddr;
+static int child_handler_pipe[2];
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--export-all]\n"
@@ -694,23 +695,47 @@ static void kill_some_children(int signo, unsigned start, unsigned stop)
}
}
+static void check_dead_children(void)
+{
+ unsigned spawned, reaped, deleted;
+
+ spawned = children_spawned;
+ reaped = children_reaped;
+ deleted = children_deleted;
+
+ while (deleted < reaped) {
+ pid_t pid = dead_child[deleted % MAX_CHILDREN];
+ const char *dead = pid < 0 ? " (with error)" : "";
+
+ if (pid < 0)
+ pid = -pid;
+
+ /* XXX: Custom logging, since we don't wanna getpid() */
+ if (verbose) {
+ if (log_syslog)
+ syslog(LOG_INFO, "[%d] Disconnected%s",
+ pid, dead);
+ else
+ fprintf(stderr, "[%d] Disconnected%s\n",
+ pid, dead);
+ }
+ remove_child(pid, deleted, spawned);
+ deleted++;
+ }
+ children_deleted = deleted;
+}
+
static void check_max_connections(void)
{
for (;;) {
int active;
- unsigned spawned, reaped, deleted;
+ unsigned spawned, deleted;
+
+ check_dead_children();
spawned = children_spawned;
- reaped = children_reaped;
deleted = children_deleted;
- while (deleted < reaped) {
- pid_t pid = dead_child[deleted % MAX_CHILDREN];
- remove_child(pid, deleted, spawned);
- deleted++;
- }
- children_deleted = deleted;
-
active = spawned - deleted;
if (active <= max_connections)
break;
@@ -760,18 +785,11 @@ static void child_handler(int signo)
if (pid > 0) {
unsigned reaped = children_reaped;
+ if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
+ pid = -pid;
dead_child[reaped % MAX_CHILDREN] = pid;
children_reaped = reaped + 1;
- /* XXX: Custom logging, since we don't wanna getpid() */
- if (verbose) {
- const char *dead = "";
- if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
- dead = " (with error)";
- if (log_syslog)
- syslog(LOG_INFO, "[%d] Disconnected%s", pid, dead);
- else
- fprintf(stderr, "[%d] Disconnected%s\n", pid, dead);
- }
+ write(child_handler_pipe[1], &status, 1);
continue;
}
break;
@@ -917,19 +935,24 @@ static int service_loop(int socknum, int *socklist)
struct pollfd *pfd;
int i;
- pfd = xcalloc(socknum, sizeof(struct pollfd));
+ if (pipe(child_handler_pipe) < 0)
+ die ("Could not set up pipe for child handler");
+
+ pfd = xcalloc(socknum + 1, sizeof(struct pollfd));
for (i = 0; i < socknum; i++) {
pfd[i].fd = socklist[i];
pfd[i].events = POLLIN;
}
+ pfd[socknum].fd = child_handler_pipe[0];
+ pfd[socknum].events = POLLIN;
signal(SIGCHLD, child_handler);
for (;;) {
int i;
- if (poll(pfd, socknum, -1) < 0) {
+ if (poll(pfd, socknum + 1, -1) < 0) {
if (errno != EINTR) {
error("poll failed, resuming: %s",
strerror(errno));
@@ -937,6 +960,10 @@ static int service_loop(int socknum, int *socklist)
}
continue;
}
+ if (pfd[socknum].revents & POLLIN) {
+ read(child_handler_pipe[0], &i, 1);
+ check_dead_children();
+ }
for (i = 0; i < socknum; i++) {
if (pfd[i].revents & POLLIN) {
--
1.5.6.1.300.gca3f
^ permalink raw reply related
* Re: [PATCH] Allow cherry-picking root commits
From: Stephan Beyer @ 2008-07-06 11:35 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, git, Daniel Barkalow, Christian Couder
In-Reply-To: <alpine.DEB.1.00.0807041617320.9925@racer>
On Fri, Jul 04, Johannes Schindelin wrote:
> + if (!commit->parents) {
> + if (action == REVERT)
> + die ("Cannot revert a root commit");
I btw wondered why _reverting_ a root commit should not work.
Then I tried to quickly add this feature and saw what's the point:
merge-recursive wants a remote -- this
> + argv[i++] = next_sha1;
to be set :)
So the change is not as trivial as I thought.
And yes, there may even be no use case for reverting root commits.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* t3503: Add test case for identical files
From: Stephan Beyer @ 2008-07-06 11:32 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, git, Daniel Barkalow, Christian Couder
In-Reply-To: <alpine.DEB.1.00.0807060331250.3557@eeepc-johanness>
---
On Sun, Jul 06, 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 5 Jul 2008, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > There is no good reason why cherry-picking root commits should not be
> > > allowed.
> >
> > Hmm, does "cherry-pick a root commit" even have a well defined
> > semantics, other than "if there is no overlap in files just add the
> > files in"?
>
> Yes. You can easily add the files identically, or some similar files, in
> which case you get an easily-resolved conflict.
I think this test case shows that it works for identical files.
This patch is btw just to show Junio that it works. ;)
Because I'd like to see Dscho's patch in git, too.
Regards.
t/t3503-cherry-pick-root.sh | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/t/t3503-cherry-pick-root.sh b/t/t3503-cherry-pick-root.sh
index b0faa29..bcb6610 100755
--- a/t/t3503-cherry-pick-root.sh
+++ b/t/t3503-cherry-pick-root.sh
@@ -6,14 +6,23 @@ test_description='test cherry-picking a root commit'
test_expect_success setup '
+ : > file0 &&
echo first > file1 &&
+ echo second > file2 &&
+ git add file0 &&
git add file1 &&
test_tick &&
git commit -m "first" &&
+ git symbolic-ref HEAD refs/heads/sharefile &&
+ rm .git/index file0 &&
+ git add file1 &&
+ git add file2 &&
+ test_tick &&
+ git commit -m "file1 and file2" &&
+
git symbolic-ref HEAD refs/heads/second &&
rm .git/index file1 &&
- echo second > file2 &&
git add file2 &&
test_tick &&
git commit -m "second"
@@ -23,6 +32,16 @@ test_expect_success setup '
test_expect_success 'cherry-pick a root commit' '
git cherry-pick master &&
+ test -f file0 &&
+ test first = $(cat file1)
+
+'
+
+test_expect_success 'cherry-pick a root commit with identical files' '
+
+ git checkout sharefile &&
+ git cherry-pick master &&
+ test -f file0 &&
test first = $(cat file1)
'
--
1.5.6.361.g18ea7
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply related
* Re: About -X<option>
From: Johannes Schindelin @ 2008-07-06 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pieter de Bie, Miklos Vajna, git
In-Reply-To: <7vmykvpq2n.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 5 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Isn't that obvious? -X looks like a short option, but the rest of
> > that string does not consist of aggregated short options.
>
> Ah, I see. Then the issue is not about "not easy to code" but about "not
> being consistent".
I never meant to say "easy to code". I always meant "not possible with
parseopt, without major -- and ugly -- surgery".
> We can change it to "--X<option>[=<value>]" and "-X option[=<value>]";
> the topic is still young, not even documented properly IIRC, and is not
> scheduled for 'master' any time soon yet.
I feel that this is too limiting. You really do not want to allow passing
"theirs" to git-merge, when you only ask for stratgey "resolve", right?
Because the "resolve" strategy never heard about "theirs".
To be frank, the semantics of "theirs" _wants_ to treat it as a strategy;
just think of
$ git merge -s ours -Xtheirs
Besides, I sincerely doubt that anybody will find the naming of "-X"
intuitive.
But let's step back a little: "theirs" is most likely something we do not
want to announce, since a careful review in case of merge conflicts should
be performed in that case.
So we do not want official support for it.
And there comes in an aspect of the broader plan for the second half of
Miklos' project: user-defined merge backends.
By allowing users to put a script in their PATH (possibly resorting to "."
just for that script), named "git-merge-<mybackend>", the following
becomes possible:
$ echo 'git merge-recursive --theirs "$@"' > ~/bin/git-merge-X
$ chmod a+x ~/bin/git-merge-X
$ git merge -s X
This would be even more flexible than the "-X" option, and it would
properly keep "--theirs" out of our officially supported features.
If we feel like it, we could even accept a "git-merge-partially-theirs"
into contrib/.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v3] Implement "git stash branch <newbranch> <stash>"
From: Abhijit Menon-Sen @ 2008-07-06 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080703061605.GB3815@toroid.org>
Restores the stashed state on a new branch rooted at the commit on which
the stash was originally created, so that conflicts caused by subsequent
changes on the original branch can be dealt with.
(Thanks to Junio for this nice idea.)
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Reposting as requested with a new test included.
Documentation/git-stash.txt | 19 ++++++++++++++++++-
git-stash.sh | 21 +++++++++++++++++++++
t/t3903-stash.sh | 24 ++++++++++++++++++++++++
3 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..a4cbd0c 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -8,8 +8,11 @@ git-stash - Stash the changes in a dirty working directory away
SYNOPSIS
--------
[verse]
-'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
+'git stash' list
+'git stash' (show | apply | drop | pop) [<stash>]
+'git stash' branch <branchname> [<stash>]
'git stash' [save [<message>]]
+'git stash' clear
DESCRIPTION
-----------
@@ -81,6 +84,20 @@ tree's changes, but also the index's ones. However, this can fail, when you
have conflicts (which are stored in the index, where you therefore can no
longer apply the changes as they were originally).
+branch <branchname> [<stash>]::
+
+ Creates and checks out a new branch named `<branchname>` starting from
+ the commit at which the `<stash>` was originally created, applies the
+ changes recorded in `<stash>` to the new working tree and index, then
+ drops the `<stash>` if that completes successfully. When no `<stash>`
+ is given, applies the latest one.
++
+This is useful if the branch on which you ran `git stash save` has
+changed enough that `git stash apply` fails due to conflicts. Since
+the stash is applied on top of the commit that was HEAD at the time
+`git stash` was run, it restores the originally stashed state with
+no conflicts.
+
clear::
Remove all the stashed states. Note that those states will then
be subject to pruning, and may be difficult or impossible to recover.
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..889445c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -218,6 +218,23 @@ drop_stash () {
git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
}
+apply_to_branch () {
+ have_stash || die 'Nothing to apply'
+
+ test -n "$1" || die 'No branch name specified'
+ branch=$1
+
+ if test -z "$2"
+ then
+ set x "$ref_stash@{0}"
+ fi
+ stash=$2
+
+ git-checkout -b $branch $stash^ &&
+ apply_stash --index $stash &&
+ drop_stash $stash
+}
+
# Main command set
case "$1" in
list)
@@ -264,6 +281,10 @@ pop)
drop_stash "$@"
fi
;;
+branch)
+ shift
+ apply_to_branch "$@"
+ ;;
*)
if test $# -eq 0
then
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..6d89218 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -117,4 +117,28 @@ test_expect_success 'stash pop' '
test 0 = $(git stash list | wc -l)
'
+cat > expect << EOF
+diff --git a/file b/file
+index 7601807..5716ca5 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-baz
++bar
+EOF
+
+test_expect_success 'stash apply' '
+ echo foo > file &&
+ git commit file -m first
+ echo bar > file &&
+ git stash &&
+ echo baz > file &&
+ git commit file -m second &&
+ git stash branch stashbranch &&
+ git commit file -m alternate\ second &&
+ git diff master..stashbranch > output &&
+ test_cmp output expect &&
+ test 0 = $(git stash list | wc -l)
+'
+
test_done
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] INSTALL: Update section about git-frotz form.
From: Johannes Schindelin @ 2008-07-06 11:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1215318521-23901-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Sun, 6 Jul 2008, Miklos Vajna wrote:
> + Let's face it, most of us don't have GNU interactive tools, and even
> + if we had it, we wouldn't know what it does. I don't think it has
> + been actively developed since 1997, and people have moved over to
This: ^ ^ ^ ^ ^ ^ ^ ^ ^
... and this:
> + In addition, as of gnuit-4.9.2, the GNU interactive tools package has
> + been renamed.
somehow contradict each other. Maybe kill the whole sentence containing
1997?
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-06 11:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk0ffhw3.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 6 Jul 2008, Junio C Hamano wrote:
> * js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
> + apply --root: thinkofix.
> + Teach "git apply" to prepend a prefix with "--root=<root>"
If we want to call this "--directory=<root>" instead, we should do it
before that commit hits master.
Ciao,
Dscho
^ permalink raw reply
* something like 'find' in revisions
From: Ittay Dror @ 2008-07-06 11:05 UTC (permalink / raw)
To: git
Hi,
How can I find files with a given name (or pattern) in my history (where
I don't know the exact path and some files have been removed)?
Thank you,
Ittay
--
--
Ittay Dror <ittay.dror@gmail.com>
^ permalink raw reply
* Re: [PATCH] branch -v: Prevent garbage output on remote refs
From: Junio C Hamano @ 2008-07-06 10:07 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1215336279-99480-1-git-send-email-benji@silverinsanity.com>
Thanks, but I have pushed out a slightly different change.
-- >8 --
branch -r -v: do not spit out garbage
The codepath to emit relationship between the branch and what it tracks
forgot to initialize a string buffer stat[] to empty when showing a
tracking branch. This moves the emptying so that the buffer starts as
empty and stays so when no information is added to fix this issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index e9423d1..ff71f3d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -287,10 +287,8 @@ static void fill_tracking_info(char *stat, const char *branch_name)
int ours, theirs;
struct branch *branch = branch_get(branch_name);
- if (!stat_tracking_info(branch, &ours, &theirs) || (!ours && !theirs)) {
- stat[0] = '\0';
+ if (!stat_tracking_info(branch, &ours, &theirs) || (!ours && !theirs))
return;
- }
if (!ours)
sprintf(stat, "[behind %d] ", theirs);
else if (!theirs)
@@ -330,6 +328,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
char stat[128];
strbuf_init(&subject, 0);
+ stat[0] = '\0';
commit = lookup_commit(item->sha1);
if (commit && !parse_commit(commit)) {
^ permalink raw reply related
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vprpwhp7t.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be applied to the maintenance series have "maint-" in their
names.
It already is beginning to become clear what 1.6.0 will look like. What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements. Bigger changes will be:
* Port for MinGW.
* With the default Makefile settings, most of the programs will be
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH will still be supported in
1.6.0, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
* git-merge will be rewritten in C.
* default pack and idx versions will be updated as scheduled for some
time ago.
* GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.
----------------------------------------------------------------
[New Topics]
* js/maint-daemon-syslog (Thu Jul 3 16:27:24 2008 +0100) 1 commit
- [PARKED improvement suggested not rolled in] git daemon: avoid
calling syslog() from a signal handler
This will eventually appear in 'maint'; currently parked on 'pu', though.
* jc/report-tracking (Sun Jul 6 02:54:56 2008 -0700) 5 commits
- branch -r -v: do not spit out garbage
+ stat_tracking_info(): clear object flags used during counting
+ git-branch -v: show the remote tracking statistics
+ git-status: show the remote tracking statistics
+ Refactor "tracking statistics" code used by "git checkout"
Makes the "your branch is ahead of the tracked one by N commits" logic and
messages available to other commands; status and branch are updated.
* sg/stash-k-i (Fri Jun 27 16:37:15 2008 +0200) 1 commit
- stash: introduce 'stash save --keep-index' option
One weakness of our "partial commit" workflow support used to be that the
user can incrementally build what is to be committed in the index but that
state cannot be tested as a whole in the working tree. This allows you to
temporarily stash the remaining changes in the working tree so that the
index state before running "stash save --keep-index" can be seen in the
working tree to be tested and then committed. A recommended workflow to
use after that commit is made needs to be documented (and support needs to
be added if necessary).
* tr/add-i-e (Thu Jul 3 00:00:00 2008 +0200) 3 commits
+ git-add--interactive: manual hunk editing mode
+ git-add--interactive: remove hunk coalescing
+ git-add--interactive: replace hunk recounting with apply --recount
Adds 'e/dit' action to interactive add command.
* am/stash-branch (Thu Jul 3 11:46:05 2008 +0530) 1 commit
+ Implement "git stash branch <newbranch> <stash>"
Creates a new branch out of the stashed state, after returning from the
interrupt that forced you to create the stash in the first place.
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- Ignore graft during object transfer [broken wrt shallow clones]
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* jk/pager-config (Thu Jul 3 07:46:57 2008 -0400) 1 commit
- Allow per-command pager config
----------------------------------------------------------------
[Will merge to master soon]
* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
+ Add another fast-import example, this time for .zip files
* js/apply-root (Wed Jul 2 15:28:22 2008 -0700) 2 commits
+ apply --root: thinkofix.
+ Teach "git apply" to prepend a prefix with "--root=<root>"
* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
+ Only use GIT_CONFIG in "git config", not other programs
* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
+ Make default expiration period of reflog used for stash infinite
+ Per-ref reflog expiry configuration
As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.
* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
+ Eliminate an unnecessary chdir("..")
+ Add support for GIT_CEILING_DIRECTORIES
+ Fold test-absolute-path into test-path-utils
+ Implement normalize_absolute_path
This still feels "because we can", not "because we need to", but it came
from somebody who had the need to, and I do not think it hurts people
without the environment variable set.
* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
+ rerere.autoupdate
+ t4200: fix rerere test
+ rerere: remove dubious "tail_optimization"
+ git-rerere: detect unparsable conflicts
+ rerere: rerere_created_at() and has_resolution() abstraction
A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.
To me, this is "because we can", but was something requested by Ingo, so
presumably some people may feel it useful in their workflow.
----------------------------------------------------------------
[Actively Cooking]
* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 15 commits
- [REJECT -- over-abuse of path-list] Build in merge
+ Fix t7601-merge-pull-config.sh on AIX
+ git-commit-tree: make it usable from other builtins
+ Add new test case to ensure git-merge prepends the custom merge
message
+ Add new test case to ensure git-merge reduces octopus parents when
possible
+ Introduce reduce_heads()
+ Introduce get_merge_bases_many()
+ Add new test to ensure git-merge handles more than 25 refs.
+ Introduce get_octopus_merge_bases() in commit.c
+ git-fmt-merge-msg: make it usable from other builtins
+ Move read_cache_unmerged() to read-cache.c
+ Add new test to ensure git-merge handles pull.twohead and
pull.octopus
+ Move parse-options's skip_prefix() to git-compat-util.h
+ Move commit_list_count() to commit.c
+ Move split_cmdline() to alias.c
The last one is still not quite there, I am afraid.
----------------------------------------------------------------
[Graduated to "master"]
* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
+ compat/pread.c: Add a forward declaration to fix a warning
+ Windows: Fix ntohl() related warnings about printf formatting
+ Windows: TMP and TEMP environment variables specify a temporary
directory.
+ Windows: Make 'git help -a' work.
+ Windows: Work around an oddity when a pipe with no reader is
written to.
+ Windows: Make the pager work.
+ When installing, be prepared that template_dir may be relative.
+ Windows: Use a relative default template_dir and ETC_GITCONFIG
+ Windows: Compute the fallback for exec_path from the program
invocation.
+ Turn builtin_exec_path into a function.
+ Windows: Use a customized struct stat that also has the st_blocks
member.
+ Windows: Add a custom implementation for utime().
+ Windows: Add a new lstat and fstat implementation based on Win32
API.
+ Windows: Implement a custom spawnve().
+ Windows: Implement wrappers for gethostbyname(), socket(), and
connect().
+ Windows: Work around incompatible sort and find.
+ Windows: Implement asynchronous functions as threads.
+ Windows: Disambiguate DOS style paths from SSH URLs.
+ Windows: A rudimentary poll() emulation.
+ Windows: Implement start_command().
+ Windows: A pipe() replacement whose ends are not inherited to
children.
+ Windows: Wrap execve so that shell scripts can be invoked.
+ Windows: Implement setitimer() and sigaction().
+ Windows: Fix PRIuMAX definition.
+ Windows: Implement gettimeofday().
+ Make my_mktime() public and rename it to tm_to_time_t()
+ Windows: Work around misbehaved rename().
+ Windows: always chmod(, 0666) before unlink().
+ Windows: A minimal implemention of getpwuid().
+ Windows: Implement a wrapper of the open() function.
+ Windows: Strip ".exe" from the program name.
+ Windows: Handle absolute paths in
safe_create_leading_directories().
+ Windows: Treat Windows style path names.
+ setup.c: Prepare for Windows directory separators.
+ Windows: Use the Windows style PATH separator ';'.
+ Add target architecture MinGW.
+ Compile some programs only conditionally.
+ Add compat/regex.[ch] and compat/fnmatch.[ch].
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
- Migrate git-blame to parse-option partially.
+ parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
+ parse-opt: fake short strings for callers to believe in.
+ parse-opt: do not print errors on unknown options, return -2
intead.
+ parse-opt: create parse_options_step.
+ parse-opt: Export a non NORETURN usage dumper.
+ parse-opt: have parse_options_{start,end}.
I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series. I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
+ git-blame --reverse
+ builtin-blame.c: allow more than 16 parents
+ builtin-blame.c: move prepare_final() into a separate function.
+ rev-list --children
+ revision traversal: --children option
The blame that finds where each line in the original lines moved to. This
may help a GSoC project that wants to gather statistical overview of the
history. The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).
The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.
* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.
The -X<option> part may change, Dscho mentions that a single-letter -X
that take stuck option is against syntax rules, and I think he's right.
This is more "because we can", not "because we need to".
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-07-06 10:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsk4g5py.fsf@gitster.siamese.dyndns.org>
With accumulated fixes, the latest maintenance release 1.5.6.2 is out.
On the 'master' front, port to MinGW has now been merged, and the next
major release 1.6.0 is already taking shape.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to what is in maint.
Adam Brewster (1):
Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
Brian Gernhardt (1):
Documentation: Point to gitcli(7) from git(1)
Brian Hetro (5):
builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and
'format.suffix'
convert.c: Use 'git_config_string' to get 'smudge' and 'clean'
diff.c: Use 'git_config_string' to get 'diff.external'
http.c: Use 'git_config_string' to clean up SSL config.
builtin-commit.c: Use 'git_config_string' to get 'commit.template'
Christian Couder (2):
Fix "config_error_nonbool" used with value instead of key
Fix "config_error_nonbool" used with value instead of key
Johannes Schindelin (2):
Windows: always chmod(, 0666) before unlink().
git fetch-pack: do not complain about "no common commits" in an empty
repo
Johannes Sixt (35):
Add compat/regex.[ch] and compat/fnmatch.[ch].
Compile some programs only conditionally.
Add target architecture MinGW.
Windows: Use the Windows style PATH separator ';'.
setup.c: Prepare for Windows directory separators.
Windows: Treat Windows style path names.
Windows: Handle absolute paths in safe_create_leading_directories().
Windows: Strip ".exe" from the program name.
Windows: Implement a wrapper of the open() function.
Windows: A minimal implemention of getpwuid().
Windows: Work around misbehaved rename().
Make my_mktime() public and rename it to tm_to_time_t()
Windows: Implement gettimeofday().
Windows: Fix PRIuMAX definition.
Windows: Implement setitimer() and sigaction().
Windows: Wrap execve so that shell scripts can be invoked.
Windows: A pipe() replacement whose ends are not inherited to children.
Windows: Implement start_command().
Windows: A rudimentary poll() emulation.
Windows: Disambiguate DOS style paths from SSH URLs.
Windows: Implement asynchronous functions as threads.
Windows: Work around incompatible sort and find.
Windows: Implement wrappers for gethostbyname(), socket(), and connect().
Windows: Implement a custom spawnve().
Windows: Add a custom implementation for utime().
Windows: Use a customized struct stat that also has the st_blocks member.
Turn builtin_exec_path into a function.
Windows: Compute the fallback for exec_path from the program invocation.
Windows: Use a relative default template_dir and ETC_GITCONFIG
When installing, be prepared that template_dir may be relative.
Windows: Make the pager work.
Windows: Work around an oddity when a pipe with no reader is written to.
Windows: Make 'git help -a' work.
Windows: TMP and TEMP environment variables specify a temporary
directory.
t4127-apply-same-fn: Avoid sed -i
Jonathan Nieder (15):
git-format-patch(1): fix stray \ in output
Documentation: fix gitlinks
manpages: fix bogus whitespace
git(1): add comma
git-commit(1): depersonalize description
Documentation: rewrap to prepare for "git-" vs "git " change
Documentation: more "git-" versus "git " changes
gitdiffcore(7): fix awkward wording
manpages: italicize command names in synopses
manpages: italicize command names
manpages: italicize git command names (which were in teletype font)
manpages: italicize gitk's name (where it was in teletype font)
manpages: italicize nongit command names (if they are in teletype font)
manpages: italicize git subcommand names (which were in teletype font)
manpages: use teletype font for sample command lines
Junio C Hamano (3):
fast-export --export-marks: fix off by one error
attribute documentation: keep EXAMPLE at end
clone -q: honor "quiet" option over native transports.
Marius Storm-Olsen (1):
Windows: Add a new lstat and fstat implementation based on Win32 API.
Matthew Ogilvie (1):
Documentation cvs: Clarify when a bare repository is needed
Miklos Vajna (6):
Retire 'stupid' merge strategy
INSTALL: Update section about git-frotz form.
hg-to-git: avoid raising a string exception
hg-to-git: abort if the project directory is not a hg repo
hg-to-git: rewrite "git-frotz" to "git frotz"
hg-to-git: use git init instead of git init-db
Nikolaus Schulz (1):
Documentation: be precise about which date --pretty uses
Ramsay Allan Jones (1):
Fix some warnings (on cygwin) to allow -Werror
Steffen Prohaska (2):
Windows: Fix ntohl() related warnings about printf formatting
compat/pread.c: Add a forward declaration to fix a warning
Thomas Rast (2):
git-send-email: Do not attempt to STARTTLS more than once
Fix apply --recount handling of no-EOL line
^ 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