* [PATCH] teaching git-add--interactive to accept a file param
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster
Back in October a thread came up, "Proposed git mv behavioral change",
and I inadvertently suggested a new feature for git-add--interactive;
the ability to supply an optional file path parameter and jump straight
to the "patch" subcommand for that file:
<http://kerneltrap.org/mailarchive/git/2007/10/19/348229>
This small patch series implements that suggestion:
Refactor patch_update_cmd
Teach git-add--interactive to accept a file path to patch
Teach builtin-add to pass a path argument to git-add--interactive
Document optional file parameter to git-add--interactive
It applies against the current master. I've not yet submitted many
patches to Git, so please be gentle!
Documentation/git-add.txt | 5 ++++-
builtin-add.c | 16 ++++++++++------
commit.h | 2 +-
git-add--interactive.perl | 11 +++++++++--
4 files changed, 24 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 3/4] Teach builtin-add to pass a path argument to git-add--interactive
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1195648601-21736-3-git-send-email-win@wincent.com>
The previous patch in the series taught git-add--interactive to handle
a single optional path argument. This patch teaches builtin-add to pass
this argument through to the script.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
builtin-add.c | 16 ++++++++++------
commit.h | 2 +-
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index cf815a0..278c02e 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -135,9 +135,9 @@ static void refresh(int verbose, const char **pathspec)
free(seen);
}
-int interactive_add(void)
+int interactive_add(const char *path)
{
- const char *argv[2] = { "add--interactive", NULL };
+ const char *argv[3] = { "add--interactive", path, NULL };
return run_command_v_opt(argv, RUN_GIT_CMD);
}
@@ -163,16 +163,20 @@ static struct option builtin_add_options[] = {
int cmd_add(int argc, const char **argv, const char *prefix)
{
- int i, newfd, orig_argc = argc;
+ int i, newfd = argc;
const char **pathspec;
struct dir_struct dir;
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
if (add_interactive) {
- if (add_interactive != 1 || orig_argc != 2)
- die("add --interactive does not take any parameters");
- exit(interactive_add());
+ if (argc > 1)
+ die("add --interactive may take only 1 optional "
+ "parameter");
+ else if (argc == 1)
+ exit(interactive_add(argv[0]));
+ else
+ exit(interactive_add(NULL));
}
git_config(git_default_config);
diff --git a/commit.h b/commit.h
index aa67986..03a6ec5 100644
--- a/commit.h
+++ b/commit.h
@@ -113,7 +113,7 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int in_merge_bases(struct commit *, struct commit **, int);
-extern int interactive_add(void);
+extern int interactive_add(const char *path);
extern void add_files_to_cache(int verbose, const char *prefix, const char **files);
extern int rerere(void);
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* [PATCH 4/4] Document optional file parameter to git-add--interactive
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1195648601-21736-4-git-send-email-win@wincent.com>
Update the documentation for git-add to mention the new optional
file parameter to git-add--interactive.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-add.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 63829d9..4b44802 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -61,7 +61,10 @@ OPTIONS
-i, \--interactive::
Add modified contents in the working tree interactively to
- the index.
+ the index. If a single optional file argument is supplied the
+ initial command loop is bypassed and the 'patch' subcommand is
+ invoked for the specified file. See ``Interactive mode'' below
+ for details.
-u::
Update only files that git already knows about. This is similar
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* [PATCH 1/4] Refactor patch_update_cmd
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1195648601-21736-1-git-send-email-win@wincent.com>
Split patch_update_cmd into two functions, one to prompt the user for
a path to patch and another to do the actual work given that file path.
This lays the groundwork for a future commit which will teach
git-add--interactive to accept a path parameter and jump directly to
the patch subcommand for that path, bypassing the interactive prompt.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 0317ad9..fb1e92a 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -564,10 +564,12 @@ sub patch_update_cmd {
IMMEDIATE => 1,
HEADER => $status_head, },
@mods);
- return if (!$it);
+ patch_update_file($it->{VALUE}) if ($it);
+}
+sub patch_update_file {
my ($ix, $num);
- my $path = $it->{VALUE};
+ my $path = shift;
my ($head, @hunk) = parse_diff($path);
for (@{$head->{TEXT}}) {
print;
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* [PATCH] Authenticate only once in git-send-email
From: Wincent Colaiuta @ 2007-11-21 12:35 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
When using git-send-email with SMTP authentication sending a patch series
would redundantly authenticate multiple times, once for each patch. In
the worst case, this would actually prevent the series from being sent
because the server would reply with a "5.5.0 Already Authenticated"
status code which would derail the process.
This commit teaches git-send-email to authenticate once and only once at
the beginning of the series.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-send-email.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9c6fa64..76baa8e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -145,6 +145,7 @@ sub format_2822_time {
my $have_email_valid = eval { require Email::Valid; 1 };
my $smtp;
+my $auth;
sub unique_email_list(@);
sub cleanup_compose_files();
@@ -635,7 +636,7 @@ X-Mailer: git-send-email $gitversion
}
if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
- $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
+ $auth ||= $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
}
$smtp->mail( $raw_from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* Re: [PATCH] Fix warning about bitfield in struct ref
From: Johannes Schindelin @ 2007-11-21 11:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071121065155.GT14735@spearce.org>
Hi,
On Wed, 21 Nov 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 18 Nov 2007, Shawn O. Pearce wrote:
> >
> > > + unsigned int force:1,
> >
> > Isn't this "unsigned force:1" everywhere else in git's source?
>
> That may be true but Junio already applied it as "unsigned int"
> as I wrote it.
Yes, I saw that _after_ I wrote this mail.
> Anyway "unsigned int" and "unsigned" will give the same result here; I
> just typed 4 characters more than I needed to.
No big problem.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-21 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vmyt8gdzv.fsf@gitster.siamese.dyndns.org>
On Nov 21, 2007 5:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> But I think an API definition that says "These fds are closed
> after the call, so if you are going to use them, you can dup()
> them beforehand" is equally valid, and I suspect that forgetting
> to dup() is easier to detect than forgetting to close() --- you
> will notice the former mistake immediately because your read and
> write say "oops, nobody on the other end" but the latter mistake
> will result in a hung process. And for that reason, I think it
> can be called more "graceful". So ...
>
I don't konw the original API definition and havn't found any API
deinition that clarifies the fds will be closed after start_command.
However, when i see child_process.close_in/close_out, i thought
start_command will not close the fds.
I never said that start_command must not close fd. At least this
behaviour of start_command makes child_process.close_in/close_out no
sense.
>
>
--
Ping Yin
^ permalink raw reply
* Adding push configuration to .git/config
From: Nico -telmich- Schottelius @ 2007-11-21 10:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
Hello guys!
We are working pretty much with branches here and I think it would be
pretty cool, to make git-push recognize some configuratio in
~/.git/config that describes where to push what:
git-push origin master:<name of worker> is what we currenty do
manually
Nice would be
[branch "master"]
remote-push = origin
remote-push-merge = another_branch
And thus perhaps also changing the existing specs:
remote = ... to remote-fetch = ...
merge = ... to remote-fetch-merge =
And perhaps it would also make sense to replace "refs/heads/master" with
only "master"?
What do you think about those three ideas?
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Jeff King @ 2007-11-21 11:27 UTC (permalink / raw)
To: Toby White; +Cc: git, Wincent Colaiuta
In-Reply-To: <47440912.8010800@cam.ac.uk>
On Wed, Nov 21, 2007 at 10:31:46AM +0000, Toby White wrote:
> So I wrote a quick script (below) which does what I need. Of all
> the available git-diff flags, it only understands "--cached", and
> up to two commit objects, and no paths, but that's enough for me.
> Within those constraints, it has the same semantics as git-diff.
Have you looked at the documentation for GIT_EXTERNAL_DIFF (try git(7))?
I think it is a cleaner way of doing what you want (although I think you
will get each file diffed individually, which is perhaps not what you
want).
Something like:
$ cat >merge.sh <<EOF
#!/bin/sh
opendiff "$1" "$2"
EOF
$ GIT_EXTERNAL_DIFF=./merge.sh git-diff ...
> #!/bin/sh
> #
> # Filemerge.app must not already be open before running
> # this script, or opendiff below will return immediately,
> # and the TMPDIRs deleted before it gets the chance to read
> # them.
>
> if test $# = 0; then
> OLD=`git-write-tree`
> elif test "$1" = --cached; then
> OLD=HEAD
> NEW=`git-write-tree`
> shift
> fi
> if test $# -gt 0; then
> OLD="$1"; shift
> fi
> test $# -gt 0 && test -z "$CACHED" && NEW="$1"
write-tree? Yikes. If you want to diff against the working tree, then do
that. If you want to diff against the index, then you probably want to
git-checkout-index to a tmpdir, and diff against that.
> git-archive --format=tar $OLD | (cd $TMPDIR1; tar xf -)
Again, this could be simpler and faster by using git-checkout-index
(preceded by git-read-tree into a temp index, if you are comparing
against a tree).
-Peff
^ permalink raw reply
* Re: stgit: another way of storing patches
From: Karl Hasselström @ 2007-11-21 11:24 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711200653g4d87c433gae2d48f3508940f5@mail.gmail.com>
On 2007-11-20 09:53:55 -0500, Jon Smirl wrote:
> What about storing each stg git patch in a branch and then
> auto-merging them into the working copy?
You mean making a "patch" be a topic branch rather than just one
commit, with the successive commits on the topic branch reflecting the
changes to the patch over time?
How would you handle operations such as refreshing a non-topmost
patch, reordering patches, dropping patches, etc? It seems to me that
the operation you'd want then would look more like cherry-picking than
merging, at least sometimes.
It might work, but someone would have to sit down with pen and paper
and work out how all the common operations should work.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Jonathan del Strother @ 2007-11-21 11:20 UTC (permalink / raw)
To: Toby White; +Cc: git, Wincent Colaiuta
In-Reply-To: <47440912.8010800@cam.ac.uk>
On 21 Nov 2007, at 10:31, Toby White wrote:
> Mac OS X bundles a rather nice graphical diff viewer (Filemerge.app)
> with its developer tools.
>
> While git-merge knows how to use this as a merge tool, I couldn't
> find any way to easily use Filemerge as a viewer for the output
> of git-diff.
>
> (http://thread.gmane.org/gmane.comp.version-control.git/58702
> discusses the problem, and recommends piping git-diff into kompare.
> Filemerge unfortunately won't accept diff output on stdin)
>
> So I wrote a quick script (below) which does what I need. Of all
> the available git-diff flags, it only understands "--cached", and
> up to two commit objects, and no paths, but that's enough for me.
> Within those constraints, it has the same semantics as git-diff.
> ...
Handy, thanks.
Just as a note to anyone who runs into the same problems as me - I
couldn't persuade this script to work at first. On my Leopard
install, mktemp needs a template argument to run. After replacing
both `mktemp -d`s in this script with `mktemp -d /tmp/diff.XXXXX`, it
works nicely.
Jon
^ permalink raw reply
* Re: [StGit PATCH] Added test case for stg refresh
From: David Kågedal @ 2007-11-21 10:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <87tznfvqb4.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
> ---
>
> This test case fails on the kha/experimental branch. Using "stg
> refresh -p <patch>" can cause all sorts of wieirdness, and there is no
> test case for it.
I just checked, and it fails on kha/safe as well. So maybe there is
some problem with the test case, but I don't know what it is.
And maybe it should be called t2301 instead?
> t/t2700-refresh.sh | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 65 insertions(+), 0 deletions(-)
> create mode 100755 t/t2700-refresh.sh
>
> diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
> new file mode 100755
> index 0000000..2e7901c
> --- /dev/null
> +++ b/t/t2700-refresh.sh
> @@ -0,0 +1,65 @@
> +#!/bin/sh
> +
> +test_description='Run "stg refresh"'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'Initialize StGit stack' '
> + stg init &&
> + echo expected.txt >> .git/info/exclude &&
> + echo patches.txt >> .git/info/exclude &&
> + stg new p0 -m "base" &&
> + for i in 1 2 3; do
> + echo base >> foo$i.txt &&
> + git add foo$i.txt
> + done
> + stg refresh &&
> + for i in 1 2 3; do
> + stg new p$i -m "foo $i" &&
> + echo "foo $i" >> foo$i.txt &&
> + stg refresh
> + done
> +'
> +
> +cat > expected.txt <<EOF
> +p0
> +p3
> +EOF
> +test_expect_success 'Refresh top patch' '
> + echo bar 3 >> foo3.txt &&
> + stg refresh &&
> + stg status &&
> + test -z "$(stg status)" &&
> + stg patches foo3.txt > patches.txt &&
> + diff -u expected.txt patches.txt
> +'
> +
> +cat > expected.txt <<EOF
> +p0
> +p2
> +EOF
> +test_expect_success 'Refresh middle patch' '
> + stg status &&
> + echo bar 2 >> foo2.txt &&
> + stg refresh -p p2 &&
> + stg status &&
> + test -z "$(stg status)" &&
> + stg patches foo2.txt > patches.txt &&
> + diff -u expected.txt patches.txt
> +'
> +
> +cat > expected.txt <<EOF
> +p0
> +p1
> +EOF
> +test_expect_success 'Refresh bottom patch' '
> + stg status &&
> + echo bar 1 >> foo1.txt &&
> + stg refresh -p p1 &&
> + stg status &&
> + test -z "$(stg status)" &&
> + stg patches foo1.txt > patches.txt &&
> + diff -u expected.txt patches.txt
> +'
> +
> +test_done
> --
> 1.5.3.6.740.ge3d12
--
David Kågedal, Virtutech
^ permalink raw reply
* Using Filemerge.app as a git-diff viewer
From: Toby White @ 2007-11-21 10:31 UTC (permalink / raw)
To: git; +Cc: Wincent Colaiuta
Mac OS X bundles a rather nice graphical diff viewer (Filemerge.app)
with its developer tools.
While git-merge knows how to use this as a merge tool, I couldn't
find any way to easily use Filemerge as a viewer for the output
of git-diff.
(http://thread.gmane.org/gmane.comp.version-control.git/58702
discusses the problem, and recommends piping git-diff into kompare.
Filemerge unfortunately won't accept diff output on stdin)
So I wrote a quick script (below) which does what I need. Of all
the available git-diff flags, it only understands "--cached", and
up to two commit objects, and no paths, but that's enough for me.
Within those constraints, it has the same semantics as git-diff.
It's not very nice, but in case anyone else wants this:
#!/bin/sh
#
# Filemerge.app must not already be open before running
# this script, or opendiff below will return immediately,
# and the TMPDIRs deleted before it gets the chance to read
# them.
if test $# = 0; then
OLD=`git-write-tree`
elif test "$1" = --cached; then
OLD=HEAD
NEW=`git-write-tree`
shift
fi
if test $# -gt 0; then
OLD="$1"; shift
fi
test $# -gt 0 && test -z "$CACHED" && NEW="$1"
TMPDIR1=`mktemp -d`
git-archive --format=tar $OLD | (cd $TMPDIR1; tar xf -)
if test -z "$NEW"; then
TMPDIR2=$(git rev-parse --show-cdup)
test -z "$cdup" && TMPDIR2=.
else
TMPDIR2=`mktemp -d`
git-archive --format=tar $NEW | (cd $TMPDIR2; tar xf -)
fi
opendiff $TMPDIR1 $TMPDIR2 | cat
rm -rf $TMPDIR1
test ! -z "$NEW" && rm -rf $TMPDIR2
--
Dr. Toby O. H. White
Dept. Earth Sciences,
Downing Street,
Cambridge CB2 3EQ
United Kingdom
Tel: +44 1223 333464
Fax: +44 1223 333450
Web: http://uszla.me.uk
^ permalink raw reply
* [StGit PATCH] Added test case for stg refresh
From: David Kågedal @ 2007-11-21 10:35 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
This test case fails on the kha/experimental branch. Using "stg
refresh -p <patch>" can cause all sorts of wieirdness, and there is no
test case for it.
t/t2700-refresh.sh | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
create mode 100755 t/t2700-refresh.sh
diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
new file mode 100755
index 0000000..2e7901c
--- /dev/null
+++ b/t/t2700-refresh.sh
@@ -0,0 +1,65 @@
+#!/bin/sh
+
+test_description='Run "stg refresh"'
+
+. ./test-lib.sh
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ echo expected.txt >> .git/info/exclude &&
+ echo patches.txt >> .git/info/exclude &&
+ stg new p0 -m "base" &&
+ for i in 1 2 3; do
+ echo base >> foo$i.txt &&
+ git add foo$i.txt
+ done
+ stg refresh &&
+ for i in 1 2 3; do
+ stg new p$i -m "foo $i" &&
+ echo "foo $i" >> foo$i.txt &&
+ stg refresh
+ done
+'
+
+cat > expected.txt <<EOF
+p0
+p3
+EOF
+test_expect_success 'Refresh top patch' '
+ echo bar 3 >> foo3.txt &&
+ stg refresh &&
+ stg status &&
+ test -z "$(stg status)" &&
+ stg patches foo3.txt > patches.txt &&
+ diff -u expected.txt patches.txt
+'
+
+cat > expected.txt <<EOF
+p0
+p2
+EOF
+test_expect_success 'Refresh middle patch' '
+ stg status &&
+ echo bar 2 >> foo2.txt &&
+ stg refresh -p p2 &&
+ stg status &&
+ test -z "$(stg status)" &&
+ stg patches foo2.txt > patches.txt &&
+ diff -u expected.txt patches.txt
+'
+
+cat > expected.txt <<EOF
+p0
+p1
+EOF
+test_expect_success 'Refresh bottom patch' '
+ stg status &&
+ echo bar 1 >> foo1.txt &&
+ stg refresh -p p1 &&
+ stg status &&
+ test -z "$(stg status)" &&
+ stg patches foo1.txt > patches.txt &&
+ diff -u expected.txt patches.txt
+'
+
+test_done
--
1.5.3.6.740.ge3d12
--
David Kågedal
^ permalink raw reply related
* Re: t9106 failure, bisect weirdness
From: carbonated beverage @ 2007-11-21 9:57 UTC (permalink / raw)
To: Eric Wong; +Cc: Christian Couder, git, Junio C Hamano
In-Reply-To: <20071121091001.GA23266@soma>
> I can't reproduce it at all on any of my boxes, but does the following
> one-liner fix it consistently?
FYI, it's a Core 2 Duo @ 2GHz (Thinkpad Z61t).
Yup, I ran the test in a loop, and it went through 15 iterations without
failure. This patch works for me.
Thanks!
-- DN
Daniel
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-21 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vabpctx3b.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.
Just in case anybody is wondering, this message is updated with
the help with a new script UWC in 'todo' branch these days (I
have 'todo' checked out in Meta/ directory, so the script is
called Meta/UWC and uses Meta/git-topic.perl script etc.)
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit
+ Move gitk to its own subdirectory
I have a phoney Makefile under the subdirectory for gitk, but
hopefully with the next pull from Paulus I can replace it with
the real thing, along with the i18n stuff.
* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits
+ Bisect reset: do nothing when not bisecting.
+ Bisect: use "$GIT_DIR/BISECT_NAMES" to check if we are bisecting.
+ Bisect visualize: use "for-each-ref" to list all good refs.
+ git-bisect: modernize branch shuffling hack
+ git-bisect: use update-ref to mark good/bad commits
+ git-bisect: war on "sed"
+ Bisect reset: remove bisect refs that may have been packed.
Will merge by the weekend (if I can find time, that is).
* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
+ Do git reset --hard HEAD when using git rebase --skip
After seeing a conflicted rebase, you may decide to skip that
patch but then you would need "git reset --hard" before saying
"git rebase --skip". This teaches "git rebase --skip" to
automatically discard the conflicted rebase for you.
Will merge by the weekend.
* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits
+ Remove hint to use "git help -a"
+ Make the list of common commands more exclusive
Some people on the list may find the exact list of commands
somewhat debatable. We can fine-tune that in-tree ('pu' does
not count as "in-tree").
* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits
+ fetch-pack: Prepare for a side-band demultiplexer in a thread.
+ rehabilitate some t5302 tests on 32-bit off_t machines
+ Allow ETC_GITCONFIG to be a relative path.
+ Introduce git_etc_gitconfig() that encapsulates access of
ETC_GITCONFIG.
+ Allow a relative builtin template directory.
+ Close files opened by lock_file() before unlinking.
+ builtin run_command: do not exit with -1.
+ Move #include <sys/select.h> and <sys/ioctl.h> to git-compat-
util.h.
+ Use is_absolute_path() in sha1_file.c.
+ Skip t3902-quoted.sh if the file system does not support funny
names.
+ t5302-pack-index: Skip tests of 64-bit offsets if necessary.
+ t7501-commit.sh: Not all seds understand option -i
+ t5300-pack-object.sh: Split the big verify-pack test into smaller
parts.
A set of good general clean-up patches.
----------------------------------------------------------------
[Actively cooking]
* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits
- send-pack: cluster ref status reporting
+ send-pack: fix "everything up-to-date" message
+ send-pack: tighten remote error reporting
+ make "find_ref_by_name" a public function
+ Fix warning about bitfield in struct ref
+ send-pack: assign remote errors to each ref
+ send-pack: check ref->status before updating tracking refs
+ send-pack: track errors for each ref
+ Merge branch 'aw/mirror-push' into jk/send-pack
+ Merge branch 'ar/send-pack-remote-track' into jk/send-pack
+ Merge branch 'db/remote-builtin' into jk/send-pack
+ git-push: add documentation for the newly added --mirror mode
+ Add tests for git push'es mirror mode
+ Update the tracking references only if they were succesfully
updated on remote
+ Add a test checking if send-pack updated local tracking branches
correctly
+ git-push: plumb in --mirror mode
+ Teach send-pack a mirror mode
+ Merge master into aw/mirror-push
+ Merge branch 'jk/terse-push' into aw/mirror-push
+ send-pack: segfault fix on forced push
+ Reteach builtin-ls-remote to understand remotes
+ send-pack: require --verbose to show update of tracking refs
+ receive-pack: don't mention successful updates
+ more terse push output
+ Build in ls-remote
+ Build-in send-pack, with an API for other programs to call.
+ Use built-in send-pack.
+ Build-in peek-remote, using transport infrastructure.
+ Miscellaneous const changes and utilities
Various improvements on status reporting and error handling by
send-pack, and implementation of "mirror" pushing.
* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits
+ Teach git clean to use setup_standard_excludes()
+ git-clean: Fix error message if clean.requireForce is not set.
+ Make git-clean a builtin
It has a subtle change in behaviour but it does not quite
qualify as a regression. Will merge to "next" shortly. We can
fix the corner case semantics in-tree. I also adjusted the
error message to match the fix from Hannes on 'master'.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
----------------------------------------------------------------
[Approaching 'next']
* kh/commit (Sun Nov 18 01:52:55 2007 -0800) 21 commits
- builtin-commit: fix partial-commit support
- Fix add_files_to_cache() to take pathspec, not user specified list
of files
- Export three helper functions from ls-files
- builtin-commit: run commit-msg hook with correct message file
- builtin-commit: do not color status output shown in the message
template
- file_exists(): dangling symlinks do exist
- Replace "runstatus" with "status" in the tests
- t7501-commit: Add test for git commit <file> with dirty index.
- builtin-commit: Clean up an unused variable and a debug fprintf().
- Call refresh_cache() when updating the user index for --only
commits.
- builtin-commit: Add newline when showing which commit was created
- builtin-commit: resurrect behavior for multiple -m options
- builtin-commit --s: add a newline if the last line was not a S-o-b
- builtin-commit: fix --signoff
- git status: show relative paths when run in a subdirectory
- builtin-commit: Refresh cache after adding files.
- builtin-commit: fix reflog message generation
- launch_editor(): read the file, even when EDITOR=:
- Port git commit to C.
- Export launch_editor() and make it accept ':' as a no-op editor.
- Add testcase for amending and fixing author in git commit.
There are still a few regressions that keep this series out of
'next', including the lossage of "-v" (final diff review).
By the way, I am meaning to squash the part that introduces and
then fixes builtin-commit.c into a smaller number of commits for
future readability and bisectability (currently the series is
not bisectable).
----------------------------------------------------------------
[Stalled]
* sp/refspec-match (Sun Nov 18 17:13:08 2007 +0100) 6 commits
- push: Add '--current', which pushes only the current branch
- push: Add '--matching' option and print warning if it should be
used
- refactor fetch's ref matching to use refname_match()
- push: use same rules as git-rev-parse to resolve refspecs
- add refname_match()
- push: support pushing HEAD to real branch name
("Stalled" is my fault, not the author's) This changes the
semantics slightly but I think it is a move in the right
direction. Perhaps merge the early parts to 'next'; I am not
entirely happy with the updated --current patch which does not
appear in this queue.
* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.
* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
- Make builtin-tag.c use parse_options.
This changes the handling of multiple -m options without much
good reason. It should be a simple fix, once we know what we
want. I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.
* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
- Added diff hunk coloring to git-add--interactive
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
This series has improved quite a bit since the last round, but
another round was requested from the list. Waiting for
refinements.
* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
+ Add missing inside_work_tree setting in setup_git_directory_gently
There was an additional patch, which still had issues Dscho
pointed out. Waiting for refinements.
* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
- Make git-svn rebase --dirty pass along --dirty to git-rebase.
- Implement --dirty for git-rebase--interactive.
- Introduce --dirty option to git-rebase, allowing you to start from
a dirty state.
This seems to be optimized for the --dirty case too much. I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").
----------------------------------------------------------------
[Others]
* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits
- git-branch --contains: doc and test
- git-branch --contains=commit
- parse-options: Allow to hide options from the default usage.
Contains Pierre's "hidable options with --help-all" patch. I
think this is ready to be in 'next'.
* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
- test format-patch -s: make sure MIME content type is shown as
needed
- format-patch -s: add MIME encoding header if signer's name
requires so
This is to apply to 'maint' later; the equivalent fix is already
in 'master'.
* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit
- Fix rev-list when showing objects involving submodules
This is to apply to 'maint' later; the equivalent fix is already
in 'next' and will be merged to 'master' soon.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
- handle renames using similarity engine
- introduce generic similarity library
- change hash table calling conventions
* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
- revert/cherry-pick: start refactoring call to merge_recursive
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
The second one could probably be used to replace the use of
path-list in the tip commit on the kh/commit series.
^ permalink raw reply
* Re: [PATCH 0/3] Implement git-svn: info
From: Eric Wong @ 2007-11-21 9:20 UTC (permalink / raw)
To: David D. Kilzer; +Cc: git
In-Reply-To: <20071121091809.GB23266@soma>
Eric Wong <normalperson@yhbt.net> wrote:
> "David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> > "David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> > > Eric Wong <normalperson@yhbt.net> wrote:
> > > > Can we expect the output of "svn info" to not change between
> > > > versions? I know "svn status" has changed between versions of
> > > > svn. I'd prefer if we keep the expected.* files hard-coded
> > > > in a test directory and compare those instead. Maybe use sed
> > > > to substitute placeholders for timestamps..
> > > Done.
> >
> > Grrr. I remember the reason I didn't do this in the first place. In Patch
> > 2/3, there are now hard-coded directory paths and my username in the static
> > expected-* files.
> >
> > That means that either I need to replace the "URL:", "Repository Root:" and
> > "Last Changed Author:" fields with place-holders (weakening the effectiveness
> > of the tests), or switch back to more dynamic tests.
> >
> > Thoughts?
>
> Ah, good point.
>
> On some of my tests (t9110, t9111, t9115), I get around this by
> generating a repository once and dumping it using `svnadmin dump'.
Wait, the paths/URLs will still be inconsistent, but author will at
least be correct...
Sorry, I need sleep :/
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/3] Implement git-svn: info
From: Eric Wong @ 2007-11-21 9:18 UTC (permalink / raw)
To: David D. Kilzer; +Cc: git
In-Reply-To: <220901.13065.qm@web52408.mail.re2.yahoo.com>
"David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> "David D. Kilzer" <ddkilzer@kilzer.net> wrote:
> > Eric Wong <normalperson@yhbt.net> wrote:
> > > Can we expect the output of "svn info" to not change between
> > > versions? I know "svn status" has changed between versions of
> > > svn. I'd prefer if we keep the expected.* files hard-coded
> > > in a test directory and compare those instead. Maybe use sed
> > > to substitute placeholders for timestamps..
> > Done.
>
> Grrr. I remember the reason I didn't do this in the first place. In Patch
> 2/3, there are now hard-coded directory paths and my username in the static
> expected-* files.
>
> That means that either I need to replace the "URL:", "Repository Root:" and
> "Last Changed Author:" fields with place-holders (weakening the effectiveness
> of the tests), or switch back to more dynamic tests.
>
> Thoughts?
Ah, good point.
On some of my tests (t9110, t9111, t9115), I get around this by
generating a repository once and dumping it using `svnadmin dump'.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Junio C Hamano @ 2007-11-21 9:11 UTC (permalink / raw)
To: Ping Yin; +Cc: Johannes Sixt, git
In-Reply-To: <46dff0320711201838g5affba6bo21a8c837b0bef681@mail.gmail.com>
"Ping Yin" <pkufranky@gmail.com> writes:
> On Nov 21, 2007 12:17 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> ...
>> This way the change is more local without affecting well-tested other callers.
>
> This way works, but it is a tricky one, not a natural or graceful one.
I do not know about "natural". That largely would depend on
where one starts thinking about the issues from.
But I think an API definition that says "These fds are closed
after the call, so if you are going to use them, you can dup()
them beforehand" is equally valid, and I suspect that forgetting
to dup() is easier to detect than forgetting to close() --- you
will notice the former mistake immediately because your read and
write say "oops, nobody on the other end" but the latter mistake
will result in a hung process. And for that reason, I think it
can be called more "graceful". So ...
>> Furthermore, I don't think that it's correct to just set the .close_in or
>> .close_out flags. This will close the fd only in finish_command(), which can
>> be too late: Think again of a writable pipe end that remains open and keeps
>> the reader waiting for input that is not going to happen.
>
> This may happen. However, i have scanned all the git codes using the
> auto closing behaviour and i don't discover the problem you mentioned.
> So i think it deserves to correct the misbehaviour after carefully
> testing. And we can make a clarification for that if necessary.
... I do not necessarily agree that your patch is correcting the
misbehaviour.
^ permalink raw reply
* Re: t9106 failure, bisect weirdness
From: Eric Wong @ 2007-11-21 9:10 UTC (permalink / raw)
To: carbonated beverage; +Cc: Christian Couder, git, Junio C Hamano
In-Reply-To: <20071121045638.GA9184@net-ronin.org>
Hi, thanks for the heads up, Christian
carbonated beverage <ramune@net-ronin.org> wrote:
> > Ok thanks for doing that too.
> > Could you also look at the "file" when the test succeed and when it does not
> > and send us both versions and a diff between them (if it's not too big).
>
> Size-wise, they're tiny -- though there's a lot of lines.
>
> The diff:
>
> ramune/lycaeum:t: diff -u works.t fails.t
> --- works.t 2007-11-20 21:54:29.000000000 -0700
> +++ fails.t 2007-11-20 21:54:39.000000000 -0700
> @@ -55,9 +55,9 @@
> 55
> 56
> 57
> -5588
> +58
> 59
> 60
> -6611
> +61
> 62
> 63
Ah, these changes should've been made on the svn side. But I'm betting
a race condition appears on faster computers (which we've seen before in
other tests).
I can't reproduce it at all on any of my boxes, but does the following
one-liner fix it consistently?
Thanks,
From: Eric Wong <normalperson@yhbt.net>
Date: Wed, 21 Nov 2007 00:57:33 -0800
Subject: [PATCH] t9106: fix a race condition that caused svn to miss modifications
carbonated beverage noticed this test was occasionally failing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9106-git-svn-dcommit-clobber-series.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t9106-git-svn-dcommit-clobber-series.sh b/t/t9106-git-svn-dcommit-clobber-series.sh
index d59acc8..7452546 100755
--- a/t/t9106-git-svn-dcommit-clobber-series.sh
+++ b/t/t9106-git-svn-dcommit-clobber-series.sh
@@ -22,6 +22,7 @@ test_expect_success '(supposedly) non-conflicting change from SVN' "
cd tmp &&
perl -i -p -e 's/^58\$/5588/' file &&
perl -i -p -e 's/^61\$/6611/' file &&
+ poke file &&
test x\"\`sed -n -e 58p < file\`\" = x5588 &&
test x\"\`sed -n -e 61p < file\`\" = x6611 &&
svn commit -m '58 => 5588, 61 => 6611' &&
--
Eric Wong
^ permalink raw reply related
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Jarek Poplawski @ 2007-11-21 8:09 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, linux-kernel, git
In-Reply-To: <20071121075217.GA1642@ff.dom.local>
On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
...
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history
I've forgotten to mention it's:
[linux/kernel/git/torvalds/linux-2.6.git] / net / core / dev.c
> and see:
> 2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
> and just below something with 2007-08-14 date.
Jarek P.
^ permalink raw reply
* Re: [PATCH] Improve documentation of git-filter-branch rev-list specification.
From: Johannes Sixt @ 2007-11-21 7:49 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <877ikc3gzc.wl%cworth@cworth.org>
Carl Worth schrieb:
> +The filters can modify the tree content stored in each commit,
> +(e.g. removing a file or running a perl rewrite on all files), or the
> +associated information about each commit, (commit message, author,
> +parent, etc.). Any information not affected by a filter (including
> +original commit times or merge information) will be preserved. If you
> +specify no filters, the commits will be recommitted without any
> +changes.
"... will be recommitted without any changes as long as no grafted parents
are encountered. Any grafted parents will be written into the commits even
if no filters are specified."
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-p4: Fix typo in --detect-labels
From: Simon Hausmann @ 2007-11-21 7:48 UTC (permalink / raw)
To: Shun Kei Leung; +Cc: Git ML, Junio C Hamano
In-Reply-To: <e66701d40711201901n712e17e6x6018a4dc16e75cea@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Wednesday 21 November 2007 04:01:19 Shun Kei Leung wrote:
> Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
Acked-by: Simon Hausmann <simon@lst.de>
Thanks,
Simon
> contrib/fast-import/git-p4 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 65c57ac..66b79b6 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -1026,7 +1026,7 @@ class P4Sync(Command):
>
> l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
> if len(l) > 0 and not self.silent:
> - print "Finding files belonging to labels in %s" %
> `self.depotPath` + print "Finding files belonging to labels in
> %s" % `self.depotPaths`
>
> for output in l:
> label = output["label"]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Jarek Poplawski @ 2007-11-21 7:52 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, linux-kernel, git
In-Reply-To: <20071121032009.GB4175@fieldses.org>
On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> > I don't know git, but it seems, at least if done for web only, this
> > shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> > date by querying a small database with kernel versions & dates.
>
> If I create a commit in my linux working repo today, but Linus doesn't
> merge it into his repository until after he releases 2.6.24, then my
> commit will be created with an earlier date than 2.6.24, even though it
> isn't included until 2.6.25.
>
> So you have to actually examine the history graph to figure this out
> this sort of thing.
Of course, you are right, and I probably miss something, but to be
sure we think about the same thing let's look at some example: so, I
open a page with current Linus' tree, go to something titled:
/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / history
and see:
2007-10-10 Stephen Hemminger [NET]: Make NAPI polling independent ...
and just below something with 2007-08-14 date.
Accidentally, I can remember this patch introduced many changes, and
this big interval in dates suggests some waiting. Then I look at the
commit, and there are 2 dates visible, so the patch really was created
earlier. Then I go back to:
/pub/scm / linux/kernel/git/torvalds/linux-2.6.git / summary
and at the bottom I can see this:
...
tags
4 days ago v2.6.24-rc3 Linux 2.6.24-rc3
2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2
4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1
6 weeks ago v2.6.23 Linux 2.6.23
which drives me crazy, because, without looking at the calendar, and
calculator, I don't really know which month was 6 weeks ago, and 4
days ago, either!
So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/,
do some scrolling, look at this:
ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M
and only now I can guess, this napi patch didn't manage to 2.6.23.
Of course, usually I've to do a few more clicks and reading to make
sure where it really started.
So, this could suggest this 2007-10-10 (probably stored with time
too), could be useful here... but it seems, I'm wrong.
Of course, this problem doesn't look so hard if we forget about
git internals: I can imagine keeping a simple database, which
could simply retrieve commit numbers from these ChangeLogs, and
connecting this with gitweb's commit page as well... For
performance reasons, doing it only for stable and testing, so with
-rc 'precision' would be very helpful too.
Regards,
Jarek P.
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Shawn O. Pearce @ 2007-11-21 7:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <4743E1D6.4010308@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Johannes Schindelin schrieb:
> > Oh, and it relies on "int" being castable to void * and vice
> > versa. Is anybody aware of a platform where this can lead to
> > problems?
>
> Win64?
Does anyone even use that? I thought that was dead. Like Vista.
Seriously though, we include stdint.h. If you want to cast a void*
to an integer type and back use ptrint_t. That's what it exists for.
--
Shawn.
^ 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