* Re: [PATCH] Implement sending mails over TLS in git-send-email.
From: Baz @ 2007-10-31 23:59 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <981e6de60710311504v666943beve3b87c6a713fb18c@mail.gmail.com>
On 31/10/2007, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> > In other words, this patch should be entirely unnecessary if you have
> > Authen::SASL installed - could you try this? (I've checked for myself,
> > git-send-email sends me mail fine via gmail without this patch)
>
> Well, it fails here, maybe maybe you can show me exactly what you did
> (configuration/parameters etc)?
>
> This is what i do now:
> > git-send-email testfile.patch -to simon.sasburg@gmail.com --chain-reply-to --smtp-server smtp.gmail.com --smtp-user simon.sasburg --smtp-pass secret --smtp-ssl --smtp-server-port 587
> and it fails, while the same line using --smtp-tls instead of
> --smtp-ssl with my patch applied works.
>
> What am i missing?
>
ok I'm going to downgrade what I said to 'it works fine with gmail' -
it just doesnt do starttls, your code does.
git-send-email --from 'brian.ewins@gmail.com' --to
'brian.ewins@gmail.com' --smtp-server smtp.gmail.com --smtp-user
'brian.ewins@gmail.com' --smtp-pass 'secret' --smtp-ssl
0001-the-patch-goes-here
That's using SSL on port 465, not TLS. Did this not work for you? I
thought Net::SMTP passed its constructor options to IO::Socket, but
no. An alternate way of getting starttls to work, without using
Net::SMTP::TLS, is this:
#connect with Net::SMTP - not ::SSL or the connect will fail
$smtp = Net::SMTP->new('smtp.gmail.com',
Port => 587,
Debug => 1) or die "Could not connect
to server\n";
#issue the starttls command, assuming user asked for this
$smtp->command('STARTTLS');
$smtp->response();
#if server says 220, then go ahead and convert the socket. Bless as
Net::SMTP::SSL
# - necessary to inherit both IO::Socket::SSL and Net::SMTP
#start_SSL has been renamed, twice. Nice stable api :)
#extra args for checking server cert etc can be passed to start_SSL.
$smtp->code() == 220 and $smtp = Net::SMTP::SSL->start_SSL($smtp) or
die "STARTTLS failed! ".$smtp->message;
# say hello again to get server features (including auth)
$smtp->hello();
# now continue as before, with $smtp->auth()...
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Johannes Schindelin @ 2007-10-31 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, git
In-Reply-To: <7v4pg6hq8u.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 31 Oct 2007, Junio C Hamano wrote:
> "type"? That's probably better than using "which", but sounds quite
> wrong. Why not add Makefile target that the shell scripts depend on to
> see if necessary tools are available and let the builder know if they
> are not?
I thought the accord was that "cpio" is a _runtime_ dependency. But yes,
I agree "type" is not necessarily the best choice. Maybe testing the exit
code for 127 (not found) is the better choice?
Ciao,
Dscho
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: David Kastrup @ 2007-10-31 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <7vhck7gdzs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> A rebase conflict resolution that results in emptiness is a rather
> rare event (especially because rebase drops upfront the identical
> changes from the set of commits to be replayed), but it does happen.
> One could argue that "rebase --continue" can notice that the resolved
> index is identical to the tree of the HEAD commit and skip it
> automatically.
>
> Given an index that is identical to HEAD, however, it is not
> easy to safely determine if that is because the patch did not
> apply at all,
Wouldn't there be a conflict in the index? A conflict which can only be
resolved by adding? Which then results in a question whether you forgot
to add?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: David Kastrup @ 2007-10-31 22:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergei Organov, git
In-Reply-To: <Pine.LNX.4.64.0710312111170.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
>> patch that *already became no-op* after conflict resolution and forced
>> me to explicitly use 'git --skip' instead?
>
> Isn't that obvious? To prevent you from accidentally losing a commit.
The commit would not change anything, so what is there to lose?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3.5
From: Junio C Hamano @ 2007-10-31 22:40 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.5.3.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.5.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.3.5-1.$arch.rpm (RPM)
There are many fixes including a handful bugs that led to
segfaults.
----------------------------------------------------------------
GIT v1.5.3.5 Release Notes
==========================
Fixes since v1.5.3.4
--------------------
* Comes with git-gui 0.8.4.
* "git-config" silently ignored options after --list; now it will
error out with a usage message.
* "git-config --file" failed if the argument used a relative path
as it changed directories before opening the file.
* "git-config --file" now displays a proper error message if it
cannot read the file specified on the command line.
* "git-config", "git-diff", "git-apply" failed if run from a
subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
* "git-blame" crashed if run during a merge conflict.
* "git-add -i" did not handle single line hunks correctly.
* "git-rebase -i" and "git-stash apply" failed if external diff
drivers were used for one or more files in a commit. They now
avoid calling the external diff drivers.
* "git-log --follow" did not work unless diff generation (e.g. -p)
was also requested.
* "git-log --follow -B" did not work at all. Fixed.
* "git-log -M -B" did not correctly handle cases of very large files
being renamed and replaced by very small files in the same commit.
* "git-log" printed extra newlines between commits when a diff
was generated internally (e.g. -S or --follow) but not displayed.
* "git-push" error message is more helpful when pushing to a
repository with no matching refs and none specified.
* "git-push" now respects + (force push) on wildcard refspecs,
matching the behavior of git-fetch.
* "git-filter-branch" now updates the working directory when it
has finished filtering the current branch.
* "git-instaweb" no longer fails on Mac OS X.
* "git-cvsexportcommit" didn't always create new parent directories
before trying to create new child directories. Fixed.
* "git-fetch" printed a scary (but bogus) error message while
fetching a tag that pointed to a tree or blob. The error did
not impact correctness, only user perception. The bogus error
is no longer printed.
* "git-ls-files --ignored" did not properly descend into non-ignored
directories that themselves contained ignored files if d_type
was not supported by the filesystem. This bug impacted systems
such as AFS. Fixed.
* Git segfaulted when reading an invalid .gitattributes file. Fixed.
* post-receive-email example hook fixed was fixed for
non-fast-forward updates.
* Documentation updates for supported (but previously undocumented)
options of "git-archive" and "git-reflog".
* "make clean" no longer deletes the configure script that ships
with the git tarball, making multiple architecture builds easier.
* "git-remote show origin" spewed a warning message from Perl
when no remote is defined for the current branch via
branch.<name>.remote configuration settings.
* Building with NO_PERL_MAKEMAKER excessively rebuilt contents
of perl/ subdirectory by rewriting perl.mak.
* http.sslVerify configuration settings were not used in scripted
Porcelains.
* "git-add" leaked a bit of memory while scanning for files to add.
* A few workarounds to squelch false warnings from recent gcc have
been added.
* "git-send-pack $remote frotz" segfaulted when there is nothing
named 'frotz' on the local end.
* "git-rebase -interactive" did not handle its "--strategy" option
properly.
----------------------------------------------------------------
Changes since v1.5.3.4 are as follows:
Alex Bennee (1):
Ensure we add directories in the correct order
Alex Riesen (1):
Fix generation of perl/perl.mak
Andrew Clausen (1):
helpful error message when send-pack finds no refs in common.
Aurelien Bompard (1):
honor the http.sslVerify option in shell scripts
Benoit Sigoure (1):
Fix a small memory leak in builtin-add
Bj旦rn Steinbrink (3):
Fix --strategy parsing in git-rebase--interactive.sh
git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.
git-rebase--interactive.sh: Make 3-way merge strategies work for -p.
Brian Gernhardt (1):
cvsserver: Use exit 1 instead of die when req_Root fails.
Frank Lichtenheld (1):
git-config: don't silently ignore options after --list
Gerrit Pape (2):
git-config: handle --file option with relative pathname properly
git-config: print error message if the config file cannot be read
Jean-Luc Herren (2):
git add -i: Fix parsing of abbreviated hunk headers
git add -i: Remove unused variables
Jeff King (1):
send-pack: respect '+' on wildcard refspecs
Joakim Tjernlund (1):
Improve receive-pack error message about funny ref creation
Johannes Schindelin (5):
clear_commit_marks(): avoid deep recursion
rebase -i: use diff plumbing instead of porcelain
Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE
fix filter-branch documentation
filter-branch: update current branch when rewritten
Julian Phillips (1):
fast-import: Fix argument order to die in file_change_m
Junio C Hamano (8):
git-remote: fix "Use of uninitialized value in string ne"
sha1_file.c: avoid gcc signed overflow warnings
merge-recursive.c: mrtree in merge() is not used before set
RelNotes-1.5.3.5: describe recent fixes
Prevent send-pack from segfaulting (backport from 'master')
git-merge: document but discourage the historical syntax
Update GIT 1.5.3.5 Release Notes
GIT 1.5.3.5
Lars Hjemli (1):
Make merge-recursive honor diff.renamelimit
Linus Torvalds (6):
Fix embarrassing "git log --follow" bug
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
git-blame shouldn't crash if run in an unmerged tree
Avoid scary errors about tagged trees/blobs during git-fetch
Fix directory scanner to correctly ignore files without d_type
Fix diffcore-break total breakage
Mathias Megyei (1):
Do not remove distributed configure script
Michael W. Olson (1):
Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
Michele Ballabio (2):
git-reflog: document --verbose
git-archive: document --exec
Nicolas Pitre (1):
cherry-pick/revert: more compact user direction message
Patrick Welche (1):
Define NI_MAXSERV if not defined by operating system
Ralf Wildenhues (1):
gitk.txt: Fix markup.
Robert Schiele (1):
fixing output of non-fast-forward output of post-receive-email
Sergei Organov (1):
core-tutorial: Use new syntax for git-merge.
Shawn O. Pearce (17):
git-gui: Display message box when we cannot find git in $PATH
git-gui: Handle starting on mapped shares under Cygwin
git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
git-gui: Don't crash when starting gitk from a browser session
Whip post 1.5.3.4 maintenance series into shape.
Correct typos in release notes for 1.5.3.5
Avoid 'expr index' on Mac OS X as it isn't supported
Document additional 1.5.3.5 fixes in release notes
Yet more 1.5.3.5 fixes mentioned in release notes
Avoid invoking diff drivers during git-stash
Further 1.5.3.5 fixes described in release notes
Paper bag fix diff invocation in 'git stash show'
git-gui: Correctly report failures from git-write-tree
git-gui: Handle progress bars from newer gits
git-gui: Don't display CR within console windows
Describe more 1.5.3.5 fixes in release notes
Simon Sasburg (1):
git-gui: Avoid using bold text in entire gui for some fonts
Steffen Prohaska (2):
git-gui: accept versions containing text annotations, like 1.5.3.mingw.1
attr: fix segfault in gitattributes parsing code
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: J. Bruce Fields @ 2007-10-31 22:38 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <4728FC5C.30709@midwinter.com>
On Wed, Oct 31, 2007 at 03:06:20PM -0700, Steven Grimm wrote:
> I've been using rebase just about every day for close to a year and it
> *still* annoys me when it happens. Especially the "Did you forget to git
> add?" part of the message. The thought that always goes through my head is,
> "No, Mr. Rebase, I did NOT forget to git add. I remembered to git add, then
> you were too stupid to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to
> work around a bug, the bug got fixed for real, and I rebased. In the
> process of conflict resolution I saw that my workaround wasn't needed any
> more and accepted the upstream version of that particular part of the file.
> Ran git-add on it, then rebase --continue, and boom, was accused of
> forgetting to run git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip
> instead, but it'd be nice if it didn't happen. I don't like having to care
> whether or not I happened to change other files in a particular commit
> after I resolve conflicts in one file in favor of the upstream version.
Yeah, I think a message saying "patch is now empty, skipping..." would
be sufficient to let the user know what's going on. This doesn't seem
so perilous to me that it's worth requiring a positive acknowledgement.
--b.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Daniel Barkalow @ 2007-10-31 22:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: J. Bruce Fields, Johannes Schindelin, Sergei Organov, git
In-Reply-To: <4728FC5C.30709@midwinter.com>
On Wed, 31 Oct 2007, Steven Grimm wrote:
> J. Bruce Fields wrote:
> > I ran into the same confusion as the original poster when starting to
> > use rebase, so I suspect it's common.
> >
>
> I've been using rebase just about every day for close to a year and it *still*
> annoys me when it happens. Especially the "Did you forget to git add?" part of
> the message. The thought that always goes through my head is, "No, Mr. Rebase,
> I did NOT forget to git add. I remembered to git add, then you were too stupid
> to do the right thing after that."
>
> Just happened to me this morning, in fact: I had a quick hack in place to work
> around a bug, the bug got fixed for real, and I rebased. In the process of
> conflict resolution I saw that my workaround wasn't needed any more and
> accepted the upstream version of that particular part of the file. Ran git-add
> on it, then rebase --continue, and boom, was accused of forgetting to run
> git-add.
>
> It is a minor annoyance and nowadays I just sigh a bit and run --skip instead,
> but it'd be nice if it didn't happen. I don't like having to care whether or
> not I happened to change other files in a particular commit after I resolve
> conflicts in one file in favor of the upstream version.
I think it's worth requiring you to say --skip in order to acknowledge
that you won't have as many commits and you'll lose the commit message. On
the other hand, the message should probably suggest that you might want to
skip this commit instead of suggesting that you come up with some other
change to include in it.
Certainly, if "git diff" returns no changes, "git add" is a bad
suggestion, and it would be nicer to suggest something possibly correct.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Junio C Hamano @ 2007-10-31 22:31 UTC (permalink / raw)
To: Jeff King
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <20071031215625.GC14211@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I had one concern that
> I was tracking down: is the author name encoding necessarily the same as
> the commit text encoding?
The user is screwing himself already if that is the case and
uses -s to format-patch, isn't he?
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Junio C Hamano @ 2007-10-31 22:29 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1193861145-20357-1-git-send-email-mh@glandium.org>
"type"? That's probably better than using "which", but sounds
quite wrong. Why not add Makefile target that the shell scripts
depend on to see if necessary tools are available and let the
builder know if they are not?
^ permalink raw reply
* [PATCH] cvsexportcommit: Add switch to specify CVS workdir
From: Robin Rosenberg @ 2007-10-31 22:12 UTC (permalink / raw)
To: gitster; +Cc: git, Robin Rosenberg
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-cvsexportcommit.txt | 22 ++++++++++++++----
git-cvsexportcommit.perl | 39 ++++++++++++++++++++++----------
2 files changed, 44 insertions(+), 17 deletions(-)
I finally got tired of swapping working directories.
-- robin
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index c3922f9..310d56a 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
-'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
@@ -16,8 +16,9 @@ DESCRIPTION
Exports a commit from GIT to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
-Execute it from the root of the CVS working copy. GIT_DIR must be defined.
-See examples below.
+Specify the name of a CVS checkout using the -w switch or execute it
+from the root of the CVS working copy. In the latter case GIT_DIR must
+be defined. See examples below.
It does its best to do the safe thing, it will check that the files are
unchanged and up to date in the CVS checkout, and it will not autocommit
@@ -61,6 +62,11 @@ OPTIONS
-u::
Update affected files from CVS repository before attempting export.
+-w::
+ Specify the location of the CVS checkout to use for the export. This
+ option does not require GIT_DIR to be set before execution if the
+ current directory is within a git repository.
+
-v::
Verbose.
@@ -76,6 +82,12 @@ $ git-cvsexportcommit -v <commit-sha1>
$ cvs commit -F .msg <files>
------------
+Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
++
+------------
+ $ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
+------------
+
Merge pending patches into CVS automatically -- only if you really know what you are doing::
+
------------
@@ -86,11 +98,11 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit
Author
------
-Written by Martin Langhoff <martin@catalyst.net.nz>
+Written by Martin Langhoff <martin@catalyst.net.nz> and others.
Documentation
--------------
-Documentation by Martin Langhoff <martin@catalyst.net.nz>
+Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
GIT
---
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index f284c88..47973e8 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -1,28 +1,42 @@
#!/usr/bin/perl -w
-# Known limitations:
-# - does not propagate permissions
-# - error handling has not been extensively tested
-#
-
use strict;
use Getopt::Std;
use File::Temp qw(tempdir);
use Data::Dumper;
use File::Basename qw(basename dirname);
-unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
- die "GIT_DIR is not defined or is unreadable";
-}
-
-our ($opt_h, $opt_P, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m, $opt_d, $opt_u);
+our ($opt_h, $opt_P, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m, $opt_d, $opt_u, $opt_w);
-getopts('uhPpvcfam:d:');
+getopts('uhPpvcfam:d:w:');
$opt_h && usage();
die "Need at least one commit identifier!" unless @ARGV;
+if ($opt_w) {
+ unless ($ENV{GIT_DIR}) {
+ # Remember where our GIT_DIR is before changing to CVS checkout
+ my $gd =`git-rev-parse --git-dir`;
+ chomp($gd);
+ if ($gd eq '.git') {
+ my $wd = `pwd`;
+ chomp($wd);
+ $gd = $wd."/.git" ;
+ }
+ $ENV{GIT_DIR} = $gd;
+ }
+
+ if (! -d $opt_w."/CVS" ) {
+ die "$opt_w is not a CVS checkout";
+ }
+ chdir $opt_w or die "Cannot change to CVS checkout at $opt_w";
+}
+unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
+ die "GIT_DIR is not defined or is unreadable";
+}
+
+
my @cvs;
if ($opt_d) {
@cvs = ('cvs', '-d', $opt_d);
@@ -267,6 +281,7 @@ if ($dirtypatch) {
print "You'll need to apply the patch in .cvsexportcommit.diff manually\n";
print "using a patch program. After applying the patch and resolving the\n";
print "problems you may commit using:";
+ print "\n cd \"$opt_w\"" if $opt_w;
print "\n $cmd\n\n";
exit(1);
}
@@ -294,7 +309,7 @@ sleep(1);
sub usage {
print STDERR <<END;
-Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-m msgprefix] [ parent ] commit
+Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-u] [-w cvsworkdir] [-m msgprefix] [ parent ] commit
END
exit(1);
}
--
1.5.3.4-dirty
^ permalink raw reply related
* Re: Newbie: report of first experience with git-rebase.
From: Steven Grimm @ 2007-10-31 22:06 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, Sergei Organov, git
In-Reply-To: <20071031212923.GL4569@fieldses.org>
J. Bruce Fields wrote:
> I ran into the same confusion as the original poster when starting to
> use rebase, so I suspect it's common.
>
I've been using rebase just about every day for close to a year and it
*still* annoys me when it happens. Especially the "Did you forget to git
add?" part of the message. The thought that always goes through my head
is, "No, Mr. Rebase, I did NOT forget to git add. I remembered to git
add, then you were too stupid to do the right thing after that."
Just happened to me this morning, in fact: I had a quick hack in place
to work around a bug, the bug got fixed for real, and I rebased. In the
process of conflict resolution I saw that my workaround wasn't needed
any more and accepted the upstream version of that particular part of
the file. Ran git-add on it, then rebase --continue, and boom, was
accused of forgetting to run git-add.
It is a minor annoyance and nowadays I just sigh a bit and run --skip
instead, but it'd be nice if it didn't happen. I don't like having to
care whether or not I happened to change other files in a particular
commit after I resolve conflicts in one file in favor of the upstream
version.
-Steve
^ permalink raw reply
* Re: [PATCH] Implement sending mails over TLS in git-send-email.
From: Simon Sasburg @ 2007-10-31 22:04 UTC (permalink / raw)
To: Baz; +Cc: git
In-Reply-To: <2faad3050710311445l51d1152cs6761803e2f3a77d3@mail.gmail.com>
> Secondly, Net::SMTP::SSL has no problem connecting to gmail - it does
> everything Net::SMTP::TLS does and more; you can use all of the
> options of IO::Socket::SSL with it. A common problem seems to be not
> having Authen::SASL installed (this is required to authenticate with
> gmail) - the one thing Net::SMTP::TLS *does* do is auth without using
> that module.
Ah, yes, i got the Authen::SASL errors at first, but even after
resolving all missing module dependencies,
the --smpt-ssl still did not work for me, so i started looking at
other solutions and found Net::SMTP::TLS.
> In other words, this patch should be entirely unnecessary if you have
> Authen::SASL installed - could you try this? (I've checked for myself,
> git-send-email sends me mail fine via gmail without this patch)
Well, it fails here, maybe maybe you can show me exactly what you did
(configuration/parameters etc)?
This is what i do now:
> git-send-email testfile.patch -to simon.sasburg@gmail.com --chain-reply-to --smtp-server smtp.gmail.com --smtp-user simon.sasburg --smtp-pass secret --smtp-ssl --smtp-server-port 587
and it fails, while the same line using --smtp-tls instead of
--smtp-ssl with my patch applied works.
What am i missing?
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Jeff King @ 2007-10-31 21:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <7v8x5jgdck.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 02:53:47PM -0700, Junio C Hamano wrote:
> The following is on top of 'master'. I haven't tested it. If it
> works, great. If it doesn't, at least it should illustrate what
> needs to be touched.
You beat me to it, as I was busy flaming Linus. :)
The patch I started is very similar to this, but I had one concern that
I was tracking down: is the author name encoding necessarily the same as
the commit text encoding?
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Junio C Hamano @ 2007-10-31 21:53 UTC (permalink / raw)
To: Jeff King
Cc: Dmitry Potapov, Karl Hasselström, Björn Steinbrink,
Johannes.Schindelin, git
In-Reply-To: <20071031180557.GA12211@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It is our old friend vger adding the iso-8859-1 header, I think, since
> no encoding was specified.
>
> I think the problem is that git-format-patch only decides whether to
> append a MIME header based on the commit message contents; it does not
> take the Signed-Off-By into account. This may also be the cause of the
> recent complaints from Matti Aarnio.
I agree. "Signed-off-by" as part of the existing commit message
should be fine, but with "format-patch -s" the code needs to be
careful.
The following is on top of 'master'. I haven't tested it. If it
works, great. If it doesn't, at least it should illustrate what
needs to be touched.
Ideally a fix to 'maint' is needed --- the pretty-print
infrastructure on the 'master' side has strbuf changes and the
patch may have conflicts at the textual level, but it should be
straightforward to adjust to it by anybody so inclined (hint,
hint).
---
builtin-branch.c | 2 +-
builtin-log.c | 2 +-
builtin-rev-list.c | 3 ++-
builtin-show-branch.c | 2 +-
commit.c | 5 ++---
commit.h | 4 +++-
log-tree.c | 15 ++++++++++++++-
7 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3da8b55..3e020cc 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -276,7 +276,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
commit = lookup_commit(item->sha1);
if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &subject, 0, NULL, NULL, 0);
+ &subject, 0, NULL, NULL, 0, 0);
sub = subject.buf;
}
printf("%c %s%-*s%s %s %s\n", c, branch_get_color(color),
diff --git a/builtin-log.c b/builtin-log.c
index e8b982d..8b2bf63 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -787,7 +787,7 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
struct strbuf buf;
strbuf_init(&buf, 0);
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &buf, 0, NULL, NULL, 0);
+ &buf, 0, NULL, NULL, 0, 0);
printf("%c %s %s\n", sign,
sha1_to_hex(commit->object.sha1), buf.buf);
strbuf_release(&buf);
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4439332..6970467 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -86,7 +86,8 @@ static void show_commit(struct commit *commit)
struct strbuf buf;
strbuf_init(&buf, 0);
pretty_print_commit(revs.commit_format, commit,
- &buf, revs.abbrev, NULL, NULL, revs.date_mode);
+ &buf, revs.abbrev, NULL, NULL,
+ revs.date_mode, 0);
if (buf.len)
printf("%s%c", buf.buf, hdr_termination);
strbuf_release(&buf);
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 07a0c23..6dc835d 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -266,7 +266,7 @@ static void show_one_commit(struct commit *commit, int no_name)
strbuf_init(&pretty, 0);
if (commit->object.parsed) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &pretty, 0, NULL, NULL, 0);
+ &pretty, 0, NULL, NULL, 0, 0);
pretty_str = pretty.buf;
}
if (!prefixcmp(pretty_str, "[PATCH] "))
diff --git a/commit.c b/commit.c
index ac24266..8262f6a 100644
--- a/commit.c
+++ b/commit.c
@@ -479,7 +479,7 @@ static int get_one_line(const char *msg)
}
/* High bit set, or ISO-2022-INT */
-static int non_ascii(int ch)
+int non_ascii(int ch)
{
ch = (ch & 0xff);
return ((ch & 0x80) || (ch == 0x1b));
@@ -1046,12 +1046,11 @@ static void pp_remainder(enum cmit_fmt fmt,
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb, int abbrev,
const char *subject, const char *after_subject,
- enum date_mode dmode)
+ enum date_mode dmode, int plain_non_ascii)
{
unsigned long beginning_of_body;
int indent = 4;
const char *msg = commit->buffer;
- int plain_non_ascii = 0;
char *reencoded;
const char *encoding;
diff --git a/commit.h b/commit.h
index b779de8..678c62b 100644
--- a/commit.h
+++ b/commit.h
@@ -61,13 +61,15 @@ enum cmit_fmt {
CMIT_FMT_UNSPECIFIED,
};
+extern int non_ascii(int);
extern enum cmit_fmt get_commit_format(const char *arg);
extern void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb);
extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit*,
struct strbuf *,
int abbrev, const char *subject,
- const char *after_subject, enum date_mode);
+ const char *after_subject, enum date_mode,
+ int non_ascii_present);
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
diff --git a/log-tree.c b/log-tree.c
index 3763ce9..a34beb0 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -125,6 +125,18 @@ static unsigned int digits_in_number(unsigned int number)
return result;
}
+static int has_non_ascii(const char *s)
+{
+ int ch;
+ if (!s)
+ return 0;
+ while ((ch = *s++) != '\0') {
+ if (non_ascii(ch))
+ return 1;
+ }
+ return 0;
+}
+
void show_log(struct rev_info *opt, const char *sep)
{
struct strbuf msgbuf;
@@ -273,7 +285,8 @@ void show_log(struct rev_info *opt, const char *sep)
*/
strbuf_init(&msgbuf, 0);
pretty_print_commit(opt->commit_format, commit, &msgbuf,
- abbrev, subject, extra_headers, opt->date_mode);
+ abbrev, subject, extra_headers, opt->date_mode,
+ has_non_ascii(opt->add_signoff));
if (opt->add_signoff)
append_signoff(&msgbuf, opt->add_signoff);
^ permalink raw reply related
* Re: [PATCH] Implement sending mails over TLS in git-send-email.
From: Baz @ 2007-10-31 21:45 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <1193845859-1788-1-git-send-email-Simon.Sasburg@gmail.com>
On 31/10/2007, Simon Sasburg <simon.sasburg@gmail.com> wrote:
> Signed-off-by: Simon Sasburg <Simon.Sasburg@gmail.com>
> ---
>
> With this patch I was able to use git-send-email to send mail through gmail's
> smpt server, which uses TLS.
Net::SMTP::SSL handles this just fine.
> Net::SMTP::TLS apparently doesn't do proper error handling, so the TLS
> codepath is essentially not checked for errors. I'm not really happy with this.
Net::SMTP::TLS is a bit ugly. It seems unable to do any checking of
the server certificate, a limitation its inherited from the original
script it was hacked from. I suspect some people wouldn't touch this
option if that's the case (although I doubt any tin-foil hatters use
gmail anyway, and we don't use this check for SSL either).
Secondly, Net::SMTP::SSL has no problem connecting to gmail - it does
everything Net::SMTP::TLS does and more; you can use all of the
options of IO::Socket::SSL with it. A common problem seems to be not
having Authen::SASL installed (this is required to authenticate with
gmail) - the one thing Net::SMTP::TLS *does* do is auth without using
that module.
In other words, this patch should be entirely unnecessary if you have
Authen::SASL installed - could you try this? (I've checked for myself,
git-send-email sends me mail fine via gmail without this patch)
> The Net::SMTP::TLS docs say this about error handling:
> >ERROR HANDLING:
> >This module will croak in the event of an SMTP error. Should you wish to handle this gracefully in your application, you may wrap your mail transmission in an eval {} block and check $@ afterward.
>
> But my perl knowledge is way too limited for me to know if/how that helps.
> (This patch was just made by copying existing code and fiddling with it untill it did what i wanted)
>
> Maybe someone who knows more about perl than I do can finish this?
My perl knowledge is a also bit stale, havent had to use it in anger
for a few years; your code looks ok to me, its the dodgy module I'm
worried about :)
> Or give an estimate how difficult it would be for me to fix after pointing me in the right direction?
> (I'm willing to learn a little perl for this, but not too much :-p)
> ---
> git-send-email.perl | 64 +++++++++++++++++++++++++++++++++-----------------
> 1 files changed, 42 insertions(+), 22 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 96051bc..5cf220f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -88,6 +88,9 @@ Options:
>
> --smtp-ssl If set, connects to the SMTP server using SSL.
>
> + --smtp-tls If set, connects to the SMTP server using TLS.
> + Overrides --smtp-ssl.
> +
> --suppress-from Suppress sending emails to yourself if your address
> appears in a From: line. Defaults to off.
>
> @@ -175,7 +178,7 @@ my ($quiet, $dry_run) = (0, 0);
>
> # Variables with corresponding config settings
> my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
> -my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl);
> +my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_authpass, $smtp_ssl, $smtp_tls);
> my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
>
> my %config_bool_settings = (
> @@ -184,6 +187,7 @@ my %config_bool_settings = (
> "suppressfrom" => [\$suppress_from, 0],
> "signedoffcc" => [\$signed_off_cc, 1],
> "smtpssl" => [\$smtp_ssl, 0],
> + "smtptls" => [\$smtp_tls, 0],
> );
>
> my %config_settings = (
> @@ -213,6 +217,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
> "smtp-user=s" => \$smtp_authuser,
> "smtp-pass=s" => \$smtp_authpass,
> "smtp-ssl!" => \$smtp_ssl,
> + "smtp-tls!" => \$smtp_tls,
> "identity=s" => \$identity,
> "compose" => \$compose,
> "quiet" => \$quiet,
> @@ -613,31 +618,46 @@ X-Mailer: git-send-email $gitversion
> die "The required SMTP server is not properly defined."
> }
>
> - if ($smtp_ssl) {
> - $smtp_server_port ||= 465; # ssmtp
> - require Net::SMTP::SSL;
> - $smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
> + if ($smtp_tls) {
> + require Net::SMTP::TLS;
> + $smtp ||= Net::SMTP::TLS->new(
> + $smtp_server,
> + Port => $smtp_server_port,
> + User => $smtp_authuser,
> + Password=> $smtp_authpass);
> +
> + $smtp->mail( $raw_from );
> + $smtp->to( @recipients );
> + $smtp->data;
> + $smtp->datasend("$header\n$message");
> + $smtp->dataend();
> }
> else {
> - require Net::SMTP;
> - $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> - ? "$smtp_server:$smtp_server_port"
> - : $smtp_server);
> - }
> + if ($smtp_ssl) {
> + require Net::SMTP::SSL;
> + $smtp ||= Net::SMTP::SSL->new($smtp_server, Port => $smtp_server_port);
> + }
> + else {
> + require Net::SMTP;
> + $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> + ? "$smtp_server:$smtp_server_port"
> + : $smtp_server);
> + }
>
> - if (!$smtp) {
> - die "Unable to initialize SMTP properly. Is there something wrong with your config?";
> - }
> + if (!$smtp) {
> + die "Unable to initialize SMTP properly. Is there something wrong with your config?";
> + }
>
> - if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
> - $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
> + if ((defined $smtp_authuser) && (defined $smtp_authpass)) {
> + $smtp->auth( $smtp_authuser, $smtp_authpass ) or die $smtp->message;
> + }
> + $smtp->mail( $raw_from ) or die $smtp->message;
> + $smtp->to( @recipients ) or die $smtp->message;
> + $smtp->data or die $smtp->message;
> + $smtp->datasend("$header\n$message") or die $smtp->message;
> + $smtp->dataend() or die $smtp->message;
> + $smtp->ok or die "Failed to send $subject\n".$smtp->message;
> }
> - $smtp->mail( $raw_from ) or die $smtp->message;
> - $smtp->to( @recipients ) or die $smtp->message;
> - $smtp->data or die $smtp->message;
> - $smtp->datasend("$header\n$message") or die $smtp->message;
> - $smtp->dataend() or die $smtp->message;
> - $smtp->ok or die "Failed to send $subject\n".$smtp->message;
> }
> if ($quiet) {
> printf (($dry_run ? "Dry-" : "")."Sent %s\n", $subject);
> @@ -651,7 +671,7 @@ X-Mailer: git-send-email $gitversion
> print "Sendmail: $smtp_server ".join(' ',@sendmail_parameters)."\n";
> }
> print "From: $sanitized_sender\nSubject: $subject\nCc: $cc\nTo: $to\n\n";
> - if ($smtp) {
> + if ($smtp && !$smtp_tls) {
> print "Result: ", $smtp->code, ' ',
> ($smtp->message =~ /\n([^\n]+\n)$/s), "\n";
> } else {
> --
> 1.5.3.4.498.g9c514
>
>
> -
> 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: Newbie: report of first experience with git-rebase.
From: Junio C Hamano @ 2007-10-31 21:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergei Organov, git
In-Reply-To: <Pine.LNX.4.64.0710312111170.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
>> patch that *already became no-op* after conflict resolution and forced
>> me to explicitly use 'git --skip' instead?
>
> Isn't that obvious? To prevent you from accidentally losing a commit.
In case it is not obvious...
A rebase conflict resolution that results in emptiness is a
rather rare event (especially because rebase drops upfront the
identical changes from the set of commits to be replayed), but
it does happen. One could argue that "rebase --continue" can
notice that the resolved index is identical to the tree of the
HEAD commit and skip it automatically.
Given an index that is identical to HEAD, however, it is not
easy to safely determine if that is because the patch did not
apply at all, or the patch was applied with conflicts _and_ the
user decided to make the patch a no-op by resolving. The
automatic droppage of the commit needs to happen only on the
latter and never on the former.
^ permalink raw reply
* Re: unmerging feature branches
From: Linus Torvalds @ 2007-10-31 21:34 UTC (permalink / raw)
To: Alejandro Martinez Ruiz; +Cc: martin f krafft, git discussion list
In-Reply-To: <20071031211658.GA5430@inspiron>
On Wed, 31 Oct 2007, Alejandro Martinez Ruiz wrote:
>
> So how about an "undo" command or a switch for revert with a special
> meaning like "hey, this one is a nice commit, but it ain't ready yet,
> I'd like you to ignore I ever committed the thing when merging or
> rebasing again, thanks"?
There is only one undo command, and that one we've had since day 1:
git reset --hard <state-you-want-to-go-back-to>
will happily undo anything at all (including an earlier undo, apart from
uncommitted dirty tree state, which is gone, gone, gone after that
"undo" and can not be retrieved).
That's the only real true "undo" with clear semantics - it actually does
undo the whole history.
But the kind of "undo" you wish for is not really possible. It implies a
level of semantics that the system just doesn't know or care about. It
also implies that anything else than the shape of history would matter for
merging, which is just anathema to everything that makes git good in the
first place.
That said, in practice, this really seldom does come up. You can often use
"git revert" as that kind of undo, and when you later do the merge, and
the other side has fixed up the code, it's (a) likely going to be obvious
in the conflicts and (b) if the fixes were to infrastructure and you had
no conflicts, it's really easy to just revert the revert too!
Linus
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-10-31 21:31 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <B16F7DA1-E3E5-47A4-AFD3-6680741F38F1@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
>> You forgot a lot more important part. Pushing into publishing
>> repositories. And the discussion is about git-push command.
>
> Exactly, here are two examples:
>
> If you push only to publishing repositories that are read
> only by others, you'll never encounter the problem that
> 10/10 tried to solve. The publishing repository is never
> changed by others. You are the only one who pushes to this
> repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I may do an emergency patch to fix breakage on 'maint' (and
'maint' only) from a location that is not my primary development
box and push the fix out. I fully expect that the push will
push out 'maint' and expect the other branches such as 'master'
on the remote side to stay the same, as I haven't touched
'master' on that box for quite a while and it is now stale. In
that situation, I _want_ the "git push" itself to report failure
to notify me that it did not push what _I_ asked it to push out,
so that I can be reminded that I'd better do "git push $remote
maint" the next time. In the meantime, even though it reports
a failure, 'master' on the remote side is _not_ updated, so the
behaviour is still _safe_.
> Another difference is the way changes are integrated. In
> a workflow without shared repositories, only pull is used
> for integration, while push in only used for publishing the
> changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
> This is different if you work with a shared repository. Bob
> checks out the shared branch foo to his local branch bar and
> later he needs to push bar back to the shared branch foo. Bob
> needs to push changes from his local branch bar to the branch
> foo in the remote repository, a branch with a different name.
> This need does not emerge when working with two publishing
> repositories, as described above.
So you do "git push $remote bar:foo". If you do that regulary,
there are configuration mechanisms to help you reduce your
keyboard wear. What's the problem?
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 21:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, David Kastrup, Jakub Narebski, git
In-Reply-To: <4728EE95.1020004@op5.se>
On Wed, Oct 31, 2007 at 10:07:33PM +0100, Andreas Ericsson wrote:
> Great. Now you just need a git-repo with an url that needs quoting, and
> this discussion could at least potentially solve a real problem for someone.
I would make one on repo.or.cz just to spite you, but it refuses to
create repos with exotic characters in the name.
-Peff
P.S. I agree with your point.
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: J. Bruce Fields @ 2007-10-31 21:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sergei Organov, git
In-Reply-To: <Pine.LNX.4.64.0710312111170.4362@racer.site>
On Wed, Oct 31, 2007 at 09:12:06PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 31 Oct 2007, Sergei Organov wrote:
>
> > Yes, and that's the problem. Why 'git --continue' didn't just skip this
> > patch that *already became no-op* after conflict resolution and forced
> > me to explicitly use 'git --skip' instead?
>
> Isn't that obvious? To prevent you from accidentally losing a commit.
That would make sense to me if this was a mistake that could easily
happen.
I'd assumed that in the case of a conflict that stopped the rebase
process, the index and working tree are always left dirty, so that if
they both agree with the HEAD at the time of commit, then it's because
the user explicitly made them that way.
I ran into the same confusion as the original poster when starting to
use rebase, so I suspect it's common.
--b.
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-31 21:28 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org>
On Wed, 31 Oct 2007, Linus Torvalds wrote:
>
> If you don't like the fact that git doesn't quote, just don't use the
> magic characters. It's that easy. And if somebody quotes the '/', just
> tell him off for being an ass.
Side note - none of the repos I use are likely to actually have any
quoting as an issue, so in that sense I don't actually care. I'd never
notice if git did any quoting or not.
What I care about - and where I entered the discussion - is that the real
impetus for this *stupid* quoting is not the actual need for quoting in
itself (which doesn't seem to exist), but because people want to extend
the repository naming to contain other things too, in particular the
broken cogito single-branch naming thing.
So I could care less about some detail that I'll never even notice, if it
wasn't for the fact that there's all this other baggage that goes with
this whole thing. So the quoting itself is more of a symptom of the real
problem.
Guess what? I didn't make the config file follow any Windows INI standards
either. I'm just waiting for the first person to point out that you cannot
parse a .gitconfig file with standard INI parsers.
Linus
^ permalink raw reply
* Re: unmerging feature branches
From: martin f krafft @ 2007-10-31 21:27 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20071031211658.GA5430@inspiron>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
also sprach Alejandro Martinez Ruiz <alex@flawedcode.org> [2007.10.31.2216 +0100]:
> So how about an "undo" command or a switch for revert with a special
> meaning like "hey, this one is a nice commit, but it ain't ready yet,
> I'd like you to ignore I ever committed the thing when merging or
> rebasing again, thanks"?
Revert does exactly that, by reverting the content. That's all Git
cares about. Does
http://lists-archives.org/git/634475-unmerging-feature-branches.html
make it clear?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"getting a scsi chain working is perfectly simple if you remember that
there must be exactly three terminations: one on one end of the
cable, one on the far end, and the goat, terminated over the scsi
chain with a silver-handled knife whilst burning *black* candles."
-- anthony deboer
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: remote#branch
From: Jeff King @ 2007-10-31 21:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org>
On Wed, Oct 31, 2007 at 02:01:54PM -0700, Linus Torvalds wrote:
> > Yes, this means that if you have a bizarre repo name, you can't
> > necessarily switch between host:file syntax and git:// syntax by simple
> > cut and paste. But you really can't _anyway_, since there is no
> > guarantee that they are rooted at the same location, or have the same
> > view of the filesystem.
>
> .. but in practice it works fine, especially for something like kernel.org
> where it really *is* the same filesystem, just mirrored out.
Yes, and in practice, it works with or without URL encoding, since
people aren't using names that need encoded.
> Also, more importantly, I think the quoting is *stupid*. It adds pointless
> code for absolutely zero gain. Are you going to unquote '/'? Or how about
> '~'?
I don't think it's zero gain; I think it's exactly what users who use
repos with characters that need quoting will expect to happen. That
being said, _I_ don't personally care that much since I think spaces in
filenames are the work of the devil, and I will never use them. And as a
result, I'm not going to implement the code to do it.
But I do think your argument that there is no value in the URL syntax is
just wrong.
I don't understand your mention of '~' and '/'; they don't need quoted
in URLs, and generally are not (though of course they can be).
> .. because it's a simple format, and it *works*. The same way INI config
> files are simple and *work*.
But if you wrote a bunch of documentation referring to the git config
file as an INI file, would you expect people to complain when it
_didn't_ follow the usual expectation for INI files?
OK, this discussion is just getting nowhere, and there is useful git
work I could be doing, so let me sum up my position:
- We should either resolve that some repo specifiers are URLs, or we
should resolve that they are not. I think they are.
- If they are URLs, then we should treat them like URLs, and not
handling quoting is probably a bug. I refuse to accept that it is an
_important_ bug until somebody actually has a repo that needs
quoting, finds that git is substandard, and provides a patch.
- If they are not URLs, then we should probably stop calling them that
in the documentation.
And with that, I shall say no more on the subject. In the spirit of not
saying "oh, I don't want to talk about it anymore, you don't get to say
anything else," I invite you to respond to any of my comments above.
-Peff
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Alex Riesen @ 2007-10-31 21:25 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87d4uv3wh1.fsf@osv.gnss.ru>
Sergei Organov, Wed, Oct 31, 2007 20:39:06 +0100:
> $ git rebase --continue
> You must edit all merge conflicts and then
> mark them as resolved using git add
>
> me> Nice helpful message, -- need to do git-add
>
> $ git add Documentation/core-tutorial.txt
> $ git rebase --continue
>
> Applying Use new syntax (-m option) for git-merge.
>
> No changes - did you forget to use 'git add'?
This "No changes" was meant as a hint
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
>
> me> What?! I just did the git-add! Moreover, before I did git-add, the
> me> error was different and helpful. Something went wrong?
Well, you edited you tree to look exactly like it already is.
> me> No luck :( A few seconds of thinking... Hmm... no-op patch, do I
> me> need to skip it? Let's try the --skip:
>
> $ git rebase --skip
Exactly.
> Applying Fix SYNOPSIS.
>
> error: patch failed: Documentation/git-merge.txt:10
> error: Documentation/git-merge.txt: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merged Documentation/git-merge.txt
> CONFLICT (content): Merge conflict in Documentation/git-merge.txt
> Failed to merge in the changes.
> Patch failed at 0003.
>
> When you have resolved this problem run "git rebase --continue".
> If you would prefer to skip this patch, instead run "git rebase --skip".
> To restore the original branch and stop rebasing run "git rebase --abort".
>
> me> Aha, that's it! But why git didn't just skip the no-op patch
> me> automatically? Well, anyway , now I have a new expected conflict,
it was not a noop patch before you resolved the conflict.
> me> and I'm sure I just want to skip this patch, so let's try exactly
> me> that:
>
> $ git rebase --skip
> Dirty index: cannot apply patches (dirty: Documentation/git-merge.txt)
Well... This one kind of hard: git-rebase _cannot_ know whether it is
safe to just drop all changes in the index and work tree (you could
have made the changes on purpose). It was decided not to drop
anything. You always can do
$ git reset --hard # kills all changes in index and work tree
$ git rebase --skip
(or maybe git-rebase is just too careful...)
> me> No luck :( Well, let's go the long way, -- edit conflicting
> me> Documentation/git-merge.txt (so that it matches upstream),
>
> $ git add Documentation/git-merge.txt
> $ git rebase --skip
> Nothing to do.
>
> me> Well, I already knew this will work, but why should I edit the file
> me> and then git-add it just to skip the patch? Is there better way?
> me> Anyway, the "Nothing to do." above is slightly confusing, -- did it
> me> actually skip the patch? So let's check the result:
Yes. It was the last commit. You were just too unlucky to hit all the
hard cases your first day.
^ permalink raw reply
* Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito
From: Jonas Fonseca @ 2007-10-31 21:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Paolo Ciarrocchi, git
In-Reply-To: <20071031170951.GR18279@machine.or.cz>
On Oct 31, 2007 6:09 PM, Petr Baudis <pasky@suse.cz> wrote:
> And some command in Git to easily get the equivalent of cg-status -g
> output is something I probably miss the most in Git now. (Originally I
> was about to say that I just miss an equivalent of cg-status, but
> thinking about it, most of the time I'm interested only in either -g
> (long branch info) or -w (git status output)).
Try `git branch -v` ... maybe with an added -a.
--
Jonas Fonseca
^ 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