* Re: [PATCH] git filter-branch: Process commits in --date-order
From: Johannes Sixt @ 2009-03-03 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Peter Rosin, Git Mailing List
In-Reply-To: <7vbpsjl97d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I am wondering if it even makes sense to allow users to disable
> topological ordering.
>
> Doesn't filter-branch have the same "child commits build on top of parent
> commits" dependency as fast-export has? And didn't you guys fix
> fast-export recently?
Doesn't --date-order have the same guarantee as --topo-order with respect
to parents and children, only that commits that can be rearranged such
that the guarantee remains are emitted in date order?
Anyway, the patch is unnecessary: If --date-order is needed, it can be
passed on the command line; this will override --topo-order.
-- Hannes
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 7:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <76718490903022337n79a0c11cw95e80d99cd598d17@mail.gmail.com>
On Tue, Mar 3, 2009 at 2:37 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> I concur w/Jeff and I think git probably should not as well.
Er, w/o being told to do so explicitly. I'd argue "--init" is a saner
option name than "--create" though since you say "git init", not "git
create" to make a repo.
j.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 7:37 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20090303070937.GB30609@coredump.intra.peff.net>
On Tue, Mar 3, 2009 at 2:09 AM, Jeff King <peff@peff.net> wrote:
> If you are going to limit it in that way, wouldn't it be better to do it
> entirely client-side? As in, "git push --create remote" will literally
> do:
>
> ssh remote_host "mkdir -p remote_dir && cd remote_dir && git init --bare"
>
> ? Then you don't have to care about whether the remote side is recent
> enough to support this, and there are no potential security issues; git
> is merely saving you from typing the commands you could have done
> yourself.
So I was curious how Mercurial implemented this, and it is similar to
what Junio coded. It runs "hg init" on the remote end via ssh. (hg
init <path> takes care of creating the directory; I just also noticed
you can do hg init ssh://host/path to create the repo remotely, which
is I guess sorta interesting.)
> I think a featur like this needs to be triggered manually via
> "--create" or similar. Otherwise a typo on a regular push will be very
> confusing as your pushes appear to go nowhere. Though I suppose most
> regular pushes happen using a configured remote, in which case it is not
> as much of an issue.
So I could've sworn Mercurial creates a remote repo for you on push,
but it turns out it does not:
$ hg push ssh://localhost/~/bar
remote: abort: There is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
I concur w/Jeff and I think git probably should not as well. I think
that instead adding it to init might be interesting
"git init <arg>" where <arg> is local (and it creates the directory
and repo for you) or arg is ssh://... and it creates the dir and repo
over there for you.
And have "git push" abort with a friendlier message than:
fatal: '~/bar': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
If that's a plumbing message maybe it can't change, unless push
swallows it and says something nicer like:
fatal: '~/bar' not a git repository. Create the destination repository
with "git init" before pushing.
We can be even friendlier than Mercurial. :-)
j.
^ permalink raw reply
* Re: proper way to merge?
From: Johannes Sixt @ 2009-03-03 7:32 UTC (permalink / raw)
To: John Dlugosz; +Cc: Bryan Donlan, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F07452@EXCHANGE.trad.tradestation.com>
John Dlugosz schrieb:
> I did not find 'grafts' in the documentation,
> but I looked for it now that I know about it. So you can add another
> parent to the graph just by adding a line to that file. BTW,
> filter-branch isn't available on msysgit.
Huh? filter-branch *is* in msysgit. Why do you think it is not?
> But leaving it in that grafts
> file should be OK -- is that pushed/pulled with everything else?
No.
You really want to use filter-branch if the new parent is to be permanent.
-- Hannes
^ permalink raw reply
* Re: [PATCH v5] Test fsck a bit harder
From: Junio C Hamano @ 2009-03-03 7:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Sixt, git
In-Reply-To: <1235946763-15252-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Johannes Sixt wrote:
>> This is wrong: It does not test the exist status. In a pipeline, the shell
>> looks only at the exit status of the last command. You really want this as
>>
>> test_must_fail git fsck >out 2>&1 &&
>
> You're right.
And you still write this after the lesson?
> +test_expect_success 'branch pointing to non-commit' '
> + git rev-parse HEAD^{tree} > .git/refs/heads/invalid &&
> + git fsck 2>&1 | tee out &&
> + grep "not a commit" out
> +'
> +git update-ref -d refs/heads/invalid
> +
> +cat > invalid-tag <<EOF
> +object ffffffffffffffffffffffffffffffffffffffff
> +type commit
> +tag invalid
> +tagger T A Gger <tagger@example.com> 1234567890 -0000
> +
> +This is an invalid tag.
> +EOF
Technically speaking, the tag is perfectly valid. It just points to a
commit you do not have.
> +cat > wrong-tag <<EOF
> +object $(echo blob | git hash-object -w --stdin)
> +type commit
> +tag wrong
> +tagger T A Gger <tagger@example.com> 1234567890 -0000
> +
> +This is an invalid tag.
> +EOF
This is indeed invalid.
> +test_expect_success 'tag pointing to something else than its type' '
> + tag=$(git hash-object -t tag -w --stdin < wrong-tag) &&
> + echo $tag > .git/refs/tags/wrong &&
> + test_must_fail git fsck >out 2>&1 &&
> + grep "Object.*is a blob, not a commit" out
> +'
> +
> +rm .git/refs/tags/wrong
I'd rather want to see test_expect_success around this "rm", and replace
that rm with something more git-ish, like "tag -d" or "update-ref -d".
By the way, is it just me or would we want to reword the subject of the
commit to tame it a little bit?
^ permalink raw reply
* git-add and index
From: bill lam @ 2009-03-03 7:20 UTC (permalink / raw)
To: git
I have 2 questions related to index
1. Is it safe to just git-add (without commit) for local changes made
before checkout or switch to another branch?
2. How to checkout the changes as recorded in index from git-add that
not yet commit to the working tree?
Thanks!
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩179 王維 奉和聖製從蓬萊向興慶閣道中留春雨中春望之作應制
渭水自縈秦塞曲 黃山舊遶漢宮斜 鑾輿迥出千門柳 閣道迴看上苑花
雲裡帝城雙鳳闕 雨中春樹萬人家 為乘陽氣行時令 不是宸遊玩物華
^ permalink raw reply
* Re: [PATCH] send-email: respect in-reply-to regardless of threading
From: Junio C Hamano @ 2009-03-03 7:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <74fdbb84d14a6d39f1b61e18ab9588ca08926292.1235947339.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> git-send-email supports the --in-reply-to option even with
> --no-thread. However, the code that adds the relevant mail headers
> was guarded by a test for --thread.
>
> Remove the test, so that the user's choice is respected.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Thomas Rast wrote:
>> But it also turns out, as you can see, that git-send-email happily
>> ignores --in-reply-to if threading is disabled. :-(
>
> This is the minimally intrusive fix. It would be more consistent to
> ask for the in-reply-to regardless of thread setting, but it would
> also be less of a fix and more of a behaviour change.
I agree. Tests?
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Jeff King, git
In-Reply-To: <7vwsb7gkvt.fsf_-_@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 1:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> + if (mkdir(dir, 0777)) {
> + error("cannot mkdir '%s': %s", dir, strerror(errno));
> + return NULL;
> + }
How about "cannot create repository; mkdir failed '%s': %s" ...
j.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jeff King @ 2009-03-03 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vwsb7gkvt.fsf_-_@gitster.siamese.dyndns.org>
On Mon, Mar 02, 2009 at 10:50:46PM -0800, Junio C Hamano wrote:
> I am not at all convinced that the use case people would for whatever
> reason do not want to "ssh-in, create and then push from here" is limited
> to "your own playpen in your $HOME", but it certainly limits the
> complexity and the scope of the damage.
If you are going to limit it in that way, wouldn't it be better to do it
entirely client-side? As in, "git push --create remote" will literally
do:
ssh remote_host "mkdir -p remote_dir && cd remote_dir && git init --bare"
? Then you don't have to care about whether the remote side is recent
enough to support this, and there are no potential security issues; git
is merely saving you from typing the commands you could have done
yourself.
> +test_expect_success 'push into nonexisting repository' '
> + this=$(git rev-parse B) &&
> + git push "file://$(pwd)/not-here.git" B:refs/heads/master &&
> + that=$(GIT_DIR=not-here.git git rev-parse HEAD) &&
> + test "$this" = "$that"
> +'
I think a feature like this needs to be triggered manually via
"--create" or similar. Otherwise a typo on a regular push will be very
confusing as your pushes appear to go nowhere. Though I suppose most
regular pushes happen using a configured remote, in which case it is not
as much of an issue.
-Peff
^ permalink raw reply
* Re: [PATCH] clone: run post-checkout hook when checking out
From: Jeff King @ 2009-03-03 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: layer, git
In-Reply-To: <7vsklvhzpm.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 02, 2009 at 10:45:09PM -0800, Junio C Hamano wrote:
> > Junio, I'm not sure what you want to do with this. It is definitely a
> > behavior change; we have never respected post-checkout hooks in shell
> > git-clone.sh or in the builtin version. However, it seems like an
> > omission rather than an intentional behavior, so I consider this a
> > bugfix.
>
> I do not mind queueing this to 'pu' and let people fight it out. I hate
> the local side hooks that have no reason to be there, and consider that
> the existence of the "checkout hook" to be a bug to begin with, but I
> really don't care that deeply anymore.
That sounds fine to me. I don't personally care either way (I didn't
even know we had a post-checkout hook until today).
-Peff
^ permalink raw reply
* Re: [PATCH] clone: run post-checkout hook when checking out
From: Jay Soffian @ 2009-03-03 6:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, layer, git
In-Reply-To: <7vsklvhzpm.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 1:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I do not mind queueing this to 'pu' and let people fight it out. I hate
> the local side hooks that have no reason to be there, and consider that
> the existence of the "checkout hook" to be a bug to begin with
I just want to clarify: do you mean to say that none of the local side
hooks have any reason to be there, or that some of the local hooks do
not belong, and checkout is one of those?
j.
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Junio C Hamano @ 2009-03-03 6:53 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Nanako Shiraishi, Paul Gortmaker
In-Reply-To: <1236055938-65407-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> There is a slight fib in message informing the user of the
> sendemail.confirm setting and this is intentional. Setting 'auto'
> differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
> obviously squelches the informational message; 2) 'auto' prompts when
> the Cc list has been expanded even in the presence of a --suppress
> related option, where leaving sendemail.confirm unset does not. This is
> intentional to keep the message simple, and to avoid adding another
> sendemail.confirm value ('auto-except-suppress'?).
I suspect you may get bug reports and refinement patches on top of this to
fix the last issue up, but I think that better should happen once the base
patch is in-tree.
Let's queue this to 'pu' and see how people react.
Thanks.
^ permalink raw reply
* Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 6:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20090301170436.GA14365@spearce.org>
This teaches receive-pack to create a new directory as a bare repository
when a user tries to push into a directory that does not exist.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
"Shawn O. Pearce" <spearce@spearce.org> writes:
> But I think that's only true for situations where you are likely the
> owner of the repository in your own home directory, such as ~you
> on kernel.org. For "hosted repositories" like any of the systems
> you described above, there is a lot more to the creation than just
> executing "git init" somewhere.
> .
> For the usage of
> creating a new repository in your own home directory on some remote
> server, why isn't this just an option to git push?
I am not at all convinced that the use case people would for whatever
reason do not want to "ssh-in, create and then push from here" is limited
to "your own playpen in your $HOME", but it certainly limits the
complexity and the scope of the damage.
builtin-receive-pack.c | 29 ++++++++++++++++++++++++++++-
t/t5541-push-create.sh | 20 ++++++++++++++++++++
2 files changed, 48 insertions(+), 1 deletions(-)
create mode 100755 t/t5541-push-create.sh
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index 849f1fe..2f2831c 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -652,6 +652,33 @@ static void add_alternate_refs(void)
foreach_alt_odb(add_refs_from_alternate, NULL);
}
+static char *create_new_repo(char *dir)
+{
+ struct child_process child;
+ const char *argv[20];
+ int argc;
+
+ if (mkdir(dir, 0777)) {
+ error("cannot mkdir '%s': %s", dir, strerror(errno));
+ return NULL;
+ }
+ argc = 0;
+ argv[argc++] = "init";
+ argv[argc++] = "--bare";
+ argv[argc++] = NULL;
+ child.argv = argv;
+ if (run_command_v_opt_cd_env(argv,
+ RUN_COMMAND_NO_STDIN |
+ RUN_COMMAND_STDOUT_TO_STDERR |
+ RUN_GIT_CMD,
+ dir,
+ NULL)) {
+ error("cannot run git init");
+ return NULL;
+ }
+ return enter_repo(dir, 0);
+}
+
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int i;
@@ -674,7 +701,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
setup_path();
- if (!enter_repo(dir, 0))
+ if (!enter_repo(dir, 0) && !create_new_repo(dir))
die("'%s': unable to chdir or not a git archive", dir);
if (is_repository_shallow())
diff --git a/t/t5541-push-create.sh b/t/t5541-push-create.sh
new file mode 100755
index 0000000..52558a5
--- /dev/null
+++ b/t/t5541-push-create.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+test_description='push into nonexisting repository'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit A &&
+ test_commit B &&
+ test_commit C
+'
+
+test_expect_success 'push into nonexisting repository' '
+ this=$(git rev-parse B) &&
+ git push "file://$(pwd)/not-here.git" B:refs/heads/master &&
+ that=$(GIT_DIR=not-here.git git rev-parse HEAD) &&
+ test "$this" = "$that"
+'
+
+test_done
--
1.6.2.rc2.123.gab4478
^ permalink raw reply related
* Re: [PATCH] clone: run post-checkout hook when checking out
From: Junio C Hamano @ 2009-03-03 6:45 UTC (permalink / raw)
To: Jeff King; +Cc: layer, git
In-Reply-To: <20090303053750.GA30201@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Junio, I'm not sure what you want to do with this. It is definitely a
> behavior change; we have never respected post-checkout hooks in shell
> git-clone.sh or in the builtin version. However, it seems like an
> omission rather than an intentional behavior, so I consider this a
> bugfix.
I do not mind queueing this to 'pu' and let people fight it out. I hate
the local side hooks that have no reason to be there, and consider that
the existence of the "checkout hook" to be a bug to begin with, but I
really don't care that deeply anymore.
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-03 5:51 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Sixt, git
In-Reply-To: <200903022221.10254.robin.rosenberg.lists@dewire.com>
Robin Rosenberg:
> Not sure what that is.
"Invariant" is defined in an old RFC as the common subset of several
ASCII-like and ASCII-based encodings. This was back before the MIME days,
IIANM.
> I mean that in a local nordic, setting people can use
> iso-8859-1|15/windows-1252/UTF-8 for their needs be means of converting
> the characters as-needed without loss, with very few practial
> restrictions.
Indeed. The trick is to have the storage (in this case, Git and it's tree
objects) storing the file name data in a commonly agreed-upon way. Then it
is simple to convert at the end-points.
> Just because I use UTF-8 doesn't mean I use start using more characters in
> practice.
Most people do not, no. But using a Unicode encoding means that they at
least have the option. Sometimes, having to mangle stuff down to ASCII is a
pain.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: fatal: git write-tree failed to write a tree
From: Caleb Cushing @ 2009-03-03 5:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903012210230.10279@pacific.mpi-cbg.de>
On Sun, Mar 1, 2009 at 4:10 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> A tree cannot contain unmerged files.
so... still looking for a solution since it seems I can no longer do a
merge from this remote. There has to be a way to get the tree back
into a proper state...
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* [PATCH] clone: run post-checkout hook when checking out
From: Jeff King @ 2009-03-03 5:37 UTC (permalink / raw)
To: layer; +Cc: git, Junio C Hamano
In-Reply-To: <23978.1236056549@relay.known.net>
The mental model for clone is that the branch is "checked
out" (and it even says this in Documentation/git-clone.txt:
"...creates and checks out an initial branch"). Therefore it
is reasonable for users to expect that any post-checkout
hook would be run.
Signed-off-by: Jeff King <peff@peff.net>
---
On Mon, Mar 02, 2009 at 09:02:29PM -0800, layer wrote:
> The hook in question was in /usr/share/git-core/templates/hooks/, so
> it would get setup on clone. That works fine. If I immediately
> switch branches, the hook gets called. It's just the `post-clone'
> (when I assume something like `checkout' is done), the hook doesn't
> get called.
This should fix it.
Junio, I'm not sure what you want to do with this. It is definitely a
behavior change; we have never respected post-checkout hooks in shell
git-clone.sh or in the builtin version. However, it seems like an
omission rather than an intentional behavior, so I consider this a
bugfix.
builtin-clone.c | 7 ++++++-
t/t5403-post-checkout-hook.sh | 12 ++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 3146ca8..ceffecb 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -21,6 +21,7 @@
#include "pack-refs.h"
#include "sigchain.h"
#include "remote.h"
+#include "run-command.h"
/*
* Overall FIXMEs:
@@ -341,6 +342,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
+ int err = 0;
struct refspec refspec;
@@ -596,6 +598,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (write_cache(fd, active_cache, active_nr) ||
commit_locked_index(lock_file))
die("unable to write new index file");
+
+ err |= run_hook(NULL, "post-checkout", sha1_to_hex(null_sha1),
+ sha1_to_hex(remote_head->old_sha1), "1", NULL);
}
strbuf_release(&reflog_msg);
@@ -603,5 +608,5 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
strbuf_release(&key);
strbuf_release(&value);
junk_pid = 0;
- return 0;
+ return err;
}
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 9b2e1a9..4fdb418 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -71,4 +71,16 @@ test_expect_success 'post-checkout receives the right args when not switching br
test $old = $new -a $flag = 0
'
+mkdir -p templates/hooks
+cat >templates/hooks/post-checkout <<'EOF'
+#!/bin/sh
+echo $@ > $GIT_DIR/post-checkout.args
+EOF
+chmod +x templates/hooks/post-checkout
+
+test_expect_success 'post-checkout hook is triggered by clone' '
+ git clone --template=templates . clone3 &&
+ test -f clone3/.git/post-checkout.args
+'
+
test_done
--
1.6.2.rc2.313.gce9b3.dirty
^ permalink raw reply related
* Re: post-checkout hook not run on clone
From: Jeff King @ 2009-03-03 5:10 UTC (permalink / raw)
To: layer; +Cc: git
In-Reply-To: <23978.1236056549@relay.known.net>
On Mon, Mar 02, 2009 at 09:02:29PM -0800, layer wrote:
> The hook in question was in /usr/share/git-core/templates/hooks/, so
> it would get setup on clone. That works fine. If I immediately
> switch branches, the hook gets called. It's just the `post-clone'
> (when I assume something like `checkout' is done), the hook doesn't
> get called.
Ah, OK. I misunderstood. Then that is a bug, IMHO. Patch in a minute.
-Peff
^ permalink raw reply
* Re: post-checkout hook not run on clone
From: Shawn O. Pearce @ 2009-03-03 5:04 UTC (permalink / raw)
To: Jeff King; +Cc: layer, git
In-Reply-To: <20090303042848.GC18136@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Mar 02, 2009 at 02:43:37PM -0800, layer wrote:
>
> > I realize this might be a feature, but when I switch to the master
> > branch with "git checkout master" it is, and I would think that a
> > clone that gets the master branch would also does a sort of "checkout
> > master" and would run the hook.
>
> Right. Hooks are not cloned with the repo.
I think the original poster was talking about a hook installed via
their template directory. In which case the hook is trusted, and is
coming from a known source, its just not being called during clone.
--
Shawn.
^ permalink raw reply
* Re: post-checkout hook not run on clone
From: layer @ 2009-03-03 5:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090303042848.GC18136@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
>> On Mon, Mar 02, 2009 at 02:43:37PM -0800, layer wrote:
>>
>> > I realize this might be a feature, but when I switch to the master
>> > branch with "git checkout master" it is, and I would think that a
>> > clone that gets the master branch would also does a sort of "checkout
>> > master" and would run the hook.
>>
>> Right. Hooks are not cloned with the repo.
The hook in question was in /usr/share/git-core/templates/hooks/, so
it would get setup on clone. That works fine. If I immediately
switch branches, the hook gets called. It's just the `post-clone'
(when I assume something like `checkout' is done), the hook doesn't
get called.
>> The general wisdom on the list is that it's a bad idea to run remote
>> code arbitrarily for security reasons...
I agree, but not in this specific situation. All the users of the
code are trusted, as is the author of the hooks.
^ permalink raw reply
* Re: proper way to merge?
From: John Tapsell @ 2009-03-03 5:01 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F07432@EXCHANGE.trad.tradestation.com>
2009/3/2 John Dlugosz <JDlugosz@tradestation.com>:
> ===Re:===
> Instead of merge, I prefer to rebase. so:
>
> git checkout dev
> git rebase origin rel
>
> This replays each commit made in 'dev' on top of release, letting you
> fix each commit separately. It also means that when I commit to
> release, the changes are a nice tree.
> ===end===
>
> The reason I'm doing this -- why I took over maintenance of the repository -- is because I strenuously objected to his plan to "rebase". NO! Merge, don't rebase. Besides never rebasing published branches, in this case it works much better the other way around: dev made systemic changes, and rel is mostly patches and completely new pieces of code. After looking at what was in dev..rel and what was in rel..dev, I chose to start with dev and bring in the commits from rel in a controlled manner.
It depends on what you're doing :-) I find that if the branch is too
large to easily rebase, then it's probably too large entirely :)
Developers don't like master to change in large ways suddenly - makes
it hard for all the other branches.
It also makes it impossible to bisect, something that I find
essential. If you are combining two trees which are too big to easily
rebase, then there's a high chance that something will break either
due to their individual changes or because of a mistake while merging.
In such a case, it's then impossible to bisect to try to pinpoint the
actual problem.
It will be interesting to hear your view on merging vs rebasing after
a year or so of trying both.
John
^ permalink raw reply
* [PATCH v3] send-email: add --confirm option and configuration setting
From: Jay Soffian @ 2009-03-03 4:52 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Nanako Shiraishi, Junio C Hamano, Paul Gortmaker
In-Reply-To: <7v1vtfjpad.fsf@gitster.siamese.dyndns.org>
send-email violates the principle of least surprise by automatically
cc'ing additional recipients without confirming this with the user.
This patch teaches send-email a --confirm option. It takes the
following values:
--confirm=always always confirm before sending
--confirm=never never confirm before sending
--confirm=cc confirm before sending when send-email has
automatically added addresses from the patch to
the Cc list
--confirm=compose confirm before sending the first message when
using --compose. (Needed to maintain backwards
compatibility with existing behavior.)
--confirm=auto 'cc' + 'compose'
If sendemail.confirm is unconfigured, the option defaults to 'compose'
if any suppress-Cc related options have been used, otherwise it defaults
to 'auto'.
Unfortunately, it is impossible to introduce this patch such that it
helps new users without potentially annoying some existing users. We
attempt to mitigate the latter by:
* Allowing the user to set 'git config sendemail.confirm never'
* Allowing the user to say 'all' after the first prompt to not be
prompted on remaining emails during the same invocation.
* Telling the user about the 'sendemail.confirm' setting if it is
unconfigured whenever we prompt due to Cc before sending.
* Only prompting if no --suppress related options have been passed, as
using such an option is likely to indicate an experienced send-email
user.
There is a slight fib in message informing the user of the
sendemail.confirm setting and this is intentional. Setting 'auto'
differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
obviously squelches the informational message; 2) 'auto' prompts when
the Cc list has been expanded even in the presence of a --suppress
related option, where leaving sendemail.confirm unset does not. This is
intentional to keep the message simple, and to avoid adding another
sendemail.confirm value ('auto-except-suppress'?).
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Differences from v2:
* Inform user of sendemail.confirm if it is unconfigured and we are
in a prompting situation where the Cc list has been expanded, per
Junio's suggestion. This is instead of informing everytime "all"
is used.
* Fixed typo in commit message
* Documented sendemail.confirm configuration setting.
Documentation/git-send-email.txt | 21 +++++++
git-send-email.perl | 84 +++++++++++++++++++++--------
t/t9001-send-email.sh | 108 ++++++++++++++++++++++++++++++++------
3 files changed, 174 insertions(+), 39 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 164d149..0335727 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -199,6 +199,22 @@ specified, as well as 'body' if --no-signed-off-cc is specified.
Administering
~~~~~~~~~~~~~
+--confirm::
+ Confirm just before sending:
++
+--
+- 'always' will always confirm before sending
+- 'never' will never confirm before sending
+- 'cc' will confirm before sending when send-email has automatically
+ added addresses from the patch to the Cc list
+- 'compose' will confirm before sending the first message when using --compose.
+- 'auto' is equivalent to 'cc' + 'compose'
+--
++
+Default is the value of 'sendemail.confirm' configuration value; if that
+is unspecified, default to 'auto' unless any of the suppress options
+have been specified, in which case default to 'compose'.
+
--dry-run::
Do everything except actually send the emails.
@@ -242,6 +258,11 @@ sendemail.multiedit::
summary when '--compose' is used). If false, files will be edited one
after the other, spawning a new editor each time.
+sendemail.confirm::
+ Sets the default for whether to confirm before sending. Must be
+ one of 'always', 'never', 'cc', 'compose', or 'auto'. See '--confirm'
+ in the previous section for the meaning of these values.
+
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index adf7ecb..57127aa 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -75,6 +75,8 @@ git send-email [options] <file | directory | rev-list options >
--[no-]thread * Use In-Reply-To: field. Default on.
Administering:
+ --confirm <str> * Confirm recipients before sending;
+ auto, cc, compose, always, or never.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
--[no-]validate * Perform patch sanity checks. Default on.
@@ -181,7 +183,7 @@ sub do_edit {
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($validate);
+my ($validate, $confirm);
my (@suppress_cc);
my %config_bool_settings = (
@@ -207,6 +209,7 @@ my %config_settings = (
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
"multiedit" => \$multiedit,
+ "confirm" => \$confirm,
);
# Handle Uncouth Termination
@@ -258,6 +261,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
+ "confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -346,6 +350,14 @@ if ($suppress_cc{'body'}) {
delete $suppress_cc{'body'};
}
+# Set confirm's default value
+my $confirm_unconfigured = !defined $confirm;
+if ($confirm_unconfigured) {
+ $confirm = scalar %suppress_cc ? 'compose' : 'auto';
+};
+die "Unknown --confirm setting: '$confirm'\n"
+ unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
+
# Debugging, print out the suppressions.
if (0) {
print "suppressions:\n";
@@ -663,25 +675,13 @@ if (!defined $smtp_server) {
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
-if ($compose) {
- while (1) {
- $_ = $term->readline("Send this email? (y|n) ");
- last if defined $_;
- print "\n";
- }
-
- if (uc substr($_,0,1) ne 'Y') {
- cleanup_compose_files();
- exit(0);
- }
-
- if ($compose > 0) {
- @files = ($compose_filename . ".final", @files);
- }
+if ($compose && $compose > 0) {
+ @files = ($compose_filename . ".final", @files);
}
# Variables we set as part of the loop over files
-our ($message_id, %mail, $subject, $reply_to, $references, $message);
+our ($message_id, %mail, $subject, $reply_to, $references, $message,
+ $needs_confirm, $message_num);
sub extract_valid_address {
my $address = shift;
@@ -837,6 +837,37 @@ X-Mailer: git-send-email $gitversion
unshift (@sendmail_parameters,
'-f', $raw_from) if(defined $envelope_sender);
+ if ($needs_confirm && !$dry_run) {
+ print "\n$header\n";
+ if ($needs_confirm eq "inform") {
+ $confirm_unconfigured = 0; # squelch this message for the rest of this run
+ print " The Cc list above has been expanded by additional\n";
+ print " addresses found in the patch commit message. By default\n";
+ print " send-email prompts before sending whenever this occurs.\n";
+ print " This behavior is controlled by the sendemail.confirm\n";
+ print " configuration setting.\n";
+ print "\n";
+ print " For additional information, run 'git send-email --help'.\n";
+ print " To retain the current behavior, but squelch this message,\n";
+ print " run 'git config --global sendemail.confirm auto'.\n\n";
+ }
+ while (1) {
+ chomp ($_ = $term->readline(
+ "Send this email? ([y]es|[n]o|[q]uit|[a]ll): "
+ ));
+ last if /^(?:yes|y|no|n|quit|q|all|a)/i;
+ print "\n";
+ }
+ if (/^n/i) {
+ return;
+ } elsif (/^q/i) {
+ cleanup_compose_files();
+ exit(0);
+ } elsif (/^a/i) {
+ $confirm = 'never';
+ }
+ }
+
if ($dry_run) {
# We don't want to send the email.
} elsif ($smtp_server =~ m#^/#) {
@@ -935,6 +966,7 @@ X-Mailer: git-send-email $gitversion
$reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
$subject = $initial_subject;
+$message_num = 0;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
@@ -943,11 +975,12 @@ foreach my $t (@files) {
my $author_encoding;
my $has_content_type;
my $body_encoding;
- @cc = @initial_cc;
+ @cc = ();
@xh = ();
my $input_format = undef;
my @header = ();
$message = "";
+ $message_num++;
# First unfold multiline header fields
while(<F>) {
last if /^\s*$/;
@@ -1080,6 +1113,14 @@ foreach my $t (@files) {
}
}
+ $needs_confirm = (
+ $confirm eq "always" or
+ ($confirm =~ /^(?:auto|cc)$/ && @cc) or
+ ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
+ $needs_confirm = "inform" if ($needs_confirm && $confirm_unconfigured && @cc);
+
+ @cc = (@initial_cc, @cc);
+
send_message();
# set up for the next message
@@ -1094,13 +1135,10 @@ foreach my $t (@files) {
$message_id = undef;
}
-if ($compose) {
- cleanup_compose_files();
-}
+cleanup_compose_files();
sub cleanup_compose_files() {
- unlink($compose_filename, $compose_filename . ".final");
-
+ unlink($compose_filename, $compose_filename . ".final") if $compose;
}
$smtp->quit if $smtp;
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 4df4f96..08d5b91 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -35,6 +35,47 @@ test_expect_success 'Extract patches' '
patches=`git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1`
'
+# Test no confirm early to ensure remaining tests will not hang
+test_no_confirm () {
+ rm -f no_confirm_okay
+ echo n | \
+ GIT_SEND_EMAIL_NOTTY=1 \
+ git send-email \
+ --from="Example <from@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $@ \
+ $patches > stdout &&
+ test_must_fail grep "Send this email" stdout &&
+ > no_confirm_okay
+}
+
+# Exit immediately to prevent hang if a no-confirm test fails
+check_no_confirm () {
+ test -f no_confirm_okay || {
+ say 'No confirm test failed; skipping remaining tests to prevent hanging'
+ test_done
+ }
+}
+
+test_expect_success 'No confirm with --suppress-cc' '
+ test_no_confirm --suppress-cc=sob
+'
+check_no_confirm
+
+test_expect_success 'No confirm with --confirm=never' '
+ test_no_confirm --confirm=never
+'
+check_no_confirm
+
+# leave sendemail.confirm set to never after this so that none of the
+# remaining tests prompt unintentionally.
+test_expect_success 'No confirm with sendemail.confirm=never' '
+ git config sendemail.confirm never &&
+ test_no_confirm --compose --subject=foo
+'
+check_no_confirm
+
test_expect_success 'Send patches' '
git send-email --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
@@ -175,15 +216,13 @@ test_set_editor "$(pwd)/fake-editor"
test_expect_success '--compose works' '
clean_fake_sendmail &&
- echo y | \
- GIT_SEND_EMAIL_NOTTY=1 \
- git send-email \
- --compose --subject foo \
- --from="Example <nobody@example.com>" \
- --to=nobody@example.com \
- --smtp-server="$(pwd)/fake.sendmail" \
- $patches \
- 2>errors
+ git send-email \
+ --compose --subject foo \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches \
+ 2>errors
'
test_expect_success 'first message is compose text' '
@@ -375,15 +414,56 @@ test_expect_success '--suppress-cc=cc' '
test_suppression cc
'
+test_confirm () {
+ echo y | \
+ GIT_SEND_EMAIL_NOTTY=1 \
+ git send-email \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $@ \
+ $patches | grep "Send this email"
+}
+
+test_expect_success '--confirm=always' '
+ test_confirm --confirm=always --suppress-cc=all
+'
+
+test_expect_success '--confirm=auto' '
+ test_confirm --confirm=auto
+'
+
+test_expect_success '--confirm=cc' '
+ test_confirm --confirm=cc
+'
+
+test_expect_success '--confirm=compose' '
+ test_confirm --confirm=compose --compose
+'
+
+test_expect_success 'confirm by default (due to cc)' '
+ CONFIRM=$(git config --get sendemail.confirm) &&
+ git config --unset sendemail.confirm &&
+ test_confirm &&
+ git config sendemail.confirm $CONFIRM
+'
+
+test_expect_success 'confirm by default (due to --compose)' '
+ CONFIRM=$(git config --get sendemail.confirm) &&
+ git config --unset sendemail.confirm &&
+ test_confirm --suppress-cc=all --compose
+ ret="$?"
+ git config sendemail.confirm ${CONFIRM:-never}
+ test $ret = "0"
+'
+
test_expect_success '--compose adds MIME for utf8 body' '
clean_fake_sendmail &&
(echo "#!$SHELL_PATH" &&
echo "echo utf8 body: àéìöú >>\"\$1\""
) >fake-editor-utf8 &&
chmod +x fake-editor-utf8 &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
@@ -405,9 +485,7 @@ test_expect_success '--compose respects user mime type' '
echo " echo utf8 body: àéìöú) >\"\$1\""
) >fake-editor-utf8-mime &&
chmod +x fake-editor-utf8-mime &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor-utf8-mime\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
@@ -421,9 +499,7 @@ test_expect_success '--compose respects user mime type' '
test_expect_success '--compose adds MIME for utf8 subject' '
clean_fake_sendmail &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject utf8-sübjëct \
--from="Example <nobody@example.com>" \
@@ -445,7 +521,7 @@ test_expect_success 'detects ambiguous reference/file conflict' '
test_expect_success 'feed two files' '
rm -fr outdir &&
git format-patch -2 -o outdir &&
- GIT_SEND_EMAIL_NOTTY=1 git send-email \
+ git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--
1.6.2.rc1.309.g5f417
^ permalink raw reply related
* Re: post-checkout hook not run on clone
From: Jeff King @ 2009-03-03 4:28 UTC (permalink / raw)
To: layer; +Cc: git
In-Reply-To: <20273.1236033817@relay.known.net>
On Mon, Mar 02, 2009 at 02:43:37PM -0800, layer wrote:
> I realize this might be a feature, but when I switch to the master
> branch with "git checkout master" it is, and I would think that a
> clone that gets the master branch would also does a sort of "checkout
> master" and would run the hook.
Right. Hooks are not cloned with the repo.
> In any case, I'd be happy of there was a post-clone hook, instead, but
> there isn't.
The general wisdom on the list is that it's a bad idea to run remote
code arbitrarily for security reasons (i.e., "git clone
git://host/foo.git" should not automatically run code from "host"). Even
if you are going to build and run the contents of "foo.git", you at
least have a chance to inspect the changes via git.
However, for situations where you are OK implicitly trusting the remote,
it is obviously less convenient.
> Any suggestions?
Most suggestions I have seen involve shipping the hooks in your repo,
and then having users copy them to their .git/hooks directory (and you
can even provide a script for that).
Unfortunately, there is a chicken-and-egg problem there with the initial
checkout. You could do something like (assuming the hooks are in "hooks"
in the repo) to bootstrap:
git clone -n <repo.git>
cd repo
git archive --format tar HEAD hooks | tar -C .git/hooks -xf -
git checkout master
-Peff
^ permalink raw reply
* Re: remote branches, and branch names in general
From: Jeff King @ 2009-03-03 4:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: John Dlugosz, git
In-Reply-To: <m3vdqrtp84.fsf@localhost.localdomain>
On Mon, Mar 02, 2009 at 04:38:42PM -0800, Jakub Narebski wrote:
> > I see the remote branches with names of the form remotes/pub/name where
> > pub is the nickname of the place I pull from. To specify such branches,
> > must I always spell it out with the leading "remotes/", or can that be
> > shorted or implied somehow?
>
> You usually can omit "remotes/" prefix, and just use
> "<remote>/<branch>" (or even "<remote>" for "<remote>/HEAD"). You need
> it only if there is need for disambiguation.
Yes. I don't know if they are documented anywhere, but the complete
lookup order is:
$ git grep -h -A8 ref_rev_parse_rules refs.c
const char *ref_rev_parse_rules[] = {
"%.*s",
"refs/%.*s",
"refs/tags/%.*s",
"refs/heads/%.*s",
"refs/remotes/%.*s",
"refs/remotes/%.*s/HEAD",
NULL
};
-Peff
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: Jeff King @ 2009-03-03 4:13 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <0d8965bb-e2ed-4f49-b323-c110f605ae2c@33g2000yqm.googlegroups.com>
On Mon, Mar 02, 2009 at 12:30:58PM -0800, davetron5000 wrote:
> So, is there a way I can move a file between two git repositories,
> maintaining the change history? I guess it would be something like
> "apply all patches that this file was involved in, but ONLY apply the
> ones affecting this file, to the new repo, then delete from the old"?
Yes, that's more or less how you would do it. There are actually two
separate issues, and each has two possible solutions.
Issue 1 is moving the history to the new repo.
One solution is, as you guessed, to export as patches and import into
the new repo:
cd /path/to/app
git format-patch --stdout --root -- <path> >~/patches
cd /path/to/core
git am ~/patches
where <path> can be a file, directory, or a list of either or both.
This should work fine if the history of that path is linear, since a
list of patches is, by definition, linear. You can see the "shape" of
the history with:
cd /path/to/app
gitk -- <path>
The other solution is to actually rewrite a version of git history that
sees only those paths, then merge it in. That will retain the actual
shape of the history. You can do this using "git filter-branch":
cd /path/to/app
# we do our work on a temporary branch
git branch just-path
# the actual filter; note you could do more than just grep here
# if you wanted to munge the pathnames
git filter-branch --index-filter '
git ls-files -s | grep path |
GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
' --prune-empty just-path
# you can inspect just-path at this point with "gitk just-path"
cd /path/to/core
# and then pull it into core's history
git pull /path/to/app just-path
The second issue is what you want to have happen in the "app"
repository. Presumably you no longer want the moved files there. You
_could_ filter-branch to pretend as if they were always in "core" and
never in "app". But that is probably not a good idea because:
1. You are rewriting history, which will make merging more complex for
your users.
2. You may be breaking historical builds which expect the files to be
there in the past.
So I think you're probably best to just remove them with a new commit
and have the duplicated history in both.
-Peff
PS I think you might be able to replace the filter-branch invocation
with a fast-export / fast-import pipeline, but I haven't tried.
^ 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