* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Michael J Gruber @ 2009-03-31 12:55 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, git
In-Reply-To: <20090330180253.GA7220@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 30.03.2009 20:02:
> On Mon, Mar 30, 2009 at 04:47:20PM +0200, Michael J Gruber wrote:
>
>> Thanks for the explanation! I rechecked, and for sure it also happened
>> with patches from Tor Arne Vestbø and Nguyễn Thái Ngọc Duy.
>> Again I feel blessed by my umlautlessness... and challenged by gmane.
>> About time to ditch it for reading patches also, or at least to be aware
>> of it when saving patches.
>
> The message gmane passes out has the content-transfer-encoding set
> properly. Your newsreader should properly un-QP it, or if it has an
> option to save it directly (encoding and all), then "git am" will un-QP
> it. If you were to "git apply" it directly, that would break, though
> (and it is user error). If your newsreader saves the QP text without the
> matching header, then that would also break (and your newsreader is
> broken).
>
> Just curious how you are seeing the breakage (because I want to make
> sure there is no git bug).
>
> -Peff
I haven't seen any breakage. I just noticed a different font being used
for Santi's posts (due to different character encoding, with a different
font preset in TB) and looked at the message source, where I saw =20 and
such all over the place (message display is fine). When saving from TB
the QP is undone. It just made me feel uneasy because of our recent
discussion regarding format-flowed and patch submission. I know ff \ne
qp, but still I thought git-{send-email,apply} would prefer straight ascii.
Michael
^ permalink raw reply
* Re: [PATCHv2 4/4] Rename push.default to push.mode
From: Jeff King @ 2009-03-31 13:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Santi Béjar, git
In-Reply-To: <49D212B0.8070005@drmicha.warpmail.net>
On Tue, Mar 31, 2009 at 02:55:12PM +0200, Michael J Gruber wrote:
> I haven't seen any breakage. I just noticed a different font being used
> for Santi's posts (due to different character encoding, with a different
> font preset in TB) and looked at the message source, where I saw =20 and
> such all over the place (message display is fine). When saving from TB
> the QP is undone. It just made me feel uneasy because of our recent
> discussion regarding format-flowed and patch submission. I know ff \ne
> qp, but still I thought git-{send-email,apply} would prefer straight ascii.
Ah, OK. I think everything is working as expected, then. Thanks for the
clarification.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] send-email: add tests for refactored prompting
From: Jay Soffian @ 2009-03-31 13:58 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Matthieu Moy, Junio C Hamano
In-Reply-To: <20090331103303.GD3307@atjola.homenet>
2009/3/31 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> + GIT_SEND_EMAIL_NOTTY=1 \
>> + test_must_fail git send-email \
>> [...]
>> + yes "bogus" | GIT_SEND_EMAIL_NOTTY=1 \
>> + test_must_fail git send-email \
>
> These two cause interactive prompts for me.
Hmpfh. I think the only way that's possible is if GIT_SEND_EMAIL_NOTTY
isn't being set by the shell. But I'm not sure why that's unique to
these tests.
Thanks for the report.
j.
^ permalink raw reply
* Re: [PATCH 2/2] send-email: add tests for refactored prompting
From: Jay Soffian @ 2009-03-31 14:07 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Matthieu Moy, Junio C Hamano
In-Reply-To: <20090331103303.GD3307@atjola.homenet>
2009/3/31 Björn Steinbrink <B.Steinbrink@gmx.de>:
> These two cause interactive prompts for me.
Ah, it's because of going through test_must_fail. Grrr, a test farm
for git would be nice. :-)
This should fix it up:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b4de98c..cd34525 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -476,7 +476,8 @@ test_expect_success 'confirm detects EOF (inform
assumes y)' '
test_expect_success 'confirm detects EOF (auto causes failure)' '
CONFIRM=$(git config --get sendemail.confirm) &&
git config sendemail.confirm auto &&
- GIT_SEND_EMAIL_NOTTY=1 \
+ GIT_SEND_EMAIL_NOTTY=1 &&
+ export GIT_SEND_EMAIL_NOTTY &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
@@ -490,8 +491,9 @@ test_expect_success 'confirm detects EOF (auto
causes failure)' '
test_expect_success 'confirm doesnt loop forever' '
CONFIRM=$(git config --get sendemail.confirm) &&
git config sendemail.confirm auto &&
- yes "bogus" | GIT_SEND_EMAIL_NOTTY=1 \
- test_must_fail git send-email \
+ GIT_SEND_EMAIL_NOTTY=1 &&
+ export GIT_SEND_EMAIL_NOTTY &&
+ yes "bogus" | test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
What's your OS and test shell btw?
j.
^ permalink raw reply related
* Re: [PATCH 1/2] send-email: refactor and ensure prompting doesn't loop forever
From: Jay Soffian @ 2009-03-31 14:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <vpqvdpq9gww.fsf@bauges.imag.fr>
On Tue, Mar 31, 2009 at 5:32 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Actually, this seems to be a totally separate issue.
Argh, I need more sleep these days.
j.
^ permalink raw reply
* Re: [PATCH 2/2] send-email: add tests for refactored prompting
From: Björn Steinbrink @ 2009-03-31 14:19 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Matthieu Moy, Junio C Hamano
In-Reply-To: <76718490903310707s75e24e39l63f0d396f60a0583@mail.gmail.com>
On 2009.03.31 10:07:25 -0400, Jay Soffian wrote:
> 2009/3/31 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > These two cause interactive prompts for me.
>
> Ah, it's because of going through test_must_fail. Grrr, a test farm
> for git would be nice. :-)
>
> This should fix it up:
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index b4de98c..cd34525 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -476,7 +476,8 @@ test_expect_success 'confirm detects EOF (inform
> assumes y)' '
> test_expect_success 'confirm detects EOF (auto causes failure)' '
> CONFIRM=$(git config --get sendemail.confirm) &&
> git config sendemail.confirm auto &&
> - GIT_SEND_EMAIL_NOTTY=1 \
> + GIT_SEND_EMAIL_NOTTY=1 &&
> + export GIT_SEND_EMAIL_NOTTY &&
> test_must_fail git send-email \
> --from="Example <nobody@example.com>" \
> --to=nobody@example.com \
> @@ -490,8 +491,9 @@ test_expect_success 'confirm detects EOF (auto
> causes failure)' '
> test_expect_success 'confirm doesnt loop forever' '
> CONFIRM=$(git config --get sendemail.confirm) &&
> git config sendemail.confirm auto &&
> - yes "bogus" | GIT_SEND_EMAIL_NOTTY=1 \
> - test_must_fail git send-email \
> + GIT_SEND_EMAIL_NOTTY=1 &&
> + export GIT_SEND_EMAIL_NOTTY &&
> + yes "bogus" | test_must_fail git send-email \
> --from="Example <nobody@example.com>" \
> --to=nobody@example.com \
> --smtp-server="$(pwd)/fake.sendmail" \
Yep, after fixing the linewrapping and restoring the tabs, this works.
> What's your OS and test shell btw?
Debian sid, kernel 2.6.29, dash as /bin/sh
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH 2/2] send-email: add tests for refactored prompting
From: Jay Soffian @ 2009-03-31 14:36 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Matthieu Moy, Junio C Hamano
In-Reply-To: <20090331141937.GC14611@atjola.homenet>
2009/3/31 Björn Steinbrink <B.Steinbrink@gmx.de>:
> Yep, after fixing the linewrapping and restoring the tabs, this works.
Thanks (sorry about the formatting, gmail...).
> Debian sid, kernel 2.6.29, dash as /bin/sh
dash seems to be a good lowest common denominator. I'll try testing
with it from now on.
j.
^ permalink raw reply
* [PATCH] tree_entry_interesting: Only recurse when the pathspec is a leading path component
From: Björn Steinbrink @ 2009-03-31 15:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Anton Gyllenberg, git
In-Reply-To: <20090331094107.GC3307@atjola.homenet>
Previously the code did a simple prefix match, which means that it
treated for example "foo/" as a subdirectory of "f".
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
I'm not exactly happy with the commit message, but that's the best I
could come up with. Probably shows how little I know about that code :-/
The test suite still passes and I'll try to provide a new testcase
tonight or tommorow.
tree-diff.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..b05d0f4 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -118,10 +118,16 @@ static int tree_entry_interesting(struct tree_desc *desc, const char *base, int
continue;
/*
- * The base is a subdirectory of a path which
- * was specified, so all of them are interesting.
+ * If the base is a subdirectory of a path which
+ * was specified, all of them are interesting.
*/
- return 2;
+ if (!matchlen ||
+ base[matchlen] == '/' ||
+ match[matchlen - 1] == '/')
+ return 2;
+
+ /* Just a random prefix match */
+ continue;
}
/* Does the base match? */
--
1.6.2.1.426.gf94cd
^ permalink raw reply related
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: P Baker @ 2009-03-31 15:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090330153245.GD23521@spearce.org>
Great, thanks Shawn. I've included my responses to your
questions/comments below, and would love to continue the dialog - any
help with the application would be much appreciated. I'll work my
responses into my application and send it out again.
On 3/30/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Hi! As someone who has coded around git submodule by creating "repo"
> for Android, I'm certainly interested in git submodule improvements,
> so this is a great idea for a GSoC project. I have some comments
> below that may help improve your proposal before you submit it.
>
I was going to send out another request for comments to the list, but
you beat me to it. The first part of my proposal is to get community
involvement, is this mailing list the best place to do that, or
something external, like a publicly editable site (e.g. a survey or
wiki)?
>
> > As opposed to ???remotes,??? which also incorporate external code into a
> > project,
>
>
> I'm not sure what you mean by that. Typically a "remote" in Git is
> thought to be a configuration that says where to download a fork of
> this project from. By default you get one remote, called "origin",
> which is where you initially cloned your fork from, but you can add
> many more, such as other developers you frequently collaborate with.
>
> This is quite different from the problem that submodule tries
> to address, as its dealing with forks of of the *same* project.
> But a submodule is trying to point to forks of *other* projects,
> whose histories are (possibly) unrelated to this project's history.
>
Right. My point is that due to either perceived or real problems with
git-submodules, some folks have abandoned it and instead used
workarounds (see
http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1210125780000#c1605130977296198852
for one example of such a comment). That so much effort has been put
into solutions external to git, shows that there is some pent up
demand for a solution built into git.
>
> > The tentative timeline is:
> >
> > End of May ??? Conclusively finish the public discussion regarding where
> > git-submodules needs to go
> > Beginning of June ??? Produce final specifications (including method stubs)
> > Middle of July ??? Finish active code and test development
> > End of July ??? Merge code into production release, fix public submitted bugs
> > Middle of August ??? Prepare code for final release and finish
> > user-facing documentation
>
>
> IMHO, this is too vague. *What exactly* are the features you want
> to add to git submodule? Break this down by features, not by phases
> of coding.
>
The features I have been considering are:
*move objects of submodules into base .git/ directory
**This would, as I understand it: protect submodules from being
overwritten and changes lost when switching between branches of the
superproject that might or might not contain the submodules and
centralize their management into one location. The added benefits of
fully using git's ability to branch and merge submodules makes it
worth adding some complexity within the .git directory.
*use .git instead of .gitmodules
**I actually don't know why this was included with the project
description, I searched for an explanation of the desired name change
on the mailing list and in commit messages, but came up with nothing.
*git submodule update --init should initialize nested levels of submodules
**As an ease of use command, either an additional flag to recurse can
be added, or it can act by default. As a requested feature on the
mailing list, this is worth implementing.
*ability to update submodule pulled from svn repo
**One workaround is to clone it as local copy using git-svn and then
import that local clone as a submodule; clearly a clunky solution.
There are many requests for this feature (see
http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
for a typical example), and it makes sense integrating git-submodule
with git-svn would expand submodule's usefulness.
*make submodules deal with updated references
**Instead of issuing merge conflicts on updated submodule references,
this will allow submodules on default detached HEAD so that changes
from the local repo can be committed without first pulling changes
from the shared repo. See
http://flavoriffic.blogspot.com/2008/05/managing-git-submodules-with-gitrake.html?showComment=1211380200000#c3897235118548537475
for an explanation of how this made 'submodules...unsuitable for
active development'. Clearly losing this kind of functionality impairs
the overall usability of git and should be fixed.
*protect changes in local submodules when doing “git submodule update”
**This is similar to the previous point, in that changes need to be
protected or merged or warnings issued when updating the submodule.
The potential to lose work with no warning is a big no-no.
*make git submodules easy to remove
** See http://pitupepito.homelinux.org/?p=24, for an example of why
this is a pain. Adding a submodule has ui, removing one should as
well.
> Further, you spend roughly a month writing method stubs.
Week max: end of May to beginning of June, but if I
>
> Also, we very much prefer Git patches to update the documentation
> at the same time that the code changes.
Fair enough. I was planning on starting documentation during the
stubbing phase, and then finishing it once having written the code.
>
>
> > A few specific changes that this project will likely include are:
> >
> > *use .git instead of .gitmodules
> > *move objects of submodules into .git/ directory
> > *git submodule update --init should initialize nested levels of submodules
>
> > *protect changes in local submodules when doing ???git submodule update???
>
> As I said above, I'd like to see this described in the timeline
> better, each of these could be done independently, so you could work
> on one item try to get it completed, tested, documented, and merged
> into Junio's tree, and then start the next item.
Ok, makes sense. I can redo the timeline like that, I'll order them by
my priority and look for community input on re-ranking them and adding
or subtracting features.
>
> I'd like to know more about each of these items, and less about
> the general reasoning of where you got these feature ideas from.
> What exactly are you talking about changing, and why? I don't need
> to see detailed code at this stage, but I'd like a better description
> of the user-visible changes that each bullet point might cause,
> and why you feel this change is better than what we have today.
>
See above.
Phill Baker
^ permalink raw reply
* [PATCH] Mailmap: Allow empty email addresses to be mapped
From: Björn Steinbrink @ 2009-03-31 15:30 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Junio C Hamano, git
While it makes no sense to map some email address to an empty one, doing
things the other way around can be useful. For example when using
filter-branch with an env-filter that employs a mailmap to fix up an
import that created such broken commits with empty email addresses.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
---
mailmap.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index f12bb45..654c629 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -90,7 +90,8 @@ static void add_mapping(struct string_list *map,
old_name, old_email, new_name, new_email);
}
-static char *parse_name_and_email(char *buffer, char **name, char **email)
+static char *parse_name_and_email(char *buffer, char **name,
+ char **email, int allow_empty_email)
{
char *left, *right, *nstart, *nend;
*name = *email = 0;
@@ -99,7 +100,7 @@ static char *parse_name_and_email(char *buffer, char **name, char **email)
return NULL;
if ((right = strchr(left+1, '>')) == NULL)
return NULL;
- if (left+1 == right)
+ if (!allow_empty_email && (left+1 == right))
return NULL;
/* remove whitespace from beginning and end of name */
@@ -150,8 +151,8 @@ static int read_single_mailmap(struct string_list *map, const char *filename, ch
}
continue;
}
- if ((name2 = parse_name_and_email(buffer, &name1, &email1)) != NULL)
- parse_name_and_email(name2, &name2, &email2);
+ if ((name2 = parse_name_and_email(buffer, &name1, &email1, 0)) != NULL)
+ parse_name_and_email(name2, &name2, &email2, 1);
if (email1)
add_mapping(map, name1, email1, name2, email2);
--
1.6.2.1.425.ga9a94
^ permalink raw reply related
* [PATCH] git submodule: fix usage line
From: Julien Danjou @ 2009-03-31 15:30 UTC (permalink / raw)
To: git; +Cc: Julien Danjou
Actually, you have to set the -b option after the path.
Signed-off-by: Julien Danjou <julien@danjou.info>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0a27232..b0c6a6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> <path> [-b branch]]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
--
1.6.2.1
^ permalink raw reply related
* Force a new version of a file without merge?
From: iware @ 2009-03-31 15:45 UTC (permalink / raw)
To: git
There's a really old bad version of a file that I want to completely overwrite. It keeps merging and removing what I want to put out there.
Is there a way to completely replace a file at HEAD in a remote repository without merging?
--
View this message in context: http://n2.nabble.com/Force-a-new-version-of-a-file-without-merge--tp2563750p2563750.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] git submodule: fix usage line
From: Julien Danjou @ 2009-03-31 15:50 UTC (permalink / raw)
To: git; +Cc: Julien Danjou
In-Reply-To: <1238513459-21813-1-git-send-email-julien@danjou.info>
Actually, you have to set the -b option after the add command.
[This cancel my previous patch]
Signed-off-by: Julien Danjou <julien@danjou.info>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0a27232..7c2e060 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
--
1.6.2.1
^ permalink raw reply related
* Re: bsd group semantics
From: Junio C Hamano @ 2009-03-31 15:55 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, git
In-Reply-To: <20090331112637.GA1910@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The recently added test t1301.17 is failing for me on FreeBSD; the
> created directories don't have the GID bit set.
>
> I traced this back to the fact that FORCE_DIR_SET_GID is a no-op on
> FreeBSD due to the DIR_HAS_BSD_GROUP_SEMANTICS flag being set. I am not
> sure I understand the original reasoning for this flag at all; GID seems
> to work just fine on my FreeBSD 6.1 test system.
IIRC, DIR_HAS_BSD_GROUP_SEMANTICS means you do not have to ask explicitly
with g+s to the filesystem to use the "subdirectory is owned by the same
group as its parent" semantics. On SysV you have to ask; on BSD you do
not have to (and do not need FORCE_DIR_SET_GID).
> The original thread is here:
>
> http://article.gmane.org/gmane.comp.version-control.git/75999
That one was not about "you do not have to ask", but "you are not allowed
to ask because the request will fail". Perhaps between FBSD4 and FBSD6
things changed, and you can now make g+s request (which I presume is still
a no-op other than setting the bit on)?
Ideally the test should be checking if the subdirectory is owned by the
same group as the toplevel, but that is rather hard to correctly arrange,
as it depends on the set of groups the user who runs the test belongs to,
how the git work tree is set up (if it is owned by his primary group or a
secondary), etc.
For now, I'd suggest teaching the test not to care about g+s bit.
^ permalink raw reply
* Re: [RFC GSoC 2009: git-submodule for multiple, active developers on active trees]
From: Johannes Schindelin @ 2009-03-31 15:57 UTC (permalink / raw)
To: P Baker; +Cc: Shawn O. Pearce, git
In-Reply-To: <526944450903310830q5f56fe82xb64ae8dc3c954ffb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3547 bytes --]
Hi,
I am a rather intense user of submodules, so I am quite interested.
Please take my comments as encouragement rather than discouragement.
On Tue, 31 Mar 2009, P Baker wrote:
> On 3/30/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> > IMHO, this is too vague. *What exactly* are the features you want to
> > add to git submodule? Break this down by features, not by phases of
> > coding.
>
> The features I have been considering are:
> *move objects of submodules into base .git/ directory
> **This would, as I understand it: protect submodules from being
> overwritten and changes lost when switching between branches of the
> superproject that might or might not contain the submodules and
> centralize their management into one location. The added benefits of
> fully using git's ability to branch and merge submodules makes it
> worth adding some complexity within the .git directory.
The main problem with renaming/deleting is not the repository of the
submodule, but the working directoy.
> *use .git instead of .gitmodules
> **I actually don't know why this was included with the project
> description, I searched for an explanation of the desired name change
> on the mailing list and in commit messages, but came up with nothing.
AFAICT somebody thought that the information about the locations of the
submodules should be in .git/ rather than in the working directory. But
of course, that is wrong: you want it to be tracked.
> *git submodule update --init should initialize nested levels of submodules
> **As an ease of use command, either an additional flag to recurse can
> be added, or it can act by default. As a requested feature on the
> mailing list, this is worth implementing.
I thought there was a patch to support "git submodule recurse"? That
would be rather less limited than yet another option to submodule update.
> *ability to update submodule pulled from svn repo
> **One workaround is to clone it as local copy using git-svn and then
> import that local clone as a submodule; clearly a clunky solution.
> There are many requests for this feature (see
> http://panthersoftware.com/articles/view/4/git-svn-dcommit-workaround-for-git-submodules
> for a typical example), and it makes sense integrating git-submodule
> with git-svn would expand submodule's usefulness.
I do not think that this would be good. Both "git svn" and "git
submodule" are rather complex by now, and mixing them would only
complicate code.
> *make submodules deal with updated references
> **Instead of issuing merge conflicts on updated submodule references,
> this will allow submodules on default detached HEAD so that changes
> from the local repo can be committed without first pulling changes
> from the shared repo.
I'd rather call this "make git-submodule help with merging".
> *protect changes in local submodules when doing “git submodule update”
> **This is similar to the previous point, in that changes need to be
> protected or merged or warnings issued when updating the submodule.
> The potential to lose work with no warning is a big no-no.
One word: Reflogs.
> *make git submodules easy to remove
> ** See http://pitupepito.homelinux.org/?p=24, for an example of why
> this is a pain. Adding a submodule has ui, removing one should as
> well.
AFAIR there was already a patch to implement this, but the OP apparently
did not address all issues.
> > Further, you spend roughly a month writing method stubs.
>
> Week max: end of May to beginning of June, but if I
... yes?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Junio C Hamano @ 2009-03-31 16:04 UTC (permalink / raw)
To: Christian Couder; +Cc: Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <200903310859.36035.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> I think it's a good thing that you started working on it even if in the end
> we decide that we want these cleanup to be done otherwise. At least we will
> hopefully have clarified our include header policy.
Before seeing a lot of patches to change #include all over the place, I'd
like to see a simple guiding principle described, not just a subjective "I
think this makes things better" but with "... because of X and Y and Z".
The document Documentation/CodingGuidelines describes the only policy that
exists currently: git-compat-util.h must be the first thing the compiler
sees. The language should probably be stronger than what appears there:
- The first #include in C files, except in platform specific
compat/ implementations, should be git-compat-util.h or another
well-known header file that includes it at the beginning, namely
cache.h or builtin.h.
Even though http.h may include "cache.h" at the very beginning, I'd rather
not to see http-walker.c lose inclusion of "cache.h". It will force us to
remember that http.h is Ok to include as the first file, and that won't
scale.
The reason git-compat-util.h must be the first is because inclusion of all
the system header files is supposed to happen there, and there are some
platforms that have broken system header dependencies we do not want
application writers to care about, and the compat-util header knows about
them.
^ permalink raw reply
* Re: bsd group semantics
From: Jeff King @ 2009-03-31 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vvdpp6623.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 31, 2009 at 08:55:00AM -0700, Junio C Hamano wrote:
> IIRC, DIR_HAS_BSD_GROUP_SEMANTICS means you do not have to ask explicitly
> with g+s to the filesystem to use the "subdirectory is owned by the same
> group as its parent" semantics. On SysV you have to ask; on BSD you do
> not have to (and do not need FORCE_DIR_SET_GID).
OK, I see. Thanks for the explanation. So the test is wrong, since it
explicitly checks for g+s, and we only need it sometimes.
> That one was not about "you do not have to ask", but "you are not allowed
> to ask because the request will fail". Perhaps between FBSD4 and FBSD6
> things changed, and you can now make g+s request (which I presume is still
> a no-op other than setting the bit on)?
Yes, you can ask just fine now:
$ uname -sr
FreeBSD 6.1-RELEASE-p17-jc1
$ mkdir foo
$ ls -ld foo
drwxr-xr-x 2 peff peff 512 Mar 31 09:04 foo/
$ chmod g+s foo
$ ls -ld foo
drwxr-sr-x 2 peff peff 512 Mar 31 09:04 foo/
But it isn't necessary.
> Ideally the test should be checking if the subdirectory is owned by the
> same group as the toplevel, but that is rather hard to correctly arrange,
> as it depends on the set of groups the user who runs the test belongs to,
> how the git work tree is set up (if it is owned by his primary group or a
> secondary), etc.
Shouldn't that just be:
perl -e 'sub group { return (stat(shift))[5] }' \
-e 'exit group($ARGV[0]) == group($ARGV[1]) ? 0 : 1' \
a b
?
-Peff
^ permalink raw reply
* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Heiko Voigt @ 2009-03-31 16:22 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: Junio C Hamano, git
In-Reply-To: <49D1ABD0.8070707@pelagic.nl>
On Tue, Mar 31, 2009 at 07:36:16AM +0200, Ferry Huberts (Pelagic) wrote:
> Heiko Voigt wrote:
> > On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:
> >> maybe you can also add remarks about autocrlf and safecrlf?
> >> both need to be off
> >
> > From my experience thats not necessarily true. You can use
> > autocrlf=input to repair broken revisions were crlf's have been
> > mistakenly committed into the repository. And if I remember correctly
> > safecrlf helps if you want to make sure that no information gets lost.
> >
> > So when importing from a nice correct cvs repository you would expect
> > safecrlf to not stop your import. And I suspect there are actually cvs
> > users that were very careful with their lineendings who would use it.
> >
> > cheers Heiko
> If you look at this thread:
> http://thread.gmane.org/gmane.comp.version-control.git/110152/focus=110358
> you'll see why I said it. I did some testing to prove my statement.
Well, from that thread I see my statement supported. It is not true that
they *need* to be off. Maybe a statement that certain crlf settings are
exclusive would be good, but I agree that should go into the config
documentation.
The main point I see here is that the User may not be aware that such a
conversion is applied so something like this could help.
cheers Heiko
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index e1fd047..d4e7fd4 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -40,6 +40,11 @@ probably want to make a bare clone of the imported repository
and use the clone as the shared repository.
See linkgit:gitcvs-migration[7].
+Note: All revisions are imported using the index so settings of
+core.autocrlf and core.safecrlf are applied. This way you can change or
+safety check the import. If you do not want this make sure these options
+are both set to false.
+
OPTIONS
-------
^ permalink raw reply related
* [PATCH 0/4] send-email: correct various issues
From: Jay Soffian @ 2009-03-31 16:22 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Matthieu Moy, Junio C Hamano, Björn Steinbrink,
Uwe Kleine-König
Junio, these are technically all independent bug fixes, but they were
minor, so I've lumped them together. I figured you'd just add them to
the js/send-email topic anyway. Also, I apologize for causing trouble in
master. :-(
Björn, I've cc'd you for 3/4, which caused me to notice the problem that
led to 4/4. Uwe, I've cc'd you for 4/4.
Jay Soffian (4):
send-email: don't attempt to prompt if tty is closed
send-email: ask_default should apply to all emails, not just the
first
send-email: correct two tests which were going interactive
send-email: ensure quoted addresses are rfc2047 encoded
git-send-email.perl | 9 ++++++---
t/t9001-send-email.sh | 25 +++++++++++++++++++++----
2 files changed, 27 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 1/4] send-email: don't attempt to prompt if tty is closed
From: Jay Soffian @ 2009-03-31 16:22 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Matthieu Moy, Junio C Hamano, Björn Steinbrink,
Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
Attempting to prompt when the tty is closed (typically when running from
cron) is pointless and emits a warning. This patch causes ask() to
return early, squelching the warning.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
git-send-email.perl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 5916c86..d790660 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -612,6 +612,9 @@ sub ask {
my $default = $arg{default};
my $resp;
my $i = 0;
+ return defined $default ? $default : undef
+ unless defined $term->IN and defined fileno($term->IN) and
+ defined $term->OUT and defined fileno($term->OUT);
while ($i++ < 10) {
$resp = $term->readline($prompt);
if (!defined $resp) { # EOF
--
1.6.2.1.427.g15408
^ permalink raw reply related
* [PATCH 2/4] send-email: ask_default should apply to all emails, not just the first
From: Jay Soffian @ 2009-03-31 16:22 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Matthieu Moy, Junio C Hamano, Björn Steinbrink,
Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
Commit 6e18251 made the "Send this email?" prompt assume yes if confirm
= "inform" when it was unable to get a valid response. However, the
"yes" assumption only worked correctly for the first email. This commit
fixes the issue and confirms the fix my modifying the existing test for
the prompt to send multiple emails.
Reported by Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
git-send-email.perl | 3 +--
t/t9001-send-email.sh | 4 +++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d790660..fc153f9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -687,7 +687,7 @@ if ($compose && $compose > 0) {
# Variables we set as part of the loop over files
our ($message_id, %mail, $subject, $reply_to, $references, $message,
- $needs_confirm, $message_num);
+ $needs_confirm, $message_num, $ask_default);
sub extract_valid_address {
my $address = shift;
@@ -845,7 +845,6 @@ X-Mailer: git-send-email $gitversion
if ($needs_confirm && !$dry_run) {
print "\n$header\n";
- my $ask_default;
if ($needs_confirm eq "inform") {
$confirm_unconfigured = 0; # squelch this message for the rest of this run
$ask_default = "y"; # assume yes on EOF since user hasn't explicitly asked for confirmation
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index b4de98c..195ff8b 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -462,12 +462,14 @@ test_expect_success 'confirm by default (due to --compose)' '
test_expect_success 'confirm detects EOF (inform assumes y)' '
CONFIRM=$(git config --get sendemail.confirm) &&
git config --unset sendemail.confirm &&
+ rm -fr outdir &&
+ git format-patch -2 -o outdir &&
GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
- $patches < /dev/null
+ outdir/*.patch < /dev/null
ret="$?"
git config sendemail.confirm ${CONFIRM:-never}
test $ret = "0"
--
1.6.2.1.427.g15408
^ permalink raw reply related
* [PATCH 3/4] send-email: correct two tests which were going interactive
From: Jay Soffian @ 2009-03-31 16:22 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Matthieu Moy, Junio C Hamano, Björn Steinbrink,
Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
Commit 67f1fe5 added two tests which went interactive under the
dash shell. This commit corrects the issue. Reported by
Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
t/t9001-send-email.sh | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 195ff8b..84238f7 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -478,7 +478,8 @@ test_expect_success 'confirm detects EOF (inform assumes y)' '
test_expect_success 'confirm detects EOF (auto causes failure)' '
CONFIRM=$(git config --get sendemail.confirm) &&
git config sendemail.confirm auto &&
- GIT_SEND_EMAIL_NOTTY=1 \
+ GIT_SEND_EMAIL_NOTTY=1 &&
+ export GIT_SEND_EMAIL_NOTTY &&
test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
@@ -492,8 +493,9 @@ test_expect_success 'confirm detects EOF (auto causes failure)' '
test_expect_success 'confirm doesnt loop forever' '
CONFIRM=$(git config --get sendemail.confirm) &&
git config sendemail.confirm auto &&
- yes "bogus" | GIT_SEND_EMAIL_NOTTY=1 \
- test_must_fail git send-email \
+ GIT_SEND_EMAIL_NOTTY=1 &&
+ export GIT_SEND_EMAIL_NOTTY &&
+ yes "bogus" | test_must_fail git send-email \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--smtp-server="$(pwd)/fake.sendmail" \
--
1.6.2.1.427.g15408
^ permalink raw reply related
* [PATCH 4/4] send-email: ensure quoted addresses are rfc2047 encoded
From: Jay Soffian @ 2009-03-31 16:22 UTC (permalink / raw)
To: git
Cc: Jay Soffian, Matthieu Moy, Junio C Hamano, Björn Steinbrink,
Uwe Kleine-König
In-Reply-To: <cover.1238516122.git.jaysoffian@gmail.com>
sanitize_address assumes that quoted addresses (e.g., "first last"
<first.last@example.com) do not need rfc2047 encoding, but this is
not always the case.
For example, various places in send-email extract addresses using
parse_address_line. parse_address_line returns the addresses already
quoted (e.g., "first last" <first.last@example.com), but not rfc2047
encoded.
This patch makes sanitize_address stricter about what needs rfc2047
encoding and adds a test demonstrating where I noticed the problem.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
git-send-email.perl | 3 ++-
t/t9001-send-email.sh | 13 +++++++++++++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fc153f9..6bbdfec 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -776,12 +776,13 @@ sub sanitize_address
}
# if recipient_name is already quoted, do nothing
- if ($recipient_name =~ /^(".*"|=\?utf-8\?q\?.*\?=)$/) {
+ if ($recipient_name =~ /^("[[:ascii:]]*"|=\?utf-8\?q\?.*\?=)$/) {
return $recipient;
}
# rfc2047 is needed if a non-ascii char is included
if ($recipient_name =~ /[^[:ascii:]]/) {
+ $recipient_name =~ s/^"(.*)"$/$1/;
$recipient_name = quote_rfc2047($recipient_name);
}
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 84238f7..192b97b 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -505,6 +505,19 @@ test_expect_success 'confirm doesnt loop forever' '
test $ret = "0"
'
+test_expect_success 'utf8 Cc is rfc2047 encoded' '
+ clean_fake_sendmail &&
+ rm -fr outdir &&
+ git format-patch -1 -o outdir --cc="à éìöú <utf8@example.com>" &&
+ git send-email \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ outdir/*.patch &&
+ grep "^Cc:" msgtxt1 |
+ grep "=?utf-8?q?=C3=A0=C3=A9=C3=AC=C3=B6=C3=BA?= <utf8@example.com>"
+'
+
test_expect_success '--compose adds MIME for utf8 body' '
clean_fake_sendmail &&
(echo "#!$SHELL_PATH" &&
--
1.6.2.1.427.g15408
^ permalink raw reply related
* legend on top-right pane in 'git gui'
From: Sitaram Chamarty @ 2009-03-31 16:25 UTC (permalink / raw)
To: git
Hello,
'git gui' has a minor issue with the legend on the main code
panel (yellow bar, top right pane).
When you click on a file in the top left pane, the yellow
bar becomes "untracked, not staged". When you click on a
file in the bottom left pane, it becomes "staged for
commit". So far so good.
But when you take a file and (un)stage a part of it, then
the text on the yellow bar changes to "Portions staged for
commit", regardless of whether you clicked on the filename
in the top left (unstaged) or bottom left (staged) pane.
One of the two texts should be different, but what? I was
thinking, just add "(partial)" to the normal text, like:
"untracked, not staged (partial)"
"staged for commit (partial)"
I also tried to see if I could patch it, but it's not just a
matter of changing the text somewhere, and I don't know tcl.
However, if someone can give me a pointer I could still
try...
Any thoughts?
^ permalink raw reply
* [PATCH] gitweb: Fix snapshots requested via PATH_INFO
From: Holger Weiß @ 2009-03-31 16:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
Fix the detection of the requested snapshot format, which failed for
PATH_INFO URLs since the references to the hashes which describe the
supported snapshot formats weren't dereferenced appropriately.
Signed-off-by: Holger Weiß <holger@zedat.fu-berlin.de>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33ef190..3f99361 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -688,10 +688,10 @@ sub evaluate_path_info {
# extensions. Allowed extensions are both the defined suffix
# (which includes the initial dot already) and the snapshot
# format key itself, with a prepended dot
- while (my ($fmt, %opt) = each %known_snapshot_formats) {
+ while (my ($fmt, $opt) = each %known_snapshot_formats) {
my $hash = $refname;
my $sfx;
- $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
+ $hash =~ s/(\Q$opt->{'suffix'}\E|\Q.$fmt\E)$//;
next unless $sfx = $1;
# a valid suffix was found, so set the snapshot format
# and reset the hash parameter
--
1.6.2.1
^ permalink raw reply related
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