* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Junio C Hamano @ 2007-07-05 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0707051636240.9789@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 5 Jul 2007, Jeff King wrote:
>
>> status=`((cmd1; echo $? >&3) | cmd2) 3>&1`
>
> Cute.
>
> This is the replacement patch, then (I guess there are still some nits to
> be had, so I did not redo the proper patch yet):
> ...
> + (sed -e '1,/^$/d' <../commit |
> + (eval "$filter_msg" ||
> + die "msg filter failed: $filter_msg" 2>&3) |
> + (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
> + $parentstr > ../map/$commit ||
> + die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
> + grep . && die
You certainly meant "grep >&2 ." at the end of that pipeline;
while I welcome people to be aware that it is possible with
esoteric shell redirection games, I personally feel this is not
worth it.
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Johannes Schindelin @ 2007-07-05 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vsl82dcj0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 5 Jul 2007, Junio C Hamano wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > On 7/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >>
> >> We have a working implementation of rerere since long ago, and we even
> >> make sure that it works as expected in a test case. It is also a very
> >> useful feature, so why not turn it on for the benefit of users who are
> >> not even aware of it? This patch does that.
> >
> > Maybe just create in template directory?
>
> Sounds saner.
Does it?
I had the impression that the templates are meant for site-specific
modifications. My patch tried to make it more standard than that.
For example, you _could_ have set core.logallrefupdates from the
templates, yet you chose not to, but rather hard-wire it into "git init".
Which I completely agree to.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Junio C Hamano @ 2007-07-05 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0707051811310.9789@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 5 Jul 2007, Junio C Hamano wrote:
>
>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>
>> > On 7/5/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> >>
>> >> We have a working implementation of rerere since long ago, and we even
>> >> make sure that it works as expected in a test case. It is also a very
>> >> useful feature, so why not turn it on for the benefit of users who are
>> >> not even aware of it? This patch does that.
>> >
>> > Maybe just create in template directory?
>>
>> Sounds saner.
>
> Does it?
>
> I had the impression that the templates are meant for site-specific
> modifications. My patch tried to make it more standard than that.
>
> For example, you _could_ have set core.logallrefupdates from the
> templates, yet you chose not to, but rather hard-wire it into "git init".
> Which I completely agree to.
I think what Alex meant is this.
diff --git a/templates/rr-cache-- b/templates/rr-cache--
new file mode 100644
index 0000000..fae8870
--- /dev/null
+++ b/templates/rr-cache--
@@ -0,0 +1 @@
+: this is just to ensure the directory exists.
^ permalink raw reply related
* Email address from username and hostname preferred over $EMAIL
From: mkraai @ 2007-07-05 17:57 UTC (permalink / raw)
To: git
Howdy,
Git prefers to use an email address constructed from the username and
hostname to the value of the EMAIL environment variable. I think it
should prefer the latter to the former. This problem was introduced by
ec563e8153cba89728a271a26c8a94e7a42d8152.
--
Matt
The server made the following annotations
---------------------------------------------------------------------------------
This message contains information that may be privileged or confidential and is the property of Beckman Coulter, Inc. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
---------------------------------------------------------------------------------
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Jan Hudec @ 2007-07-05 18:54 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550706102245p27aea579w65ee96161630a624@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
Hello,
On Mon, Jun 11, 2007 at 07:45:51 +0200, Marco Costalba wrote:
> On 6/11/07, Jan Hudec <bulb@ucw.cz> wrote:
>> I think I mostly understood it now. Thank you.
>
> Anyhow I think this could be useful to you:
>
> /*
> getAllRefSha() returns the list of sha of a given
> type, where type is a mask of Git::RefType flags
> see src/git.h.
> In this case we want the sha of the current branch
> */
> QStringList revs = getAllRefSha(CUR_BRANCH);
>
> if (!revs.isEmpty()) {
>
> // all the sha info is stored in this QGit::Rev
> // class defined in src/common.h
> const Rev* r = revLookup(revs.first());
>
> // short log (title) is
> r->shortLog();
>
> // message body is
> r->longLog();
>
> // etc....
> }
I thought I should be using something more explicit. Like getRefSha("HEAD",
ANY_REF, false) -- only to find that it wouldn't work. That means that this
code would not work either. Why? Well, because HEAD does not have to be
a symbolic ref. If you check out anything else than branch (which you can),
HEAD will be set to the SHA1 directly and if you commit in such state (which
you also can), the HEAD will be different from anything in refs/.
Therefore I'll either have to always ask git via run("git-rev-parse HEAD",
head), add HEAD into the map, or store HEAD somewhere in the Git object.
Which do you think makes most sense?
(Note: Yes, I noted that getRefSha("HEAD", ANY_REF, true) should work, but of
course that is the run("git-rev-parse HEAD") case.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Johannes Schindelin @ 2007-07-05 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vfy42d6m0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 5 Jul 2007, Junio C Hamano wrote:
> I think what Alex meant is this.
>
> diff --git a/templates/rr-cache-- b/templates/rr-cache--
> new file mode 100644
> index 0000000..fae8870
> --- /dev/null
> +++ b/templates/rr-cache--
> @@ -0,0 +1 @@
> +: this is just to ensure the directory exists.
>
Yes, I fully understood.
However, when I use a new version of Git (which happens regularly, since I
pull quite often), I do not update the templates. I guess that many
distros do not update their templates as often as the core, because they
are much more likely to be modified distro-specifically. Further, there
are some platforms which are insane enough that you cannot trust the
executable bit, and therefore the templates are disabled by default.
All this means that the given patch would not hardly make rerere as
widespread as I intended.
Yes, templates are nice. But I don't think that templates are the way to
go for introducing nice features as rr-cache.
Ciao,
Dscho
^ permalink raw reply
* Re: Email address from username and hostname preferred over $EMAIL
From: Pierre Habouzit @ 2007-07-05 20:21 UTC (permalink / raw)
To: mkraai; +Cc: git
In-Reply-To: <OF40A04FE5.AA34B1BF-ON8825730F.005D733A-8825730F.0062A716@beckman.com>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Thu, Jul 05, 2007 at 10:57:37AM -0700, mkraai@beckman.com wrote:
> Howdy,
>
> Git prefers to use an email address constructed from the username and
> hostname to the value of the EMAIL environment variable. I think it
> should prefer the latter to the former. This problem was introduced by
> ec563e8153cba89728a271a26c8a94e7a42d8152.
no, ec563e8153cba89728a271a26c8a94e7a42d8152 is about making the
emails and usernames be taken from EMAIL iff there is none specified in
the different .gitconfig's (which is sane as $EMAIL is a system wide
default setting and that .git/config is definitely meant as an ovveride
of that setting).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Email address from username and hostname preferred over $EMAIL
From: mkraai @ 2007-07-05 20:48 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070705202140.GA24349@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
Yes, ec563e8153cba89728a271a26c8a94e7a42d8152 made user.email take
precedence over $EMAIL, but it also made the constructed email address
take precedence over $EMAIL. It made fmt_ident prefer git_default_email
to $EMAIL, and git_default_email is set to the constructed email address
by setup_ident if it's not already set by user.email.
Pierre Habouzit <madcoder@debian.org>
07/05/2007 01:21 PM
To
mkraai@beckman.com
cc
git@vger.kernel.org
Subject
Re: Email address from username and hostname preferred over $EMAIL
On Thu, Jul 05, 2007 at 10:57:37AM -0700, mkraai@beckman.com wrote:
> Howdy,
>
> Git prefers to use an email address constructed from the username and
> hostname to the value of the EMAIL environment variable. I think it
> should prefer the latter to the former. This problem was introduced by
> ec563e8153cba89728a271a26c8a94e7a42d8152.
no, ec563e8153cba89728a271a26c8a94e7a42d8152 is about making the
emails and usernames be taken from EMAIL iff there is none specified in
the different .gitconfig's (which is sane as $EMAIL is a system wide
default setting and that .git/config is definitely meant as an ovveride
of that setting).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
The server made the following annotations
---------------------------------------------------------------------------------
This message contains information that may be privileged or confidential and is the property of Beckman Coulter, Inc. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
---------------------------------------------------------------------------------
[-- Attachment #2: atttv2u2.dat --]
[-- Type: application/octet-stream, Size: 196 bytes --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBGjVLUvGr7W6HudhwRAi+OAKCbdSLx888s5fS1fuM1xAPgtISJqwCghh4B
0yRMdqfnMTea9jmP6jjZSLs=
=hYUo
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Email address from username and hostname preferred over $EMAIL
From: Linus Torvalds @ 2007-07-05 21:10 UTC (permalink / raw)
To: mkraai; +Cc: git
In-Reply-To: <OF40A04FE5.AA34B1BF-ON8825730F.005D733A-8825730F.0062A716@beckman.com>
On Thu, 5 Jul 2007, mkraai@beckman.com wrote:
>
> Git prefers to use an email address constructed from the username and
> hostname to the value of the EMAIL environment variable. I think it
> should prefer the latter to the former. This problem was introduced by
> ec563e8153cba89728a271a26c8a94e7a42d8152.
It did that very much on purpose. "git_default_email" must take
precedence, because that's the one that is filled in by the config file
syntax.
So just use
[user]
name = ..
email = ..
and be happy. Only in the absense of that will git start guessing, and
yeah, it will not generally use EMAIL, unless it cannot get anything at
all from username/hostname.
If you want it to prefer $EMAIL, you'd need to change the initialization
of git_default_email, methinks.
Linus
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Alex Riesen @ 2007-07-05 21:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707052018260.9789@racer.site>
Johannes Schindelin, Thu, Jul 05, 2007 21:22:43 +0200:
> Yes, templates are nice. But I don't think that templates are the way to
> go for introducing nice features as rr-cache.
Looks like you're trying to enforce the feature, not introduce.
It changes the user-visible behaviour, and this can be unexpected.
It is not like you see people asking question: "How do I avoid
repeating the same boring conflict?" every day on vger or irc.
That said, the templates are installed with every make install (and I
suppose with every .deb and .rpm), and template is copied in every new
repo, so people will get the rr-cache sooner or later. What's wrong
with "a bit later" than "much sooner"?
^ permalink raw reply
* [PATCH] Add -v|--verbose to git remote to show remote url
From: Alex Riesen @ 2007-07-05 21:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Many other commands already have such an option, and I find it
practical to see where all the remotes actually come from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
The $VERBOSE may be even used by some of the subcommands
later.
git-remote.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index b59cafd..449d97b 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -319,9 +319,14 @@ sub add_usage {
exit(1);
}
+local $VERBOSE = 0;
+@ARGV = grep { $VERBOSE=1,0 if $_ eq '-v' or $_ eq '--verbose' } @ARGV;
+
if (!@ARGV) {
for (sort keys %$remote) {
- print "$_\n";
+ print "$_";
+ print "\t$remote->{$_}->{URL}" if $VERBOSE;
+ print "\n";
}
}
elsif ($ARGV[0] eq 'show') {
--
1.5.3.rc0.56.g6b87
^ permalink raw reply related
* Re: [PATCH] Add -v|--verbose to git remote to show remote url
From: Alex Riesen @ 2007-07-05 22:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20070705215730.GC8751@steel.home>
Alex Riesen, Thu, Jul 05, 2007 23:57:30 +0200:
> +local $VERBOSE = 0;
> +@ARGV = grep { $VERBOSE=1,0 if $_ eq '-v' or $_ eq '--verbose' } @ARGV;
> +
Do NOT apply: this filters out _all_ of command line.
^ permalink raw reply
* [PATCH] Add -v|--verbose to git remote to show remote url
From: Alex Riesen @ 2007-07-05 22:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Many other commands already have such an option, and I find it
practical to see where all the remotes actually come from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Fixed and tested. Being used.
git-remote.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index b59cafd..e13d7b9 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -319,9 +319,21 @@ sub add_usage {
exit(1);
}
+local $VERBOSE = 0;
+@ARGV = grep {
+ if ($_ eq '-v' or $_ eq '--verbose') {
+ $VERBOSE=1;
+ 0
+ } else {
+ 1
+ }
+} @ARGV;
+
if (!@ARGV) {
for (sort keys %$remote) {
- print "$_\n";
+ print "$_";
+ print "\t$remote->{$_}->{URL}" if $VERBOSE;
+ print "\n";
}
}
elsif ($ARGV[0] eq 'show') {
--
1.5.3.rc0.56.g6b87
^ permalink raw reply related
* Re: [PATCH] Add -v|--verbose to git remote to show remote url
From: Junio C Hamano @ 2007-07-05 22:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070705220247.GD8751@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Alex Riesen, Thu, Jul 05, 2007 23:57:30 +0200:
>> +local $VERBOSE = 0;
>> +@ARGV = grep { $VERBOSE=1,0 if $_ eq '-v' or $_ eq '--verbose' } @ARGV;
>> +
>
> Do NOT apply: this filters out _all_ of command line.
Heh, I was wondering what you were smoking ;-).
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Johannes Schindelin @ 2007-07-05 22:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070705214032.GB8751@steel.home>
Hi,
On Thu, 5 Jul 2007, Alex Riesen wrote:
> Johannes Schindelin, Thu, Jul 05, 2007 21:22:43 +0200:
> > Yes, templates are nice. But I don't think that templates are the way to
> > go for introducing nice features as rr-cache.
>
> Looks like you're trying to enforce the feature, not introduce.
Yes. Actually, since long I wondered if this feature should not be
controlled by a core.rerere variable.
> It changes the user-visible behaviour, and this can be unexpected.
Yes, but I think for the better.
> It is not like you see people asking question: "How do I avoid repeating
> the same boring conflict?" every day on vger or irc.
That is because people have been trained to cope with CVS. They do not
even know rerere exists.
> That said, the templates are installed with every make install (and I
> suppose with every .deb and .rpm), and template is copied in every new
> repo, so people will get the rr-cache sooner or later. What's wrong with
> "a bit later" than "much sooner"?
In the part of my reply that you conveniently scissored, I explained that
it is often not "a bit later", but "never".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] remote: add 'rm' subcommand
From: Johannes Schindelin @ 2007-07-05 22:38 UTC (permalink / raw)
To: James Bowes; +Cc: gitster, git
In-Reply-To: <11810859232541-git-send-email-jbowes@dangerouslyinc.com>
Hi,
On Tue, 5 Jun 2007, James Bowes wrote:
> Introduce git-remote rm <name> which will:
> - Remove the remote config entry for <name>.
> - Remove any config entries for tracking branches of <name>.
> - Remove any stored remote branches of <name>.
Any word on this?
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] git-clone: split up long &&-command-chain and use a function for cleanup
From: Matthias Lederhofer @ 2007-07-05 22:54 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
This is in preparation for the next patch.
Actually the old cleanup code could leave the repository directory if
D=$(cd "$dir" && pwd)
failed before this patch.
---
git-clone.sh | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index bd44ce1..59a457b 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -176,15 +176,24 @@ dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && die "destination directory '$dir' already exists."
-mkdir -p "$dir" &&
-D=$(cd "$dir" && pwd) &&
-trap 'err=$?; cd ..; rm -rf "$D"; exit $err' 0
+D=
+cleanup() {
+ err=$?
+ test -z "$D" && rm -rf "$dir"
+ cd ..
+ test -n "$D" && rm -rf "$D"
+ exit $err
+}
+trap cleanup 0
+mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
case "$bare" in
yes)
GIT_DIR="$D" ;;
*)
GIT_DIR="$D/.git" ;;
-esac && export GIT_DIR && git-init ${template+"$template"} || usage
+esac
+export GIT_DIR
+git-init ${template+"$template"} || usage
if test -n "$reference"
then
--
1.5.2.2.647.ga00fe
^ permalink raw reply related
* [PATCH 2/2] make git-clone GIT_WORK_TREE aware
From: Matthias Lederhofer @ 2007-07-05 23:10 UTC (permalink / raw)
To: git
In-Reply-To: <20070705225433.GA26061@moooo.ath.cx>
If GIT_WORK_TREE is set git-clone will use that path for the
working tree.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
All those import scripts which call git init too probably have
problems when GIT_WORK_TREE is exported. Perhaps a simple
test -n "$GIT_WORK_TREE" ||
die "GIT_WORK_TREE is not supported by this script yet"
is enough for the moment for those scripts.
---
git-clone.sh | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 59a457b..b72a242 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -176,22 +176,29 @@ dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && die "destination directory '$dir' already exists."
+[ yes = "$bare" ] && unset GIT_WORK_TREE
+[ -n "$GIT_WORK_TREE" ] && [ -e "$GIT_WORK_TREE" ] &&
+die "working tree '$GIT_WORK_TREE' already exists."
D=
+W=
cleanup() {
err=$?
test -z "$D" && rm -rf "$dir"
+ test -z "$W" && test -n "$GIT_WORK_TREE" && rm -rf "$GIT_WORK_TREE"
cd ..
test -n "$D" && rm -rf "$D"
+ test -n "$W" && rm -rf "$W"
exit $err
}
trap cleanup 0
mkdir -p "$dir" && D=$(cd "$dir" && pwd) || usage
-case "$bare" in
-yes)
- GIT_DIR="$D" ;;
-*)
- GIT_DIR="$D/.git" ;;
-esac
+test -n "$GIT_WORK_TREE" && mkdir -p "$GIT_WORK_TREE" &&
+W=$(cd "$GIT_WORK_TREE" && pwd) && export GIT_WORK_TREE="$W"
+if test yes = "$bare" || test -n "$GIT_WORK_TREE"; then
+ GIT_DIR="$D"
+else
+ GIT_DIR="$D/.git"
+fi
export GIT_DIR
git-init ${template+"$template"} || usage
@@ -347,7 +354,11 @@ then
done < "$GIT_DIR/CLONE_HEAD"
fi
-cd "$D" || exit
+if test -n "$W"; then
+ cd "$W" || exit
+else
+ cd "$D" || exit
+fi
if test -z "$bare" && test -f "$GIT_DIR/REMOTE_HEAD"
then
--
1.5.2.2.647.ga00fe
^ permalink raw reply related
* git-apply{,mbox,patch} should default to --unidiff-zero
From: Adrian Bunk @ 2007-07-05 23:22 UTC (permalink / raw)
To: git
I just ran into the following issue:
I sent someone a patch that purposefully contained a chunk without
context, and git-apply of the recipient refused to apply it without
an explicit --unidiff-zero.
git-apply{,mbox,patch} should default to doing --unidiff-zero:
Generating a patch without context is something I have to do explicitely
by giving "diff" an option or by manually editing the patch. I know
about the dangers of having no context, but there are use cases where
I know that replacing and/or deleting one or more lines is safe even
without context and where I want to avoid context e.g. for avoiding to
clash with other patches.
Example use case:
Look at the file Documentation/feature-removal-schedule.txt in the Linux
kernel. If I want to send someone two independent patches removing
adjanced entries in this file, the patches can be applied in any order
exactly as long as this chunk does not contain any context. Removing an
entry from this file is obviously safe even without any context.
TIA
Adrian
BTW: Please Cc me on replies.
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH] stash: end commit log with a newline
From: しらいしななこ @ 2007-07-05 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Kleine-König, Git Mailing List
In-Reply-To: <7vodiqdcgl.fsf@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano <gitster@pobox.com>:
> Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> writes:
>
>> I didn't test it yet, but it sounds good. I will apply your patch and
>> work a while with it. But I think if someone adds documentation, I will
>> give my Ack. :-)
>>
>> BTW: I prefer help over usage, but if it nanako prefers usage, why not
>> both?
>
> We could do that, I guess. Nana?
Thank you very much for asking.
I think it is good to accept both usage and help, then. I will try your
patch myself and will report if I can think of further improvements.
Please do not expect much documentation from me, however. My writing is
not very good.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com/tag/3
^ permalink raw reply
* Update local tracking refs when pushing- no way to disable
From: Dan McGee @ 2007-07-06 0:22 UTC (permalink / raw)
To: git
In this commit:
b516968ff62ec153e008d033c153affd7ba9ddc6
I don't know if anyone else has the same way of working as I do, but I
tend to set the "remote.<name>.skipDefaultUpdate" property to true for
my publicly visible repository, just so I don't have duplicate branch
heads lying around in my local repository. Call this peculiar, but I
like it that way. However, git-push does not respect this property,
meaning I know have these branches whether I want them or not. In a
tool such as qgit or even 'git branch -a' output, it starts to get
awful cluttered.
I'm not terribly familiar with GIT internals, so I don't know that I
am the best to make a patch for this, but I'll take no response as a
answer that I should start coding something up. Please CC me on
emails, I'm not on the GIT mailing list.
-Dan
^ permalink raw reply
* [PATCH] Prefer EMAIL to username@hostname.
From: Matt Kraai @ 2007-07-06 0:29 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
ident.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/ident.c b/ident.c
index 3d49608..6612d17 100644
--- a/ident.c
+++ b/ident.c
@@ -83,11 +83,18 @@ static void setup_ident(void)
}
if (!git_default_email[0]) {
- if (!pw)
- pw = getpwuid(getuid());
- if (!pw)
- die("You don't exist. Go away!");
- copy_email(pw);
+ const char *email = getenv("EMAIL");
+
+ if (email && email[0])
+ strlcpy(git_default_email, email,
+ sizeof(git_default_email));
+ else {
+ if (!pw)
+ pw = getpwuid(getuid());
+ if (!pw)
+ die("You don't exist. Go away!");
+ copy_email(pw);
+ }
}
/* And set the default date */
@@ -197,8 +204,6 @@ const char *fmt_ident(const char *name, const char *email,
name = git_default_name;
if (!email)
email = git_default_email;
- if (!email)
- email = getenv("EMAIL");
if (!*name) {
struct passwd *pw;
--
1.5.2.3
^ permalink raw reply related
* Re: Email address from username and hostname preferred over $EMAIL
From: Brandon Casey @ 2007-07-06 0:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mkraai, git
In-Reply-To: <alpine.LFD.0.98.0707051357360.9434@woody.linux-foundation.org>
Linus Torvalds wrote:
> If you want it to prefer $EMAIL, you'd need to change the initialization
> of git_default_email, methinks.
>
> Linus
I just sent an email to the list, and not in reply to this thread
because I thought I read a comment about not posting a patch deep in
a thread.
But, I'm thinking I should have just posted it as a reply to the thread
since I quoted a portion of your message.
-brandon
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Johannes Schindelin @ 2007-07-06 1:17 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com>
Hi,
[on this list, it is considered polite to not cull the Cc list anyway]
On Thu, 5 Jul 2007, Dan McGee wrote:
> In this commit:
> b516968ff62ec153e008d033c153affd7ba9ddc6
You might be interested to look only at the changes to builtin-push.c. I
have a hunch that you just need to disable setting the remote if
"remote.<name>.skipDefaultUpdate" is set.
Of course, for that to work, you would also need to add a member variable
to struct remote in remote.h, and handle it at the end of handle_config()
in remote.c.
Then just use remote->skip_default_update in builtin-push.c, to guard
around lines 90--93.
As for submitting, please read Documentation/SubmittingPatches first, it
is not really long, and most of it is obvious.
Hth,
Dscho
^ permalink raw reply
* Re: Email address from username and hostname preferred over $EMAIL
From: Junio C Hamano @ 2007-07-06 1:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Linus Torvalds, mkraai, git
In-Reply-To: <468D917F.9090707@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Linus Torvalds wrote:
>
>> If you want it to prefer $EMAIL, you'd need to change the
>> initialization of git_default_email, methinks.
>>
>> Linus
>
> I just sent an email to the list, and not in reply to this thread
> because I thought I read a comment about not posting a patch deep in
> a thread.
>
> But, I'm thinking I should have just posted it as a reply to the thread
> since I quoted a portion of your message.
Are Brandon Casey and Matt Kraai the same person?
I do not mind threadedness of the patch too much, but the patch
recently posted by the latter does not have any description
other than the title.
Other than that, I think the change itself seems sane.
^ 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