* Re: [PATCH/RFCv3 2/2] receive-pack: don't pass non-existent refs to post-{receive,update} hooks in push deletions
From: Pang Yan Han @ 2011-09-30 13:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Sitaram Chamarty, Shawn O. Pearce, Jeff King,
Johannes Schindelin
In-Reply-To: <7vk48sxn5g.fsf@alter.siamese.dyndns.org>
On Wed, Sep 28, 2011 at 04:28:11PM -0700, Junio C Hamano wrote:
> Pang Yan Han <pangyanhan@gmail.com> writes:
>
> > I am unable to reply this until much later, but are the tests in this patch ok?
> > It's the first time I'm writing test cases for git.
>
> I'll squash in a bit more updates and later publish the result.
> Thanks.
Hi Junio,
Thank you for correcting my many amateur mistakes!
Sorry for asking, but do I need to reroll this with the fixup in
origin/ph/push-to-delete-nothing ? Is the commit message fine especially
in light of the changes in the fixup?
Thanks.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-30 13:23 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20110930T041939-332@post.gmane.org>
On Fri, Sep 30, 2011 at 02:51, Peter Shenkin <shenkin@gmail.com> wrote:
> Perhaps it will be useful to say what would have been most
> helpful for me. In the current documentation for "fetch
> --tags", one sentence reads, "This flag lets all tags and
> their associated objects be downloaded." The following small
> modification would, IMO, be sufficient: "This flag causes all
> tags and their associated objects (only) to be downloaded."
Well, you're missing the fact that it not only causes those to
be downloaded, but it also causes the defaults to be ignored,
which is why you don't get the other stuff. You can still tell
git to fetch anything else you want in addition.
See here:
[PATCH v3] Docs: Clarify the --tags option of `git fetch'
Message-ID: <686c38876d5a4ad6bfac67ca77fe9bb3-mfwitten@gmail.com>
http://article.gmane.org/gmane.comp.version-control.git/181887
^ permalink raw reply
* [RFC/PATCH]: reverse bisect v 2.0
From: Michal Vyskocil @ 2011-09-30 11:42 UTC (permalink / raw)
To: git
In-Reply-To: <20110929142027.GA4936@zelva.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 5213 bytes --]
The bugfix command works like the previous git bisect start --reverse.
It switch the meaning of good(s) and bad from the default regression
search approach to the bugfix one.
I don't like adding more new subcommands into bisect, so I decided to
not add ideas I have found on this mailinglist, like 'git bisect
regression' or 'yes', 'no', 'fixed', 'unfixed' or whatever.
The git bisect start/bugfix good/bad/skip log replay and vizualize were
tested (however on simple linear example).
The missing points:
* git-bisect--helper has the "bad" hardcoded, so the commit fixing a
bug is reffered as a bad one
* in git bisect vizualize, the good commit is shown under refs/bad in
gitk (however that's the same problem if user reverse the usage of
good/bad itself).
* documentation and tests of course
Regards
Michal Vyskocil
---
bisect.c | 2 +-
git-bisect.sh | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++------
2 files changed, 60 insertions(+), 8 deletions(-)
diff --git a/bisect.c b/bisect.c
index c7b7d79..2eb34db 100644
--- a/bisect.c
+++ b/bisect.c
@@ -768,7 +768,7 @@ static void handle_bad_merge_base(void)
fprintf(stderr, "Some good revs are not ancestor of the bad rev.\n"
"git bisect cannot work properly in this case.\n"
- "Maybe you mistake good and bad revs?\n");
+ "Try git bisect bugfix to switch the default bisect logic.\n");
exit(1);
}
diff --git a/git-bisect.sh b/git-bisect.sh
index 2524060..6959cf8 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -4,7 +4,9 @@ USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<pathspec>...]
- reset bisect state and start bisection.
+ reset bisect state and start bisection to find a regression.
+git bisect bugfix [--no-checkout] [<good> [<bad>...]] [--] [<pathspec>...]
+ reset bisect state and start bisection to find a bugfix.
git bisect bad [<rev>]
mark <rev> a known-bad revision.
git bisect good [<rev>...]
@@ -33,6 +35,29 @@ OPTIONS_SPEC=
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+setup_bugfix_mode() {
+ /bin/touch "$GIT_DIR/BISECT_BUGFIX"
+}
+
+bisect_bugfix_mode() {
+ test -f "$GIT_DIR/BISECT_BUGFIX"
+}
+
+bisect_check_state() {
+
+ if bisect_bugfix_mode; then
+ if test "$1" = "good"; then
+ echo "bad"
+ return 0
+ elif test "$1" = "bad"; then
+ echo "good"
+ return 0
+ fi
+ fi
+
+ echo $1
+}
+
bisect_head()
{
if test -f "$GIT_DIR/BISECT_HEAD"
@@ -69,6 +94,15 @@ bisect_start() {
# Check for one bad and then some good revisions.
#
has_double_dash=0
+ #
+ # Exchange the internal meaning of good/bad allowing bisect to find
+ # a commit fixing a bug, not "only" the one causes a regression
+ #
+ cmd="start"
+ if test -n "$1" && test "$1" = "bugfix"; then
+ cmd="bugfix"
+ shift 1
+ fi
for arg; do
case "$arg" in --) has_double_dash=1; break ;; esac
done
@@ -99,10 +133,17 @@ bisect_start() {
die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
break
}
- case $bad_seen in
- 0) state='bad' ; bad_seen=1 ;;
- *) state='good' ;;
- esac
+ #if test $cmd = "bisect"; then
+ case $bad_seen in
+ 0) state='bad' ; bad_seen=1 ;;
+ *) state='good' ;;
+ esac
+ #else
+ # case $bad_seen in
+ # 0) state='good' ; bad_seen=1 ;;
+ # *) state='bad' ;;
+ # esac
+ #fi
eval="$eval bisect_write '$state' '$rev' 'nolog' &&"
shift
;;
@@ -169,7 +210,10 @@ bisect_start() {
} &&
git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
eval "$eval true" &&
- echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
+ echo "git bisect $cmd$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
+ if test $cmd = "bugfix"; then
+ setup_bugfix_mode || exit
+ fi
#
# Check if we can proceed to the next bisect state.
#
@@ -225,7 +269,7 @@ bisect_skip() {
bisect_state() {
bisect_autostart
- state=$1
+ state=$(bisect_check_state $1)
case "$#,$state" in
0,*)
die "$(gettext "Please call 'bisect_state' with at least one argument.")" ;;
@@ -377,6 +421,7 @@ bisect_clean_state() {
rm -f "$GIT_DIR/BISECT_LOG" &&
rm -f "$GIT_DIR/BISECT_NAMES" &&
rm -f "$GIT_DIR/BISECT_RUN" &&
+ rm -f "$GIT_DIR/BISECT_BUGFIX" &&
# Cleanup head-name if it got left by an old version of git-bisect
rm -f "$GIT_DIR/head-name" &&
git update-ref -d --no-deref BISECT_HEAD &&
@@ -401,7 +446,12 @@ bisect_replay () {
start)
cmd="bisect_start $rev"
eval "$cmd" ;;
+ bugfix)
+ cmd="bisect_start 'bugfix' $rev"
+ setup_bugfix_mode || exit
+ eval "$cmd" ;;
good|bad|skip)
+ command=$(bisect_check_state $1)
bisect_write "$command" "$rev" ;;
*)
die "$(gettext "?? what are you talking about?")" ;;
@@ -485,6 +535,8 @@ case "$#" in
git bisect -h ;;
start)
bisect_start "$@" ;;
+ bugfix)
+ bisect_start "bugfix" "$@" ;;
bad|good)
bisect_state "$cmd" "$@" ;;
skip)
--
1.7.6.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [PATCH 2/2] use new Git::config_path() for aliasesfile
From: Cord Seele @ 2011-09-30 10:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano, Eric Wong, Cord Seele
In-Reply-To: <1317379945-9355-1-git-send-email-cowose@gmail.com>
Signed-off-by: Cord Seele <cowose@gmail.com>
---
git-send-email.perl | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 98ab33a..f17f7b3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -225,7 +225,6 @@ my %config_settings = (
"cccmd" => \$cc_cmd,
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
- "aliasesfile" => \@alias_files,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
"multiedit" => \$multiedit,
@@ -234,6 +233,10 @@ my %config_settings = (
"assume8bitencoding" => \$auto_8bit_encoding,
);
+my %config_path_settings = (
+ "aliasesfile" => \@alias_files,
+);
+
# Help users prepare for 1.7.0
sub chain_reply_to {
if (defined $chain_reply_to &&
@@ -330,6 +333,11 @@ sub read_config {
$$target = Git::config_bool(@repo, "$prefix.$setting") unless (defined $$target);
}
+ foreach my $setting (keys %config_path_settings) {
+ my $target = $config_path_settings{$setting}->[0];
+ $$target = Git::config_path(@repo, "$prefix.$setting") unless (defined $$target);
+ }
+
foreach my $setting (keys %config_settings) {
my $target = $config_settings{$setting};
next if $setting eq "to" and defined $no_to;
--
1.7.6.4
^ permalink raw reply related
* [PATCH 1/2] Add Git::config_path()
From: Cord Seele @ 2011-09-30 10:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano, Eric Wong, Cord Seele
In-Reply-To: <1317379945-9355-1-git-send-email-cowose@gmail.com>
Use --path option when calling 'git config' thus allow for pathname
expansion, e.g. a tilde.
Signed-off-by: Cord Seele <cowose@gmail.com>
---
perl/Git.pm | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index a86ab70..c279bfb 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -627,6 +627,38 @@ sub config_bool {
};
}
+
+=item config_path ( VARIABLE )
+
+Retrieve the path configuration C<VARIABLE>. The return value
+is an expanded path or C<undef> if it's not defined.
+
+This currently wraps command('config') so it is not so fast.
+
+=cut
+
+sub config_path {
+ my ($self, $var) = _maybe_self(@_);
+
+ try {
+ my @cmd = ('config', '--path');
+ unshift @cmd, $self if $self;
+ if (wantarray) {
+ return command(@cmd, '--get-all', $var);
+ } else {
+ return command_oneline(@cmd, '--get', $var);
+ }
+ } catch Git::Error::Command with {
+ my $E = shift;
+ if ($E->value() == 1) {
+ # Key not found.
+ return undef;
+ } else {
+ throw $E;
+ }
+ };
+}
+
=item config_int ( VARIABLE )
Retrieve the integer configuration C<VARIABLE>. The return value
--
1.7.6.4
^ permalink raw reply related
* [PATCH v2] git-send-email: allow filename expansion
From: Cord Seele @ 2011-09-30 10:52 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano, Eric Wong
In-Reply-To: <vpqty7wk9km.fsf@bauges.imag.fr>
OK, here's another try to get it more Git-like.
Filename expansion now works as far as I can tell. But I failed actually
using my mutt aliases (but also with plain v1.7.6.4). Since I'm not
familiar with perl-debugging could please someone more experienced have a look?
Thanks.
-- Cord
[PATCH 1/2] Add Git::config_path()
[PATCH 2/2] use new Git::config_path() for aliasesfile
^ permalink raw reply
* Re: [PATCH v3 0/4] port upload-archive to Windows
From: Jeff King @ 2011-09-30 10:46 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-1-git-send-email-kusmabite@gmail.com>
On Thu, Sep 29, 2011 at 10:59:19PM +0200, Erik Faye-Lund wrote:
> It's been a while, but here's another updated version of this
> series.
>
> The only change since last time is that the series has been made
> compatible with Peff's "when remote, disable some features"
> changes.
>
> Erik Faye-Lund (4):
> compat/win32/sys/poll.c: upgrade from upstream
> mingw: fix compilation of poll-emulation
> enter_repo: do not modify input
> upload-archive: use start_command instead of fork
Thanks. I can't comment on the earlier patches, but 4/4 looks sane to
me.
-Peff
^ permalink raw reply
* Re: [PATCH] show git tag output in pager
From: Jeff King @ 2011-09-30 10:42 UTC (permalink / raw)
To: Michal Vyskocil; +Cc: Matthieu Moy, git
In-Reply-To: <20110929093749.GB27152@zelva.suse.cz>
On Thu, Sep 29, 2011 at 11:37:49AM +0200, Michal Vyskocil wrote:
> On Tue, Sep 27, 2011 at 04:19:39PM +0200, Matthieu Moy wrote:
> > The commit message should explain why this is needed, and in particular
> > why you prefer this to setting pager.tag in your ~/.gitconfig.
>
> Opps! I read a documentation, but I did not realize this works for all
> commands and not only for them calling setup_pager(). Then sorry, no
> change is needed.
I don't think you want to set pager.tag. It will invoke the pager for
all tag subcommands, including tag creation and deletion. It's not a
huge deal if your pager exits immediately when the input is less than a
page (which I think our default LESS settings will do). But I wouldn't
be surprised if it ends up confusing some program at some point.
I think instead, you want some way for commands to say "OK, I'm in a
subcommand that might or might not want a pager now".
Something like the (thoroughly not tested) patch below, which you can
use like:
git config pager.tag.list
diff --git a/builtin.h b/builtin.h
index 0e9da90..d0fe971 100644
--- a/builtin.h
+++ b/builtin.h
@@ -35,6 +35,7 @@ int copy_note_for_rewrite(struct notes_rewrite_cfg *c,
void finish_copy_notes_for_rewrite(struct notes_rewrite_cfg *c);
extern int check_pager_config(const char *cmd);
+extern void try_subcommand_pager(const char *subcommand);
extern int textconv_object(const char *path, unsigned mode, const unsigned char *sha1, char **buf, unsigned long *buf_size);
diff --git a/builtin/tag.c b/builtin/tag.c
index 667515e..bc45fe6 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -152,6 +152,7 @@ static int list_tags(const char **patterns, int lines,
filter.lines = lines;
filter.with_commit = with_commit;
+ try_subcommand_pager("tag.list");
for_each_tag_ref(show_reference, (void *) &filter);
return 0;
diff --git a/git.c b/git.c
index 8e34903..60fbf1e 100644
--- a/git.c
+++ b/git.c
@@ -64,6 +64,16 @@ static void commit_pager_choice(void) {
}
}
+void try_subcommand_pager(const char *subcommand)
+{
+ /* it's too late to turn off a running pager */
+ if (pager_in_use())
+ return;
+
+ use_pager = check_pager_config(subcommand);
+ commit_pager_choice();
+}
+
static int handle_options(const char ***argv, int *argc, int *envchanged)
{
const char **orig_argv = *argv;
Other programs like "git branch list" would probably want similar hooks.
For commands like "tag" and "branch" where there's really only one
operation that you would want to be paged (i.e., "list"), it's tempting
to also (or instead) make "pager.tag" only affect the useful command.
That's not too hard for internal commands like "tag" (patch below). But
I'm not sure how you would do it for something external like "stash";
from git.c's perspective, we don't know anything about stash or whether
it would want to respect pager config or not.
diff --git a/builtin/tag.c b/builtin/tag.c
index bc45fe6..bbdb135 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -152,7 +152,7 @@ static int list_tags(const char **patterns, int lines,
filter.lines = lines;
filter.with_commit = with_commit;
- try_subcommand_pager("tag.list");
+ try_subcommand_pager("tag");
for_each_tag_ref(show_reference, (void *) &filter);
return 0;
diff --git a/git.c b/git.c
index 60fbf1e..64a078d 100644
--- a/git.c
+++ b/git.c
@@ -276,6 +276,7 @@ static int handle_alias(int *argcp, const char ***argv)
* RUN_SETUP for reading from the configuration file.
*/
#define NEED_WORK_TREE (1<<3)
+#define NO_PAGER_CONFIG (1<<4)
struct cmd_struct {
const char *cmd;
@@ -299,7 +300,9 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
prefix = setup_git_directory_gently(&nongit_ok);
}
- if (use_pager == -1 && p->option & (RUN_SETUP | RUN_SETUP_GENTLY))
+ if (use_pager == -1 &&
+ p->option & (RUN_SETUP | RUN_SETUP_GENTLY) &&
+ !(p->option & NO_PAGER_CONFIG))
use_pager = check_pager_config(p->cmd);
if (use_pager == -1 && p->option & USE_PAGER)
use_pager = 1;
@@ -436,7 +439,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
- { "tag", cmd_tag, RUN_SETUP },
+ { "tag", cmd_tag, RUN_SETUP | NO_PAGER_CONFIG },
{ "tar-tree", cmd_tar_tree },
{ "unpack-file", cmd_unpack_file, RUN_SETUP },
{ "unpack-objects", cmd_unpack_objects, RUN_SETUP },
-Peff
^ permalink raw reply related
* Re: [PATCH v2] Add a credential-helper for KDE
From: Jeff King @ 2011-09-30 10:21 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List
In-Reply-To: <4E7605CA.7020204@gmail.com>
On Sun, Sep 18, 2011 at 04:52:58PM +0200, Lukas Sandström wrote:
> This Python script plugs into the credentials API
> of Git to ask the user for passwords with a nice
> KDE password dialog.
>
> The password is saved in the KWallet.
So I managed to play with this a bit tonight. Overall, it seems pretty
nice.
Initially, it seemed somewhat clumsy. It asked me to open the wallet
(using a password) each time git ran. Which is about as annoying as just
typing my git password each time. :)
The magic trick was to configure kwallet to "keep the wallet open for 10
minutes after the last use" instead of "close when no applications have
the wallet open". Since git runs as many small programs, kwallet has no
real idea of how long a git session is.
This is totally not a kwallet thing, and nothing to do with your helper.
But since the helper is so annoyingly useless without that config, it
might be worth mentioning it in a README.
> Right. Multiple usernames per "unique" context is supported in this version.
> I looked at the git-credential-storage helper when I wrote the first patch,
> which didn't have obvious support for multiple usernames per unique context.
This part passed my tests just fine. Very nice.
> +class CredentialHelper(KApplication):
> + def __init__(self, token, username = None, desc = None, reject = False):
> + super(CredentialHelper, self).__init__()
> + self.password = None
> + self.username = username
> + self.save_password = False
> + self.token = token
> + self.desc = desc
> +
> + if not self.token:
> + return
My tests complained about doing nothing when there is no token. As I've
mentioned elsewhere, this doesn't matter now (as git never invokes the
helper that way), but it would be nice to future-proof the helper by
just ignoring the wallet, but still doing the nice password dialog.
> + def open_wallet(self):
> + self.wallet = KWallet.Wallet.openWallet(
> + KWallet.Wallet.LocalWallet(), 0, KWallet.Wallet.Synchronous)
> + if not self.wallet.isOpen():
> + return None
> + if not self.wallet.hasFolder("GitCredentials"):
> + self.wallet.createFolder("GitCredentials")
> + self.wallet.setFolder("GitCredentials")
I peeked around the KWallet manager. There's a "passwords" folder in the
wallet, and I was surprised that the passwords didn't go there. But when
I tried using konqueror to store a password, I found that it also made
its own folder, and then stored a map within it for each URL.
So I'm not really sure if you're following kwallet best practices or
not, as I'm clearly confused about what the "passwords" folder is for.
;)
> + def check_wallet(self):
> + (res, data) = self.wallet.readMap(self.token)
So you're just using the token as a big blob. Which is how I
anticipated, but is the complete opposite of what OS X Keychain wants.
Which is leading me to think we should really just hand helpers both
forms: the information broken down by item (e.g., --host=github.com),
and a full URL (e.g., --url=https://github.com/). And then the helpers
can use whatever they like (where you would use "url" instead of the
current "unique").
-Peff
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: René Scharfe @ 2011-09-30 9:12 UTC (permalink / raw)
To: Martin Fick
Cc: Julian Phillips, Christian Couder, git, Christian Couder,
Thomas Rast, Junio C Hamano
In-Reply-To: <201109291411.06733.mfick@codeaurora.org>
Hi Martin,
Am 29.09.2011 22:11, schrieb Martin Fick:
> Your patch works well for me. It achieves about the same
> gains as Julian's patch. Thanks!
OK, and what happens if you apply the following patch on top of my first
one? It avoids going through all the refs a second time during cleanup,
at the cost of going through the list of all known objects. I wonder if
that's any faster in your case.
Thanks,
René
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 84e0cdc..a4b1003 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -596,15 +596,14 @@ static int add_pending_uninteresting_ref(const char *refname,
return 0;
}
-static int clear_commit_marks_from_one_ref(const char *refname,
- const unsigned char *sha1,
- int flags,
- void *cb_data)
+static void clear_commit_marks_for_all(unsigned int mark)
{
- struct commit *commit = lookup_commit_reference_gently(sha1, 1);
- if (commit)
- clear_commit_marks(commit, -1);
- return 0;
+ unsigned int i, max = get_max_object_index();
+ for (i = 0; i < max; i++) {
+ struct object *object = get_indexed_object(i);
+ if (object && object->type == OBJ_COMMIT)
+ object->flags &= ~mark;
+ }
}
static void describe_one_orphan(struct strbuf *sb, struct commit *commit)
@@ -690,8 +689,7 @@ static void orphaned_commit_warning(struct commit *commit)
else
describe_detached_head(_("Previous HEAD position was"), commit);
- clear_commit_marks(commit, -1);
- for_each_ref(clear_commit_marks_from_one_ref, NULL);
+ clear_commit_marks_for_all(ALL_REV_FLAGS);
}
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
^ permalink raw reply related
* Re: [RFC/PATCHv2] git-p4: handle files with shell metacharacters
From: Luke Diamand @ 2011-09-30 9:06 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20110927130334.GA24327@arf.padd.com>
On 27/09/11 14:03, Pete Wyckoff wrote:
<snip>
>
> If you don't mind, I'll just queue it up with the utf16 and
> test-refactor stuff I have, and send it all to Junio post-1.7.7.
> Here's how I plan to adjust your tests, given the feedback that
> Junio gave earlier and from reading other tests in t/.
>
> -- Pete
Pete - I've just noticed that t9803 sets P4EDITOR up for the wrong commit.
It works fine for me in my the setup I've got at home but on another
setup hangs trying to run vi from within the test.
It looks like two or possibly three bugs combine with each other.
(a) my misplacement of P4EDITOR
(b) git-p4 doesn't check the return code from system(editor + fileName)
at around 1018, so it just carries blithely on.
(c) "git var GIT_EDITOR" called from within the test harness gives
differing results. In one setup I get "vi", in another, nothing. The
tests pass in the latter case.
I'll submit a new patch series to fix (a) and (b). I'm not sure if (c)
is a bug or a feature. If I get very keen I might also include a tidied
up version of the recent patch for turning off the editor explicitly.
Luke
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Jakub Narebski @ 2011-09-30 8:44 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20110930T041939-332@post.gmane.org>
Peter Shenkin <shenkin@gmail.com> writes:
[...]
> Now I have a related question. I always want to retrieve all
> tags from tracking branches when I do a "git pull". Right now,
> if I want to do this, it seem (unless I am missing something)
> that I have to do "git fetch --tags; git fetch; git merge". Is
> there a way I can put something into my .git/config file so
> that I get this effect simply by doing a "git pull"? That's
> what I was trying to do when I added "tagopt = --tags".
Actually fetching of branches on remote into remote-tracking branches
would also fetch all tags that point to commits on fetched branches
(so called "autofollow" feature).
If you want to fetch _all_ tags, you need to configure fetched
branches (e.g. via glob refspec). I think that then "tagopt = --tags"
works as expected then, as it is in addition to refspec not as the
only refspec; "fetch = +refs/tags/*:refs/tags/*" should work as well.
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: RFC: reverse bisect
From: Michal Vyskocil @ 2011-09-30 8:29 UTC (permalink / raw)
To: git
In-Reply-To: <4E849C5B.7050201@kdbg.org>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
On Thu, Sep 29, 2011 at 06:27:07PM +0200, Johannes Sixt wrote:
> Am 29.09.2011 16:20, schrieb Michal Vyskocil:
> > git bisect start --reverse HEAD~999 HEAD
>
> With the regular meaning of the start subcommand, the revs given are
> ordered: bad good good...
>
> With the reversed meaning, this would have to become: good bad bad...
>
> This would have to be mentioned clearly in the documentation.
>
> > git bisect good/bad/skip/run
>
> Last time this came up on the list I suggested to add the following
> commands:
>
> git bisect regression # a synonym for git bisect start
> git bisect improvement # your --reverse
Good point! As you mentioned, the --switch already reverse the meanings
of arguments as you mentioned. Using a new command will be less
confusing for users.
Michal Vyskocil
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* fatal: index-pack failed
From: Matti Linnanvuori @ 2011-09-30 8:11 UTC (permalink / raw)
To: git
Jenkins got an error:
Error performing command: git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/
Command "git fetch -t ssh://iac-builder@sorsa.portalify.com/p/git/.git+refs/heads/*:refs/remotes/origin/*" returned status code 128: error: refs/remotes/origin/HEAD does not point to a valid object!
error: refs/remotes/origin/master does not point to a valid object!
error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
error: refs/remotes/origin/HEAD does not point to a valid object!
error: refs/remotes/origin/master does not point to a valid object!
error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
error: refs/remotes/origin/HEAD does not point to a valid object!
error: refs/remotes/origin/master does not point to a valid object!
error: missing object referenced by 'refs/tags/iac-1.4.13'
error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
error: Could not read 49f273234b582edb44bbdbda29193719e5054cb7
fatal: pack has 26 unresolved deltas
fatal: index-pack failed
git fsck --full
error: refs/remotes/origin/HEAD does not point to a valid object!
error: refs/remotes/origin/master does not point to a valid object!
error: refs/tags/jenkins-iac-orm-snapshot-889 does not point to a valid object!
broken link from commit 5d4e8989e0b84546cd85fc5e1da12f68e4d38972
to tree 54e146b9fca023bbde2b311629d82601fa1e89a0
broken link from commit 5d4e8989e0b84546cd85fc5e1da12f68e4d38972
to commit 49f273234b582edb44bbdbda29193719e5054cb7
dangling tree ec3b83770e89242fccda40b5194dd450122e49ed
dangling tree dd51bc467f3f36c89b8064e550298f91d15bf28d
dangling blob 1756f72adc8a8292e6fadeb306823f1d26feeb7b
dangling tree 5e58d68ae6f5d5f554fbeb80f14c49bbf097a44c
dangling blob 0f67ad10d3ad05b33b4689f3859cf2455bc0c292
dangling tree 72818c927d476f0d56846d82062afe2648f9b554
dangling blob 07969328481717f171624066c43948b8d69b4933
dangling tree c49ef6d9a7a248c726327fb9e00bffa365f84dcb
dangling tree 66b64e2a6ba858d357baa65887e8e117b368e771
dangling blob 18c48a80fde2c5e1c9e696c055852af723eec01c
dangling blob 4dcf4f005cc2e57f0f2720a937fa53740504ebf8
dangling tree add32288c58a090c3746f7286bfaefd5f5fb24a4
missing tree 54e146b9fca023bbde2b311629d82601fa1e89a0
missing commit 49f273234b582edb44bbdbda29193719e5054cb7
git --version
git version 1.7.2.5
Debian GNU/Linux 6.0
Matti Linnanvuori
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Julian Phillips @ 2011-09-30 8:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Fick, Christian Couder, git, Christian Couder, Thomas Rast
In-Reply-To: <7vwrcqpuc7.fsf@alter.siamese.dyndns.org>
On Thu, 29 Sep 2011 20:44:40 -0700, Junio C Hamano wrote:
> Martin Fick <mfick@codeaurora.org> writes:
>
>> This works for me, however unfortunately, I cannot find any
>> scenarios where it improves anything over the previous fix
>> by René. :(
>
> Nevertheless, I would appreciate it if you can try this _without_
> René's
> patch. This attempts to make resolve_ref() cheap for _any_ caller.
> René's
> patch avoids calling it in one specific callchain.
>
> They address different issues. René's patch is probably an
> independently
> good change (I haven't thought about the interactions with the topics
> in
> flight and its implications on the future direction), but would not
> help
> other/new callers that make many calls to resolve_ref().
It certainly helps with my test repo (~140k refs, of which ~40k are
branches). User times for checkout starting from an orphaned commit
are:
No fix : ~16m8s
+ Binary Search : ~4s
+ René's patch : ~2s
(The 2s includes both patches, though the timing is the same for René's
patch alone)
--
Julian
^ permalink raw reply
* Updated tag 'junio-gpg-pub' ?
From: Stefan Näwe @ 2011-09-30 6:49 UTC (permalink / raw)
To: Junio C. Hamano; +Cc: Git List
Junio,
I haven't seen any announcement of this:
> Fetching origin
> >From http://github.com/gitster/git
> - [tag update] junio-gpg-pub -> junio-gpg-pub
Did you update your GPG key ?
Greetings,
Stefan
--
----------------------------------------------------------------
/dev/random says: Bullets speak louder than reason.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* [ANNOUNCE] Gitolite v2.1 and mirroring features
From: Sitaram Chamarty @ 2011-09-30 6:44 UTC (permalink / raw)
To: Git Mailing List
Hello all,
I've kinda stopped sending "announce" emails for all the little
features and enhancements that happen to gitolite, but this one seemed
big enough and important enough to send one out to this list.
Gitolite v2.1 now does mirroring much more flexibly and powerfully
than the old, rather naive, setup.
Most of the impetus for these changes came from a rather large product
development group within TCS, the company I work for -- many cities,
offices, servers, repos, and developers.
Here are the highlights:
(1) the "NUMA" thing: Different repos can now be mastered on different
servers, depending on which city/office has the most developers for
*that* project.
This was the single biggest motivator for the new mirroring code; the
rest of the cool stuff just happened along.
(2) almost as good as "active-active" mirroring: If the "master"
server trusts the authentication performed by the "slave" server, you
can have the slave internally redirect a "git push" to the correct
master.
With this, developers don't have to remember which repo is mastered
where, use different 'pushurl's, etc. They just do *everything* with
their local mirror and let the system deal with it. (You can even
change which server is "master" and people don't even need to know it
has changed!)
(3) partial mirrors and local repos: A server doesn't have to carry
*all* the repos in the system -- it can choose to carry only some.
In our case it was often because there were no developers for that
project in that office, but there could be other reasons. Server
load/resource constraints, legal/jurisdictional issues, server in a
non-free country and repo has crypto code ;-) etc.
Similarly, a server can have repos that it wants to keep purely local
-- not to be mirrored at all.
(4) laggy mirrors: If daytime bandwidth is an issue, and you're ok
with the lag, you can postpone mirroring to night times instead of
with every push. The actual mirroring is triggered with a simple
command -- you can write your cron jobs around that quite easily.
(5) autonomous mirrors: Your mirrors don't all have to be under your
control. They can be owned by someone else and you negotiate what
repos you'll mirror for each other. For example, an open source
project may find a "donor" that is willing to mirror a few
highly-trafficked repos and make them available via git:// or http://
----
We use all these features (except the last one; it's not pertinent to
our setup), and things have been humming along for a few weeks now.
If you have any questions not answered by the documentation[1], feel
free to email me.
[1]: http://sitaramc.github.com/gitolite/doc/mirroring.html
--
Sitaram
^ permalink raw reply
* Re: RFC: reverse bisect
From: Frans Klaver @ 2011-09-30 5:31 UTC (permalink / raw)
To: git
In-Reply-To: <20110930040924.GA28724@sigill.intra.peff.net>
On Fri, 30 Sep 2011 06:09:24 +0200, Jeff King <peff@peff.net> wrote:
> One catch is that the run command assumes a successful exit is "good",
> and anything else is "bad". Which makes:
>
> git bisect run make test
>
> good for finding regressions, but is a little counterintuitive for the
> yes/no thing (a successful exit means "no").
Then you would require a script that inverts the result, no? From my
point of view it's either that or add an option telling bisect run how
to interpret the results. In the latter case you could still consider
adding the regression/improvement qualification to bisect start. It might
help getting the mind set right.
Frans
^ permalink raw reply
* Re: RFC: reverse bisect
From: Jeff King @ 2011-09-30 4:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michal Vyskocil, git
In-Reply-To: <4E849C5B.7050201@kdbg.org>
On Thu, Sep 29, 2011 at 06:27:07PM +0200, Johannes Sixt wrote:
> > git bisect good/bad/skip/run
>
> Last time this came up on the list I suggested to add the following
> commands:
>
> git bisect regression # a synonym for git bisect start
> git bisect improvement # your --reverse
That makes some sense to me. But I do wonder if you could simply get rid
of the connotations of "good" and "bad" entirely, by thinking of it as
simply looking for a commit that introduced some property. Like:
# find a bug
git bisect start
git bisect yes ;# has the bug
git bisect no ;# does not have the bug
git bisect skip ;# no idea
# find a feature being implemented
git bisect start
git bisect yes ;# has the feature
git bisect no ;# does not have the feature
git bisect skip ;# no idea
IOW, I feel like we are having to handle this weird negation only
because we have assigned a value judgement to the tests. That instead of
saying "yes, we have this bug", we say "bad", which only makes sense if
you are looking for a bad thing.
You can still produce a negation in your mind, of course, by asking
"when did this property go away". But that is usually about a bug being
fixed, so the right answer is generally not a set of command line
options, but to stop asking "when did bug X go away", and instead ask
"when did the fix for bug X appear".
One catch is that the run command assumes a successful exit is "good",
and anything else is "bad". Which makes:
git bisect run make test
good for finding regressions, but is a little counterintuitive for the
yes/no thing (a successful exit means "no").
-Peff
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Junio C Hamano @ 2011-09-30 3:44 UTC (permalink / raw)
To: Martin Fick
Cc: Julian Phillips, Christian Couder, git, Christian Couder,
Thomas Rast
In-Reply-To: <201109291913.34196.mfick@codeaurora.org>
Martin Fick <mfick@codeaurora.org> writes:
> This works for me, however unfortunately, I cannot find any
> scenarios where it improves anything over the previous fix
> by René. :(
Nevertheless, I would appreciate it if you can try this _without_ René's
patch. This attempts to make resolve_ref() cheap for _any_ caller. René's
patch avoids calling it in one specific callchain.
They address different issues. René's patch is probably an independently
good change (I haven't thought about the interactions with the topics in
flight and its implications on the future direction), but would not help
other/new callers that make many calls to resolve_ref().
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-09-30 2:51 UTC (permalink / raw)
To: git
In-Reply-To: <119711285.RuumktFLOq@hyperion>
Hi,
I just searched the List to see if there were any postings on
"fetch --tags", because I was recently thrown for a loop by
the fact the this command retrieves only tags (and commits
needed to fulfill them). So I was very happy to find this
discussion. I was actually trying to figure out whether the
observed behavior is a bug, given that there is no mention of
it in the documentation.
Perhaps it will be useful to say what would have been most
helpful for me. In the current documentation for "fetch
--tags", one sentence reads, "This flag lets all tags and
their associated objects be downloaded." The following small
modification would, IMO, be sufficient: "This flag causes all
tags and their associated objects (only) to be downloaded."
Now I have a related question. I always want to retrieve all
tags from tracking branches when I do a "git pull". Right now,
if I want to do this, it seem (unless I am missing something)
that I have to do "git fetch --tags; git fetch; git merge". Is
there a way I can put something into my .git/config file so
that I get this effect simply by doing a "git pull"? That's
what I was trying to do when I added "tagopt = --tags".
Thanks,
-P.
^ permalink raw reply
* Re: In favor of "git commit --no-parent"
From: Junio C Hamano @ 2011-09-30 2:28 UTC (permalink / raw)
To: Michael Witten
Cc: Phil Hord, Carlos Martín Nieto, vra5107, Michael J Gruber,
Matthieu Moy, Eric Raible, Philip Oakley, Jeff King, Jay Soffian,
git
In-Reply-To: <CAMOZ1BuUvuyrf3Tio+9EZR_-b3zy-RWpq36+0rmDO+QKWaVmxQ@mail.gmail.com>
Michael Witten <mfwitten@gmail.com> writes:
> The main issue with "git commit --no-parent" is [supposedly] safety, but it
> can be made pretty safe:
>
> $ cd repo
> $ # Hack away as usual or not
> $ git status # As with any other commit.
> $ git commit --no-parent
> Error! There must be another branch head directly referencing the
> same commit that is directly referenced by the current branch head!
That safety indeed will work, and I kind of like it. I think this is in
line with what we try to do when you come back from a detached HEAD state.
You may also want to allow this when HEAD is detached already (I am just
thinking aloud here). One possible workflow may be to start from somewhere
random, such as the last customer release point:
git checkout rel-2011-09-01
# strip proprietary stuff away
# make sure the result is satisfactory
git commit --no-parent
git checkout -b opensource
By the way, I am not convinced enough with the "git status" argument,
though.
The output from "status" and "diff" will show what you changed, but in the
"strip proprietary stuff" scenario, what you care much more about is what
you forgot to remove.
If my current source is littered with a confidencial name of an unreleased
device that I need to remove, I am more likely to use "git grep" on the
_remaining_ files, and this does not make a difference between "checkout
--orphan" or "commit --no-parent".
But I would imagine I would not _know_ what I am looking for until I see
it. There may be the name of another confidential device in the source
that I need to sanitize, too.
In a "strip" scenario, I suspect that the most natural way to verify would
be to run "git diff" between what is about to be committed and an empty
tree and inspect the output. That would be what I would do if I were
starting from an empty repository, populating the working tree and the
index with what I think is releaseable.
Another an advantage of "commit --no-parent" is that we do not have to
worry about a corner case like this:
git checkout --orphan xyzzy
# time passes, you do many things
git checkout foo
git branch | grep xyzzy ;# not found -- what happened to the branch?
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: John Szakmeister @ 2011-09-30 1:17 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, Junio C Hamano
In-Reply-To: <CAEBDL5WhpVg17aPuRqrE5=2Q293kVD4fYtxGqRzx_K=87t-jgw@mail.gmail.com>
On Thu, Sep 29, 2011 at 6:03 AM, John Szakmeister <john@szakmeister.net> wrote:
[snip]
> Yep, I agree. And it's worse when using the security command line
> tool... when you grant security access to the key, then any app could
> technically gain access to the item via the security tool. That's one
> of the reasons I didn't pursue that route early on.
Thinking about this a little more, git-credential-anything has the
same problem. I can run it, and it'll dump out my password for
anybody. I'd rather it didn't do that. I think it would be more
satisfying to have the mechanisms built into git itself, without a
separate application. I'm not sure how practical that is though.
-John
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Martin Fick @ 2011-09-30 1:13 UTC (permalink / raw)
To: Julian Phillips
Cc: Junio C Hamano, Christian Couder, git, Christian Couder,
Thomas Rast
In-Reply-To: <20110929221143.23806.25666.julian@quantumfyre.co.uk>
On Thursday, September 29, 2011 04:11:42 pm Julian Phillips
wrote:
> Currently we linearly search through lists of refs when
> we need to find a specific ref. This can be very slow
> if we need to lookup a large number of refs. By
> changing to a binary search we can make this faster.
>
> In order to be able to use a binary search we need to
> change from using linked lists to arrays, which we can
> manage using ALLOC_GROW.
>
> We can now also use the standard library qsort function
> to sort the refs arrays.
>
This works for me, however unfortunately, I cannot find any
scenarios where it improves anything over the previous fix
by René. :(
I tested many things, clones, fetches, fetch noops,
checkouts, garbage collection. I am a bit surprised,
because I thought that my hack of a hash map did improve
still on checkouts on packed refs, but it could just be that
my hack was buggy and did not actually do a full orphan
check.
Thanks,
-Martin
^ permalink raw reply
* Re: [RFC/PATCH] git checkout $tree path
From: John Szakmeister @ 2011-09-30 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk48rq854.fsf@alter.siamese.dyndns.org>
On Thu, Sep 29, 2011 at 6:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
[snip]
> According to that definition, because "master" has dir/file1, and the
> index is unchanged since "next", we would add dir/file1 to the index, and
> then check dir/file1 and dir/file3 out of the index. Hence, we end up
> resurrecting dir/file3 out of the index, even though "master" does not
> have that path.
>
> This is somewhat surprising.
That is surprising! It explains something I saw just yesterday which
closely mirrors your recipe.
> It may make sense to tweak the semantics a little bit. We can grab the
> paths out of the named tree ("master" in this case), update the index, and
> update the working tree with only with these paths we grabbed from the
> named tree. By doing so, we will keep the local modification to dir/file3
> (in this case, the modification is to "delete", but the above observation
> hold equally true if dir/file3 were modified).
That seems sane.
> An alternative semantics could be to first remove paths that match the
> given pathspec from the index, then update the index with paths taken from
> the named tree, and update the working tree. "git checkout master dir"
> would then mean "replace anything currently in dir with whatever is in dir
> in master". It is more dangerous, and it can easily emulated by doing:
This is equally sane, but is probably closer to my expectation.
[snip]
> * This is a behaviour change, but it may qualify as a bugfix. I dunno.
Personally, I lean towards it being a bugfix.
-John
^ 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