* Re: jgit and ignore
From: Tor Arne Vestbø @ 2009-03-01 14:21 UTC (permalink / raw)
To: Jon Smirl; +Cc: Ferry Huberts (Pelagic), Shawn O. Pearce, Git Mailing List
In-Reply-To: <9e4733910903010608u1777f0d4j843f12551154f962@mail.gmail.com>
Jon Smirl wrote:
> I have a C/C++ perspective open right now. Navigator is on the left,
> editor in the middle, outline on the right. In the navigator there are
> several files that should be ignored. I'd like to right click on them
> and select team/ignore. When I do that they will be ignored in git and
> also disappear from my navigator.
That would be Team->Add to .gitignore, as Eclipse does not have a way to
add files to the global ignore from context menus, but I agree, we
should have something like that eventually.
If we were to also remove ignored files from the views we would have to
either add a View Filter for .git-ignored files, or for globally ignored
files. Good idea for enhancement, please report in the issue tracker:
http://code.google.com/p/egit/issues/
> I also don't like how I have a global .git for all of my projects
> instead of a .git for each project individually. (Did I select that
> when I first installed egit and didn't know what I was doing?) Now I'm
> in a mess and can't publish individual projects.
That's a result of choosing "Create repository in project's parent
directory" when you shared the project in Eclipse.
Perhaps we should try to detect if the project is a Java (/JDT) project,
or otherwise likely to be a "child"-project, where it makes sense to
have the repository in the parent directory?
Tor Arne
^ permalink raw reply
* Re: jgit and ignore
From: Jon Smirl @ 2009-03-01 14:31 UTC (permalink / raw)
To: Tor Arne Vestbø
Cc: Ferry Huberts (Pelagic), Shawn O. Pearce, Git Mailing List
In-Reply-To: <49AA9A05.6010404@gmail.com>
On Sun, Mar 1, 2009 at 9:21 AM, Tor Arne Vestbø <torarnv@gmail.com> wrote:
> Jon Smirl wrote:
>> I have a C/C++ perspective open right now. Navigator is on the left,
>> editor in the middle, outline on the right. In the navigator there are
>> several files that should be ignored. I'd like to right click on them
>> and select team/ignore. When I do that they will be ignored in git and
>> also disappear from my navigator.
>
> That would be Team->Add to .gitignore, as Eclipse does not have a way to
> add files to the global ignore from context menus, but I agree, we
> should have something like that eventually.
>
> If we were to also remove ignored files from the views we would have to
> either add a View Filter for .git-ignored files, or for globally ignored
> files. Good idea for enhancement, please report in the issue tracker:
>
> http://code.google.com/p/egit/issues/
>
>> I also don't like how I have a global .git for all of my projects
>> instead of a .git for each project individually. (Did I select that
>> when I first installed egit and didn't know what I was doing?) Now I'm
>> in a mess and can't publish individual projects.
>
> That's a result of choosing "Create repository in project's parent
> directory" when you shared the project in Eclipse.
>
> Perhaps we should try to detect if the project is a Java (/JDT) project,
> or otherwise likely to be a "child"-project, where it makes sense to
> have the repository in the parent directory?
My .git got created in my workspace root. Is there ever a case where
you would want .git in your workspace root? If not, remove this choice
when the parent directory is the workspace root.
>
> Tor Arne
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: jgit and ignore
From: Tor Arne Vestbø @ 2009-03-01 14:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: Ferry Huberts (Pelagic), Shawn O. Pearce, Git Mailing List
In-Reply-To: <9e4733910903010631p51f9d4a7xddf9d823ff848bde@mail.gmail.com>
Jon Smirl wrote:
> On Sun, Mar 1, 2009 at 9:21 AM, Tor Arne Vestbø <torarnv@gmail.com> wrote:
>> Perhaps we should try to detect if the project is a Java (/JDT) project,
>> or otherwise likely to be a "child"-project, where it makes sense to
>> have the repository in the parent directory?
>
> My .git got created in my workspace root. Is there ever a case where
> you would want .git in your workspace root? If not, remove this choice
> when the parent directory is the workspace root.
That would be one heuristics to figure out if the option should be
enabled or disabled (or hidden) yes.
Could you open an issue in the issue tracker for this?
http://code.google.com/p/egit/issues/list
Tor Arne
^ permalink raw reply
* Re: jgit and ignore
From: Tor Arne Vestbø @ 2009-03-01 14:58 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: Jon Smirl, Shawn O. Pearce, Git Mailing List
In-Reply-To: <49AA91F0.7050008@pelagic.nl>
Ferry Huberts (Pelagic) wrote:
> Tor Arne Vestbø wrote:
>> In my opinion, EGit should default to using Eclipse's built in ignores,
>> but then detect the presence of a global core.excludesfile, in which
>> case it would notify the user ("I see you have a core.excludesfile") and
>> let the user switch to using that one instead.
[snip]
First of all, I do appreciate you working on the ignore feature :)
> I do not agree with your propasal however.
> We then would have different behaviour between how 'git' behaves within
> Eclipse (by means of the plugin) and how 'git' behaves within the
> command line. That alone can cause much more confusion.
I see what you mean, and I agree that in general the command line git
porcelain and the Eclipse git porcelain should work in similar ways.
But, with that said, I think of EGit as a standalone Eclipse-plugin
implementation of the git porcelain -- not just a wrapper around the
command line porcelain.
To me that means that EGit should focus just as much on integrating with
Eclipse properly as it does on keeping command line porcelain
interoperability.
The core.excludesfile is one such case, and I think my proposal is a
good compromise.
> Your proposal can also be implemented differently by (for example)
> building a UI that allows the user to edit the global ignore file.
That would be going out of scope of Eclipse as a framework, and also
does not solve the problem for those users who have a list of global
team ignores, and expect the Git plugin to just work with those ignores.
> The Eclipse global team ignores simply are too broad: think of the
> situation where I also have non-git project (like svn) in my workspace.
Not sure I understand? Isn't that exactly why you would have Eclipse's
global ignores specified in one place -- so that they could be shared
between version control systems instead of replicated in each repo?
Let' say you have a CVS project, a SVN project, and a Git project in
your workspace. The CVS and SVN projects would pick up ".bak" as an
ignore pattern from your team ignores, but the Git project would not.
To make the Git project pick it up, you would have to either add it
(repatedly for more than one project) to the .gitignore of that project,
or open an editor outside of Eclipse to edit your ~/.gitconfig.
Either ways seem redundant and awkward to me.
Tor Arne
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Joi Ellis @ 2009-03-01 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Miles Bader, Johannes Schindelin, git
In-Reply-To: <7vskmr43le.fsf@gitster.siamese.dyndns.org>
On Fri, 6 Feb 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Now, in this case, it was only one tweak and other responders have
> > already pointed him in the right direction. So just making that tweak
> > manually is probably the sane thing to do in this situation.
> >
> > But I wanted to point out that autoconf is not totally without value
> > here.
>
> I am not saying something that strong, either. If autoconf generated
> configure works _for you_ without hassle, great. Keep using it.
>
> The original message that started this thread was what to do when it does
> NOT work for you, and my point was in general it is much nicer to point at
> the knob to tweak from the make invocation command line (or in config.mak)
> than having you spend time on upgrade autoconf, generate configure and run
> it.
Actually, guys, if you go back and re-read my original message, I was
pointing out that if you use a 'git clone' to get a build tree, THERE IS
NO CONFIGURE SCRIPT in the tree.
The problem is not that the configure script does not work. I pointed
out in the first paragraph that the configure script in the TARBALL
works just fine. What I pointed out is that the build tree DOES NOT
PROVIDE THE CONFIGURE SCRIPT. All I asked you to do is to consider
adding the configure script to the repository so that it gets pushed out
in a clone.
> Fanboys may say that autoconf generated configure is the greatest thing
> since sliced bread. But let's face it. Honestly, the track record of
> those people in keeping autoconf part in this project up-to-date has not
> been all that great. There are things that the generated configure file
> does not detect nor configure correctly (we had --with-expat patch, and we
> also saw "the trailing slash in template_dir definition in config.mak.in"
> discussed fairly recently). You are much better off tweaking known
> peculiarity of your platform in config.mak, when configure does not work
> out of box for you.
I've been building and installing multi-platform *nix software on
various flavors for two decades now. "./configure && make && make install" has
been the standard build process even before GNU. The whole point of
autoconf/configure/make tools is to eliminate the need to manually tweak
makefiles so that software is easily portable between platforms.
I got such a rash of SNOTTY messages from you folks, all directed to me
privately, that I nearly deleted git from my laptop altogether. You can be
sure I will not bother attempting to build git from a clone ever again.
I took the time to debug and diagnose the build failures I was getting,
and I tried to politely pass it along in case anyone cares.
Clearly, you don't. I shall not waste your or my time any further.
--
Joi Ellis
gyles19@visi.com
No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried. Anything
that kicks a monopoly in the pants has got to be good for something.
- Chris Johnson
^ permalink raw reply
* [PATCH v2] send-email: add --confirm option
From: Jay Soffian @ 2009-03-01 16:17 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Nanako Shiraishi, Junio C Hamano, Paul Gortmaker
In-Reply-To: <7vhc2d8vjk.fsf@gitster.siamese.dyndns.org>
send-email violates the principle of least surprise by automatically
cc'ing additional recipients without confirming this with the user.
This patch teaches send-email a --confirm option. It takes the
following values:
--confirm=always always confirm before sending
--confirm=never never confirm before sending
--confirm=cc confirm before sending when send-email has
automatically added addresses from the patch to
the Cc list
--confirm=compose confirm before sending the first message when
using --compose. (Needed to maintain backwards
compatibility with existing behavior.)
--confirm=auto 'cc' + 'compose'
The option defaults to 'compose' if any suppress Cc related options have
been used, otherwise it defaults to 'auto'.
Unfortunately, it is impossible to introduce this patch such that it
helps new users without potentially upsetting some existing users. We
attempt to mitigate the latter by:
* Allowing the user to "git config sendemail.config never"
* Allowing the user to say "all" after the first prompt to not be
prompted on remaining emails during the same invocation.
* Telling the user about the "sendemail.confirm" setting whenever they
use "all"
* Only prompting if no --suppress related options have been passed, as
using such an option is likely to indicate an experienced send-email
user.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Changes from v1:
- Added no-confirm tests, and put them early to prevent the rest of
the tests from potentially hanging. Note if one of these tests
fails then we exit t9001-send-email.sh immediately.
- Added verification of the --confirm setting. (I had done this
previously but somehow failed to stage it.)
- Added additional language to the commit messsage in an attempt to
provide justification for the change in default behavior.
- When the user specifies "all" in response to a confirm prompt, we
hint them about how to use "sendemail.confirm" config setting.
Documentation/git-send-email.txt | 16 ++++++
git-send-email.perl | 72 +++++++++++++++++--------
t/t9001-send-email.sh | 108 ++++++++++++++++++++++++++++++++------
3 files changed, 157 insertions(+), 39 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 164d149..bcf7ff1 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -199,6 +199,22 @@ specified, as well as 'body' if --no-signed-off-cc is specified.
Administering
~~~~~~~~~~~~~
+--confirm::
+ Confirm just before sending:
++
+--
+- 'always' will always confirm before sending
+- 'never' will never confirm before sending
+- 'cc' will confirm before sending when send-email has automatically
+ added addresses from the patch to the Cc list
+- 'compose' will confirm before sending the first message when using --compose.
+- 'auto' is equivalent to 'cc' + 'compose'
+--
++
+Default is the value of 'sendemail.confirm' configuration value; if that
+is unspecified, default to 'auto' unless any of the suppress options
+have been specified, in which case default to 'compose'.
+
--dry-run::
Do everything except actually send the emails.
diff --git a/git-send-email.perl b/git-send-email.perl
index adf7ecb..439b70b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -75,6 +75,8 @@ git send-email [options] <file | directory | rev-list options >
--[no-]thread * Use In-Reply-To: field. Default on.
Administering:
+ --confirm <str> * Confirm recipients before sending;
+ auto, cc, compose, always, or never.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
--[no-]validate * Perform patch sanity checks. Default on.
@@ -181,7 +183,7 @@ sub do_edit {
my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
-my ($validate);
+my ($validate, $confirm);
my (@suppress_cc);
my %config_bool_settings = (
@@ -207,6 +209,7 @@ my %config_settings = (
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
"multiedit" => \$multiedit,
+ "confirm" => \$confirm,
);
# Handle Uncouth Termination
@@ -258,6 +261,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
+ "confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -346,6 +350,13 @@ if ($suppress_cc{'body'}) {
delete $suppress_cc{'body'};
}
+# Set confirm
+if (!defined $confirm) {
+ $confirm = scalar %suppress_cc ? 'compose' : 'auto';
+};
+die "Unknown --confirm setting: '$confirm'\n"
+ unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
+
# Debugging, print out the suppressions.
if (0) {
print "suppressions:\n";
@@ -663,25 +674,13 @@ if (!defined $smtp_server) {
$smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
}
-if ($compose) {
- while (1) {
- $_ = $term->readline("Send this email? (y|n) ");
- last if defined $_;
- print "\n";
- }
-
- if (uc substr($_,0,1) ne 'Y') {
- cleanup_compose_files();
- exit(0);
- }
-
- if ($compose > 0) {
- @files = ($compose_filename . ".final", @files);
- }
+if ($compose && $compose > 0) {
+ @files = ($compose_filename . ".final", @files);
}
# Variables we set as part of the loop over files
-our ($message_id, %mail, $subject, $reply_to, $references, $message);
+our ($message_id, %mail, $subject, $reply_to, $references, $message,
+ $needs_confirm, $message_num);
sub extract_valid_address {
my $address = shift;
@@ -837,6 +836,27 @@ X-Mailer: git-send-email $gitversion
unshift (@sendmail_parameters,
'-f', $raw_from) if(defined $envelope_sender);
+ if ($needs_confirm && !$dry_run) {
+ print "\n$header\n";
+ while (1) {
+ chomp ($_ = $term->readline(
+ "Send this email? ([y]es|[n]o|[q]uit|[a]ll): "
+ ));
+ last if /^(?:yes|y|no|n|quit|q|all|a)/i;
+ print "\n";
+ }
+ if (/^n/i) {
+ return;
+ } elsif (/^q/i) {
+ cleanup_compose_files();
+ exit(0);
+ } elsif (/^a/i) {
+ $confirm = 'never';
+ print "You may disable all future prompting via sendemail.confirm;\n";
+ print "Run 'git send-email --help' for details.\n";
+ }
+ }
+
if ($dry_run) {
# We don't want to send the email.
} elsif ($smtp_server =~ m#^/#) {
@@ -935,6 +955,7 @@ X-Mailer: git-send-email $gitversion
$reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
$subject = $initial_subject;
+$message_num = 0;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
@@ -943,11 +964,12 @@ foreach my $t (@files) {
my $author_encoding;
my $has_content_type;
my $body_encoding;
- @cc = @initial_cc;
+ @cc = ();
@xh = ();
my $input_format = undef;
my @header = ();
$message = "";
+ $message_num++;
# First unfold multiline header fields
while(<F>) {
last if /^\s*$/;
@@ -1080,6 +1102,13 @@ foreach my $t (@files) {
}
}
+ $needs_confirm = (
+ $confirm eq "always" or
+ ($confirm =~ /^(?:auto|cc)$/ && @cc) or
+ ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
+
+ @cc = (@initial_cc, @cc);
+
send_message();
# set up for the next message
@@ -1094,13 +1123,10 @@ foreach my $t (@files) {
$message_id = undef;
}
-if ($compose) {
- cleanup_compose_files();
-}
+cleanup_compose_files();
sub cleanup_compose_files() {
- unlink($compose_filename, $compose_filename . ".final");
-
+ unlink($compose_filename, $compose_filename . ".final") if $compose;
}
$smtp->quit if $smtp;
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 4df4f96..08d5b91 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -35,6 +35,47 @@ test_expect_success 'Extract patches' '
patches=`git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1`
'
+# Test no confirm early to ensure remaining tests will not hang
+test_no_confirm () {
+ rm -f no_confirm_okay
+ echo n | \
+ GIT_SEND_EMAIL_NOTTY=1 \
+ git send-email \
+ --from="Example <from@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $@ \
+ $patches > stdout &&
+ test_must_fail grep "Send this email" stdout &&
+ > no_confirm_okay
+}
+
+# Exit immediately to prevent hang if a no-confirm test fails
+check_no_confirm () {
+ test -f no_confirm_okay || {
+ say 'No confirm test failed; skipping remaining tests to prevent hanging'
+ test_done
+ }
+}
+
+test_expect_success 'No confirm with --suppress-cc' '
+ test_no_confirm --suppress-cc=sob
+'
+check_no_confirm
+
+test_expect_success 'No confirm with --confirm=never' '
+ test_no_confirm --confirm=never
+'
+check_no_confirm
+
+# leave sendemail.confirm set to never after this so that none of the
+# remaining tests prompt unintentionally.
+test_expect_success 'No confirm with sendemail.confirm=never' '
+ git config sendemail.confirm never &&
+ test_no_confirm --compose --subject=foo
+'
+check_no_confirm
+
test_expect_success 'Send patches' '
git send-email --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
'
@@ -175,15 +216,13 @@ test_set_editor "$(pwd)/fake-editor"
test_expect_success '--compose works' '
clean_fake_sendmail &&
- echo y | \
- GIT_SEND_EMAIL_NOTTY=1 \
- git send-email \
- --compose --subject foo \
- --from="Example <nobody@example.com>" \
- --to=nobody@example.com \
- --smtp-server="$(pwd)/fake.sendmail" \
- $patches \
- 2>errors
+ git send-email \
+ --compose --subject foo \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $patches \
+ 2>errors
'
test_expect_success 'first message is compose text' '
@@ -375,15 +414,56 @@ test_expect_success '--suppress-cc=cc' '
test_suppression cc
'
+test_confirm () {
+ echo y | \
+ GIT_SEND_EMAIL_NOTTY=1 \
+ git send-email \
+ --from="Example <nobody@example.com>" \
+ --to=nobody@example.com \
+ --smtp-server="$(pwd)/fake.sendmail" \
+ $@ \
+ $patches | grep "Send this email"
+}
+
+test_expect_success '--confirm=always' '
+ test_confirm --confirm=always --suppress-cc=all
+'
+
+test_expect_success '--confirm=auto' '
+ test_confirm --confirm=auto
+'
+
+test_expect_success '--confirm=cc' '
+ test_confirm --confirm=cc
+'
+
+test_expect_success '--confirm=compose' '
+ test_confirm --confirm=compose --compose
+'
+
+test_expect_success 'confirm by default (due to cc)' '
+ CONFIRM=$(git config --get sendemail.confirm) &&
+ git config --unset sendemail.confirm &&
+ test_confirm &&
+ git config sendemail.confirm $CONFIRM
+'
+
+test_expect_success 'confirm by default (due to --compose)' '
+ CONFIRM=$(git config --get sendemail.confirm) &&
+ git config --unset sendemail.confirm &&
+ test_confirm --suppress-cc=all --compose
+ ret="$?"
+ git config sendemail.confirm ${CONFIRM:-never}
+ test $ret = "0"
+'
+
test_expect_success '--compose adds MIME for utf8 body' '
clean_fake_sendmail &&
(echo "#!$SHELL_PATH" &&
echo "echo utf8 body: àéìöú >>\"\$1\""
) >fake-editor-utf8 &&
chmod +x fake-editor-utf8 &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
@@ -405,9 +485,7 @@ test_expect_success '--compose respects user mime type' '
echo " echo utf8 body: àéìöú) >\"\$1\""
) >fake-editor-utf8-mime &&
chmod +x fake-editor-utf8-mime &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor-utf8-mime\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject foo \
--from="Example <nobody@example.com>" \
@@ -421,9 +499,7 @@ test_expect_success '--compose respects user mime type' '
test_expect_success '--compose adds MIME for utf8 subject' '
clean_fake_sendmail &&
- echo y | \
GIT_EDITOR="\"$(pwd)/fake-editor\"" \
- GIT_SEND_EMAIL_NOTTY=1 \
git send-email \
--compose --subject utf8-sübjëct \
--from="Example <nobody@example.com>" \
@@ -445,7 +521,7 @@ test_expect_success 'detects ambiguous reference/file conflict' '
test_expect_success 'feed two files' '
rm -fr outdir &&
git format-patch -2 -o outdir &&
- GIT_SEND_EMAIL_NOTTY=1 git send-email \
+ git send-email \
--dry-run \
--from="Example <nobody@example.com>" \
--to=nobody@example.com \
--
1.6.2.rc1.309.g5f417
^ permalink raw reply related
* Re: Chicken/egg problem building from a 'git clone'
From: Björn Steinbrink @ 2009-03-01 16:34 UTC (permalink / raw)
To: Joi Ellis
Cc: Junio C Hamano, Jeff King, Miles Bader, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.44.0903010945290.4675-100000@localhost.localdomain>
On 2009.03.01 09:56:46 -0600, Joi Ellis wrote:
> On Fri, 6 Feb 2009, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > Now, in this case, it was only one tweak and other responders have
> > > already pointed him in the right direction. So just making that tweak
> > > manually is probably the sane thing to do in this situation.
> > >
> > > But I wanted to point out that autoconf is not totally without value
> > > here.
> >
> > I am not saying something that strong, either. If autoconf generated
> > configure works _for you_ without hassle, great. Keep using it.
> >
> > The original message that started this thread was what to do when it does
> > NOT work for you, and my point was in general it is much nicer to point at
> > the knob to tweak from the make invocation command line (or in config.mak)
> > than having you spend time on upgrade autoconf, generate configure and run
> > it.
>
> Actually, guys, if you go back and re-read my original message, I was
> pointing out that if you use a 'git clone' to get a build tree, THERE IS
> NO CONFIGURE SCRIPT in the tree.
And Junio was talking about the Makefile not working for you. And btw,
if you want a real chicken/egg problem, go complaining to the autoconf
folks that the autoconf git repository has no configure script either.
And autoconf actually requires autoconf for bootstrapping AFAICT, while
git does not. I'm sure they'll be happy to explain to you why having a
generated configure script in the repo is not a good idea.
Björn
^ permalink raw reply
* git monthly links: 2009-02
From: Felipe Contreras @ 2009-03-01 16:44 UTC (permalink / raw)
To: git
Hi,
git monthly links is my attempt to gather all the links people have
been tagging as "git" in delicious.com[1] (these are not chosen by
me). It's a manual process so I might miss some links; I subscribe to
the RSS feed and go through all the links simply picking the ones
tagged the most.
The fancier blog version is here:
http://gitlog.wordpress.com/2009/03/01/git-monthly-links-2009-02/
== Hot ==
This month there was a lot of stuff from Japan, too bad I don't
understand it, Dulwich, and a lot more.
Dulwich: pure-Python implementation of the Git file formats and protocols
http://samba.org/~jelmer/dulwich/
分散バージョン管理システムGit入門 - SourceForge.JP Magazine
http://sourceforge.jp/magazine/09/02/02/0655246
Git is the C of Version Control Tools
http://www.ericsink.com/entries/git_index.html
Git for the real world
Twitter developer explains how git should be used in his opinion.
http://robey.lag.net/2008/07/13/git-for-the-real-world.html
flashbake « Bit Bucket Labs
Scripts to automate git for non-technical users.
http://bitbucketlabs.net/flashbake/
Easy Git -- git for mere mortals
Single-file wrapper script for git, designed to make git easy to learn and use.
http://www.gnome.org/~newren/eg/
git ready » what git is not
http://gitready.com/beginner/2009/02/19/what-git-is-not.html
git ready » how git stores your data
http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
git ready » converting from svn
http://gitready.com/beginner/2009/02/04/converting-from-svn.html
git ready » intro to rebase
http://gitready.com/intermediate/2009/01/31/intro-to-rebase.html
【コラム】今週の注目オンラインソフト for Mac OS X (51) バージョン管理システムGit用GUIフロントエンド「GitX」 |
パソコン | マイコミジャーナル
http://journal.mycom.co.jp/column/softwares_for_macosx/051/index.html
デブサミ2009 はてなの開発戦略 - 川o・-・）＜2nd life
http://d.hatena.ne.jp/secondlife/20090213/1234502842
デブサミ2009「株式会社はてなの開発戦略」講演メモ - RX-7乗りの適当な日々
http://d.hatena.ne.jp/rx7/20090212/p1
== Other links ==
Developers Summit 2009 1日目にちょこっとだけ行ってきました - d.hatena.zeg.la
http://d.hatena.ne.jp/zegenvs/20090212/p1
Git for the lazy - Spheriki
http://www.spheredev.org/wiki/Git_for_the_lazy
git cheat sheet
http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png
Fully automated bisecting with "git bisect run" [LWN.net]
http://lwn.net/Articles/317154/
thomas.apestaart.org » ways in which git makes the opposite of sense to me
http://thomas.apestaart.org/log/?p=487
git のある生活 - KBDAHOLIC - やぬすさんとこ
http://d.hatena.ne.jp/janus_wel/20090209/1234277892
git ちゃんさま - KBDAHOLIC - やぬすさんとこ
http://d.hatena.ne.jp/janus_wel/20090207/1234031200
Bedazzle Your Bash Prompt with Git Info // RailsTips by John Nunemaker
http://railstips.org/2009/2/2/bedazzle-your-bash-prompt-with-git-info
Git Tip: How to “Merge” Specific Files from Another Branch
http://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/
The Git Bell: post-commit → ruby → arduino → bell - Ideas For Dozens
http://www.urbanhonking.com/ideasfordozens/2009/02/the_git_bell_postcommit_ruby_a.html
Nardol: Git basics: reversing the 'git sucks' effect
http://www.nardol.org/2009/2/19/git-basics-reversing-the-git-sucks-effect
Scott James Remnant » Blog Archive » GIT sucks (2)
http://www.netsplit.com/2009/02/17/git-sucks-2/
[1] http://delicious.com/tag/git
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] git.el: Only show completions from refs/heads
From: Alexandre Julliard @ 2009-03-01 16:56 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87vdqztvrl.fsf_-_@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
> ---
>
> Here is a version that can to both commit name lookup and branch name
> lookup, and with a configuration parameter that determines how to find
> branch names to complete on.
Why do you introduce a separate function for checkouts? I don't see
much need to have a different set of completions for checkout
vs. cherry-pick, they both can be used with an arbitrary commit anyway.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path"
From: Shawn O. Pearce @ 2009-03-01 17:04 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090301100039.GD4146@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Feb 28, 2009 at 09:54:56PM -0800, Junio C Hamano wrote:
>
> > One issue I did not describe in the message was to what extent we would
> > want to allow operations other than the creating of a new repository
> > itself.
> >
> > "Other than the creation" includes things like these:
>
> Hmph. I am not too excited by this list. What is the advantage of doing
> them over the git protocol versus some out-of-band method?
My feelings echo Peff's here.
> Furthermore, in the case of many providers (e.g., github,
> repo.or.cz), there is already a separate out-of-band interface for
> doing "meta" stuff, like managing user accounts and repos. Isn't it
> more natural for them to integrate these features with their
> existing interfaces?
Don't forget about my day-job project, Gerrit Code Review.
I'm already hosting 138 projects on review.source.android.com, and
based on weekly downloads of Gerrit builds I'd estimate another ~60
deployments at internal servers within organizations. (I'm doing
weekly "stable" builds and I'm seeing an average of ~70 downloads
for each build.)
> But let's say that there really is some value in setting up this
> channel (because we want a uniform way of doing these things so we can
> add more automated tool support from the client side). Then I think it
> makes sense to look at what the people in (2) above are doing already.
> That is, what sorts of things can you already do (and not do) in
> github's or repo.or.cz's interface? On top of that, it probably makes
> sense to ask them if they are interested in such a feature, as they
> would be primary users. And if they are, what do they want out of it?
Earlier last week a co-worker who is new to git complained that he
can't create a repository easily from his desktop. There may be
value in being able to create a repository remotely, as it removes
that confusion.
But I think that's only true for situations where you are likely the
owner of the repository in your own home directory, such as ~you
on kernel.org. For "hosted repositories" like any of the systems
you described above, there is a lot more to the creation than just
executing "git init" somewhere.
FWIW, JGit automatically creates a repository over the amazon-s3://
transport during push if it doesn't exist yet. In my mind, this is
somewhat like scp or rsync automatically creating the destination
directory when recursively copying a directory. For the usage of
creating a new repository in your own home directory on some remote
server, why isn't this just an option to git push?
git push --create me@george:my/new/repo.git master
It fits better with the push-creates-a-branch feature.
Gitosis allows repositories to be created during the first push
into that repository, if the repository is listed in the config
and the user is permitted to write to it.
GitHub and repo.or.cz allow you to create empty repositories,
but both do so through the web interface.
Gerrit Code Review still requires you to manually run "git init"
and also do a SQL INSERT by hand. Its missing some sort of user
friendly repository creation feature. But I'm starting to consider
doing it automatically during "git push", like gitosis does.
Repository creation in Gerrit is more than just "git init" and
a SQL INSERT. I also have to run rsync a few times to replicate
the repository onto multiple servers, so that subsequent pushes
to those servers won't fail.
I suspect the situation is the same for GitHub; I know they have
a custom daemon that handles repository mapping, and some database
behind that daemon to store those translations.
IMHO, _if_ we do support remote repository creation, it should match
branch creation UI better (meaning, be part of git push, not part of
git init), and it should be something that the hosted providers can
all hook into so we can keep our non-git state management current.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] send-email: add --confirm option
From: Paul Gortmaker @ 2009-03-01 17:09 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Nanako Shiraishi, Junio C Hamano
In-Reply-To: <1235924234-16923-1-git-send-email-jaysoffian@gmail.com>
On Sun, Mar 1, 2009 at 11:17 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> send-email violates the principle of least surprise by automatically
> cc'ing additional recipients without confirming this with the user.
>
> This patch teaches send-email a --confirm option. It takes the
> following values:
>
> --confirm=always always confirm before sending
> --confirm=never never confirm before sending
> --confirm=cc confirm before sending when send-email has
> automatically added addresses from the patch to
> the Cc list
> --confirm=compose confirm before sending the first message when
> using --compose. (Needed to maintain backwards
> compatibility with existing behavior.)
> --confirm=auto 'cc' + 'compose'
>
> The option defaults to 'compose' if any suppress Cc related options have
> been used, otherwise it defaults to 'auto'.
>
> Unfortunately, it is impossible to introduce this patch such that it
> helps new users without potentially upsetting some existing users. We
> attempt to mitigate the latter by:
>
> * Allowing the user to "git config sendemail.config never"
I think it should be sendemail.confirm in the above. Thanks for
taking this seriously -- I think lots of new git users (who probably
will never make it to this list) will benefit from it without ever
even knowing.
Paul.
> * Allowing the user to say "all" after the first prompt to not be
> prompted on remaining emails during the same invocation.
> * Telling the user about the "sendemail.confirm" setting whenever they
> use "all"
> * Only prompting if no --suppress related options have been passed, as
> using such an option is likely to indicate an experienced send-email
> user.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> Changes from v1:
>
> - Added no-confirm tests, and put them early to prevent the rest of
> the tests from potentially hanging. Note if one of these tests
> fails then we exit t9001-send-email.sh immediately.
>
> - Added verification of the --confirm setting. (I had done this
> previously but somehow failed to stage it.)
>
> - Added additional language to the commit messsage in an attempt to
> provide justification for the change in default behavior.
>
> - When the user specifies "all" in response to a confirm prompt, we
> hint them about how to use "sendemail.confirm" config setting.
>
> Documentation/git-send-email.txt | 16 ++++++
> git-send-email.perl | 72 +++++++++++++++++--------
> t/t9001-send-email.sh | 108 ++++++++++++++++++++++++++++++++------
> 3 files changed, 157 insertions(+), 39 deletions(-)
>
> diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
> index 164d149..bcf7ff1 100644
> --- a/Documentation/git-send-email.txt
> +++ b/Documentation/git-send-email.txt
> @@ -199,6 +199,22 @@ specified, as well as 'body' if --no-signed-off-cc is specified.
> Administering
> ~~~~~~~~~~~~~
>
> +--confirm::
> + Confirm just before sending:
> ++
> +--
> +- 'always' will always confirm before sending
> +- 'never' will never confirm before sending
> +- 'cc' will confirm before sending when send-email has automatically
> + added addresses from the patch to the Cc list
> +- 'compose' will confirm before sending the first message when using --compose.
> +- 'auto' is equivalent to 'cc' + 'compose'
> +--
> ++
> +Default is the value of 'sendemail.confirm' configuration value; if that
> +is unspecified, default to 'auto' unless any of the suppress options
> +have been specified, in which case default to 'compose'.
> +
> --dry-run::
> Do everything except actually send the emails.
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index adf7ecb..439b70b 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -75,6 +75,8 @@ git send-email [options] <file | directory | rev-list options >
> --[no-]thread * Use In-Reply-To: field. Default on.
>
> Administering:
> + --confirm <str> * Confirm recipients before sending;
> + auto, cc, compose, always, or never.
> --quiet * Output one line of info per email.
> --dry-run * Don't actually send the emails.
> --[no-]validate * Perform patch sanity checks. Default on.
> @@ -181,7 +183,7 @@ sub do_edit {
> my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
> my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
> my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
> -my ($validate);
> +my ($validate, $confirm);
> my (@suppress_cc);
>
> my %config_bool_settings = (
> @@ -207,6 +209,7 @@ my %config_settings = (
> "suppresscc" => \@suppress_cc,
> "envelopesender" => \$envelope_sender,
> "multiedit" => \$multiedit,
> + "confirm" => \$confirm,
> );
>
> # Handle Uncouth Termination
> @@ -258,6 +261,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
> "suppress-from!" => \$suppress_from,
> "suppress-cc=s" => \@suppress_cc,
> "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
> + "confirm=s" => \$confirm,
> "dry-run" => \$dry_run,
> "envelope-sender=s" => \$envelope_sender,
> "thread!" => \$thread,
> @@ -346,6 +350,13 @@ if ($suppress_cc{'body'}) {
> delete $suppress_cc{'body'};
> }
>
> +# Set confirm
> +if (!defined $confirm) {
> + $confirm = scalar %suppress_cc ? 'compose' : 'auto';
> +};
> +die "Unknown --confirm setting: '$confirm'\n"
> + unless $confirm =~ /^(?:auto|cc|compose|always|never)/;
> +
> # Debugging, print out the suppressions.
> if (0) {
> print "suppressions:\n";
> @@ -663,25 +674,13 @@ if (!defined $smtp_server) {
> $smtp_server ||= 'localhost'; # could be 127.0.0.1, too... *shrug*
> }
>
> -if ($compose) {
> - while (1) {
> - $_ = $term->readline("Send this email? (y|n) ");
> - last if defined $_;
> - print "\n";
> - }
> -
> - if (uc substr($_,0,1) ne 'Y') {
> - cleanup_compose_files();
> - exit(0);
> - }
> -
> - if ($compose > 0) {
> - @files = ($compose_filename . ".final", @files);
> - }
> +if ($compose && $compose > 0) {
> + @files = ($compose_filename . ".final", @files);
> }
>
> # Variables we set as part of the loop over files
> -our ($message_id, %mail, $subject, $reply_to, $references, $message);
> +our ($message_id, %mail, $subject, $reply_to, $references, $message,
> + $needs_confirm, $message_num);
>
> sub extract_valid_address {
> my $address = shift;
> @@ -837,6 +836,27 @@ X-Mailer: git-send-email $gitversion
> unshift (@sendmail_parameters,
> '-f', $raw_from) if(defined $envelope_sender);
>
> + if ($needs_confirm && !$dry_run) {
> + print "\n$header\n";
> + while (1) {
> + chomp ($_ = $term->readline(
> + "Send this email? ([y]es|[n]o|[q]uit|[a]ll): "
> + ));
> + last if /^(?:yes|y|no|n|quit|q|all|a)/i;
> + print "\n";
> + }
> + if (/^n/i) {
> + return;
> + } elsif (/^q/i) {
> + cleanup_compose_files();
> + exit(0);
> + } elsif (/^a/i) {
> + $confirm = 'never';
> + print "You may disable all future prompting via sendemail.confirm;\n";
> + print "Run 'git send-email --help' for details.\n";
> + }
> + }
> +
> if ($dry_run) {
> # We don't want to send the email.
> } elsif ($smtp_server =~ m#^/#) {
> @@ -935,6 +955,7 @@ X-Mailer: git-send-email $gitversion
> $reply_to = $initial_reply_to;
> $references = $initial_reply_to || '';
> $subject = $initial_subject;
> +$message_num = 0;
>
> foreach my $t (@files) {
> open(F,"<",$t) or die "can't open file $t";
> @@ -943,11 +964,12 @@ foreach my $t (@files) {
> my $author_encoding;
> my $has_content_type;
> my $body_encoding;
> - @cc = @initial_cc;
> + @cc = ();
> @xh = ();
> my $input_format = undef;
> my @header = ();
> $message = "";
> + $message_num++;
> # First unfold multiline header fields
> while(<F>) {
> last if /^\s*$/;
> @@ -1080,6 +1102,13 @@ foreach my $t (@files) {
> }
> }
>
> + $needs_confirm = (
> + $confirm eq "always" or
> + ($confirm =~ /^(?:auto|cc)$/ && @cc) or
> + ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
> +
> + @cc = (@initial_cc, @cc);
> +
> send_message();
>
> # set up for the next message
> @@ -1094,13 +1123,10 @@ foreach my $t (@files) {
> $message_id = undef;
> }
>
> -if ($compose) {
> - cleanup_compose_files();
> -}
> +cleanup_compose_files();
>
> sub cleanup_compose_files() {
> - unlink($compose_filename, $compose_filename . ".final");
> -
> + unlink($compose_filename, $compose_filename . ".final") if $compose;
> }
>
> $smtp->quit if $smtp;
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index 4df4f96..08d5b91 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -35,6 +35,47 @@ test_expect_success 'Extract patches' '
> patches=`git format-patch -s --cc="One <one@example.com>" --cc=two@example.com -n HEAD^1`
> '
>
> +# Test no confirm early to ensure remaining tests will not hang
> +test_no_confirm () {
> + rm -f no_confirm_okay
> + echo n | \
> + GIT_SEND_EMAIL_NOTTY=1 \
> + git send-email \
> + --from="Example <from@example.com>" \
> + --to=nobody@example.com \
> + --smtp-server="$(pwd)/fake.sendmail" \
> + $@ \
> + $patches > stdout &&
> + test_must_fail grep "Send this email" stdout &&
> + > no_confirm_okay
> +}
> +
> +# Exit immediately to prevent hang if a no-confirm test fails
> +check_no_confirm () {
> + test -f no_confirm_okay || {
> + say 'No confirm test failed; skipping remaining tests to prevent hanging'
> + test_done
> + }
> +}
> +
> +test_expect_success 'No confirm with --suppress-cc' '
> + test_no_confirm --suppress-cc=sob
> +'
> +check_no_confirm
> +
> +test_expect_success 'No confirm with --confirm=never' '
> + test_no_confirm --confirm=never
> +'
> +check_no_confirm
> +
> +# leave sendemail.confirm set to never after this so that none of the
> +# remaining tests prompt unintentionally.
> +test_expect_success 'No confirm with sendemail.confirm=never' '
> + git config sendemail.confirm never &&
> + test_no_confirm --compose --subject=foo
> +'
> +check_no_confirm
> +
> test_expect_success 'Send patches' '
> git send-email --suppress-cc=sob --from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
> '
> @@ -175,15 +216,13 @@ test_set_editor "$(pwd)/fake-editor"
>
> test_expect_success '--compose works' '
> clean_fake_sendmail &&
> - echo y | \
> - GIT_SEND_EMAIL_NOTTY=1 \
> - git send-email \
> - --compose --subject foo \
> - --from="Example <nobody@example.com>" \
> - --to=nobody@example.com \
> - --smtp-server="$(pwd)/fake.sendmail" \
> - $patches \
> - 2>errors
> + git send-email \
> + --compose --subject foo \
> + --from="Example <nobody@example.com>" \
> + --to=nobody@example.com \
> + --smtp-server="$(pwd)/fake.sendmail" \
> + $patches \
> + 2>errors
> '
>
> test_expect_success 'first message is compose text' '
> @@ -375,15 +414,56 @@ test_expect_success '--suppress-cc=cc' '
> test_suppression cc
> '
>
> +test_confirm () {
> + echo y | \
> + GIT_SEND_EMAIL_NOTTY=1 \
> + git send-email \
> + --from="Example <nobody@example.com>" \
> + --to=nobody@example.com \
> + --smtp-server="$(pwd)/fake.sendmail" \
> + $@ \
> + $patches | grep "Send this email"
> +}
> +
> +test_expect_success '--confirm=always' '
> + test_confirm --confirm=always --suppress-cc=all
> +'
> +
> +test_expect_success '--confirm=auto' '
> + test_confirm --confirm=auto
> +'
> +
> +test_expect_success '--confirm=cc' '
> + test_confirm --confirm=cc
> +'
> +
> +test_expect_success '--confirm=compose' '
> + test_confirm --confirm=compose --compose
> +'
> +
> +test_expect_success 'confirm by default (due to cc)' '
> + CONFIRM=$(git config --get sendemail.confirm) &&
> + git config --unset sendemail.confirm &&
> + test_confirm &&
> + git config sendemail.confirm $CONFIRM
> +'
> +
> +test_expect_success 'confirm by default (due to --compose)' '
> + CONFIRM=$(git config --get sendemail.confirm) &&
> + git config --unset sendemail.confirm &&
> + test_confirm --suppress-cc=all --compose
> + ret="$?"
> + git config sendemail.confirm ${CONFIRM:-never}
> + test $ret = "0"
> +'
> +
> test_expect_success '--compose adds MIME for utf8 body' '
> clean_fake_sendmail &&
> (echo "#!$SHELL_PATH" &&
> echo "echo utf8 body: àéìöú >>\"\$1\""
> ) >fake-editor-utf8 &&
> chmod +x fake-editor-utf8 &&
> - echo y | \
> GIT_EDITOR="\"$(pwd)/fake-editor-utf8\"" \
> - GIT_SEND_EMAIL_NOTTY=1 \
> git send-email \
> --compose --subject foo \
> --from="Example <nobody@example.com>" \
> @@ -405,9 +485,7 @@ test_expect_success '--compose respects user mime type' '
> echo " echo utf8 body: àéìöú) >\"\$1\""
> ) >fake-editor-utf8-mime &&
> chmod +x fake-editor-utf8-mime &&
> - echo y | \
> GIT_EDITOR="\"$(pwd)/fake-editor-utf8-mime\"" \
> - GIT_SEND_EMAIL_NOTTY=1 \
> git send-email \
> --compose --subject foo \
> --from="Example <nobody@example.com>" \
> @@ -421,9 +499,7 @@ test_expect_success '--compose respects user mime type' '
>
> test_expect_success '--compose adds MIME for utf8 subject' '
> clean_fake_sendmail &&
> - echo y | \
> GIT_EDITOR="\"$(pwd)/fake-editor\"" \
> - GIT_SEND_EMAIL_NOTTY=1 \
> git send-email \
> --compose --subject utf8-sübjëct \
> --from="Example <nobody@example.com>" \
> @@ -445,7 +521,7 @@ test_expect_success 'detects ambiguous reference/file conflict' '
> test_expect_success 'feed two files' '
> rm -fr outdir &&
> git format-patch -2 -o outdir &&
> - GIT_SEND_EMAIL_NOTTY=1 git send-email \
> + git send-email \
> --dry-run \
> --from="Example <nobody@example.com>" \
> --to=nobody@example.com \
> --
> 1.6.2.rc1.309.g5f417
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: jgit and ignore
From: Shawn O. Pearce @ 2009-03-01 17:16 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Ferry Huberts (Pelagic), Jon Smirl, Git Mailing List
In-Reply-To: <49AAA2B3.40808@gmail.com>
Tor Arne Vestbø <torarnv@gmail.com> wrote:
>
> But, with that said, I think of EGit as a standalone Eclipse-plugin
> implementation of the git porcelain -- not just a wrapper around the
> command line porcelain.
Yes, exactly. JGit is about keeping on-disk and on-network binary
compatability with git-core. But we don't necessarily need to keep
UI or behavior always the same within the porcelain that uses that
library, aka EGit.
> To me that means that EGit should focus just as much on integrating with
> Eclipse properly as it does on keeping command line porcelain
> interoperability.
Yup, I agree completely. I think Robin would too.
> The core.excludesfile is one such case, and I think my proposal is a
> good compromise.
IMHO, we should honor ignores in EGit as:
per-directory .gitignore
per-repostiory GIT_DIR/info/exclude
per-repository core.excludesfile (yes, really, it can be per
repository, which overrides ~/.gitconfig setting of same)
Eclipse global team ignore patterns
Skipping the core.excludesfile in favor of only the Eclipse global
team ignores feels wrong to me, as we may be missing something
the user has configured. FWIW, I think core.excludesfile is a
lot less frequently used then .gitignore and GIT_DIR/info/exclude.
If there is a core.excludesfile, the user is a pretty advanced user
and they really want that behavior to be honored by Git poreclain.
EGit should honor it.
But likewise with the global team ignores. I think most people set
up ignores in their VCS, so they are distributed to everyone on the
project automatically. But if you do twiddle your own workspace
settings, we should honor them.
--
Shawn.
^ permalink raw reply
* Re: jgit and ignore
From: Ferry Huberts (Pelagic) @ 2009-03-01 17:17 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Jon Smirl, Shawn O. Pearce, Git Mailing List
In-Reply-To: <49AAA2B3.40808@gmail.com>
Tor Arne Vestbø wrote:
> Ferry Huberts (Pelagic) wrote:
>> Tor Arne Vestbø wrote:
>>> In my opinion, EGit should default to using Eclipse's built in ignores,
>>> but then detect the presence of a global core.excludesfile, in which
>>> case it would notify the user ("I see you have a core.excludesfile") and
>>> let the user switch to using that one instead.
>
> [snip]
>
> First of all, I do appreciate you working on the ignore feature :)
>
>> I do not agree with your propasal however.
>> We then would have different behaviour between how 'git' behaves within
>> Eclipse (by means of the plugin) and how 'git' behaves within the
>> command line. That alone can cause much more confusion.
>
> I see what you mean, and I agree that in general the command line git
> porcelain and the Eclipse git porcelain should work in similar ways.
>
> But, with that said, I think of EGit as a standalone Eclipse-plugin
> implementation of the git porcelain -- not just a wrapper around the
> command line porcelain.
>
> To me that means that EGit should focus just as much on integrating with
> Eclipse properly as it does on keeping command line porcelain
> interoperability.
>
> The core.excludesfile is one such case, and I think my proposal is a
> good compromise.
>
how about we all (especially me) think a bit better on this and solve it
later when I've completed the rest? That allows me to focus for now.
I think we can easily synchronise between the eclipse global ignores and
the core.excludesfile when we (really) want to.
^ permalink raw reply
* Re: jgit and ignore
From: Tor Arne Vestbø @ 2009-03-01 17:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ferry Huberts (Pelagic), Jon Smirl, Git Mailing List
In-Reply-To: <20090301171648.GB14365@spearce.org>
Shawn O. Pearce wrote:
> IMHO, we should honor ignores in EGit as:
>
> per-directory .gitignore
> per-repostiory GIT_DIR/info/exclude
>
> per-repository core.excludesfile (yes, really, it can be per
> repository, which overrides ~/.gitconfig setting of same)
>
> Eclipse global team ignore patterns
Just to be clear, I noticed you left out the global core.excludesfile
(from ~/.gitconfig) here. I guess this intentional?
Or should we combine the ignores from the global team ignores and the
ignores from the global core.excludesfile in ~/.gitconfig?
Either way, I full agree that we should honor all repository ignores
(whether they are in directory .gitignores, info/exclude, or given by
repository-specific core.excludesfile).
Tor Arne
^ permalink raw reply
* Re: jgit and ignore
From: Ferry Huberts (Pelagic) @ 2009-03-01 17:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tor Arne Vestbø, Jon Smirl, Git Mailing List
In-Reply-To: <20090301171648.GB14365@spearce.org>
> IMHO, we should honor ignores in EGit as:
>
> per-directory .gitignore
> per-repostiory GIT_DIR/info/exclude
>
> per-repository core.excludesfile (yes, really, it can be per
> repository, which overrides ~/.gitconfig setting of same)
wow. override? really?
>
> Eclipse global team ignore patterns
>
so, should these then override, supplement, or something else?
the per-repo files (.gitignore's and info/exclude supplement eachother.
> Skipping the core.excludesfile in favor of only the Eclipse global
> team ignores feels wrong to me, as we may be missing something
> the user has configured. FWIW, I think core.excludesfile is a
> lot less frequently used then .gitignore and GIT_DIR/info/exclude.
> If there is a core.excludesfile, the user is a pretty advanced user
> and they really want that behavior to be honored by Git poreclain.
> EGit should honor it.
I could also argue that an advanced user would expect Egit and git to
behave the same. especially for advanced features. and even more so
because EGit now is very basic and to be able to use the advanced
features you have to switch to the commandline from Eclipse. making this
a very very real use-case for EGit usage.
Once we have more advanced features implemented this use-case will
become less prevalent and only then I'd (personally) be more inclined to
allow more behaviour differences
^ permalink raw reply
* Re: jgit and ignore
From: Shawn O. Pearce @ 2009-03-01 17:47 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: Tor Arne Vestbø, Jon Smirl, Git Mailing List
In-Reply-To: <49AAC959.70406@pelagic.nl>
"Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl> wrote:
> > IMHO, we should honor ignores in EGit as:
> >
> > per-directory .gitignore
> > per-repostiory GIT_DIR/info/exclude
> >
> > per-repository core.excludesfile (yes, really, it can be per
> > repository, which overrides ~/.gitconfig setting of same)
>
> wow. override? really?
Yes. I'd have to go back and read the git-core code again, but in
general a config setting of foo.bar in GIT_DIR/config overrides a
foo.bar setting in ~/.gitconfig, *unless* you use the --all flag.
Most of the C code parses as though the last value seen is the
only value set, and GIT_DIR/config is parsed after ~/.gitconfig,
hence it overrides.
> > Eclipse global team ignore patterns
>
> so, should these then override, supplement, or something else?
> the per-repo files (.gitignore's and info/exclude supplement eachother.
They all supplement each other. You union every entry in that list
into a single override set and then evaluate against that. That list
changes with each directory, due to the per-directory .gitignore
possibly changing, but otherwise its fixed for any given repository.
--
Shawn.
^ permalink raw reply
* Re: jgit and ignore
From: Shawn O. Pearce @ 2009-03-01 17:49 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Ferry Huberts (Pelagic), Jon Smirl, Git Mailing List
In-Reply-To: <49AAC91E.1000401@gmail.com>
Tor Arne Vestbø <torarnv@gmail.com> wrote:
> Shawn O. Pearce wrote:
> > IMHO, we should honor ignores in EGit as:
> >
> > per-directory .gitignore
> > per-repostiory GIT_DIR/info/exclude
> >
> > per-repository core.excludesfile (yes, really, it can be per
> > repository, which overrides ~/.gitconfig setting of same)
> >
> > Eclipse global team ignore patterns
>
> Just to be clear, I noticed you left out the global core.excludesfile
> (from ~/.gitconfig) here. I guess this intentional?
No, I didn't. core.excludesfile is read from the config, the config
is a union of /etc/gitconfig, ~/.gitconfig, and GIT_DIR/config. The
last setting wins.
> Or should we combine the ignores from the global team ignores and the
> ignores from the global core.excludesfile in ~/.gitconfig?
>
> Either way, I full agree that we should honor all repository ignores
> (whether they are in directory .gitignores, info/exclude, or given by
> repository-specific core.excludesfile).
Right. See my reply to Ferry, we union all of them together, but in
the case of core.excludesfile we have to honor what the repository
is telling us is the correct setting for that one repository,
which may differ from other repositories if it has been overridden.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] send-email: add --confirm option
From: Jay Soffian @ 2009-03-01 17:49 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: git, Nanako Shiraishi, Junio C Hamano
In-Reply-To: <7d1d9c250903010909h7d92f165oc703a05e819671a4@mail.gmail.com>
On Sun, Mar 1, 2009 at 12:09 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
>
> On Sun, Mar 1, 2009 at 11:17 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> * Allowing the user to "git config sendemail.config never"
>
> I think it should be sendemail.confirm in the above.
Yep, thanks. Junio, please amend my commit message if v2 is acceptable as is.
> Thanks for
> taking this seriously -- I think lots of new git users (who probably
> will never make it to this list) will benefit from it without ever
> even knowing.
Well it's all for naught unless Junio can be convinced that it's an
acceptable trade-off. On this point I want to elaborate a little more,
so pardon me while I step up on the soap box.
Once upon a time, all git commands were git-something and they were
installed in PATH. A smattering of users complained about this.
Eventually git learned "git something" in addition to "git-something".
Then some folks decided why not just get rid of "git-something"
entirely. And so it was done. And many other users who were happy with
the way it was complained.
And rightly so. The change was made w/no escape hatch for those users.
And to plumbing no less. The users who wanted "git-something" out of
PATH (which wasn't really hurting anything) got what they wanted, but
nothing was done to accommodate the existing users. Eventually a
compromise was reached. The git-something commands moved out of PATH,
but were still installed, and existing users could relatively easily get
to them by adding "git --exec-path" to their PATH.
(Please correct me if my summary is wrong, but that's how I recall it.)
If the compromise is how it was done in the first place, perhaps Junio
would not be as hyper-sensitive to any change which affects existing
users expectations.
But this patch is not like the git-something situation. This patch
benefits new (all?) users, while bending over backwards to accommodate
existing users. And it is a porcelain change.
I sympathize with Junio's aversion to accepting patches which affect
existing users expectations. But I also think there are times when the
greater good is served by such patches, and it would be nice to have
some guidelines for how and when such patches can be made. For example:
- No non-backwards compatible changes to plumbing.
- Non-backwards compatible changes to porcelain IFF:
- The change provides a notable (non-trivial) benefit to new users.
Some litmus tests for such a change might be:
- "in hindsight, this is how it clearly should've been done."
- "this is really confusing for new users; existing users users have
forgotten how confusing it was when they first encountered it."
- "the default behavior is potentially dangerous/embarrassing."
- Existing users can easily get the prior behavior. i.e. via a config
setting
- The change, where possible, maintains previous expectations if it
appears the command is being used by an experienced user.
(In fairness, there appears to be a framework for non-backwards
compatible changes; you introduce a warning about the change in the next
minor release that the behavior of X will change and inform the user how
they can keep the existing behavior of X; wait one patch release, then
make the actual change. But my reading of Junio's message is that he
doesn't think _this_ patch is even worthy of that step until I can
demonstrate that there is not a silent-majority who really likes the
existing behavior of send-email. But as I said, this is not my itch, and
while I'm happy to offer up this patch, that's as far as I go.)
Stepping off soapbox.
j.
^ permalink raw reply
* Re: jgit and ignore
From: Tor Arne Vestbø @ 2009-03-01 17:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ferry Huberts (Pelagic), Jon Smirl, Git Mailing List
In-Reply-To: <20090301174941.GD14365@spearce.org>
Shawn O. Pearce wrote:
>> Just to be clear, I noticed you left out the global core.excludesfile
>> (from ~/.gitconfig) here. I guess this intentional?
>
> No, I didn't. core.excludesfile is read from the config, the config
> is a union of /etc/gitconfig, ~/.gitconfig, and GIT_DIR/config. The
> last setting wins.
Ah, I see, I thought each config was read in a separate steps. Thanks
for clearing that up.
>> Either way, I full agree that we should honor all repository ignores
>> (whether they are in directory .gitignores, info/exclude, or given by
>> repository-specific core.excludesfile).
>
> Right. See my reply to Ferry, we union all of them together, but in
> the case of core.excludesfile we have to honor what the repository
> is telling us is the correct setting for that one repository,
> which may differ from other repositories if it has been overridden.
Yepp, full ack.
Tor Arne
^ permalink raw reply
* Re: jgit and ignore
From: Shawn O. Pearce @ 2009-03-01 17:57 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Ferry Huberts (Pelagic), Jon Smirl, Git Mailing List
In-Reply-To: <49AACB3A.8070809@gmail.com>
Tor Arne Vestbø <torarnv@gmail.com> wrote:
> Shawn O. Pearce wrote:
> >> Just to be clear, I noticed you left out the global core.excludesfile
> >> (from ~/.gitconfig) here. I guess this intentional?
> >
> > No, I didn't. core.excludesfile is read from the config, the config
> > is a union of /etc/gitconfig, ~/.gitconfig, and GIT_DIR/config. The
> > last setting wins.
>
> Ah, I see, I thought each config was read in a separate steps. Thanks
> for clearing that up.
Well, they are.
But in git-core the value is pulled into a single static. For a
string its often a single static char*. So the config handle
function is called up to 3 times for foo.bar, and the last one to
be called is the one that finally set the value. They are read
in the order I described above, so GIT_DIR/config has a chance to
override any prior setting.
In JGit the RepositoryConfig object parses the other direction.
Its a more classical "default" pattern, where if GIT_DIR/config
doesn't have a foo.bar we call to another instance which had parsed
~/.gitconfig, and so on.
Either way produces the same result.
--
Shawn.
^ permalink raw reply
* "warning: no common commits" triggered due to change of remote's IP address?
From: Brent Goodrick @ 2009-03-01 18:01 UTC (permalink / raw)
To: git
Hi,
I had this setup in my .git/config on my satellite machine:
[remote "origin"]
url = 192.168.2.3:git.repos/environ.git
fetch = +refs/heads/home:refs/remotes/origin/home
192.168.2.3 is the IP address of the main machine and repo, and is
internal to my LAN at home. My workflow is fairly simple: At home, on
my internal LAN, I usually update via these commands:
git fetch
git branch # <-- verify I am on the "home" branch
git merge origin/home # <-- merge origin/home into home and fix conflicts
I needed to do a git fetch of that same repository while out at an
Internet cafe (via ssh). I know ahead of time that I might have had a
couple of files out of date between my satellite machines repo and my
origin repo, but certainly not megabytes of data in difference. I want
to pull those differences to the satellite machines repo to continue
to work.
On the satellite machine, I simply did the fetch manually by changing
the IP address to be the WAN internet IP address of my ssh daemon I'm
running at home:
gitw fetch 88.99.100.101:git.repos/environ.git
+refs/heads/home:refs/remotes/origin/home
My expectation at this point is that, since I've changed only the IP
address, and kept everything else the same, git should be smart enough
to compare SHA1 values only and not download the entire remote repo
just to do that comparison.
But I was quite surprised to find that it was pulling down tons of data:
warning: no common commits
remote: Counting objects: 2473, done.
remote: Compressing objects: 100% (2199/2199), done.
Receiving objects: 83% (2077/2473), 66.58 MiB | 67 KiB/s C-c C-c
At this point, for some reason I can't explain, the network got very
slow (network bandwidth limiting?). So, I terminated the git fetch
(the C-c C-c above), thinking that I can repair this when I get back
to my LAN.
So my questions are:
1. Will terminating the git fetch like I did leave the satellite repo
in an inconsistent state? If so, is my only choice to start
a new repo from scratch on the satellite machine, or is there some
repair mechanism?
2. Why did git conclude that there was no common commits?
Thanks,
Brent
^ permalink raw reply
* Re: [PATCH] send-email: confirm auto cc before sending
From: Sverre Rabbelier @ 2009-03-01 18:09 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Paul Gortmaker, Junio C Hamano
In-Reply-To: <1235879630-39439-1-git-send-email-jaysoffian@gmail.com>
Heya,
On Sun, Mar 1, 2009 at 04:53, Jay Soffian <jaysoffian@gmail.com> wrote:
> Untested patch, just soliciting ideas.
With a config option to turn it on permanently this would be very nice
to have. It personally annoys me that it decides who to cc (I already
do that manually, thank you very much).
So, FWIW, I like this idea :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] import memmem() with linear complexity from Gnulib
From: René Scharfe @ 2009-03-01 18:55 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <49AA6E35.40205@lsrfire.ath.cx>
René Scharfe schrieb:
> I was going to say that with a fast memmem() we could convert some
> strstr() calls, especially those where we know the lengths of the
> strings anyway -- intuitively, memmem() should be faster than strstr()
> in that case. However, the following patch on top of the Gnulib import
> makes "git grep grep v1.6.1" take 10% *more* time for me (on Windows).
> I wonder why.
More numbers. "memmem" is the patch I'm replying to which converts
grep's fixed string search from strstr() to memmem(). "quadratic" means
the current version of compat/memmem.c was used (NO_MEMMEM=yes),
"linear" is the same, but with the newer memmem() from Gnulib imported.
The numbers are elapsed seconds for the following command, run in a
Linux kernel repo:
git grep grep v2.6.28 >/dev/null
Ubuntu Fedora
[1] v1.6.2-rc2 2.99 3.52
[2] v1.6.2-rc2+memmem 3.09 3.28
[3] v1.6.2-rc2+memmem+quadratic 8.42 8.50
[4] v1.6.2-rc2+memmem+linear 3.17 3.25
So, we should be careful when using memmem() as long as we have the
current implementation in compat/, as the quadratic complexity can
result in a significant slowdown ([3]).
The new memmem() indeed is faster than the new strstr(), as expected
(Fedora [2] and [4] vs. Fedora [1]). Remember, Fedora 10 already
includes the glibc version with the linear implementations while Ubuntu
8.10 doesn't.
I'm not sure if the difference between the old and new memmem() is
significant or in the noise (Ubuntu [2] and [4]).
In any case, and this surprised me, the fastest of them all is the old
strstr() (Ubuntu [1]). This is consistent with the slowdown observed on
Windows.
What's even more surprising is the difference between Ubuntu [2] and
[3], which use basically the same memmem(). Or so I thought. Wrong.
The old memmem() in glibc has a small but effective optimization, that
our version lacks. I don't remember if I cut it out during the initial
import for increased simplicity or if the version the import was based
on didn't have it. Anyway, with the following patch, case [3] runs as
fast as case [2] on both Fedora and Ubuntu.
Next step would be to check if pickaxe simply needs this short patch or
really the full-blown linear reimplementation. I'm off to an
appointment, though, so I'll look into this again tomorrow.
René
diff --git a/compat/memmem.c b/compat/memmem.c
index cd0d877..fed5a77 100644
--- a/compat/memmem.c
+++ b/compat/memmem.c
@@ -5,6 +5,7 @@ void *gitmemmem(const void *haystack, size_t haystack_len,
{
const char *begin = haystack;
const char *last_possible = begin + haystack_len - needle_len;
+ char tip;
/*
* The first occurrence of the empty string is deemed to occur at
@@ -20,8 +21,10 @@ void *gitmemmem(const void *haystack, size_t haystack_len,
if (haystack_len < needle_len)
return NULL;
+ tip = *((const char *)needle);
+
for (; begin <= last_possible; begin++) {
- if (!memcmp(begin, needle, needle_len))
+ if (*begin == tip && !memcmp(begin, needle, needle_len))
return (void *)begin;
}
^ permalink raw reply related
* Re: git monthly links: 2009-02
From: Jakub Narebski @ 2009-03-01 20:10 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530903010844u78cc9a2en23124e40467bd8b8@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Git for the real world
> Twitter developer explains how git should be used in his opinion.
> http://robey.lag.net/2008/07/13/git-for-the-real-world.html
Grrr... blog without comments is not a blog. How I hate if somebody
writes critic which simply shows that he/she does not undertsnad git,
and doesn't have place for correcting misinformation...
> flashbake « Bit Bucket Labs
> Scripts to automate git for non-technical users.
> http://bitbucketlabs.net/flashbake/
Cory Doctorow on Lifestreaming Contextual Snapshots Using New Tool Flashbake
http://lifestreamblog.com/cory-doctorow-on-lifestreaming-contextual-snapshots-using-new-tool-flashbake/
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: jgit and ignore
From: Robin Rosenberg @ 2009-03-01 20:24 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Tor Arne Vestbø, Ferry Huberts (Pelagic), Jon Smirl,
Git Mailing List
In-Reply-To: <20090301171648.GB14365@spearce.org>
Shawn writes:
> Tor Arne Vestbø <torarnv@gmail.com> wrote:
> > To me that means that EGit should focus just as much on integrating with
> > Eclipse properly as it does on keeping command line porcelain
> > interoperability.
>
> Yup, I agree completely. I think Robin would too.
100% (or close).
-- robin
^ 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