* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 17:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <491B131D.2050501@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
[...]
> Bisecting gives:
>
>
> 5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
> commit 5521883490e85f4d973141972cf16f89a79f1979
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Sun Sep 7 19:49:25 2008 -0700
>
> checkout: do not lose staged removal
I got the same, which is reassuring.
Looks like a deliberate change with (what seems to me to be) an
unfortunate interaction with "git clone -n"
^ permalink raw reply
* Re: [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 17:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Adam, git, Andy Parkins, Junio C Hamano
In-Reply-To: <491B0D9B.7080306@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
Johannes Sixt wrote:
> Michael Adam schrieb:
> > This changes the behaviour of post-receive-email when a list of recipients
> > (separated by commas) is specified as hooks.mailinglist. With this modification,
> > an individual mail is sent out for each recipient entry in the list, instead
> > of sending a single mail with all the recipients in the "To: " field.
>
> I don't think this is well-behaved:
>
> - The load multiplies for the sender (typically a repository server).
This is right.
> - And wouldn't each recipient get a new Message-Id? This would break
> threading if further communication takes place among the recipients.
My idea was that different recipients have different threading anyways.
OK, threading for multiple recipients can be conserved with group replies.
I thought that usually you specify a single mailing list as recipient.
My use case is that I have additional recipients that do not necessarily
want to be seen as recipients on the mailing list that is specified as
the primary recipient.
> But I may be wrong on both accounts.
Your concerns are surely valid.
Maybe it would be useful to make this optional?
Thanks for your comments!
Cheers - Michael
--
Michael Adam <ma@sernet.de> <obnox@samba.org>
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.SerNet.DE, mailto: Info @ SerNet.DE
[-- Attachment #2: Type: application/pgp-signature, Size: 206 bytes --]
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 17:40 UTC (permalink / raw)
To: git
In-Reply-To: <80wsf9ovsp.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
> The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
> later:
>
> git clone -n git git-test
> cd git-test
> git checkout -b work v1.6.0.2
>
> When it breaks, the error is:
>
> error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>
> I'm guessing it's a bug rather than a deliberate change?
According to "git bisect", the commit that caused this is the
following one. Perhaps "git clone -n" doesn't start out with the
index empty in the relevant sense?
commit 5521883490e85f4d973141972cf16f89a79f1979
Author: Junio C Hamano <gitster@pobox.com>
Date: Sun Sep 7 19:49:25 2008 -0700
checkout: do not lose staged removal
The logic to checkout a different commit implements the safety to never
lose user's local changes. For example, switching from a commit to
another commit, when you have changed a path that is different between
them, need to merge your changes to the version from the switched-to
commit, which you may not necessarily be able to resolve easily. By
default, "git checkout" refused to switch branches, to give you a chance
to stash your local changes (or use "-m" to merge, accepting the risks of
getting conflicts).
This safety, however, had one deliberate hole since early June 2005. When
your local change was to remove a path (and optionally to stage that
removal), the command checked out the path from the switched-to commit
nevertheless.
This was to allow an initial checkout to happen smoothly (e.g. an initial
checkout is done by starting with an empty index and switching from the
commit at the HEAD to the same commit). We can tighten the rule slightly
to allow this special case to pass, without losing sight of removal
explicitly done by the user, by noticing if the index is truly empty when
the operation begins.
For historical background, see:
http://thread.gmane.org/gmane.comp.version-control.git/4641/focus=4646
This case is marked as *0* in the message, which both Linus and I said "it
feels somewhat wrong but otherwise we cannot start from an empty index".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: hosting git on a nfs
From: David Brown @ 2008-11-12 17:36 UTC (permalink / raw)
To: Thomas Koch; +Cc: git, dabe
In-Reply-To: <200811121029.34841.thomas@koch.ro>
On Wed, Nov 12, 2008 at 10:29:34AM +0100, Thomas Koch wrote:
>finally I managed to convince a critical mass of developers (our chief
>dev :-) in our company so that we are starting to migrate to GIT.
>
>The final question is, whether GIT will life peacefully on our cluster
>fileservers. The GIT repository dir (/var/cache/git) should be mounted
>via NFS via PAN on top of DRBD (so I was told).
>
>Are there any known problems with this setup? We're asking, because
>there are problems with SVN on such a setup[1].
We had occasionally run into locking problems with 1.5.4.x with
renames between different directories. This should be fixed in
1.6.0.3, but we have since migrated to a server model so I don't have
any way of testing this.
None of these problems ever caused repository corruption, only errors
during fetch/clone that were resolved by repeating the operation.
Using ssh: or git: does seem to be a bit faster than NFS. The
configuration we did find completely unworkable was using git with the
work tree on NFS.
David
^ permalink raw reply
* Re: Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Michael J Gruber @ 2008-11-12 17:32 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git, Junio C Hamano
In-Reply-To: <80wsf9ovsp.fsf@tiny.isode.net>
Bruce Stephens venit, vidit, dixit 12.11.2008 15:36:
> The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
> later:
>
> git clone -n git git-test
> cd git-test
> git checkout -b work v1.6.0.2
>
> When it breaks, the error is:
>
> error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>
> I'm guessing it's a bug rather than a deliberate change?
Bisecting gives:
5521883490e85f4d973141972cf16f89a79f1979 is first bad commit
commit 5521883490e85f4d973141972cf16f89a79f1979
Author: Junio C Hamano <gitster@pobox.com>
Date: Sun Sep 7 19:49:25 2008 -0700
checkout: do not lose staged removal
CCing Junio...
Michael
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-12 17:30 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <20081112080909.GA29176@coredump.intra.peff.net>
Jeff King wrote:
> On Mon, Nov 03, 2008 at 02:37:05PM -0600, Brandon Casey wrote:
>
>> This version replaces the use of 'head -n -1' with a grep, and should work on
>> all platforms.
>
> Hmm. I'm not sure what happened, but the version in 'next' has "head -n
> -1" in it.
Well, there were so many revisions, I probably should have re-rolled the
whole series. I wasn't sure this was going to go in as is, based on the
[Dropped] message in the "What's Cooking" email and Junio's last email about
reconciling --unpacked and --incremental. I have been working through
the --unpacked code path, but I'm not to the point where I can suggest
a change there.
But, I think it's worse than just the wrong t7700.
These two:
packed_git: convert pack_local flag into generic bit mask
packed_git: add new PACK_KEEP flag and haspackkeep() access macro
should have been replaced by:
packed_git: convert pack_local flag into a bitfield and add pack_keep
which uses a struct bitfield rather than a bitmask.
And then this
pack-objects: honor '.keep' files
was replaced by this
pack-objects: new option --honor-pack-keep
repack: don't repack local objects in packs with .keep file
if that's the way we want to go. I'm not partial to the phrase honor-pack-keep,
but I don't think ignore-pack-keep is appropriate, and it's the best I've come
up with.
So,
31d92611e45d1286b805e362dbc451936af24121
7c335327be664751fa4c04e81b2fe3bfedceaada
77b5a5478a77cc04b674891b542db1ba1a1bf4f7
13e7f5d2f1da42619bd545590d0044b30d00ce4b
should be reverted, and replaced by the series to follow.
-brandon
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-12 17:10 UTC (permalink / raw)
To: Jeff King; +Cc: Brandon Casey, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <20081112080909.GA29176@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Nov 03, 2008 at 02:37:05PM -0600, Brandon Casey wrote:
>
>> This version replaces the use of 'head -n -1' with a grep, and should work on
>> all platforms.
>
> Hmm. I'm not sure what happened, but the version in 'next' has "head -n
> -1" in it.
You mean this one?
commit 31d92611e45d1286b805e362dbc451936af24121
Author: Brandon Casey <drafnel@gmail.com>
AuthorDate: Sat Nov 1 22:35:19 2008 -0500
Commit: Junio C Hamano <gitster@pobox.com>
CommitDate: Sun Nov 2 15:58:09 2008 -0800
t7700: demonstrate mishandling of objects in packs with a .keep file
^ permalink raw reply
* [PATCH v2 0/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7viqqtshdd.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 11, 2008 at 08:22:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> The function migrate_file() introduced by [2/4] is called for any
> remote definition that did not come from config (by definition, it
> either came from remotes/foo or branches/foo). The function adds the
> entries for the given remote definition to the config file, and then
> removes remotes/foo file if the remote definition came from it. So it
> is a logically consistent change if you only called this function only
> for remote definitions that came from remotes/foo.
>
> But the function is called for a remote definition that originally
> came from branches/foo as well. It happily adds the definition to the
> config, even though it *fails to remove* branches/foo file.
>
> Do you still think 2/4 is a logically contained good change?
OK, here is an updated series, which is supposed to fix this issue. 1/4
and 4/4 is unchanged.
Miklos Vajna (4):
remote: add a new 'origin' variable to the struct
git-remote rename: support remotes->config migration
git-remote rename: support branches->config migration
git-remote: document the migration feature of the rename subcommand
Documentation/git-remote.txt | 4 ++++
builtin-remote.c | 37 +++++++++++++++++++++++++++++++++++++
remote.c | 3 +++
remote.h | 7 +++++++
t/t5505-remote.sh | 33 +++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 3/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This is similar to the remotes->config one, but it makes the
branches->config conversion possible.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 6 +++++-
t/t5505-remote.sh | 12 ++++++++++++
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 4fa64a2..5b525c7 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -384,6 +384,8 @@ static int migrate_file(struct remote *remote)
remote->fetch_refspec[i], buf.buf);
if (remote->origin == REMOTE_REMOTES)
path = git_path("remotes/%s", remote->name);
+ else if (remote->origin == REMOTE_BRANCHES)
+ path = git_path("branches/%s", remote->name);
if (path && unlink(path))
warning("failed to remove '%s'", path);
return 0;
@@ -411,7 +413,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
- if (!strcmp(rename.old, rename.new) && oldremote->origin == REMOTE_REMOTES)
+ if (!strcmp(rename.old, rename.new) &&
+ (oldremote->origin == REMOTE_REMOTES ||
+ oldremote->origin == REMOTE_BRANCHES))
return migrate_file(oldremote);
newremote = remote_get(rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 1567631..1f59960 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -364,4 +364,16 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
'
+test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' '
+ git clone one six &&
+ origin_url=$(pwd)/one &&
+ (cd six &&
+ git remote rm origin &&
+ echo "$origin_url" > .git/branches/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/branches/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] git-remote rename: support remotes->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This patch makes it possible to migrate a remote stored in a
$GIT_DIR/remotes/nick file to the configuration file format.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 33 +++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 21 +++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 1ca6cdb..4fa64a2 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -359,6 +359,36 @@ static int read_remote_branches(const char *refname,
return 0;
}
+static int migrate_file(struct remote *remote)
+{
+ struct strbuf buf = STRBUF_INIT;
+ int i;
+ char *path = NULL;
+
+ strbuf_addf(&buf, "remote.%s.url", remote->name);
+ for (i = 0; i < remote->url_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->url[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->url[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.push", remote->name);
+ for (i = 0; i < remote->push_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->push_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->push_refspec[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", remote->name);
+ for (i = 0; i < remote->fetch_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->fetch_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->fetch_refspec[i], buf.buf);
+ if (remote->origin == REMOTE_REMOTES)
+ path = git_path("remotes/%s", remote->name);
+ if (path && unlink(path))
+ warning("failed to remove '%s'", path);
+ return 0;
+}
+
static int mv(int argc, const char **argv)
{
struct option options[] = {
@@ -381,6 +411,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
+ if (!strcmp(rename.old, rename.new) && oldremote->origin == REMOTE_REMOTES)
+ return migrate_file(oldremote);
+
newremote = remote_get(rename.new);
if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
die("remote %s already exists.", rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0c956ba..1567631 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -343,4 +343,25 @@ test_expect_success 'rename a remote' '
test "$(git config branch.master.remote)" = "upstream")
'
+
+cat > remotes_origin << EOF
+URL: $(pwd)/one
+Push: refs/heads/master:refs/heads/upstream
+Pull: refs/heads/master:refs/heads/origin
+EOF
+
+test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
+ git clone one five &&
+ origin_url=$(pwd)/one &&
+ (cd five &&
+ git remote rm origin &&
+ mkdir -p .git/remotes &&
+ cat ../remotes_origin > .git/remotes/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/remotes/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.push)" = "refs/heads/master:refs/heads/upstream" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] git-remote: document the migration feature of the rename subcommand
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-remote.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 7b227b3..fad983e 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -66,6 +66,10 @@ was passed.
Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
++
+In case <old> and <new> are the same, and <old> is a file under
+`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+the configuration file format.
'rm'::
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/4] remote: add a new 'origin' variable to the struct
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This allows one to track where was the remote's original source, so that
it's possible to decide if it makes sense to migrate it to the config
format or not.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
remote.c | 3 +++
remote.h | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index e530a21..cbb3e48 100644
--- a/remote.c
+++ b/remote.c
@@ -201,6 +201,7 @@ static void read_remotes_file(struct remote *remote)
if (!f)
return;
+ remote->origin = REMOTE_REMOTES;
while (fgets(buffer, BUF_SIZE, f)) {
int value_list;
char *s, *p;
@@ -261,6 +262,7 @@ static void read_branches_file(struct remote *remote)
s++;
if (!*s)
return;
+ remote->origin = REMOTE_BRANCHES;
p = s + strlen(s);
while (isspace(p[-1]))
*--p = 0;
@@ -350,6 +352,7 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!subkey)
return error("Config with no key for remote %s", name);
remote = make_remote(name, subkey - name);
+ remote->origin = REMOTE_CONFIG;
if (!strcmp(subkey, ".mirror"))
remote->mirror = git_config_bool(key, value);
else if (!strcmp(subkey, ".skipdefaultupdate"))
diff --git a/remote.h b/remote.h
index d2e170c..a46a5be 100644
--- a/remote.h
+++ b/remote.h
@@ -1,8 +1,15 @@
#ifndef REMOTE_H
#define REMOTE_H
+enum {
+ REMOTE_CONFIG,
+ REMOTE_REMOTES,
+ REMOTE_BRANCHES
+};
+
struct remote {
const char *name;
+ int origin;
const char **url;
int url_nr;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Johannes Sixt @ 2008-11-12 17:08 UTC (permalink / raw)
To: Michael Adam; +Cc: git, Andy Parkins, Junio C Hamano
In-Reply-To: <E1L0Iv1-00BwsF-Jh@intern.SerNet.DE>
Michael Adam schrieb:
> This changes the behaviour of post-receive-email when a list of recipients
> (separated by commas) is specified as hooks.mailinglist. With this modification,
> an individual mail is sent out for each recipient entry in the list, instead
> of sending a single mail with all the recipients in the "To: " field.
I don't think this is well-behaved:
- The load multiplies for the sender (typically a repository server).
- And wouldn't each recipient get a new Message-Id? This would break
threading if further communication takes place among the recipients.
But I may be wrong on both accounts.
-- Hannes
^ permalink raw reply
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Alexander Gavrilov @ 2008-11-12 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0811121740120.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 7:42 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 12 Nov 2008, Alexander Gavrilov wrote:
>> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>> >> Commit encoding is set correctly. The problem is that git log and git
>> >> show do not support the *output* encodings UTF-16 and UCS-4 and
>> >> silently fail in that case instead of reporting the error.
>> >
>> > That looks more like an iconv bug to me. I assume you are using Windows?
>>
>> Iconv has no way to know that git cannot work with ASCII-incompatible
>> encodings, and UTF-16 is incompatible, because it fills the output with
>> loads of zero bytes. Git both truncates messages on these bytes, and
>> forgets inserting them in strings that it produces itself.
>
> Ah, I thought that the issue was that Git would not handle commits in that
> encoding correctly. Instead, it appears that Git cannot work with UTF-16
> _displays_.
Actually, I think that using those encodings in commits is asking for
trouble too, because the encoding conversion is, as far as I remember,
applied to the entire contents of the commit object, and Git,
naturally, doesn't insert any null bytes in the commit headers to
please the decoder. The result is a completely trashed object on
output.
Also, I think that they are generally a poor choice of an encoding for
data transmission, because they are ASCII-incompatible,
stdlib-incompatible, unreliable to loss and addition of single bytes,
and have no way to detect encoding mismatch except by metadata or
heuristics: almost any string of shorts is "valid".
Alexander
^ permalink raw reply
* [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 16:50 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
This changes the behaviour of post-receive-email when a list of recipients
(separated by commas) is specified as hooks.mailinglist. With this modification,
an individual mail is sent out for each recipient entry in the list, instead
of sending a single mail with all the recipients in the "To: " field.
Signed-off-by: Michael Adam <obnox@samba.org>
---
Sorry, in the first version of the patch, I forgot to
adapt the generate_email_header() function fill the "To"
field only with "$recipient" instad of "$recipients".
Cheers - Michael
contrib/hooks/post-receive-email | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 28a3c0e..f8bbeab 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -169,21 +169,25 @@ generate_email()
describe=$rev
fi
- generate_email_header
+ # loop over the recipients to send individual mails
+ echo $recipients | sed -e 's/\s*,\s*/\n/' | while read recipient
+ do
+ generate_email_header
- # Call the correct body generation function
- fn_name=general
- case "$refname_type" in
- "tracking branch"|branch)
- fn_name=branch
- ;;
- "annotated tag")
- fn_name=atag
- ;;
- esac
- generate_${change_type}_${fn_name}_email
+ # Call the correct body generation function
+ fn_name=general
+ case "$refname_type" in
+ "tracking branch"|branch)
+ fn_name=branch
+ ;;
+ "annotated tag")
+ fn_name=atag
+ ;;
+ esac
+ generate_${change_type}_${fn_name}_email
- generate_email_footer
+ generate_email_footer
+ done
}
generate_email_header()
@@ -191,7 +195,7 @@ generate_email_header()
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
- To: $recipients
+ To: $recipient
Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
--
1.5.6
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: document individual mails in comments
From: Michael Adam @ 2008-11-12 16:21 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
In-Reply-To: <1226506888-2841305-1-git-send-email-obnox@samba.org>
This documents the new behaviour to send individual mails for the
recipient emails in the "Config" section of the comment header.
Signed-off-by: Michael Adam <obnox@samba.org>
---
contrib/hooks/post-receive-email | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 5deaf28..ecef707 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -27,11 +27,15 @@
# ------
# hooks.mailinglist
# This is the list that all pushes will go to; leave it blank to not send
-# emails for every ref update.
+# emails for every ref update. A list of recipient addresses separated
+# by commas may be specified. Each recipient in the list will receive an
+# individual mail.
# hooks.announcelist
# This is the list that all pushes of annotated tags will go to. Leave it
# blank to default to the mailinglist field. The announce emails lists
# the short log summary of the changes since the last annotated tag.
+# Lists of email addresses are treated the same way as in the mailinglists
+# field.
# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope
# sender address to be set
--
1.5.6
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 16:21 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
This changes the behaviour of post-receive-email when a list of recipients
(separated by commas) is specified as hooks.mailinglist. With this modification,
an individual mail is sent out for each recipient entry in the list, instead
of sending a single mail with all the recipients in the "To: " field.
Signed-off-by: Michael Adam <obnox@samba.org>
---
contrib/hooks/post-receive-email | 30 +++++++++++++++++-------------
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 28a3c0e..5deaf28 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -169,21 +169,25 @@ generate_email()
describe=$rev
fi
- generate_email_header
+ # loop over the recipients to send individual mails
+ echo $recipients | sed -e 's/\s*,\s*/\n/' | while read recipient
+ do
+ generate_email_header
- # Call the correct body generation function
- fn_name=general
- case "$refname_type" in
- "tracking branch"|branch)
- fn_name=branch
- ;;
- "annotated tag")
- fn_name=atag
- ;;
- esac
- generate_${change_type}_${fn_name}_email
+ # Call the correct body generation function
+ fn_name=general
+ case "$refname_type" in
+ "tracking branch"|branch)
+ fn_name=branch
+ ;;
+ "annotated tag")
+ fn_name=atag
+ ;;
+ esac
+ generate_${change_type}_${fn_name}_email
- generate_email_footer
+ generate_email_footer
+ done
}
generate_email_header()
--
1.5.6
^ permalink raw reply related
* [PATCH fixed] git-svn: Update git-svn to use the ability to place temporary files within repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 16:38 UTC (permalink / raw)
To: msysgit, git; +Cc: normalperson
In-Reply-To: <491AE935.4040406@svanfeldt.com>
This fixes git-svn within msys where Perl will provide temporary files with path
such as /tmp while the git suit expects native Windows paths.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
Somehow I managed to screw up the last patch when getting it ready for
submission. This patch is a fixed version that actually works.
git-svn.perl | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ef6d773..23ceaff 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3312,11 +3312,11 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- my $fh = Git::temp_acquire('svn_delta');
+ my $fh = $::_repository->temp_acquire('svn_delta');
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
- my $base = Git::temp_acquire('git_blob');
+ my $base = $::_repository->temp_acquire('git_blob');
if ($fb->{blob}) {
print $base 'link ' if ($fb->{mode_a} == 120000);
my $size = $::_repository->cat_blob($fb->{blob}, $base);
@@ -3357,7 +3357,8 @@ sub close_file {
warn "$path has mode 120000",
" but is not a link\n";
} else {
- my $tmp_fh = Git::temp_acquire('svn_hash');
+ my $tmp_fh = $::_repository->temp_acquire(
+ 'svn_hash');
my $res;
while ($res = sysread($fh, my $str, 1024)) {
my $out = syswrite($tmp_fh, $str, $res);
@@ -3745,7 +3746,7 @@ sub change_file_prop {
sub _chg_file_get_blob ($$$$) {
my ($self, $fbat, $m, $which) = @_;
- my $fh = Git::temp_acquire("git_blob_$which");
+ my $fh = $::_repository->temp_acquire("git_blob_$which");
if ($m->{"mode_$which"} =~ /^120/) {
print $fh 'link ' or croak $!;
$self->change_file_prop($fbat,'svn:special','*');
--
1.6.0.3.1439.gc9385a
^ permalink raw reply related
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 16:42 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Constantine Plotnikov, git
In-Reply-To: <bb6f213e0811120817i20d5c0ajf0c9e289c11387a6@mail.gmail.com>
Hi,
On Wed, 12 Nov 2008, Alexander Gavrilov wrote:
> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > [re Cc:ing the list]
> >
> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >
> >> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >
> >> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >> >
> >> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log,
> >> >> the git completes successfully but commit messages and author
> >> >> information are not shown. I suggest that git should fail with
> >> >> fatal error if such zero producing encoding is used.
> >> >>
> >> >> If the incorrect encoding name is used, the git log does not
> >> >> perform any re-encoding, but just display commits in their native
> >> >> encoding. I suggest that git should fail with fatal error in this
> >> >> case as well.
> >> >
> >> > Have you set the correct encoding with i18n.commitEncoding? If
> >> > not, you should not be surprised: Git's default encoding is UTF-8,
> >> > and that fact is well documented, AFAICT.
> >> >
> >> Commit encoding is set correctly. The problem is that git log and git
> >> show do not support the *output* encodings UTF-16 and UCS-4 and
> >> silently fail in that case instead of reporting the error.
> >
> > That looks more like an iconv bug to me. I assume you are using Windows?
>
> Iconv has no way to know that git cannot work with ASCII-incompatible
> encodings, and UTF-16 is incompatible, because it fills the output with
> loads of zero bytes. Git both truncates messages on these bytes, and
> forgets inserting them in strings that it produces itself.
Ah, I thought that the issue was that Git would not handle commits in that
encoding correctly. Instead, it appears that Git cannot work with UTF-16
_displays_.
Yep, I would have expected that.
Ciao,
Dscho
^ permalink raw reply
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Alexander Gavrilov @ 2008-11-12 16:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0811121714280.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> [re Cc:ing the list]
>
> On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>
>> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>> >
>> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
>> >> git completes successfully but commit messages and author information
>> >> are not shown. I suggest that git should fail with fatal error if such
>> >> zero producing encoding is used.
>> >>
>> >> If the incorrect encoding name is used, the git log does not perform any
>> >> re-encoding, but just display commits in their native encoding. I
>> >> suggest that git should fail with fatal error in this case as well.
>> >
>> > Have you set the correct encoding with i18n.commitEncoding? If not, you
>> > should not be surprised: Git's default encoding is UTF-8, and that fact is
>> > well documented, AFAICT.
>> >
>> Commit encoding is set correctly. The problem is that git log and git
>> show do not support the *output* encodings UTF-16 and UCS-4 and
>> silently fail in that case instead of reporting the error.
>
> That looks more like an iconv bug to me. I assume you are using Windows?
>
Iconv has no way to know that git cannot work with ASCII-incompatible
encodings, and UTF-16 is incompatible, because it fills the output
with loads of zero bytes. Git both truncates messages on these bytes,
and forgets inserting them in strings that it produces itself.
A separate problem is that it allows creating commits with invalid
encoding names, which may be unnoticed for a long time in an
environment with uniform commitencoding settings.
Alexander
^ permalink raw reply
* [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Nicolas Pitre @ 2008-11-12 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Nelson, git
In-Reply-To: <cccedfc60811120712o7fcbf648l9f4b8e6f52e50e39@mail.gmail.com>
First, pack.packSizeLimit and --max-pack-size didn't use the same base
unit which was confusing. They both use MiB now.
Also, if the limit was sufficiently low, having a single object written
could bust the limit (by design), but caused the remaining allowed size
to go negative for subsequent objects, which for an unsigned variable is
a rather huge limit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 12 Nov 2008, Jon Nelson wrote:
> I'm using 1.6.0.4 and I've found some weird behavior with
> pack.packSizeLimit and/or --max-pack-size.
>
> Initially, I thought I could just use pack.packSizeLimit and set it to
> (say) 1 to try to limit the size of individual packfiles to 1MiB or
> less. That does not appear to be working.
>
> In one case I performed the following set of commands:
>
> # set pack.packSizeLimit to 20
> git config --global pack.packSizeLimit 20
>
> # verify that it's 20
> git config --get pack.packSizeLimit # verify it's 20
>
> # run gc --prune
> git gc --prune
>
> # show the packfiles
> # I find a *single* 65MB packfile, not a series
> # of 20MB (or less) packfiles.
> ls -la .git/objects/pack/*.pack
>
> # try repack -ad
> git repack -ad
>
> # I find a *single* 65MB packfile, not a series
> # of 20MB (or less) packfiles.
> ls -la .git/objects/pack/*.pack
>
>
> So it would appear that the pack.packSizeLimit param
> is just being ignored??
>
> Then I tested using --max-pack-size explicitly. This works, to a degree.
>
> git repack -ad --max-pack-size 20
>
> # the following shows *4* pack files none larger
> # than (about) 20MB
> ls -la .git/objects/pack/*.pack
>
> # try again with 3MB. This also works.
> git repack -ad --max-pack-size 3
> find .git/objects/pack -name '*.pack' -size +3M -ls # nothing
>
> # try again with 1MB. This does NOT work.
> git repack -ad --max-pack-size 1
>
> # here, I find a *single* 65MB pack file again:
> find .git/objects/pack -name '*.pack' -size +1M -ls
>
> Am I doing something completely wrong with pack.packSizeLimit?
> What is going on with --max-pack-size in the 1MB case?
Does this fix it for you?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 32dcd64..e7808b8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1036,9 +1036,9 @@ you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
the `{asterisk}.idx` file.
pack.packSizeLimit::
- The default maximum size of a pack. This setting only affects
- packing to a file, i.e. the git:// protocol is unaffected. It
- can be overridden by the `\--max-pack-size` option of
+ The default maximum size of a pack, expressed in MiB. This
+ setting only affects packing to a file, i.e. the git:// protocol is
+ unaffected. It can be overridden by the `\--max-pack-size` option of
linkgit:git-repack[1].
pager.<cmd>::
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 0c4649c..fdee9c6 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -245,8 +245,12 @@ static unsigned long write_object(struct sha1file *f,
type = entry->type;
/* write limit if limited packsize and not first object */
- limit = pack_size_limit && nr_written ?
- pack_size_limit - write_offset : 0;
+ if (!pack_size_limit || !nr_written)
+ limit = 0;
+ else if (pack_size_limit <= write_offset)
+ limit = 1;
+ else
+ limit = pack_size_limit - write_offset;
if (!entry->delta)
usable_delta = 0; /* no delta */
@@ -1844,7 +1848,7 @@ static int git_pack_config(const char *k, const char *v, void *cb)
return 0;
}
if (!strcmp(k, "pack.packsizelimit")) {
- pack_size_limit_cfg = git_config_ulong(k, v);
+ pack_size_limit_cfg = git_config_ulong(k, v) * 1024 * 1024;
return 0;
}
return git_default_config(k, v, cb);
^ permalink raw reply related
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 16:15 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120727j730cb6e3lf4103c200d042fb9@mail.gmail.com>
Hi,
[re Cc:ing the list]
On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >
> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
> >> git completes successfully but commit messages and author information
> >> are not shown. I suggest that git should fail with fatal error if such
> >> zero producing encoding is used.
> >>
> >> If the incorrect encoding name is used, the git log does not perform any
> >> re-encoding, but just display commits in their native encoding. I
> >> suggest that git should fail with fatal error in this case as well.
> >
> > Have you set the correct encoding with i18n.commitEncoding? If not, you
> > should not be surprised: Git's default encoding is UTF-8, and that fact is
> > well documented, AFAICT.
> >
> Commit encoding is set correctly. The problem is that git log and git
> show do not support the *output* encodings UTF-16 and UCS-4 and
> silently fail in that case instead of reporting the error.
That looks more like an iconv bug to me. I assume you are using Windows?
Ciao,
Dscho
^ permalink raw reply
* EGIT branch checkout errors
From: Chris Dumoulin @ 2008-11-12 15:50 UTC (permalink / raw)
To: git
Using EGIT in Eclipse, I'm able to create a new branch, but not able to
checkout a branch. When I try Team->Branch...->Checkout, nothing
happens, so I launched Eclipse from a terminal to see any output it
might be giving. Here's what I got:
java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:415)
at
org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:758)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at
org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:755)
at
org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2487)
at
org.spearce.egit.ui.internal.actions.BranchAction.run(BranchAction.java:53)
at
org.eclipse.team.internal.ui.actions.TeamAction.runWithEvent(TeamAction.java:548)
at
org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:241)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583)
at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
Caused by: java.lang.NullPointerException
at org.spearce.jgit.lib.GitIndex.addEntry(GitIndex.java:746)
at
org.spearce.jgit.lib.WorkDirCheckout.checkoutTwoTrees(WorkDirCheckout.java:146)
at
org.spearce.jgit.lib.WorkDirCheckout.checkout(WorkDirCheckout.java:137)
at
org.spearce.egit.core.op.BranchOperation.checkoutTree(BranchOperation.java:133)
at org.spearce.egit.core.op.BranchOperation.run(BranchOperation.java:69)
at
org.spearce.egit.ui.internal.actions.BranchAction$1.run(BranchAction.java:58)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Any help would be appreciated.
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 15:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Björn Steinbrink, David Symonds,
git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 6:10 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Just in case anybody thought about creating tree objects on the fly and
> use their SHA-1s: that won't fly, as you can have unmerged entries in the
> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
Hmm, I tried it to see, and "git diff --cached branchname" when there
are unmerged entries looks like this (one line):
* Unmerged path /whatever/file
Which is pretty unhelpful anyhow (although I don't know what would be
better). I can think of several ways to produce the same output,
including using a magic SHA-1 that means "unmerged", or using a
different filemode for unmerged files in the tree object, or actually
including all three versions of the file in the tree object, each with
a different mode. I admit that sounds pretty gross, though.
> Maybe we could play tricks with a special staged_commit (pretending to be
> a commit with SHA-1 000000... so that git log STAGED.. would do the same
> as plain git log, the rationale being that STAGED is no commit, so ^STAGED
> should be a nop).
I might have imagined STAGED to be a child commit of HEAD (or rather,
its parents should be the same as if you did 'git commit'), but I
don't really know for sure. In such a case, ^STAGED would definitely
have a meaning.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 15:39 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112110629.GA20473@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 6:06 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:
>
>> Just in case anybody thought about creating tree objects on the fly and
>> use their SHA-1s: that won't fly, as you can have unmerged entries in the
>> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
>
> I thought about that at first, too, but the working tree is even more
> painful. You would have to hash every changed file on the filesystem to
> create the tree object.
Is that so bad? You have to read all those files anyway in order to do a diff.
Avery
^ 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