* [PATCH 4/4] remote-hg: avoid bad refs
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
Turns out fast-export throws bad 'reset' commands because of a behavior
in transport-helper that is not even needed.
Either way, better to ignore them, otherwise the user will get warnings
when we OK them.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 3cdc1e2..48f8f5d 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -704,6 +704,9 @@ def do_export(parser):
elif ref.startswith('refs/tags/'):
tag = ref[len('refs/tags/'):]
parser.repo.tag([tag], node, None, True, None, {})
+ else:
+ # transport-helper/fast-export bugs
+ continue
print "ok %s" % ref
print
--
1.8.0
^ permalink raw reply related
* [PATCH 3/4] remote-hg: try the 'tip' if no checkout present
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
There's no concept of HEAD in mercurial, but let's try our best to do
something sensible.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index c6d0367..3cdc1e2 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -440,6 +440,8 @@ def list_head(repo, cur):
head = cur
node = repo['.']
if not node:
+ node = repo['tip']
+ if not node:
return
if head == 'default':
head = 'master'
--
1.8.0
^ permalink raw reply related
* [PATCH 2/4] remote-hg: fix compatibility with older versions of hg
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
Turns out repo.revs was introduced quite late, and it doesn't do
anything fancy for our refspec; only list all the numbers in that range.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 1d46838..c6d0367 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -294,7 +294,7 @@ def export_ref(repo, name, kind, head):
if tip and tip == head.rev():
# nothing to do
return
- revs = repo.revs('%u:%u' % (tip, head))
+ revs = xrange(tip, head.rev() + 1)
count = 0
revs = [rev for rev in revs if not marks.is_marked(rev)]
--
1.8.0
^ permalink raw reply related
* [PATCH 1/4] remote-hg: add missing config for basic tests
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras, Ramkumar Ramachandra
In-Reply-To: <1352742068-15346-1-git-send-email-felipe.contreras@gmail.com>
From: Ramkumar Ramachandra <artagnon@gmail.com>
'hg commit' fails otherwise in some versiosn of mercurial because of
the missing user information. Other versions simply throw a warning and
guess though.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/test-hg.sh | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh b/contrib/remote-helpers/test-hg.sh
index 40e6e3c..031dcbd 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/remote-helpers/test-hg.sh
@@ -29,6 +29,15 @@ check () {
test_cmp expected actual
}
+setup () {
+ (
+ echo "[ui]"
+ echo "username = A U Thor <author@example.com>"
+ ) >> "$HOME"/.hgrc
+}
+
+setup
+
test_expect_success 'cloning' '
test_when_finished "rm -rf gitrepo*" &&
--
1.8.0
^ permalink raw reply related
* [PATCH 0/4] remote-hg: small fixes
From: Felipe Contreras @ 2012-11-12 17:41 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Hi,
Just a few fixes, nothing major.
Felipe Contreras (3):
remote-hg: fix compatibility with older versions of hg
remote-hg: try the 'tip' if no checkout present
remote-hg: avoid bad refs
Ramkumar Ramachandra (1):
remote-hg: add missing config for basic tests
contrib/remote-helpers/git-remote-hg | 7 ++++++-
contrib/remote-helpers/test-hg.sh | 9 +++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
--
1.8.0
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-12 17:13 UTC (permalink / raw)
To: Kevin; +Cc: git
In-Reply-To: <CAO54GHA=r8WUK3okm2imVkoB=SuZ=3o+wwdwLr_rmPXhdFzG_g@mail.gmail.com>
> Maybe handy to say that you're on a Powerpc platform.
My host, build and target is: powerpc-linux-gnu
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Kevin @ 2012-11-12 17:12 UTC (permalink / raw)
To: Douglas Mencken; +Cc: git
In-Reply-To: <CACYvZ7jPd0_XD6YVdfJ2AnKRnKewmzX4uu7w3zt+_gK+qU49gQ@mail.gmail.com>
Maybe handy to say that you're on a Powerpc platform.
On Mon, Nov 12, 2012 at 5:32 PM, Douglas Mencken <dougmencken@gmail.com> wrote:
> *Any* git clone fails with:
>
> fatal: premature end of pack file, 106 bytes missing
> fatal: index-pack failed
>
> At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
> then, and it worked. Then I tried 1.7.12.2, but it fails the same way
> as 1.8.0.
> So I decided to git bisect.
>
^ permalink raw reply
* RE: splitting off shell test framework
From: Pyeron, Jason J CTR (US) @ 2012-11-12 16:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <CAMP44s2n56c=k4o6wup81Hb3WNzuDLkL30GpMdivQixJX_YOsw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
> -----Original Message-----
> From: Felipe Contreras
> Sent: Monday, November 12, 2012 11:44 AM
>
> On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org>
> wrote:
>
> > I've been pretty impressed with git's test framework, and I'm not
> > aware of many other (decent) shell-based test frameworks out there.
> > (One that springs to mind is the one used by rvm, but last time I
> > looked - admittedly a while ago now - it had limitations).
> >
> > Recently a situation arose where I craved the ability to test
> > something via shell. I did a quick proof of concept and successfully
> > extracted out the non-git-specific bits of git's test framework to be
> > used to test something entirely unrelated to git:
> >
> > https://github.com/aspiers/shell-env/tree/master/t
> >
> > As it turned out to be fairly easy, I was wondering if there would be
> > any interest in doing this more formally, i.e. splitting off the
> > framework so that it could be used and improved outside the scope of
> > git development? Of course this would pose the question how git
> would
> > consume this new project without any risk of destabilisation. I'm
> > guessing that simply using a git submodule would solve the problem,
> > but ICBW ...
>
> FWIW, the notmuch project seems to be doing the same; extracting and
> using git's test framework.
The Apache Maven project is migrating to GIT right now and they just covered a long discussion on the pros and cons of this (sort of). It might be a bit of a read [1] but I can also provide some perspective. The question is asked in reverse in [2] since Maven had them separate and some suggested to merge them.
1: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3cA5D13406-474A-43E6-9708-D5D4DE9BE64C@tesla.io%3e
2: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3c1349937687.79626.YahooMailNeo@web28903.mail.ir2.yahoo.com%3e
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: splitting off shell test framework
From: Felipe Contreras @ 2012-11-12 16:44 UTC (permalink / raw)
To: Adam Spiers; +Cc: Git Mailing List
In-Reply-To: <CAOkDyE8KxFvM4CJhC4U=Jb95D6HQ-4qQBtKAgBMyHH15UOhvqg@mail.gmail.com>
On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org> wrote:
> I've been pretty impressed with git's test framework, and I'm not
> aware of many other (decent) shell-based test frameworks out there.
> (One that springs to mind is the one used by rvm, but last time I
> looked - admittedly a while ago now - it had limitations).
>
> Recently a situation arose where I craved the ability to test
> something via shell. I did a quick proof of concept and successfully
> extracted out the non-git-specific bits of git's test framework to be
> used to test something entirely unrelated to git:
>
> https://github.com/aspiers/shell-env/tree/master/t
>
> As it turned out to be fairly easy, I was wondering if there would be
> any interest in doing this more formally, i.e. splitting off the
> framework so that it could be used and improved outside the scope of
> git development? Of course this would pose the question how git would
> consume this new project without any risk of destabilisation. I'm
> guessing that simply using a git submodule would solve the problem,
> but ICBW ...
FWIW, the notmuch project seems to be doing the same; extracting and
using git's test framework.
> Just an idea. Interesting, or terrible? :)
That I don't know :)
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Felipe Contreras @ 2012-11-12 16:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Max Horn, git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <20121112154515.GB3546@elie.Belkin>
On Mon, Nov 12, 2012 at 4:45 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Max Horn wrote:
>
>> Aha, now I understand what this patch is about. So I would suggest
>> this alternate commit message:
>>
>> remote-testgit: make it explicit clear that we use the 'done' feature
>>
>> Previously we relied on passing '--use-done-feature ' to git
>> fast-export, which is easy to miss when looking at this script.
>
> I'm not immediately sure I agree this is even a problem. Is the point
> that other fast-import frontends do not have a --use-done-feature
> switch,
You mean other fast-exports.
And what other fast-exports? Most remote helpers don't use an external
fast-export tool, and the only I know that used one is the one I wrote
(and is now deprecated) that used bzr fast-export, and no, that one
didn't support the done feature.
Most remote helpers would probably be doing the equivalent of
fast-export themselves.
> so a typical remote helper has to do that work itself, and the
> sample "testgit" remote helper would be a more helpful example by
> doing that work itself?
Yes.
> The idea behind --use-done-feature is that if fast-export exits early
> for some reason and its output is going to a pipe then at least the
> stream will be malformed, making it easier to catch errors. So there
> is something to be weighed here: is it more important to illustrate
> how to make your fast-export tool's output prefix-free,
What fast-export tool?
This is a remote helper.
> or is it more
> important to illustrate how to work around a fast-export tool that
> doesn't support that feature?
Ditto.
If you want to launch a campaign of adding the 'done' feature to
whatever fast-export tools are out there (that I'm not aware of), go
ahead, but this is about remote helpers, most (all?) of which would
not use a fast-export tool to achieve the export, but do it
themselves.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* splitting off shell test framework
From: Adam Spiers @ 2012-11-12 16:37 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I've been pretty impressed with git's test framework, and I'm not
aware of many other (decent) shell-based test frameworks out there.
(One that springs to mind is the one used by rvm, but last time I
looked - admittedly a while ago now - it had limitations).
Recently a situation arose where I craved the ability to test
something via shell. I did a quick proof of concept and successfully
extracted out the non-git-specific bits of git's test framework to be
used to test something entirely unrelated to git:
https://github.com/aspiers/shell-env/tree/master/t
As it turned out to be fairly easy, I was wondering if there would be
any interest in doing this more formally, i.e. splitting off the
framework so that it could be used and improved outside the scope of
git development? Of course this would pose the question how git would
consume this new project without any risk of destabilisation. I'm
guessing that simply using a git submodule would solve the problem,
but ICBW ...
Just an idea. Interesting, or terrible? :)
Regards,
Adam
^ permalink raw reply
* [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-12 16:32 UTC (permalink / raw)
To: git
*Any* git clone fails with:
fatal: premature end of pack file, 106 bytes missing
fatal: index-pack failed
At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
then, and it worked. Then I tried 1.7.12.2, but it fails the same way
as 1.8.0.
So I decided to git bisect.
b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit
``index-pack: support multithreaded delta resolving''
--------------------------------------------------------------------------------
b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit
commit b8a2486f1524947f232f657e9f2ebf44e3e7a243
Author: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Date: Sun May 6 19:31:55 2012 +0700
index-pack: support multithreaded delta resolving
This puts delta resolving on each base on a separate thread, one base
cache per thread. Per-thread data is grouped in struct thread_local.
When running with nr_threads == 1, no pthreads calls are made. The
system essentially runs in non-thread mode.
An experiment on a Xeon 24 core machine with git.git shows that
performance does not increase proportional to the number of cores. So
by default, we use maximum 3 cores. Some numbers with --threads from 1
to 16:
1..4
real 0m8.003s 0m5.307s 0m4.321s 0m3.830s
user 0m7.720s 0m8.009s 0m8.133s 0m8.305s
sys 0m0.224s 0m0.372s 0m0.360s 0m0.360s
5..8
real 0m3.727s 0m3.604s 0m3.332s 0m3.369s
user 0m9.361s 0m9.817s 0m9.525s 0m9.769s
sys 0m0.584s 0m0.624s 0m0.540s 0m0.560s
9..12
real 0m3.036s 0m3.139s 0m3.177s 0m2.961s
user 0m8.977s 0m10.205s 0m9.737s 0m10.073s
sys 0m0.596s 0m0.680s 0m0.684s 0m0.680s
13..16
real 0m2.985s 0m2.894s 0m2.975s 0m2.971s
user 0m9.825s 0m10.573s 0m10.833s 0m11.361s
sys 0m0.788s 0m0.732s 0m0.904s 0m1.016s
On an Intel dual core and linux-2.6.git
1..4
real 2m37.789s 2m7.963s 2m0.920s 1m58.213s
user 2m28.415s 2m52.325s 2m50.176s 2m41.187s
sys 0m7.808s 0m11.181s 0m11.224s 0m10.731s
Thanks Ramsay Jones for troubleshooting and support on MinGW platform.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:040000 040000 e5597fe041cd7985648030c8cf1cc35ea57786bb
6e64f3e76b350c04c9d0c435e0a53b89e0821339 M Documentation
:100644 100644 cf2c40b44f8383d002235400660d76ef7f6de33c
e41955ff955693ddc78722c14fff2a6e98663a46 M Makefile
:040000 040000 1e6b5ac5f11bf7ba3eff7b5be4410bad379feee6
85bc79414f00b7fc3698c069161ea10039641082 M builtin
:040000 040000 04916545d959c8af772cd3a2de5e6b470529bea1
325c8c748dd41d469135db84c7621d8225cc1cdd M t
$ git bisect log
git bisect start
# bad: [d8cf053dacb4f78920c112d10c7be21e4f5a5817] Git 1.7.12.2
git bisect bad d8cf053dacb4f78920c112d10c7be21e4f5a5817
# good: [785ee4960c3d334cbc2b17ab74d2cebdf1b4db64] Git 1.7.10.5
git bisect good 785ee4960c3d334cbc2b17ab74d2cebdf1b4db64
# bad: [d692d34653f74be6b16add3e993e957f33fe049b] Merge branch
'rs/git-blame-mapcar-mapc'
git bisect bad d692d34653f74be6b16add3e993e957f33fe049b
# good: [73ff8cf784b6ee447072fad6c06fd0eef0e9c9f6] Merge branch
'lp/diffstat-with-graph'
git bisect good 73ff8cf784b6ee447072fad6c06fd0eef0e9c9f6
# bad: [7903e66a3e10e98f29fc9524c13274376bae5303] Merge branch
'mh/test-keep-prove-cache'
git bisect bad 7903e66a3e10e98f29fc9524c13274376bae5303
# good: [499e7b31509cfbb59dcb2a046f8e2fd1a3e73d6f] Merge branch
'jc/install-no-hardlinks'
git bisect good 499e7b31509cfbb59dcb2a046f8e2fd1a3e73d6f
# bad: [2e464dd5b220d4d2d8a16d5c43efe7af3c9adda9] Merge branch
'rs/xdiff-lose-emit-func'
git bisect bad 2e464dd5b220d4d2d8a16d5c43efe7af3c9adda9
# good: [8fbe0db4fce68ed8239742b14e9d77d45201870b] Merge branch
'master' of git://github.com/git-l10n/git-po
git bisect good 8fbe0db4fce68ed8239742b14e9d77d45201870b
# bad: [2b26b65f9abc77c4af87626452005a73edda0c8f] git-svn: clarify
the referent of dcommit's optional argument
git bisect bad 2b26b65f9abc77c4af87626452005a73edda0c8f
# bad: [cc13431a49800a6a1d2b7ff0b94f67da0fecdbab] Merge branch
'nd/threaded-index-pack'
git bisect bad cc13431a49800a6a1d2b7ff0b94f67da0fecdbab
# bad: [b8a2486f1524947f232f657e9f2ebf44e3e7a243] index-pack:
support multithreaded delta resolving
git bisect bad b8a2486f1524947f232f657e9f2ebf44e3e7a243
# good: [5272f75587abb4cb396059ecbf1a6130bb2e69d3] index-pack:
restructure pack processing into three main functions
git bisect good 5272f75587abb4cb396059ecbf1a6130bb2e69d3
$ git bisect reset
Previous HEAD position was 5272f75... index-pack: restructure pack
processing into three main functions
HEAD is now at d8cf053... Git 1.7.12.2
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-12 16:28 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-16-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 2:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> They have been marked as UNINTERESTING for a reason, lets respect that.
>
> Currently the first ref is handled properly, but not the rest, so:
>
> % git fast-export master ^master
>
> Would currently throw a reset for master (2nd ref), which is not what we
> want.
>
> % git fast-export master ^foo ^bar ^roo
> % git fast-export master salsa..tacos
>
> Even if all these refs point to the same object; foo, bar, roo, salsa,
> and tacos would all get a reset, and to a non-existing object (invalid
> mark :0).
>
> And even more, it would only happen if the ref is pointing to exactly
> the same commit, but not otherwise:
>
> % git fast-export ^next next
> reset refs/heads/next
> from :0
>
> % git fast-export ^next next^{commit}
> # nothing
> % git fast-export ^next next~0
> # nothing
> % git fast-export ^next next~1
> # nothing
> % git fast-export ^next next~2
> # nothing
>
> The reason this happens is that before traversing the commits,
> fast-export checks if any of the refs point to the same object, and any
> duplicated ref gets added to a list in order to issue 'reset' commands
> after the traversing. Unfortunately, it's not even checking if the
> commit is flagged as UNINTERESTING. The fix of course, is to do
> precisely that.
>
> The current behavior is most certainly not what we want. After this
> patch, nothing gets exported, because nothing was selected (everything
> is UNINTERESTING).
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
And here's yet another reason why this is obviously correct that I just found:
% git fast-export --use-done-feature
--{import,export}-marks=.git/hg/origin/marks-git
^refs/hg/origin/branches/default ^refs/hg/origin/bookmarks/test6
refs/heads/test6 ^refs/hg/origin/bookmarks/master
^refs/hg/origin/bookmarks/test
feature done
reset refs/hg/origin/bookmarks/test
from :4
reset refs/heads/test6
from :14
done
What is that refs/hg/origin/bookmarks/test doing there?
transport-helper does use a fast-export command like that to specify
precisely what refs should be *IGNORED*, and yet fast-export will
throw a reset for a ref that has been marked as UNINTERESTING. So, the
receiving end in the helper will see a reset for a ref that it
explicitly said was marked as outside it's refspec realm:
refspec refs/heads/*:refs/hg/origin/bookmarks/*
What is remote-hg supposed to do with 'refs/hg/origin/bookmarks/test'?
There's nothing that can be done, it's a bug in fast-export that such
a thing was exported in the first place. And the reason it happens is
that another ref happens to be pointing to the same object, (in this
case refs/hg/origin/branches/default)
So yeah, the patch is good.
Of course, transport-helper shouldn't even be specifying the negative
(^) refs, but that's another story.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Jonathan Nieder @ 2012-11-12 15:45 UTC (permalink / raw)
To: Max Horn
Cc: Felipe Contreras, git, Junio C Hamano, Johannes Schindelin,
Jeff King, Sverre Rabbelier, Brandon Casey, Brandon Casey,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <EA56F0CC-7C93-491F-A076-4A1AA9593ED0@quendi.de>
Max Horn wrote:
> Aha, now I understand what this patch is about. So I would suggest
> this alternate commit message:
>
> remote-testgit: make it explicit clear that we use the 'done' feature
>
> Previously we relied on passing '--use-done-feature ' to git
> fast-export, which is easy to miss when looking at this script.
I'm not immediately sure I agree this is even a problem. Is the point
that other fast-import frontends do not have a --use-done-feature
switch, so a typical remote helper has to do that work itself, and the
sample "testgit" remote helper would be a more helpful example by
doing that work itself?
The idea behind --use-done-feature is that if fast-export exits early
for some reason and its output is going to a pipe then at least the
stream will be malformed, making it easier to catch errors. So there
is something to be weighed here: is it more important to illustrate
how to make your fast-export tool's output prefix-free, or is it more
important to illustrate how to work around a fast-export tool that
doesn't support that feature? The answer is not immediately obvious
to me. A good description could provide context to make it obvious.
Hoping that clarifies,
Jonathan
^ permalink raw reply
* Re: [PATCH] Documentation/log: fix description of format.pretty
From: Jonathan Nieder @ 2012-11-12 15:38 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0nR_9mWDKzKygR379x3L=d4bGKKo27AP-2Y=+coc7H+sQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> Oops, I read about `--pretty` in pretty-formats.txt and didn't realize
> that `--format` existed. However, your patch is still wrong because
> there seems to be a subtle (and confusing) difference between
> `--pretty` and `--format`. In the latter, you can't omit the format,
> and expect it to be picked up from format.pretty:
>
> $ git log --format
> fatal: unrecognized argument: --format
You can do
$ git log
and format.pretty will still take effect. In other words, setting
format.pretty to "foo" is somewhat like making
$ git log
do
$ git log --format=foo
which is what the text is supposed to explain. It is based on the
following text from Documentation/config.txt:
format.pretty::
The default pretty format for log/show/whatchanged command,
See linkgit:git-log[1], linkgit:git-show[1],
linkgit:git-whatchanged[1].
I do imagine it can be made clearer. s/--format/--pretty/ does not go
far enough --- it only replaces one confusing explanation with
another.
Hoping that clarifies,
Jonathan
^ permalink raw reply
* RE: git-svn with ignore-paths misses/skips some revisions during fetch
From: McHenry, Matt @ 2012-11-12 15:00 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Enrico Weigelt
In-Reply-To: <be90fa6b-3927-47cb-9306-6dbb7bac2c04@zcs>
Enrico asked:
> Could it be that certain files spent parts of their historical lifetime
> inside the ignored paths ?
I left out one possibly important piece of information: My initial 'git svn fetch' used '-r' to "cauterize" the history, both because there is a lot of it (almost 12 years) and because the repository was reorganized significantly after a cvs -> svn migration. The first revision I have is r83875:
$ git log --max-parents=0 --all --date-order | tail -n 1
git-svn-id: svn://dev.carnegielearning.com/trunk@83875 752fcc94-cd22-0410-baa8-ef54ac2c6973
So to answer Enrico's question: Prior to the initial revision that was fetched into git, these files did live in a different top-level directory. However it's not one that's matched by the 'ignore-paths' regex. Here's one example:
$ svn log -v svn://dev/branches/localization-merge/buildprocess/antfiles/dmg.xml | grep /dmg.xml | uniq -c
9 M /branches/localization-merge/buildprocess/antfiles/dmg.xml
35 M /trunk/buildprocess/antfiles/dmg.xml
1 A /trunk/buildprocess/antfiles/dmg.xml (from /trunk/buildprocess/assemble-support/dmg.xml:48305)
1 D /trunk/buildprocess/assemble-support/dmg.xml
57 M /trunk/assemble-support/dmg.xml
1 A /trunk/assemble-support/dmg.xml
Here are the svn revisions that explain the transition from 'assemble-support' to 'buildprocess/assemble-support', just after the cvs -> svn migration.
------------------------------------------------------------------------
r48303 | matt | 2006-11-27 14:56:10 -0500 (Mon, 27 Nov 2006) | 1 line
Changed paths:
D /old-trunk/assemble-support
A /trunk/buildprocess/assemble-support (from /old-trunk/assemble-support:48302)
moving old assemble-support into new buildprocess
------------------------------------------------------------------------
r48248 | matt | 2006-11-22 13:41:42 -0500 (Wed, 22 Nov 2006) | 1 line
Changed paths:
A /old-trunk (from /trunk:48247)
D /trunk
moving old trunk out of the way
------------------------------------------------------------------------
Matt McHenry
Software Developer
Carnegie Learning, Inc.
(888) 851-7094 x150 toll free
(412) 690-2444 fax
mmchenry@carnegielearning.com
www.carnegielearning.com
Decision 2012: Election Math | Engaging Video Content | FREE Interactive Math Problems
http://www.nbclearn.com/portal/site/learn/decision2012
^ permalink raw reply
* [PATCHv3] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-11-12 14:18 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <50A0B896.8050700@drmicha.warpmail.net>
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the argument to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Notes:
v3 safeguards the hex buffer against reuse
builtin/replace.c | 16 ++++++++++------
t/t6050-replace.sh | 11 +++++++++++
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..33e6ec3 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,28 @@ typedef int (*each_replace_name_fn)(const char *name, const char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
- const char **p;
+ const char **p, *q;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
- >= sizeof(ref)) {
- error("replace ref name too long: %.*s...", 50, *p);
+ q = *p;
+ if (get_sha1(q, sha1)) {
+ error("Failed to resolve '%s' as a valid ref.", q);
had_error = 1;
continue;
}
+ q = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), "refs/replace/%s", q);
+ /* read_ref() may reuse the buffer */
+ q = ref + strlen("refs/replace/");
if (read_ref(ref, sha1)) {
- error("replace ref '%s' not found.", *p);
+ error("replace ref '%s' not found.", q);
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(q, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
test "$HASH2" = "$(git replace)"
'
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
# This creates a side branch where the bug in H2
# does not appear because P2 is created by applying
# H2 and squashing H5 into it.
--
1.8.0.311.gdd08018
^ permalink raw reply related
* Re: Help requested - trying to build a tool doing whole-tree commits
From: ydirson @ 2012-11-12 13:11 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <931951238.74665890.1352725212354.JavaMail.root@zimbra39-e7.priv.proxad.net>
esr:
>Junio C Hamano <gitster <at> pobox.com>:
>> Perhaps not exactly what you are looking for, but don't we have
>> import-tar somewhere in contrib/fast-import hierarchy (sorry, not on
>> a machine yet, and I cannot give more details).
>
>If I recall correctly, that can only be used for original import.
You may find my (old) ag-import-patch tool useful. Although the name does not
imply it, it allows to import a series of releases that can be available either as
tarballs or as patches.
http://ydirson.free.fr/soft/git/argit.git/
There's not much doc in there, and not so much I can remember myself from the short
help string. IIRC you can specify which base revision a patch applies to (ie. it
may apply to an older revision, not necessarily to the current HEAD).
It has also quite some bitrot (git-* direct invocation, use of cg-tag, surely more).
^ permalink raw reply
* RE: Failure using webdav basic auth by git client
From: Pyeron, Jason J CTR (US) @ 2012-11-12 12:27 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20121111182842.GC21654@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
> -----Original Message-----
> From: Jeff King
> Sent: Sunday, November 11, 2012 1:29 PM
>
> On Sun, Nov 11, 2012 at 01:09:02PM -0500, Jason Pyeron wrote:
>
> > > My google fu has failed me on this issue. I am trying to setup
> http(s)
> > > repositories for git. If I require authenticated users then git
> asks
> > > for a username and password for the first volley of communications,
> but
> > > then does not include the Authorization header on subsequent
> requests.
> > [...]
> > > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1
> > > User-Agent: git/1.7.9
>
> Can you try with a more recent git version? There were some bugs with
> on-demand http auth when using the dumb protocol (which I see you are
> using). They were fixed in v1.7.10.2 and higher.
Having some troubles compiling the maint branch on cygwin (same issue for master).
>
> Also, consider setting up the smart-http protocol, as it is way more
> efficient.
Will look into that after I get git compiling...
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: git merge commits are non-deterministic? what changed?
From: Michael J Gruber @ 2012-11-12 11:27 UTC (permalink / raw)
To: Ulrich Spörlein; +Cc: Jeff King, Matthieu Moy, Andreas Schwab, git
In-Reply-To: <20121109182753.GQ69724@acme.spoerlein.net>
Ulrich Spörlein venit, vidit, dixit 09.11.2012 19:27:
> On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
>> On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
>>
>>> Ulrich Spörlein <uqs@spoerlein.net> writes:
>>>
>>>>>> 2. Why the hell is the commit hash dependent on the ordering of the
>>>>>> parent commits? IMHO it should sort the set of parents before
>>>>>> calculating the hash ...
>>>>>
>>>>> What would be the sort key?
>>>>
>>>> Trivially, the hash of the parents itself. So you'd always get
>>>>
>>>> ...
>>>> parent 0000
>>>> parent 1111
>>>> parent aaaa
>>>> parent ffff
>>>
>>> That would change the behavior of --first-parent. Or you'd need to
>>> compute the sha1 of the sorted list, but keep the unsorted one in the
>>> commit. Possible, but weird ;-).
>>
>> Right. The reason that merge parents are stored in the order given on
>> the command line is not random or because it was not considered. It
>> encodes a valuable piece of information: did the user merge "foo" into
>> "bar", or did they merge "bar" into "foo"?
>>
>> So I think this discussion is going in the wrong direction; git should
>> never sort the parents, because the order is meaningful. The original
>> complaint was that a run of svn2git produced different results on two
>> different git versions. The important question to me is: did svn2git
>> feed the parents to git in the same order?
>>
>> If it did, and git produced different results, then that is a serious
>> bug.
>>
>> If it did not, then the issue needs to be resolved in svn2git (which
>> _may_ want to sort the parents that it feeds to git, but it would depend
>> on whether the order it is currently presenting is meaningful).
>
> Yeah, thanks, looks like I have some more work to do. I don't quite get
> how it could come up with a different order, seeing that it is using svn
> as the base.
>
> Will run some more experiments, thanks for the info so far.
There was a change in the order in which "git cherry-pick A B C" applies
the commits. It's the only odering affecting change in 1.8.0 that I can
think of right now.
Michael
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Max Horn @ 2012-11-12 11:20 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <CAMP44s0o1eP+aeT0AHu4uP1NPLqJq56qUDb-+F_x5NjoJCnf+A@mail.gmail.com>
On 11.11.2012, at 22:22, Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 9:49 PM, Max Horn <max@quendi.de> wrote:
>>
>> On 11.11.2012, at 14:59, Felipe Contreras wrote:
>>
>>> People seeking for reference would find it useful.
>>
>> Hm, I don't understand this commit message. Probably means I am j git fast-export --use-done-featureust too dumb, but since I am one of those people who would likely be seeking for reference, I would really appreciate if it could clarified. Like, for example, I don't see how the patch below makes anything "clear", it just seems to change the "import" command of git-remote-testgit to make use of the 'done' feature?
>
> No, the done feature was there already, but not so visible: git
> fast-export --use-done-feature <-there. Which is the problem, it's too
> easy to miss, therefore the need to make it clear.
Aha, now I understand what this patch is about. So I would suggest this alternate commit message:
remote-testgit: make it explicit clear that we use the 'done' feature
Previously we relied on passing '--use-done-feature ' to git fast-export, which is
easy to miss when looking at this script. Since remote-testgit is also a reference
implementation, we now explicitly output 'feature done' / 'done' to make it
crystal clear that we implement this feature.
Or perhaps a little bit less verbose. With a commit message like the above, I think I would have grokked the patch right away. With the original message, that was not the case (else I wouldn't have wrote my initial email). And even though I now understand (or at least believe to understand) the patch, I don't think the original message is that helpful... indeed, "make clear the 'done' feature" is ambiguous. You meant it as "make clear the 'done' feature is implemented / used", while I understood it as "make clear what the 'done' feature is about". Looking at the patch can help to resolve that, but (a) my wrong interpretation threw me off-track and (b) I thought that the point of commit messages was to give an overview of a patch without having to look at it...
So at the very least, the message should explain what exactly is "made clear".
Anyway, a small change to the commit message hopefully will not be a problem. :-)
Cheers,
Max
^ permalink raw reply
* Re: [PATCH] Documentation/log: fix description of format.pretty
From: Ramkumar Ramachandra @ 2012-11-12 9:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Git List
In-Reply-To: <20121112080527.GB3581@elie.Belkin>
Hi Jonathan,
Jonathan Nieder wrote:
> Hi Ram,
>
> Ramkumar Ramachandra wrote:
>
>> 59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
>> mentioned that `format.pretty` is the default for the `--format`
>> option. Such an option never existed,
>
> False. Have you tried it?
Oops, I read about `--pretty` in pretty-formats.txt and didn't realize
that `--format` existed. However, your patch is still wrong because
there seems to be a subtle (and confusing) difference between
`--pretty` and `--format`. In the latter, you can't omit the format,
and expect it to be picked up from format.pretty:
$ git log --format
fatal: unrecognized argument: --format
Instead, you have to specify the format explicitly:
$ git log --format=medium
So, we should change the commit message in my patch?
Ram
^ permalink raw reply
* Re: [PATCHv2] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-11-12 8:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121109164808.GE19725@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 09.11.2012 17:48:
> On Mon, Oct 29, 2012 at 02:23:27PM +0100, Michael J Gruber wrote:
>
>> 'git replace' parses the revision arguments when it creates replacements
>> (so that a sha1 can be abbreviated, e.g.) but not when deleting
>> replacements.
>>
>> Make it parse the arguments to 'replace -d' in the same way.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> v2 has the simplified error check as per Jeff, and a reworded message.
>> Comes with a free test case, too.
>
> I noticed this today in my pile of "to look at" patches. Sorry for being
> slow.
No problem. This is not urgent, and it takes some effort to look at code
amongst all those black-and-white discussions. [It even takes effort to
refrain from responding when you words are being twisted around...]
>> for (p = argv; *p; p++) {
>> - if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
>> - >= sizeof(ref)) {
>> - error("replace ref name too long: %.*s...", 50, *p);
>> + q = *p;
>> + if (get_sha1(q, sha1)) {
>> + error("Failed to resolve '%s' as a valid ref.", q);
>> had_error = 1;
>> continue;
>> }
>
> Looks reasonable.
>
>> + q = sha1_to_hex(sha1);
>> + snprintf(ref, sizeof(ref), "refs/replace/%s", q);
>> if (read_ref(ref, sha1)) {
>> - error("replace ref '%s' not found.", *p);
>> + error("replace ref '%s' not found.", q);
>
> I worry a little about assuming that "q", which points to a static
> internal buffer of sha1_to_hex, is still valid after calling read_ref.
> We'll end up in resolve_ref, which might need to do considerable work
> (e.g., loading the whole packed refs file). Just grepping for
> sha1_to_hex, I don't think it is a problem currently, but it might be
> worth copying the value (you could even point into the "ref" buffer to
> avoid dealing with an extra allocation).
We could just leave '*p' as it is (after all, that was the user input),
or use 'ref+strlen("refs/replace/")'.
I wasn't aware of the volatile nature of the return value. Thanks for
spotting!
Michael
^ permalink raw reply
* "git imap-send" with HTML preformatting broken for multipart messages
From: Michael Haggerty @ 2012-11-12 8:43 UTC (permalink / raw)
To: git discussion list, Jeremy White, Mike McCormack
I just noticed that "git imap-send" with imap.preformattedHTML turned on
is broken for multipart messages. The problem is that "git imap-send"
embeds *everything* after the main email header in <pre></pre> and
HTML-escapes it, instead of splitting out the email parts and quoting
their bodies individually.
Ironically, the "git imap-send" manpage specifically lists the typical
usage as
git format-patch --signoff --stdout --attach origin | git imap-send
which is broken if imap.preformattedHTML is set.
It seems to me that rather than fix "git imap-send" (which would require
it to become more complicated), it would be better to teach "git
format-patch" how to do preformatting and restrict "git imap-send" to
sending messages verbatim to an IMAP server. Moving the functionality
to "git format-patch" would also make it possible to create preformatted
emails to be used with other transports.
Oh, and, by the way, "git imap-send" is utterly untested by the test
suite. The fact that it is intrinsically hard to test without lots of
extra infrastructure is another argument for making it as stupid as
possible.
I don't plan to work on this.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Documentation/log: fix description of format.pretty
From: Jonathan Nieder @ 2012-11-12 8:05 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0=hdmYF2VoOZY4F7+yPD8D0rBnPY-tvp5pryRWp-0WBeg@mail.gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> 59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
> mentioned that `format.pretty` is the default for the `--format`
> option. Such an option never existed,
False. Have you tried it?
Thanks,
Jonathan
^ 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