* Re: clone from url with email address as username?(escaping @ symbol)
From: Matthieu Moy @ 2009-09-29 18:09 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Ben Bennett, Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.2.00.0909291946520.23903@tvnag.unkk.fr>
Daniel Stenberg <daniel@haxx.se> writes:
> On Tue, 29 Sep 2009, Matthieu Moy wrote:
>
>> Unfortunately, it seems the complete URL is passed to curl, and curl
>> is the one doing it wrong. Indeed:
>>
>> $ curl -v https://user@email.com@server.com/path/
>> * getaddrinfo(3) failed for email.com@server.com:443
>
> This is not exactly curl "doing it wrong". This is a user passing in
> something that isn't a URL to the command that asks for a URL to work
> on. The user part cannot legally have a '@' letter in a URL, you must
> encode it.
>
>> In short, you have to use %40 to escape the @, and curl does it this
>> way because the RFC doesn't allow @ in usernames.
>
> Exactly. So curl is not "wrong", it just can't work around this user-error.
It may not want work around user-errors, but you can hardly say that
it _can't_. Many tools do in this case, Firefox is one of them. And
anyway, trying to connect to email.com@server.com is probably the
worst thing it can do.
At least, it could warn about two @ in the URL and say it can't
handle it ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: clone from url with email address as username?(escaping @ symbol)
From: Matthieu Moy @ 2009-09-29 18:12 UTC (permalink / raw)
To: Ben Bennett; +Cc: Sverre Rabbelier, git
In-Reply-To: <vpq1vlpr5le.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> OK, so it seems Git should be fixed to unescape this %40 somewhere,
> most likely in http_auth_init in http.c, in addition to by fix
> below.
... err, no not _in addition_ to it, forget this. There's one @ and
git finds it correctly.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Leo Razoumov @ 2009-09-29 18:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Anteru, git
In-Reply-To: <m33a66br69.fsf@localhost.localdomain>
On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> [..snip..]
> Besides with nonlinear history with
> revision numbers such as 12678 and 12687 you know that 12678 is older
> than 12687 if and only if 12678 and 12687 are on the same line of
> development.
>
The statement above is incorrect!! In a Mercurial repo local revision
numbers are strictly ordered in commit time. 12678 < 12687 means that
12678 was committed prior to 12687. But these two commits could belong
to two completely unrelated lines of development.
--Leo--
^ permalink raw reply
* Re: clone from url with email address as username?(escaping @ symbol)
From: Ben Bennett @ 2009-09-29 18:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sverre Rabbelier, git
In-Reply-To: <vpqpr99pqle.fsf@bauges.imag.fr>
I will look at it tonight. But my fix would be to automatically escape
the @ symbol when git passes onto curl.
Don't know if this would work easy or not, but it would be something
along the lines of .
https://(USERNAME)@(SERVER_ADDR)
The @ would be the last index of the @ symbol in the URL.
Then somekind of function that escape_username_for_curl.
On Tue, Sep 29, 2009 at 1:12 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> OK, so it seems Git should be fixed to unescape this %40 somewhere,
>> most likely in http_auth_init in http.c, in addition to by fix
>> below.
>
> ... err, no not _in addition_ to it, forget this. There's one @ and
> git finds it correctly.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Jakub Narebski @ 2009-09-29 18:58 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Anteru, git
In-Reply-To: <ee2a733e0909291144g4b99ab7ay9e63bfac935013aa@mail.gmail.com>
On Tue, 29 Sep 2009, Leo Razoumov wrote:
> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > [..snip..]
> > Besides with nonlinear history with
> > revision numbers such as 12678 and 12687 you know that 12678 is older
> > than 12687 if and only if 12678 and 12687 are on the same line of
> > development.
>
> The statement above is incorrect!! In a Mercurial repo local revision
> numbers are strictly ordered in commit time. 12678 < 12687 means that
> 12678 was committed prior to 12687. But these two commits could belong
> to two completely unrelated lines of development.
This is impossible with distributed development. If the second branch
comes from other repository, with commits _created_ (in that repository)
earlier than commits in current repository, but commits in first
branch (from current repository) were created earlier than _fetching_
those commits in second branch:
.---.---.---.---x---1---2---3---M---.
\ /
\-A---B---C-/ <-- from repository B
Either you would have to change commits numbers, and therefore they would
be not stable, or you would have to change commit time to mean 'time this
commit got into current repository', which would kill performance for sure.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthieu Moy @ 2009-09-29 19:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: SLONIK.AZ, Anteru, git
In-Reply-To: <200909292058.53045.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [..snip..]
>> > Besides with nonlinear history with
>> > revision numbers such as 12678 and 12687 you know that 12678 is older
>> > than 12687 if and only if 12678 and 12687 are on the same line of
>> > development.
>>
>> The statement above is incorrect!! In a Mercurial repo local revision
>> numbers are strictly ordered in commit time. 12678 < 12687 means that
>> 12678 was committed prior to 12687. But these two commits could belong
>> to two completely unrelated lines of development.
>
> This is impossible with distributed development.
Yes, the accurate statement is (I think): "In a Mercurial repo local
revision numbers are strictly ordered according _the time when the_
_commit entered the repository_" (i.e. the time you did a merge, not
the time the other guy did the commit).
Just tested:
$ hg log
changeset: 3:4d6db21df0cd
tag: tip
parent: 1:31f8406ae59c
parent: 2:33bfb84a5113
user: Matthieu Moy <Matthieu.Moy@imag.fr>
date: Tue Sep 29 21:54:25 2009 +0200
summary: merge
changeset: 2:33bfb84a5113
parent: 0:a508b050e5ae
user: Matthieu Moy <Matthieu.Moy@imag.fr>
date: Tue Sep 29 21:54:02 2009 +0200
summary: in branch bar
changeset: 1:31f8406ae59c
user: Matthieu Moy <Matthieu.Moy@imag.fr>
date: Tue Sep 29 21:54:11 2009 +0200
summary: in branch foo
changeset: 0:a508b050e5ae
user: Matthieu Moy <Matthieu.Moy@imag.fr>
date: Tue Sep 29 21:53:33 2009 +0200
summary: init
Either I have a time machine at home, or changesets 1 was not made
before changeset 2.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: clone from url with email address as username?(escaping @ symbol)
From: Daniel Stenberg @ 2009-09-29 20:38 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ben Bennett, Sverre Rabbelier, git
In-Reply-To: <vpqws3hpqr1.fsf@bauges.imag.fr>
On Tue, 29 Sep 2009, Matthieu Moy wrote:
>> Exactly. So curl is not "wrong", it just can't work around this user-error.
>
> It may not want work around user-errors, but you can hardly say that
> it _can't_.
It can't work around this error. In theory we could make it GUESS that one of
the @-letters are actually supposed to be %40, but I won't. It could also
guess that @ was accidentally a '2' with alt-gr pressed when using a nordic
keyboard layout. Guessing here is crazy.
> Many tools do in this case, Firefox is one of them.
So what if you had that @ in your password and not in your user name?
> And anyway, trying to connect to email.com@server.com is probably the worst
> thing it can do.
I understand that you're saying that as a git user and someone who's not into
curl and libcurl details, but I'm in the opposite corner mostly and I claim
that isn't at all such a bad outcome from that input. curl has that approach
through-out its entire URL parser. It gets what it needs and then uses the
rest unparsed. That way it is very liberal in what it accepts and it doesn't
reject bad URLs as long as it only can extract the parts it needs.
If curl had a strict parser it would of course bluntly reject that URL at
once.
> At least, it could warn about two @ in the URL and say it can't handle it
It could, sure. But curl has no such strict parser so it accepts all sorts of
various violations.
I don't think this is the proper place to discuss what curl (or libcurl)
should or shouldn't do with given URLs - but you're most welcome to bring your
ideas and patches to the curl project and we can debate their virtues over
there.
--
/ daniel.haxx.se
^ permalink raw reply
* Re: clone from url with email address as username?(escaping @ symbol)
From: Matthieu Moy @ 2009-09-29 20:47 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Ben Bennett, Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.2.00.0909292228120.23903@tvnag.unkk.fr>
Daniel Stenberg <daniel@haxx.se> writes:
>> Many tools do in this case, Firefox is one of them.
>
> So what if you had that @ in your password and not in your user
> name?
Then the last @ would still be the separator between the
login/password and the hostname, and looking at the '@' starting from
the right hand side would still work.
The problem is if you have a ":" in your login or password, _then_ it
is ambiguous (but by far less common), but the @ is here to split
something that can have a @ in it (login:pass) and something which
can't (hostname), so there isn't any ambiguity.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 0:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong, Felipe Contreras
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0700d80..ec43a5e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -401,7 +401,7 @@ my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
mutt => sub { my $fh = shift; while (<$fh>) {
- if (/^\s*alias\s+(\S+)\s+(.*)$/) {
+ if (/^\s*alias\s+(?:-group\s+\S+\s+)?(\S+)\s+(.*)$/) {
my ($alias, $addr) = ($1, $2);
$addr =~ s/#.*$//; # mutt allows # comments
# commas delimit multiple addresses
--
1.6.5.rc2.1.gec34
^ permalink raw reply related
* New JGit project history
From: Shawn O. Pearce @ 2009-09-30 0:28 UTC (permalink / raw)
To: egit-dev, git
As the JGit project is moving to eclipse.org (but is retaining
its current BSD license) we have to start the project history all
over again. The Eclipse Foundation won't permit the project to
host the older LGPL history before our switch to the BSD license,
so we have had to filter it out.
I have posted the new JGit history for the new eclipse.org based
repository to the existing repo.or.cz/jgit repository, in the
branch eclipse.org-post.
In theory, you can migrate a topic branch that is a still in progress
by rebasing with the proper split points:
git rebase -m --onto origin/eclipse.org-post origin/eclipse.org-pre
A complication is the packages were renamed from 'org.spearce' to
'org.eclipse', which means the rename detection stuff is going to
have some fun trying to perform a merge here, and new source files
will need to be adjusted manually.
In the new history the shell script tools/graft-old-history.sh
can be used to create a graft point to pick up the old history,
for use by data mining history tools like log and blame.
Going forward, all pending contributions should be targeting the
new history, and the new package namespace.
--
Shawn.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Leo Razoumov @ 2009-09-30 0:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Anteru, git
In-Reply-To: <200909292058.53045.jnareb@gmail.com>
On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 29 Sep 2009, Leo Razoumov wrote:
> > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > > [..snip..]
> > > Besides with nonlinear history with
> > > revision numbers such as 12678 and 12687 you know that 12678 is older
> > > than 12687 if and only if 12678 and 12687 are on the same line of
> > > development.
> >
> > The statement above is incorrect!! In a Mercurial repo local revision
> > numbers are strictly ordered in commit time. 12678 < 12687 means that
> > 12678 was committed prior to 12687. But these two commits could belong
> > to two completely unrelated lines of development.
>
>
> This is impossible with distributed development. If the second branch
> comes from other repository, with commits _created_ (in that repository)
> earlier than commits in current repository, but commits in first
> branch (from current repository) were created earlier than _fetching_
> those commits in second branch:
>
> .---.---.---.---x---1---2---3---M---.
> \ /
> \-A---B---C-/ <-- from repository B
>
>
> Either you would have to change commits numbers, and therefore they would
> be not stable, or you would have to change commit time to mean 'time this
> commit got into current repository', which would kill performance for sure.
>
Jakub,
in Mercurial sequential commit numbers are local to a repo and are not
unique between the clones. Unique ID is SHA1 as in git. So mercurial
commit 127:aaf123453dfgdfgddd...
means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
In another clone commit 127 might mean completely different thing.
Sequential commit numbers are strictly for "local convenience".
--Leo--
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Björn Steinbrink @ 2009-09-30 6:28 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Jakub Narebski, Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On 2009.09.29 20:49:52 -0400, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Tue, 29 Sep 2009, Leo Razoumov wrote:
> > > On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
> > > > [..snip..]
> > > > Besides with nonlinear history with
> > > > revision numbers such as 12678 and 12687 you know that 12678 is older
> > > > than 12687 if and only if 12678 and 12687 are on the same line of
> > > > development.
> > >
> > > The statement above is incorrect!! In a Mercurial repo local revision
> > > numbers are strictly ordered in commit time. 12678 < 12687 means that
> > > 12678 was committed prior to 12687. But these two commits could belong
> > > to two completely unrelated lines of development.
> >
> > This is impossible with distributed development. If the second branch
> > comes from other repository, with commits _created_ (in that repository)
> > earlier than commits in current repository, but commits in first
> > branch (from current repository) were created earlier than _fetching_
> > those commits in second branch:
> >
> > .---.---.---.---x---1---2---3---M---.
> > \ /
> > \-A---B---C-/ <-- from repository B
> >
> >
> > Either you would have to change commits numbers, and therefore they would
> > be not stable, or you would have to change commit time to mean 'time this
> > commit got into current repository', which would kill performance for sure.
> >
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
To quote his first mail:
First, you have to remember that this 'number of commit' thingy
is *local* to your repository, so you cannot use commit numbers
to communicate with other developers.
With the above example, he has just shown that even with those local
commit numbers, you can't tell that commit X is older than commit Y just
because X < Y.
Björn
^ permalink raw reply
* Re: [PATCH 5/6 (v4)] full integration of rev-cache into git, completed test suite
From: Chris Johnsen @ 2009-09-30 7:53 UTC (permalink / raw)
To: Nick Edelen
Cc: Chris Johnsen, git, Sam Vilain, Junio C Hamano, Nicolas Pitre,
Johannes Schindelin, Michael J Gruber, Jeff King, Shawn O. Pearce,
Andreas Ericsson, Christian Couder
In-Reply-To: <op.uzv4covmtdk399@sirnot.private>
(The Cc list of the parent message was truncated.
The Cc list of this message was adopted from later messages.)
I needed something like the following to get the tests to pass.
If you like it, squash it into 5/6.
-->8--
Subject: [PATCH] t6017: use 'tr -d' to strip spaces from 'wc -c' output
The previous use of 'grep -o "[0-9]*"' was producing an empty string
(GNU grep 2.5.1 on Mac OS X 10.4.11). Additionally, since 'wc' echos
its filename arguments when stdin is not the source, the 'grep -o'
might have also extracted additional decimal strings embedded in the
filename (a SHA-1 hash value).
This 'tr -d' style is used in git-filter-branch.sh, and t6003.
Another alternative (in t1006) is to use 'sed' to strip off the
leading spaces.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
t/t6017-rev-cache-list.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6017-rev-cache-list.sh b/t/t6017-rev-cache-list.sh
index 6ada7ac..3f49cb3 100755
--- a/t/t6017-rev-cache-list.sh
+++ b/t/t6017-rev-cache-list.sh
@@ -246,7 +246,7 @@ test_expect_success 'make fragmented slices' '
test `grep "final return value: 0" output.err | wc -l` -eq 3
'
-cache_size=`wc -c .git/rev-cache/$cache_sha1 | grep -o "[0-9]*"`
+cache_size=`wc -c < .git/rev-cache/$cache_sha1 | tr -d ' '`
test_expect_success 'test --ignore-size function in fuse' '
git-rev-cache fuse --ignore-size=$cache_size 2>output.err &&
grep "final return value: 0" output.err &&
--
1.6.5.rc1.183.g23fa6
^ permalink raw reply related
* Re: [PATCH 7/6 (v4)] support for commit grafts, slight change to general mechanism
From: Chris Johnsen @ 2009-09-30 8:00 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nick Edelen, Junio C Hamano, Nicolas Pitre, Johannes Schindelin,
Sam Vilain, Michael J Gruber, Jeff King, Andreas Ericsson,
Christian Couder, git@vger.kernel.org
In-Reply-To: <20090929163414.GA25756@spearce.org>
On 2009 Sep 29, at 11:34, Shawn O. Pearce wrote:
> Nick Edelen <sirnot@gmail.com> wrote:
>> diff --git a/builtin-rev-cache.c b/builtin-rev-cache.c
>> index 4c1766d..b36bc39 100644
>
> This doesn't apply against ne/rev-cache^, and I don't have the
> blobs in my repostiory. So I'm dropping this patch and will wait
> for a resend of the series or something...
It appears that the patch suffers from "format=flowed" whitespace
mangling. This caused the context lines to have an extra leading
space character.
After running a ham-fisted "sed -e 's/^ / /'" over the patch,
'git am' was able to apply it to ne/rev-cache^ (d05c9be9fa) even
though one of the referenced blobs (6c96297; rev-cache.c) was missing.
--
Chris
^ permalink raw reply
* Re: [PATCH 5/6 (v4)] full integration of rev-cache into git, completed test suite
From: Johannes Sixt @ 2009-09-30 8:09 UTC (permalink / raw)
To: Chris Johnsen
Cc: Nick Edelen, git, Sam Vilain, Junio C Hamano, Nicolas Pitre,
Johannes Schindelin, Michael J Gruber, Jeff King, Shawn O. Pearce,
Andreas Ericsson, Christian Couder
In-Reply-To: <1254297229-14806-1-git-send-email-chris_johnsen@pobox.com>
Chris Johnsen schrieb:
> -cache_size=`wc -c .git/rev-cache/$cache_sha1 | grep -o "[0-9]*"`
> +cache_size=`wc -c < .git/rev-cache/$cache_sha1 | tr -d ' '`
> test_expect_success 'test --ignore-size function in fuse' '
> git-rev-cache fuse --ignore-size=$cache_size 2>output.err &&
> grep "final return value: 0" output.err &&
You can also have the shell strip the blanks:
cache_size=$(wc -c < .git/rev-cache/$cache_sha1)
test_expect_success 'test --ignore-size function in fuse' '
git-rev-cache fuse --ignore-size=${cache_size##* } 2>output.err &&
grep "final return value: 0" output.err &&
-- Hannes
^ permalink raw reply
* [gitk] after exiting gitk the X11 clipboard is "messed up" - it contains the wrong commit
From: Christoph Duelli @ 2009-09-30 8:38 UTC (permalink / raw)
To: git
(Using git 1.6.5.rc1.19.g8426 on SLES10 Linux) I am having the following
problem:
1) gitk somefile.c
2) find the interesting commit, double click the sha1 id to bring it
into the clipboard (works)
3) exit gitk
4) gitk <paste from clipboard>
-> the id that is pasted is NOT the one I double clicked but the first
one in the list
As a workaround I paste the ID first and exit gitk later, but this is a
bit annoying (and a trap for gitk users).
See also
http://article.gmane.org/gmane.comp.version-control.git/65845/match=gitk+clipboard
Best regards and thank you for a helpful tool.
--
Christoph Duelli
---------------------------------------------------------------------------------
MELOS GmbH
Medizinische Labor-Organisations-Systeme GmbH
Franz-Beer-Straße 6
86459 Gessertshausen
Tel.: +49 8238/9611-0
Fax: +49 8238/9611-99
mailto: info@melosgmbh.de
URL: www.melosgmbh.de
Amtsgericht Augsburg, HRB 13226
USt-IdNr. DE 130 958 139
Geschäftsführer:
Herbert Mayer, Andreas Manntz, Helmut Welsch
--------------------------------------------
This e-mail (including any attachments) is confidential and may be privileged. If you have received it by mistake, please notify the sender by e-mail and delete it from your system.
Any unauthorised use or dissemination of this e-mail or its contents in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change.
MELOS GmbH shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt.
MELOS GmbH does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Andreas Ericsson @ 2009-09-30 9:17 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Jakub Narebski, Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On 09/30/2009 02:49 AM, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski<jnareb@gmail.com> wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>> > On 2009-09-28, Jakub Narebski<jnareb@gmail.com> wrote:
>> > > [..snip..]
>> > > Besides with nonlinear history with
>> > > revision numbers such as 12678 and 12687 you know that 12678 is older
>> > > than 12687 if and only if 12678 and 12687 are on the same line of
>> > > development.
>> >
>> > The statement above is incorrect!! In a Mercurial repo local revision
>> > numbers are strictly ordered in commit time. 12678< 12687 means that
>> > 12678 was committed prior to 12687. But these two commits could belong
>> > to two completely unrelated lines of development.
>>
>>
>> This is impossible with distributed development. If the second branch
>> comes from other repository, with commits _created_ (in that repository)
>> earlier than commits in current repository, but commits in first
>> branch (from current repository) were created earlier than _fetching_
>> those commits in second branch:
>>
>> .---.---.---.---x---1---2---3---M---.
>> \ /
>> \-A---B---C-/<-- from repository B
>>
>>
>> Either you would have to change commits numbers, and therefore they would
>> be not stable, or you would have to change commit time to mean 'time this
>> commit got into current repository', which would kill performance for sure.
>>
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
>
Personally I much prefer the "commit'ish-backward" notation of git,
where HEAD~4 means "the commit 4 commits back from HEAD".
You'd get awfully tired of writing the six-digit "shorthand" numbers
of large projects fairly quickly, I imagine.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthias Andree @ 2009-09-30 11:09 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
Anteru schrieb:
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
That tale is told all over, but that doesn't make it truer. I've never had
issues getting a Cygwin version of git to work properly (haven't tried the
msysgit or jgit variants, never felt the need), and integration went smooth.
With Mercurial, getting it integrated with a Windows-native Emacs (Cygwin emacs
doesn't work for me but hangs on startup) was somewhat of an undertaking even
with Cygwin's bash (rather than cmdproxy) underneath Emacs. It boiled down to
building Mercurial with py2exe and create an installer and use the compiled
hg.exe which I find starts rather slowly.
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).
Yes, but beware of git-svn under Cygwin 1.5 - that works for svn+ssh:// URLs,
but https:// or file:// don't work well because the underdocumented gazillion of
dependencies piece of sh.. called apr does stupid things WRT temporary files
since the Cygwin Subversion 1.6 days. Cygwin's Subversion 1.5 fared better.
I'm not sure about msysgit or jgit projects, but for Cygwin you'll definitely
want to take the plunge and go for Cygwin 1.7 which is still in Beta (because
that allows you to remove a file and create a file with the same name, which
doesn't work with Cygwin 1.5).
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Jakub Narebski @ 2009-09-30 11:09 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Anteru, git
In-Reply-To: <ee2a733e0909291749s71801b29ufa827cab715d0abb@mail.gmail.com>
On Wed, 30 Sep 2009, Leo Razoumov wrote:
> On 2009-09-29, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Tue, 29 Sep 2009, Leo Razoumov wrote:
>>> On 2009-09-28, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> [..snip..]
>>>> Besides with nonlinear history with
>>>> revision numbers such as 12678 and 12687 you know that 12678 is older
>>>> than 12687 if and only if 12678 and 12687 are on the same line of
>>>> development.
>>>
>>> The statement above is incorrect!! In a Mercurial repo local revision
>>> numbers are strictly ordered in commit time. 12678 < 12687 means that
>>> 12678 was committed prior to 12687. But these two commits could belong
>>> to two completely unrelated lines of development.
>>
>> This is impossible with distributed development. If the second branch
>> comes from other repository, with commits _created_ (in that repository)
>> earlier than commits in current repository, but commits in first
>> branch (from current repository) were created earlier than _fetching_
>> those commits in second branch:
>>
>> .---.---.---.---x---1---2---3---M---.
>> \ /
>> \-A---B---C-/ <-- from repository B
>>
>>
>> Either you would have to change commits numbers, and therefore they would
>> be not stable, or you would have to change commit time to mean 'time this
>> commit got into current repository', which would kill performance for sure.
>
> Jakub,
> in Mercurial sequential commit numbers are local to a repo and are not
> unique between the clones. Unique ID is SHA1 as in git. So mercurial
> commit 127:aaf123453dfgdfgddd...
> means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..."
> In another clone commit 127 might mean completely different thing.
> Sequential commit numbers are strictly for "local convenience".
Yes, I know that in Mercurial commit numbers are local to repository,
and even written about it (that sequential commit numbers are possible
only either as local identifiers, or in centralized workflow).
The issue I was writing about that sequential commit numbers cannot
tell us if commit was earlier or later than some other commit based
solely on those commit numbers. As other people in this thread wrote
Mercurial numbers commits not in order of commit creation, but in
order of commit arriving (being present) in given repository. So
commit numbers are not 'strictly ordered in commit time', but ordered
in 'time commit got into current (local) repository'.
I'd like also to note that this means that at some time Mercurial has
to number all those commit it got on fetch / pull from remote repository.
This can be a lot of work... work which Git doesn't have to do (OTOH Git
creates index for packfile on local side after fetch...).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthias Andree @ 2009-09-30 11:14 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0909281059180.4985@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> I tried to refrain from commenting in this thread, because I do not want
> to encourage people just to use msysGit and never even attempt to fix
> their own issues.
>
> But I cannot let this go uncommented:
>
> On Mon, 28 Sep 2009, Felipe Contreras wrote:
>
>> IMO the key difference between hg and git is the storage model: hg
>> stores deltas, while git stores snapshots. That would mean that certain
>> operations are theoretically faster in git (e.g. checkout, diff) while
>> others faster in hg, although with git's packed format I guess there's
>> no operation faster in hg. This means that it doesn't matter how much
>> hg's python code improves, or if they even re-write parts in C, they
>> will never be able to match git's performance (unless they change the
>> storage model, which essentially means changing the whole design --
>> won't happen).
>
> That is wrong. "git log -- <file>" will always be slightly faster in
> Mercurial, for all the reasons you mentioned.
>
> In addition, Mercurial _has_ parts re-written in C for performance, which
> renders it not-exactly more portable if you ask me. Last time I checked,
> there was no way to compile a Python module with MinGW (or for that
> matter, Python itself), but you needed MSVC...
I have a shortish mercurial build script that works under Cygwin 1.5 and uses
msys, py2exe and iscc to build an installable Mercurial package, but I'm not
sure what this boils down to WRT C-versions of "modules". Maybe these are lumped
into the resulting hg.exe, I never bothered to check the details.
^ permalink raw reply
* Re: [PATCH] send-email: fix mutt regex for grouped aliases
From: Jeff King @ 2009-09-30 11:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, Eric Wong
In-Reply-To: <1254269323-16600-1-git-send-email-felipe.contreras@gmail.com>
On Wed, Sep 30, 2009 at 03:08:43AM +0300, Felipe Contreras wrote:
> For example:
> alias -group friends foo Foo Bar <foo@bar.com>
Hmm. If I am reading the mutt docs correctly, is it also legal to have:
alias -group group1 -group group2 foo Foo Bar <foo@bar.com>
?
Which would need just:
> - if (/^\s*alias\s+(\S+)\s+(.*)$/) {
> + if (/^\s*alias\s+(?:-group\s+\S+\s+)?(\S+)\s+(.*)$/) {
(?:-group\s+\S+\s+)*
I think.
-Peff
^ permalink raw reply
* search branches which contain a blob id
From: Reto Glauser @ 2009-09-30 12:38 UTC (permalink / raw)
To: git
To get a list of branches which contain a specific commit we use:
$ git branch --contains <commit id>
Is there a similar way to get a list of branches with respect to a
specific blob (e.g. the actual code change a commit introduces)?
Obvious use-case: One isn't interested in the commit information (author,
parent, date) but merely in the set of changes a commit introduces.
^ permalink raw reply
* Re: search branches which contain a blob id
From: Tomas Carnecky @ 2009-09-30 13:43 UTC (permalink / raw)
To: Reto Glauser; +Cc: git
In-Reply-To: <8a906e45ab8e0252a0be11e4d4e9389e@blinkeye.ch>
On Sep 30, 2009, at 2:38 PM, Reto Glauser wrote:
> To get a list of branches which contain a specific commit we use:
>
> $ git branch --contains <commit id>
>
> Is there a similar way to get a list of branches with respect to a
> specific blob (e.g. the actual code change a commit introduces)?
Blob == contents of a file. To see what code changed you need to
compare two blobs (or trees).
> Obvious use-case: One isn't interested in the commit information
> (author,
> parent, date) but merely in the set of changes a commit introduces.
git log -S'string to search for'
searches the history for commits which introduced or removed that
string from a file.
Or 'git log -p', if you want to see the diff alongside the other
information that log gives you.
tom
^ permalink raw reply
* [JGIT PATCH] Include description for missing prereqs
From: Sasa Zivkov @ 2009-09-30 14:41 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git, Sasa Zivkov
From: Sasa Zivkov <sasa.zivkov@sap.com>
When throwing MissingBundlePrerequisiteException we
also include the short description, if available, of
each missing object.
This is the fix for the following issue:
http://code.google.com/p/egit/issues/detail?id=25
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
---
.../errors/MissingBundlePrerequisiteException.java | 19 +++++++++++--------
.../jgit/transport/BundleFetchConnection.java | 20 +++++++++++++-------
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java b/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
index cc7b34b..b91f3cd 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/errors/MissingBundlePrerequisiteException.java
@@ -37,7 +37,7 @@
package org.eclipse.jgit.errors;
-import java.util.Collection;
+import java.util.Map;
import org.eclipse.jgit.lib.ObjectId;
import org.eclipse.jgit.transport.URIish;
@@ -48,12 +48,14 @@
public class MissingBundlePrerequisiteException extends TransportException {
private static final long serialVersionUID = 1L;
- private static String format(final Collection<ObjectId> ids) {
+ private static String format(final Map<ObjectId, String> missingCommits) {
final StringBuilder r = new StringBuilder();
r.append("missing prerequisite commits:");
- for (final ObjectId p : ids) {
+ for (final Map.Entry<ObjectId, String> e : missingCommits.entrySet()) {
r.append("\n ");
- r.append(p.name());
+ r.append(e.getKey().name());
+ if (e.getValue() != null)
+ r.append(" ").append(e.getValue());
}
return r.toString();
}
@@ -63,11 +65,12 @@ private static String format(final Collection<ObjectId> ids) {
*
* @param uri
* URI used for transport
- * @param ids
- * the ids of the base/common object(s) we don't have.
+ * @param missingCommits
+ * the Map of the base/common object(s) we don't have. Keys are
+ * ids of the missing objects and values are short descriptions.
*/
public MissingBundlePrerequisiteException(final URIish uri,
- final Collection<ObjectId> ids) {
- super(uri, format(ids));
+ final Map<ObjectId, String> missingCommits) {
+ super(uri, format(missingCommits));
}
}
diff --git a/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java b/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
index 42888cf..ceb51d9 100644
--- a/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
+++ b/org.eclipse.jgit/src/org/eclipse/jgit/transport/BundleFetchConnection.java
@@ -44,9 +44,10 @@
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
-import java.util.HashSet;
+import java.util.HashMap;
import java.util.LinkedHashMap;
import java.util.List;
+import java.util.Map;
import java.util.Set;
import org.eclipse.jgit.errors.MissingBundlePrerequisiteException;
@@ -75,7 +76,7 @@
InputStream bin;
- final Set<ObjectId> prereqs = new HashSet<ObjectId>();
+ final Map<ObjectId, String> prereqs = new HashMap<ObjectId, String>();
private String lockMessage;
@@ -120,7 +121,11 @@ private void readBundleV2() throws IOException {
break;
if (line.charAt(0) == '-') {
- prereqs.add(ObjectId.fromString(line.substring(1, 41)));
+ ObjectId id = ObjectId.fromString(line.substring(1, 41));
+ String shortDesc = null;
+ if (line.length() > 42)
+ shortDesc = line.substring(42);
+ prereqs.put(id, shortDesc);
continue;
}
@@ -199,9 +204,10 @@ private void verifyPrerequisites() throws TransportException {
final RevFlag PREREQ = rw.newFlag("PREREQ");
final RevFlag SEEN = rw.newFlag("SEEN");
- final List<ObjectId> missing = new ArrayList<ObjectId>();
+ final Map<ObjectId, String> missing = new HashMap<ObjectId, String>();
final List<RevObject> commits = new ArrayList<RevObject>();
- for (final ObjectId p : prereqs) {
+ for (final Map.Entry<ObjectId, String> e : prereqs.entrySet()) {
+ ObjectId p = e.getKey();
try {
final RevCommit c = rw.parseCommit(p);
if (!c.has(PREREQ)) {
@@ -209,7 +215,7 @@ private void verifyPrerequisites() throws TransportException {
commits.add(c);
}
} catch (MissingObjectException notFound) {
- missing.add(p);
+ missing.put(p, e.getValue());
} catch (IOException err) {
throw new TransportException(transport.uri, "Cannot read commit "
+ p.name(), err);
@@ -243,7 +249,7 @@ private void verifyPrerequisites() throws TransportException {
if (remaining > 0) {
for (final RevObject o : commits) {
if (!o.has(SEEN))
- missing.add(o);
+ missing.put(o, prereqs.get(o));
}
throw new MissingBundlePrerequisiteException(transport.uri, missing);
}
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v2] send-email: fix mutt regex for grouped aliases
From: Felipe Contreras @ 2009-09-30 14:49 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Eric Wong, Jeff King, Felipe Contreras
In-Reply-To: <20090930112833.GA4984@sigio.peff.net>
For example:
alias -group friends foo Foo Bar <foo@bar.com>
Comments by Jeff King.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 0700d80..93b7ed2 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -401,7 +401,7 @@ my %aliases;
my %parse_alias = (
# multiline formats can be supported in the future
mutt => sub { my $fh = shift; while (<$fh>) {
- if (/^\s*alias\s+(\S+)\s+(.*)$/) {
+ if (/^\s*alias\s+(?:-group\s+\S+\s+)*(\S+)\s+(.*)$/) {
my ($alias, $addr) = ($1, $2);
$addr =~ s/#.*$//; # mutt allows # comments
# commas delimit multiple addresses
--
1.6.5.rc2.1.g9071
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox