* Re: remote#branch
From: Jeff King @ 2007-10-31 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999.0710310816180.30120@woody.linux-foundation.org>
On Wed, Oct 31, 2007 at 08:28:36AM -0700, Linus Torvalds wrote:
> Because we don't care! This is *exactly* why I brought up the whole
> discussion about "interoperability with a web browser", and pointed out
> that there is no such thing *anyway*, since a GIT URL is generally not
> suitable for browsing _regardless_ of any encoding issues!
>
> So it doesn't matter one whit if a mail client recognizes GIT URL's or
> not! Because the mail client cannot do the right thing with them anyway,
> and would generally think that it's something that it should highlight so
> that you can browse it!
Two points:
1. Just because _your_ mail client can't do anything useful with git
URLs^H^H^H^H repo specifications, doesn't mean that others can't.
2. You are conflating syntax and semantics. Think of the task I
mentioned as two subtasks: pulling the location specifier from the
email, and then doing something useful with it (in this case,
git-cloning it it). The first subtask depends _only_ on a parseable
syntax. The user can provide the context necessary for accomplishing
the second subtask.
For example, consider a terminal that, upon pressing some keyboard
combination, will highlight the first URL-ish looking blob on the
screen, prompt you for a command, and then execute '$command $url'. The
terminal doesn't have to know the semantics of the blob, but it has to
know the syntax. The user provides the semantics.
And yes, such a terminal exists, and I'm using it right now.
> Besides, you generally shouldn't use http for git URL's in the first
> place, and they are very much a secondary citizen. Yes, some people use
> them because they have firewall issues, and they *work*, but giving them
> as examples of GIT URL's and discussing them as it they were a big deal is
> just *stupid* when no other - more realistic - git url works that way
> anyway.
The example above is equally applicable to git:// URLs. As it is to
host:path specifiers, although obviously that is a syntax that the
highlighter would have to recognize. But the point is that by following
established syntaxes, you don't have to write a git-repo-specifier
syntax parser; it comes for free (and isn't that, after all, the entire
_point_ of URLs?).
> This was the whole and only point of my "interoperability" thing. The GIT
> URL's - even when they are perfectly well-formed URL's (which is basically
> 100% of the time, since no current git server tends to put things like
> spaces in the path anyway) - are simply in a different "space" than most
> other URL's.
Sure, you need context to use them correctly. But that doesn't
necessarily mean you should just give up on the syntax part. I would
rather the computer do half of the task and let me finish it than make
me do the whole thing.
> You cannot feed them to a web browser or a file browser anyway, since the
> URL is actually mal-formed (on purpose) in *another* and more fundamental
> way: it doesn't say what the "application domain" is, since it basically
> just assumes that the application domain is git, and the "scheme" part of
> the URL really talks only about the _protocol_, not about the fact that
> it's a git thing.
>
> So if you wanted to be inter-operable, you'd have add the "git" part to
> the scheme, and do the (insane, in my opinion) cogito thing with
> "git+http://xyz.hjashja/" thing!
Yes, if you did that, you could automate _both_ parts of the task. But
again, that doesn't mean there isn't value to automating the first part
But that aside, even git+http doesn't solve all of your problems,
because it doesn't say _what_ you want to do with the location. Web
browsers just assume you want to fetch and view a location. But other
tools which accept URLs might perform _other_ actions on a given
location. So URLs really are a "subject" that can be operated on. It's
just that we are most accustomed to seeing them used by the "retrieve
this and display it" tool.
> - the only way to make git interoperate would be to be user-UNfriendly
> with stupid markers that no git program really needs or wants, and by
> making the escaping depend on the form of the GIT URL.
Some git specifiers clearly look like URLs. Why not accept URL encoding
for them? And if there are characters that _should_ have been encoded by
URL encoding standards, treat them as if they had been encoded (i.e.,
handing 'http://foo.tld/repo with space' would be treated the same as
'http://foo.tld/repo%20with%20space'). This means that most unencoded
repos will behave exactly the same, but we are more liberal in wht we
accept. The exception is that repos with a '%' in the specifier will
parse differently (i.e., if you actually had a repo with the literal
characters '%20' in it, it will no parse).
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.
> Personally, I think it's a much better idea to just be git-specific.
Then why in the world did you choose a specifier syntax that looks
_exactly_ like a URL?
-Peff
^ permalink raw reply
* [PATCH] cvsexportcommit: fix for commits that do not have parents
From: Brad King @ 2007-10-31 20:16 UTC (permalink / raw)
To: git
Previously commits without parents would fail to export with a
message indicating that the commits had more than one parent.
Instead we should use the --root option for git-diff-tree in
place of a parent.
Signed-off-by: Brad King <brad.king@kitware.com>
---
git-cvsexportcommit.perl | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index f284c88..7548cc0 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -82,6 +82,7 @@ foreach my $line (@commit) {
}
}
+my $noparent = "0000000000000000000000000000000000000000";
if ($parent) {
my $found;
# double check that it's a valid parent
@@ -95,8 +96,10 @@ if ($parent) {
} else { # we don't have a parent from the cmdline...
if (@parents == 1) { # it's safe to get it from the commit
$parent = $parents[0];
- } else { # or perhaps not!
- die "This commit has more than one parent -- please name the parent you want to use explicitly";
+ } elsif (@parents == 0) { # there is no parent
+ $parent = $noparent;
+ } else { # cannot choose automatically from multiple parents
+ die "This commit has more than one parent -- please name the parent you want to use explicitly";
}
}
@@ -116,7 +119,11 @@ if ($opt_a) {
}
close MSG;
-`git-diff-tree --binary -p $parent $commit >.cvsexportcommit.diff`;# || die "Cannot diff";
+if ($parent == $noparent) {
+ `git-diff-tree --binary -p --root $commit >.cvsexportcommit.diff`;# || die "Cannot diff";
+} else {
+ `git-diff-tree --binary -p $parent $commit >.cvsexportcommit.diff`;# || die "Cannot diff";
+}
## apply non-binary changes
--
1.5.3.2
^ permalink raw reply related
* Re: Newbie: report of first experience with git-rebase.
From: Sergei Organov @ 2007-10-31 20:28 UTC (permalink / raw)
To: git
In-Reply-To: <20071031195702.GB24332@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:
>> Hello,
>>
>> I've made my first attempt at tracking my changes to upstream git
>> repository using git-fetch/git-rebase workflow. I did three commits to
>> my master branch, and then upstream incorporated two of them in slightly
>> modified form, so that some conflicts are to be expected. I did
>> git-fetch followed by git-rebase, and finally have got the end result I
>> hoped for, but there were some confusion along the way. I think I'd post
>> the log of the session here along with my thoughts so that an interested
>> person could see how it works for a newbie (my thoughts and non-git
>> actions at the time of rebasing are marked with 'me>' prefix):
>>
>> $ git fetch
>> [...]
>> $ git rebase origin
>> First, rewinding head to replay your work on top of it...
>> HEAD is now at 9c51414... Merge branch 'maint' into HEAD
>>
>> Applying Fix a typo.
>>
>> Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
>> Committed: 983e907b1360c17c7ac925d6035d82cc7243f406
>>
>> Applying Use new syntax (-m option) for git-merge.
>>
>> error: patch failed: Documentation/core-tutorial.txt:878
>> error: Documentation/core-tutorial.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/core-tutorial.txt
>> CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
>> Failed to merge in the changes.
>> Patch failed at 0002.
>>
>> 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> Nice, this conflict is expected.
>> me> Editing Documentation/core-tutorial.txt to resolve the
>> me> conflict... Conflict is resolved so that the working file matches
>> me> upstream version.
>>
>> $ 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'?
>>
>> 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?
>> me> Well, it's unlikely, but maybe I made a mistake of not specifying
>> me> the 'origin'?
>>
>> $ git rebase --continue origin
>>
>> Applying Use new syntax (-m option) for git-merge.
>>
>> No changes - did you forget to use 'git add'?
>>
>> 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> 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
>>
>> 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
>
> It wasn't a no-op patch. It had conflicts which you resolved to the
> upstream version and _then_ you had a no-op.
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?
This forces one to use 'git --skip' if the patch happens to become a
no-op after conflict resolution, and 'git --continue' otherwise. Why
this complication?
--
Sergei.
^ permalink raw reply
* Re: [PATCH] Get rid of cpio in git-clone (was: Re: cpio command not found)
From: Jeff King @ 2007-10-31 20:22 UTC (permalink / raw)
To: Erik Mouw; +Cc: Johannes Schindelin, Karl Hasselstr?m, Bill Lear, git
In-Reply-To: <20071031201425.GA29332@gateway.home>
On Wed, Oct 31, 2007 at 09:14:25PM +0100, Erik Mouw wrote:
> > Patch, please?
>
> Here you go.
Good, now we have something to critique. :)
> - find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
> + cp -Rp$l objects/ "$GIT_DIR/" || exit 1
cp -l isn't even close to portable. It's not in POSIX, and doesn't work
on (at least) Solaris.
I think Mike's patch (cpio if available, copy otherwise) is a reasonable
approach. If there are other methods (and I think cp -l is not
unreasonable for systems where it is supported and cpio is unavailable),
then perhaps it is worth trying them one by one and dropping back to
full copy if all fail.
-Peff
^ permalink raw reply
* Bug in git-show-branch, or in core-tutorial?
From: Sergei Organov @ 2007-10-31 20:17 UTC (permalink / raw)
To: git
Or is it me who needs a fix?
[Sorry, this is roughly a repeat of my earlier post
<http://permalink.gmane.org/gmane.comp.version-control.git/62493>
I didn't get any answer to, and I'm trying once more to attract
your attention to the issue.]
Please consider the following quote starting at core-tutorial.txt:933
(emphasis is mine):
<quote>
------------------------------------------------
$ git show-branch --topo-order master mybranch
* [master] Merge work in mybranch
! [mybranch] Some work.
--
- [master] Merge work in mybranch
*+ [mybranch] Some work.
------------------------------------------------
The first two lines indicate that it is showing the two branches
and the first line of the commit log message from their
top-of-the-tree commits, you are currently on `master` branch
(notice the asterisk `\*` character), and the first column for
the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. *Three* commits are shown along with their log messages.
All of them have non blank characters in the first column (`*`
shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
commits from the master branch. The string inside brackets
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. '*master~1*' is the first parent of 'master'
branch head.
</quote>
You see, there are only *two* commits shown by git-show-branch while
description mentions *three* of them, and there is no 'master~1' commit
in the git-show-branch output while description does mention it.
I've replayed all the tutorial up to this point, and the git-show-branch
output matches those in the tutorial exactly, but then the explanation
text makes little sense? On the other hand, the state of the repo
suggests that there should be 'master~1' commit in the git-show-branch
output in accordance with the explanation, so it's git-show-branch that
is buggy? I'm totally confused :(
Please, help!
--
Sergei.
^ permalink raw reply
* [PATCH] Get rid of cpio in git-clone (was: Re: cpio command not found)
From: Erik Mouw @ 2007-10-31 20:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Karl Hasselstr?m, Bill Lear, git
In-Reply-To: <Pine.LNX.4.64.0710311420330.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]
On Wed, Oct 31, 2007 at 02:20:47PM +0000, Johannes Schindelin wrote:
> On Wed, 31 Oct 2007, Erik Mouw wrote:
>
> > On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:
> > > On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> > >
> > > > I don't remember this dependence from earlier versions of git. I
> > > > have been running git 1.4.xx on this machine for a while...
> > >
> > > When you clone with -l, git uses cpio to hardlink to the original
> > > repository. What has changed is that -l is now used by default when
> > > cloning a repository that's accessed via the file system (as opposed
> > > to over some network protocol).
> >
> > Why cpio? What is wrong with ln(1) (every Unix should have one) or
> > link(2) ?
>
> Patch, please?
Here you go.
Remove dependency on cpio for git-clone. Apparently some POSIX systems
out there don't have cpio, just assume cp is there.
Signed-off-by: Erik Mouw <mouw@nl.linux.org>
diff --git a/INSTALL b/INSTALL
index f1eb404..9074563 100644
--- a/INSTALL
+++ b/INSTALL
@@ -79,8 +79,7 @@ Issues of note:
- "perl" and POSIX-compliant shells are needed to use most of
the barebone Porcelainish scripts.
- - "cpio" is used by git-merge for saving and restoring the index,
- and by git-clone when doing a local (possibly hardlinked) clone.
+ - "cpio" is used by git-merge for saving and restoring the index.
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..061534c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -294,7 +294,7 @@ yes)
fi
fi &&
cd "$repo" &&
- find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
+ cp -Rp$l objects/ "$GIT_DIR/" || exit 1
fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-10-31 20:10 UTC (permalink / raw)
To: git
In-Reply-To: <1193861145-20357-1-git-send-email-mh@glandium.org>
Damn, and I forgot git-send-email doesn't add the <> to In-Reply-To.
Mike
^ permalink raw reply
* [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-10-31 20:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Mike Hommey <mh@glandium.org>
---
git-clone.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..57e96ae 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -191,7 +191,9 @@ fi
# it is local
if base=$(get_repo_base "$repo"); then
repo="$base"
- local=yes
+ if type cpio > /dev/null 2>&1; then
+ local=yes
+ fi
fi
dir="$2"
--
1.5.3.4
^ permalink raw reply related
* Re: Newbie: report of first experience with git-rebase.
From: Björn Steinbrink @ 2007-10-31 19:57 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87d4uv3wh1.fsf@osv.gnss.ru>
On 2007.10.31 22:39:06 +0300, Sergei Organov wrote:
> Hello,
>
> I've made my first attempt at tracking my changes to upstream git
> repository using git-fetch/git-rebase workflow. I did three commits to
> my master branch, and then upstream incorporated two of them in slightly
> modified form, so that some conflicts are to be expected. I did
> git-fetch followed by git-rebase, and finally have got the end result I
> hoped for, but there were some confusion along the way. I think I'd post
> the log of the session here along with my thoughts so that an interested
> person could see how it works for a newbie (my thoughts and non-git
> actions at the time of rebasing are marked with 'me>' prefix):
>
> $ git fetch
> [...]
> $ git rebase origin
> First, rewinding head to replay your work on top of it...
> HEAD is now at 9c51414... Merge branch 'maint' into HEAD
>
> Applying Fix a typo.
>
> Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
> Committed: 983e907b1360c17c7ac925d6035d82cc7243f406
>
> Applying Use new syntax (-m option) for git-merge.
>
> error: patch failed: Documentation/core-tutorial.txt:878
> error: Documentation/core-tutorial.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/core-tutorial.txt
> CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
> Failed to merge in the changes.
> Patch failed at 0002.
>
> 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> Nice, this conflict is expected.
> me> Editing Documentation/core-tutorial.txt to resolve the
> me> conflict... Conflict is resolved so that the working file matches
> me> upstream version.
>
> $ 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'?
>
> 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?
> me> Well, it's unlikely, but maybe I made a mistake of not specifying
> me> the 'origin'?
>
> $ git rebase --continue origin
>
> Applying Use new syntax (-m option) for git-merge.
>
> No changes - did you forget to use 'git add'?
>
> 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> 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
>
> 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
It wasn't a no-op patch. It had conflicts which you resolved to the
upstream version and _then_ you had a no-op.
> me> automatically? Well, anyway , now I have a new expected 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)
>
> 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:
There seems to be some bug in rebase that makes it fail in this case.
Someone on #git also reported that --abort failed to reset his branch to
the old head in a similar case, but I didn't manage to reproduce that
yet (well, I didn't try that hard), so I don't know if it's really a bug
or a misuse by that guy.
Björn
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Björn Steinbrink @ 2007-10-31 19:50 UTC (permalink / raw)
To: Jeff King
Cc: Dmitry Potapov, Karl Hasselström, Junio C Hamano,
Johannes.Schindelin, git
In-Reply-To: <20071031180557.GA12211@coredump.intra.peff.net>
On 2007.10.31 14:05:57 -0400, Jeff King wrote:
> On Wed, Oct 31, 2007 at 05:36:41PM +0300, Dmitry Potapov wrote:
>
> > Hmm... I looked at the mail again and I cannot see where 8859-1 is
> > specified. It seems that context encoding is not specified at all.
> > Of course, it is incorrect to use non ASCII characters in a mail
> > without specifying encoding. Apparently, because I use utf-8 in the
> > terminal, the Sign-off line displays correctly for me, so I did not
> > notice the problem. Sorry for the noise...
>
> 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.
Yep, that's it. If the Signed-Off-By was added by commit -s, it works,
while format-patch -s causes the header to be missing, although the
Signed-Off-By is utf-8 encoded. Will try to remember that.
Thanks,
Björn
^ permalink raw reply
* Re: cpio command not found
From: Mike Hommey @ 2007-10-31 19:48 UTC (permalink / raw)
To: Erik Mouw; +Cc: Karl Hasselstr?m, Bill Lear, git
In-Reply-To: <20071031140655.GA8802@gateway.home>
On Wed, Oct 31, 2007 at 03:06:55PM +0100, Erik Mouw wrote:
> On Wed, Oct 31, 2007 at 02:30:39PM +0100, Karl Hasselstr?m wrote:
> > On 2007-10-31 06:51:30 -0600, Bill Lear wrote:
> >
> > > I don't remember this dependence from earlier versions of git. I
> > > have been running git 1.4.xx on this machine for a while...
> >
> > When you clone with -l, git uses cpio to hardlink to the original
> > repository. What has changed is that -l is now used by default when
> > cloning a repository that's accessed via the file system (as opposed
> > to over some network protocol).
>
> Why cpio? What is wrong with ln(1) (every Unix should have one) or
> link(2) ?
Since git-clone is not yet a builtin, and is actually a shell script, it
makes more sense to use cpio than ln.
Mike
^ permalink raw reply
* Re: remote#branch
From: Erik Warendorph @ 2007-10-31 19:29 UTC (permalink / raw)
To: Jan Hudec
Cc: Linus Torvalds, Tom Prince, Theodore Tso, Junio C Hamano,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030193610.GA4442@efreet.light.src>
* Jan Hudec <bulb@ucw.cz> [2007-10-30 20:36:10 +0100]:
>
> On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:
> > > So, how should git deal with
> > >
> > > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> >
> > The way it has always cared. Git itself does no quoting what-so-ever
> > (except for the *argument* quoting etc that it needs).
> >
> > Now, the *transport* back-end may end up quoting it, of course, the same
> > way it may end up using some random protocol. The user shouldn't care
> > about the implementation details!
> >
> > In the case of the git transport, there is no quoting even by the
> > transport protocol. In the case of http, libcurl would hopefully quote for
> > us.
>
> So the three addresses will all be different, right?
>
> > > compared to
> > >
> > > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
> >
> > No difference, what-so-ever, that I can see. Git doesn't quote it.
>
> Yes. But the server will unquote it. ' ' should not have been there, but it's
> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
> for ' ' as well. Therefore all these three addresses are the *SAME*.
>
> Now the user expectation will be that when these are the same, the git://
> ones above will be as well. But they are not. This is not about following any
> RFC for sake of it, but about being consistent with ourselves.
I don't think the
'+' is quoting for ' '
part is fully correct, at least not if you're talking about
"real RFC 2396 URLs" (not "Git URLs"). I might misunderstand
you here, but there has also been other postings suggesting
that plus should/could be used instead of space, implying that
people think that pluses are always transformed to spaces in
URLs. But if I understand RFC 2396 correctly, this is *not*
the case.
RFC 2396 says that pluses are treated as "reserved" in the
*query* part of the URL (ie on the right side of the question
mark) -- here they *are* transformed to spaces, although the
RFC itself doesn't really say specifically what happens to
them. In the path part, pluses are not "reserved", they are
simply a "pchar" along with "unreserved", "escaped" and a
couple of other characters. There is nothing in the RFC
implying that pluses in the path part will be transformed into
spaces, and in my experience this does not happen in practice
either.
To recap:
(In the examples below <...> is used to mean legal URLs,
while "..." is used to mean "the literal characters in the
URL" (more or less))
* In the query part:
'%20' = '+' = a literal space
'%2B' = a literal plus
For example:
<http://example.com/somescript?v=x%20y>
= <http://example.com/somescript?v=x+y>
= "http://example.com/somescript?v=x y"
<http://example.com/somescript?v=x%2By>
= "http://example.com/somescript?v=x+y"
* In the path part:
'%20' = a literal space
'%2B' = '+' = a literal plus
For example:
<http://example.com/x%20y.html>
= "http://example.com/x y.html"
<http://example.com/x%2By>
= <http://example.com/x+y>
= "http://example.com/x+y"
I'm not advocating that "Git URLs" necessarily should be made
fully RFC 2396 compliant (neither am I nitpicking just for the
sake of nitpicking), I'm just pointing out that if someone
*should* want to make "Git URLs" fully or more RFC 2396
compliant in some way for some reason, having pluses being
automatically transformed to spaces in the path part of the URL
does not follow the RFC (as far as I understand it).
--
Erik Warendorph <erik@warendorph.org>
^ permalink raw reply
* Newbie: report of first experience with git-rebase.
From: Sergei Organov @ 2007-10-31 19:39 UTC (permalink / raw)
To: git
Hello,
I've made my first attempt at tracking my changes to upstream git
repository using git-fetch/git-rebase workflow. I did three commits to
my master branch, and then upstream incorporated two of them in slightly
modified form, so that some conflicts are to be expected. I did
git-fetch followed by git-rebase, and finally have got the end result I
hoped for, but there were some confusion along the way. I think I'd post
the log of the session here along with my thoughts so that an interested
person could see how it works for a newbie (my thoughts and non-git
actions at the time of rebasing are marked with 'me>' prefix):
$ git fetch
[...]
$ git rebase origin
First, rewinding head to replay your work on top of it...
HEAD is now at 9c51414... Merge branch 'maint' into HEAD
Applying Fix a typo.
Wrote tree f5b2feefc021486eae9d2d84c69e0d6ead027a9d
Committed: 983e907b1360c17c7ac925d6035d82cc7243f406
Applying Use new syntax (-m option) for git-merge.
error: patch failed: Documentation/core-tutorial.txt:878
error: Documentation/core-tutorial.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/core-tutorial.txt
CONFLICT (content): Merge conflict in Documentation/core-tutorial.txt
Failed to merge in the changes.
Patch failed at 0002.
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> Nice, this conflict is expected.
me> Editing Documentation/core-tutorial.txt to resolve the
me> conflict... Conflict is resolved so that the working file matches
me> upstream version.
$ 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'?
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?
me> Well, it's unlikely, but maybe I made a mistake of not specifying
me> the 'origin'?
$ git rebase --continue origin
Applying Use new syntax (-m option) for git-merge.
No changes - did you forget to use 'git add'?
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> 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
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,
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)
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:
$ gitk
me> The result is as expected, -- the only patch on top of current origin
me> HEAD, -- nice.
--
Sergei.
^ 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 18:51 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <B3C76DB8-076D-4C43-AC28-99119A05325C@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 31, 2007, at 9:45 AM, Junio C Hamano wrote:
>
>> I would not doubt it would be safer for _your_ workflow, but you
>> should consider the risk of making things more cumbersome for
>> workflows of others by enforcing that policy.
>
> Together with the '--create' flag it would be safer in all
> cases, because it would always do _less_ than what git push
> currently does. The safest choice would be if "git push"
> refused to do anything until configured appropriately.
>
> "safer" is independent of the workflow.
By your definition, a command that does not do anything by
default is safer regardless of the workflow.
That may be theoretically true --- it cannot do any harm by
default. But that is not useful.
> I'm mainly interested in using git against a shared repo,
> and make it as simple and as safe as possible to use in
> such a setup. I suspect that git is more optimized for the
> workflow used for the Linux kernel and for developing git,
> which heavily rely on sending patches to mailing lists and
> pulling fro read-only repos.
You forgot a lot more important part. Pushing into publishing
repositories. And the discussion is about git-push command.
^ permalink raw reply
* Re: [PATCH 1/1] Add --first-parent support to interactive rebase.
From: Jeff King @ 2007-10-31 18:05 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Karl Hasselström, Björn Steinbrink, Junio C Hamano,
Johannes.Schindelin, git
In-Reply-To: <20071031143641.GF15182@dpotapov.dyndns.org>
On Wed, Oct 31, 2007 at 05:36:41PM +0300, Dmitry Potapov wrote:
> Hmm... I looked at the mail again and I cannot see where 8859-1 is
> specified. It seems that context encoding is not specified at all.
> Of course, it is incorrect to use non ASCII characters in a mail
> without specifying encoding. Apparently, because I use utf-8 in the
> terminal, the Sign-off line displays correctly for me, so I did not
> notice the problem. Sorry for the noise...
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.
-Peff
^ permalink raw reply
* Re: remote#branch
From: Petr Baudis @ 2007-10-31 17:13 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Paolo Ciarrocchi, git
In-Reply-To: <20071030235823.GA22747@coredump.intra.peff.net>
On Tue, Oct 30, 2007 at 07:58:23PM -0400, Jeff King wrote:
> http://host/git repo with spaces in the path
>
> compared to:
>
> http://host/git+repo+with+spaces+in+the+path
Just pedantic side-note: these two URLs are not equivalent. '+' is valid
substitute for a space only in query string part of URL. In path you
have to use %20.
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 17:08 UTC (permalink / raw)
To: git
Cc: Linus Torvalds, Johannes Schindelin, Peter Karlsson, Lars Hjemli,
Benoit SIGOURE
In-Reply-To: <alpine.LFD.0.999.0710310928490.3340@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]
On Wednesday 31 October 2007, Linus Torvalds wrote:
> On Wed, 31 Oct 2007, Johannes Schindelin wrote:
> > Seriously, your proposal does not make any sense. If you have to set up a
> > hook to get the _sane_ behaviour, something is really wrong. So I do not
> > really understand why you brought up this idea here and now.
>
> Well, I think this does kind of have some commonality with another issue
> that has come up before: git clone only clones the really core repository
> data.
>
> That's generally a big feature, and I think it's absolutely the correct
> thing to do.
>
> But I can also see that sometimes, you might want to clone more than the
> actual repository, and get things like SVN metadata, branch reflogs,
> various hooks and all the config options too.
>
> Of course, in practice, at least right now, the right thing to do for that
> is to just do a recursive filesystem copy and then a "git status", but I
> think the background here is that some people simply do end up wanting to
> transfer more infrastructure than just the actual repository data.
>
> One thing to note: one reason for *not* allowing that is that incremental
> upgrades of non-repo data is obviously not possible. You might be able to
> *clone* a repo with config info and other metadata (if nothing else, then
> by just doing that raw filesystem copy), but you will never ever be able
> to _fetch_ the updates, because they aren't part of the core repository,
> and aren't versioned.
>
> So I think I can understand why some people would want to do things like
> this, but I do think it's broken. Yes, you can make the grafts file (or
> the config file) be part of the repo, and even just add a symlink to your
> .git/ directory, but it's simply not a very good model.
>
> So I think it always does end up breaking (other people might rebase, and
> break your grafts, or just not want them in the first place, or they don't
> care about the same things, and mess up "your" configuration etc etc). So
> the git repo layout is designed to have the minimally required shared
> state, and not anything else.
I agree that sharing the "metainfo" (i.e. config, grafts, hooks, reflogs,
rerere magic, etc.) of the repo is not something git should do in the general
case.
But in some specific workflows (e.g. in-house, centralized workflows), I think
it makes sense to coordinate/share some of this info between repos. But in
that case, I guess such coordination/sharing can be done by special-purpose
tools built on top of git (e.g. in-house admin scripts).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: cogito and remote#branch, was Re: [PATCH] Git homepage: remove all the references to Cogito
From: Petr Baudis @ 2007-10-31 17:09 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Johannes Schindelin, Paolo Ciarrocchi, git
In-Reply-To: <2c6b72b30710161516j5c029847r1acb3ce2d88344a1@mail.gmail.com>
On Wed, Oct 17, 2007 at 12:16:25AM +0200, Jonas Fonseca wrote:
> On 10/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 16 Oct 2007, Petr Baudis wrote:
> > > I'm not sure this is good idea, Cogito is still quite frequently used
> > > and it should be documented that it exists.
> >
> > I agree. But maybe it could be marked as unmaintained? Maybe someone
> > steps up to maintain it. Or, even better, comes up with a list of "this
> > is what I like do regularly with cogito, but there's no easy way with core
> > git" issues.
>
> One thing that I occasionally miss is
>
> cg-export /path/to/directory/
>
> And yes, I know it can be accomplished via "obscurities" like
> git-archive+tar (or worse git-checkout-index) but I think having
> an easy way to checkout to a directory could be great (and possibly
> with the ability to apply substitutions with the recent discussion).
>
> Else, I am really looking forward for the option parser work to provide
> an easy way to list options. I found it very useful with Cogito.
> Also, most of the "status" commands in Cogito seemd to provide a richer
> default output geared towards human consumption. For example stuff like
> git-branch -v and git remote -v flags would have been the default for
> Cogito ... I think.
A "me too" mail for once...
I fully second this. cg-export is one of the Cogito commands I still use
frequently. I wonder if there is any obvious piece of Git command set we
could glue this on (so that we don't introduce Yet Another Command)... I
think cg-export is better-named here than git-archive. ;-)
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)).
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Linus Torvalds @ 2007-10-31 16:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311553510.4362@racer.site>
On Wed, 31 Oct 2007, Johannes Schindelin wrote:
>
> Seriously, your proposal does not make any sense. If you have to set up a
> hook to get the _sane_ behaviour, something is really wrong. So I do not
> really understand why you brought up this idea here and now.
Well, I think this does kind of have some commonality with another issue
that has come up before: git clone only clones the really core repository
data.
That's generally a big feature, and I think it's absolutely the correct
thing to do.
But I can also see that sometimes, you might want to clone more than the
actual repository, and get things like SVN metadata, branch reflogs,
various hooks and all the config options too.
Of course, in practice, at least right now, the right thing to do for that
is to just do a recursive filesystem copy and then a "git status", but I
think the background here is that some people simply do end up wanting to
transfer more infrastructure than just the actual repository data.
One thing to note: one reason for *not* allowing that is that incremental
upgrades of non-repo data is obviously not possible. You might be able to
*clone* a repo with config info and other metadata (if nothing else, then
by just doing that raw filesystem copy), but you will never ever be able
to _fetch_ the updates, because they aren't part of the core repository,
and aren't versioned.
So I think I can understand why some people would want to do things like
this, but I do think it's broken. Yes, you can make the grafts file (or
the config file) be part of the repo, and even just add a symlink to your
.git/ directory, but it's simply not a very good model.
So I think it always does end up breaking (other people might rebase, and
break your grafts, or just not want them in the first place, or they don't
care about the same things, and mess up "your" configuration etc etc). So
the git repo layout is designed to have the minimally required shared
state, and not anything else.
Linus
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-31 15:57 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <200710311621.09845.johan@herland.net>
Hi,
On Wed, 31 Oct 2007, Johan Herland wrote:
> Well, to a certain degree (and depending on your level of paranoia),
> you're always responsible for the code entering your own repo, and you
> could always set up a hook disallowing ".gitgrafts" (or whatever it
> would be called) from entering your repo.
Yeah, right. And you could also stay in an oxygen tent the whole time to
avoid being infected with some virus.
Seriously, your proposal does not make any sense. If you have to set up a
hook to get the _sane_ behaviour, something is really wrong. So I do not
really understand why you brought up this idea here and now.
I understand that you wanted to end this discussion, but I could _not_ let
your statement stand uncorrected.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Implement sending mails over TLS in git-send-email.
From: Simon Sasburg @ 2007-10-31 15:50 UTC (permalink / raw)
To: git; +Cc: Simon Sasburg
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::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.
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?
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
^ permalink raw reply related
* Re: remote#branch
From: Linus Torvalds @ 2007-10-31 15:28 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, git
In-Reply-To: <85lk9jzsxb.fsf@lola.goethe.zz>
On Wed, 31 Oct 2007, David Kastrup wrote:
>
> I can click on links in my mail reader, and the above is not recognized
> as one. <URL:http://host/git repo with spaces in the path> would likely
> work.
I don't think this whole discussion is relevant at all.
Why?
Because we don't care! This is *exactly* why I brought up the whole
discussion about "interoperability with a web browser", and pointed out
that there is no such thing *anyway*, since a GIT URL is generally not
suitable for browsing _regardless_ of any encoding issues!
So it doesn't matter one whit if a mail client recognizes GIT URL's or
not! Because the mail client cannot do the right thing with them anyway,
and would generally think that it's something that it should highlight so
that you can browse it!
Besides, you generally shouldn't use http for git URL's in the first
place, and they are very much a secondary citizen. Yes, some people use
them because they have firewall issues, and they *work*, but giving them
as examples of GIT URL's and discussing them as it they were a big deal is
just *stupid* when no other - more realistic - git url works that way
anyway.
This was the whole and only point of my "interoperability" thing. The GIT
URL's - even when they are perfectly well-formed URL's (which is basically
100% of the time, since no current git server tends to put things like
spaces in the path anyway) - are simply in a different "space" than most
other URL's.
You cannot feed them to a web browser or a file browser anyway, since the
URL is actually mal-formed (on purpose) in *another* and more fundamental
way: it doesn't say what the "application domain" is, since it basically
just assumes that the application domain is git, and the "scheme" part of
the URL really talks only about the _protocol_, not about the fact that
it's a git thing.
So if you wanted to be inter-operable, you'd have add the "git" part to
the scheme, and do the (insane, in my opinion) cogito thing with
"git+http://xyz.hjashja/" thing!
See? Otherwise no non-git program could understand *anyway* that it's a
git address, and not meant to be some html thing.
So to summarise:
- the only way to make git interoperate would be to be user-UNfriendly
with stupid markers that no git program really needs or wants, and by
making the escaping depend on the form of the GIT URL.
But hey, if people want to screw up git even more, and make the "git+"
crap also encode the address, I don't care. I would never *ever* use the
"git+xyz://" forms anyway. They're stupid and useless, but if you want to
have programs automatically do something magical about git url's, you'd
need that "git+" thing.
Personally, I think it's a much better idea to just be git-specific.
Because realistically, nobody is ever going to really be anything else
anyway. There is nothing you can sanely do with a git link, unless it's
something very git specific and conscious in the first place!
Linus
^ permalink raw reply
* git-commit broken with GIT_INDEX_FILE
From: Tim Janik @ 2007-10-31 15:02 UTC (permalink / raw)
To: git
hey All.
i'm maintaining my own git porcelainen, and as part of that had to
(re-)implement my own commit command:
http://blogs.gnome.org/timj/2007/10/13/13102007-yummy-yummy-porcelain-version-08/
i've read through git-commit and cg-commit, and would really like to avoid
reimplementing the hook and utf8 encoding handling. thus, my tool calls
git-commit once it has created an index file with all the files that
need comitting.
ideally, it'd construct a temporary index, e.g. $GIT_DIR/next-index$$ and
then invoke:
GIT_INDEX_FILE=$GIT_DIR/next-index$$ git-commit -F commitmsg.txt
this is not working as expected however.
when GIT_INDEX_FILE=tmpindex is specified for git-commit-1.5.3.4, it will
construct a commit message for tmpindex, but it'll still use the standard
index file $GIT_DIR/index for git-write-tree.
(so my current implementation saves and restores the standard index file
around committs.)
for consistent commit messages, the index file used for commit message
construction should be the same index used for git-write-tree.
ideally however, GIT_INDEX_FILE=tmpindex git-commit would work correctly
in using tmpindex for git-write-tree as well.
---
ciaoTJ
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johan Herland @ 2007-10-31 15:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Peter Karlsson, Lars Hjemli, Benoit SIGOURE
In-Reply-To: <Pine.LNX.4.64.0710311503120.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Wednesday 31 October 2007, Johannes Schindelin wrote:
> On Wed, 31 Oct 2007, Johan Herland wrote:
> > On Wednesday 31 October 2007, Johannes Schindelin wrote:
> > > All this does not change the fact that installing a graft and 'git gc
> > > --prune'ing gets rid of the old history. D'oh.
> >
> > So will rebasing and --prune'ing, or pulling a rebased branch and
> > --prune'ing. Git already gives you _plenty_ of different ropes to hang
> > yourself with. The question is whether adding yet another one is worth
> > it.
>
> But that is not the question here. The question here is: are users
> allowed to hang _others_? I say: no.
Well, to a certain degree (and depending on your level of paranoia), you're
always responsible for the code entering your own repo, and you could always
set up a hook disallowing ".gitgrafts" (or whatever it would be called) from
entering your repo.
But taking this (and everything else that's been said) into account, I totally
agree with you that adding this feature would open up a _massive_ can of
worms.
EOD
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Steffen Prohaska @ 2007-10-31 15:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wbfufbo.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 9:58 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Oct 28, 2007, at 5:03 PM, Junio C Hamano wrote:
>> ...
>>> An alternative, just to let me keep my nicer public image by
>>> pretending to be constructive ;-)
>>>
>>> Introduce a configuration "remote.$name.push_default" whose
>>> value can be a list of refs. Teach the push command without
>>> refspecs:
>>>
>>> $ git push
>>> $ git push $remote
>>>
>>> to pretend as if the listed refspecs are given, instead of the
>>> traditional "matching branches" behaviour.
>>>
>>> Then, introduce another option
>>>
>>> $ git push --matching
>>> $ git push --matching $remote
>>>
>>> to override that configuration, if set, so that the user who
>>> usually pushes only the selected branches can use the "matching
>>> branches" behaviour when needed.
>>>
>>> Along with your earlier "git push $remote HEAD" patch, this will
>>> allow you to say:
>>>
>>> [remote "origin"]
>>> push_default = HEAD
>>>
>>> and your
>>>
>>> $ git push
>>>
>>> will push only the current branch.
>>
>> Sounds reasonable; but it is more work. I'm not starting to
>> implement this today.
>
> Take your time; nobody is in a hurry.
>
> If somebody usually uses "matching" behaviour, i.e. without
> remote.$name.push_default configuration, but wants to push only
> the current branch as a one-shot operation, we can obviously use
> "git push $remote HEAD". But to be complete, it may make sense
> to have another option
>
> $ git push --current
>
> that lets you omit $remote (and default to the value configured
> with branch.$name.remote).
Here is an alternative proposal.
The idea is that in a workflow based on a shared repository
git pull and git push should be 'more' symmetric than they are
in a pull-only based workflow. The integration of changes is
'more' direct. Working against a shared repository may require
to integrate new changes before pushing. Changes are also
pushed directly to the remote branch you originally branched
off. Both is different from a pull-only workflow, where I first
push my changes to a privately owned but publicly readable repo
and someone else does the integration by pulling from there.
The branch in the shared repository serves as the single
'integration' branch. One can use 'git branch --track' to set
up local branches that automatically merge changes from the
shared 'integration' branch. That is git pull without further
arguments is the right command to integrate changes from the
shared branch to the local branch. (git provides more advanced
ways, but git pull is simple and in principle does the right
thing.)
What is missing is a simple way to 'push' local changes back
to shared integration branch in the remote repository. This
can be seen as a 'symmetric' operation to pulling. So, git push
should do the right thing. And the right thing is pushing the
current branch to the shared 'integration' branch.
The automerge behaviour stores information in branch.$name.remote
and branch.$name.merge that provide sufficient information to
make "git pull" the equivalent of
git pull <remoteURL> <remoteref>
where <remoteURL> is the full URL of the remote stored in
branch.$name.remote, and <remoteref> is the value of
branch.$name.merge.
A 'symmetric' push command would push the current branch to the
remote head it originally was branched off, that is
git push <remoteURL> <currentbranch>:<remoteref>
Now, the proposal is
- add a configuration variable branch.$name.push
- change git push to check if the push configuration variable
is set for the current branch $name, and if so run the
equivalent of
git push branch.$name.remote $name:branch.$name.push
- teach git branch a flag --push/--no-push that sets up
branch.$name.push. Add branch.autosetuppush configuration
flag to configure if --push or --no-push is the default.
(maybe we need better names here).
This breaks the symmetry between git fetch/git push and
replaces it with a symmetry between git pull/git push for some
branches. I believe this might be the right thing to do for
a workflow based on shared repos.
Steffen
^ 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