* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-28 8:44 UTC (permalink / raw)
To: Thomas Berg; +Cc: Junio C Hamano, Jeff King, Shawn Pearce, Eric Raymond, git
In-Reply-To: <CABYiQpmEpdf3L56NYSvPWovNOs_ifqj5QctuPSMoygHyMrz8+g@mail.gmail.com>
On Wed, Nov 28, 2012 at 9:19 AM, Thomas Berg <merlin66b@gmail.com> wrote:
> On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> There is room for new headers, and older versions of git will ignore
>>> them. You could add a new "committer-timestamp" field that elaborates on
>>> the timestamp included on the committer line. Newer versions of git
>>> would respect it, and older versions would fall back to using the
>>> committer timestamp.
>>>
>>> But I really wonder if anybody actually cares about adding sub-second
>>> timestamp support, or if it is merely "because SVN has it".
>>
>> Roundtrip conversions may benefit from sub-second timestamps, but
>> personally I think negative timestamps are more interesting and of
>> practical use. Prehistoric projects need them even if they intend
>> to switch to Git, never to go back to their original tarballs and
>> collection of RCS ,v files.
>
> If roundtripping to other version control systems is an argument,
> adding sub-second timestamps could potentially create as many problems
> as it solves. For example, I've been using the hg-git bridge, and it
> supports roundtripping between git and mercurial today (for most repos
> I've tried anyway). I may have missed something, but this could imply
> that mercurial doesn't care about sub-second timestamps either. If so,
> and if git suddenly were to record it, it would no longer be as
> straight forward to represent git history in hg.
I'm not entirely sure. The API seems to return a float for the time,
but at least as far I can see, it never has any decimals anyway.
But it doesn't really matter, mercurial doesn't have a committer
information either. This is solved by tools like hg-git by storing the
information in an 'extra' field, which can store anything.
Unfortunately git doesn't have a similar field, so people have been
using the commit message to store extra information.
Either way, I don't see the point in changing git's commit format for
external tools. The git-notes functionality works just fine for that,
it just needs to be attached in the relevant places, like 'git
fast-export'.
BTW. Have you checked git's native support for hg?[1]
Cheers.
[1] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Christian Couder @ 2012-11-28 8:55 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Christian Couder, git
In-Reply-To: <CAMP44s17Gycr2tWOLYAxMG7-CGP3SpFf7XTWf94qGg3WfVpT-A@mail.gmail.com>
On Wed, Nov 28, 2012 at 9:03 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, Nov 28, 2012 at 8:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Christian Couder <chriscool@tuxfamily.org> writes:
>>
>>> All the python scripts except contrib/svn-fe/svnrdump_sim.py
>>> start with "#!/usr/bin/env python".
>>>
>>> This patch fix contrib/svn-fe/svnrdump_sim.py to do the same.
>>
>> I suspect you need a bit more than that.
>>
>> $ make git-p4
>> $ diff -u git-p4.py git-p4
>>
>> shows you how we tell the scripts how to find their interpreters
>> (that way, there is no need to rely on the existence of
>> /usr/bin/env).
>
> That works if somebody managed to export PYTHON_PATH, which very very
> often is not the case for me.
Yeah, and even if PYTHON_PATH is used, in t9020-remote-svn.sh,
svnrdump.py is used as is.
So if your python is not /usr/bin/python, you cannot just add
something to $PATH to pass the test.
Best regards,
Christian.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Thomas Berg @ 2012-11-28 9:10 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Jeff King, Shawn Pearce, Eric Raymond, git
In-Reply-To: <CAMP44s3MPMySnwjWjzo4aRX05u05xratgiyiYJUYPmnV2WK6kQ@mail.gmail.com>
On Wed, Nov 28, 2012 at 9:44 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
>> If roundtripping to other version control systems is an argument,
>> adding sub-second timestamps could potentially create as many problems
>> as it solves. For example, I've been using the hg-git bridge, and it
>> supports roundtripping between git and mercurial today (for most repos
>> I've tried anyway). I may have missed something, but this could imply
>> that mercurial doesn't care about sub-second timestamps either. If so,
>> and if git suddenly were to record it, it would no longer be as
>> straight forward to represent git history in hg.
>
> I'm not entirely sure. The API seems to return a float for the time,
> but at least as far I can see, it never has any decimals anyway.
>
> But it doesn't really matter, mercurial doesn't have a committer
> information either. This is solved by tools like hg-git by storing the
> information in an 'extra' field, which can store anything.
True. For many commits though, hg-git doesn't need any extra fields,
as far as I've seen. A timestamp incompatibility would require extra
info on every commit.
> Either way, I don't see the point in changing git's commit format for
> external tools. The git-notes functionality works just fine for that,
> it just needs to be attached in the relevant places, like 'git
> fast-export'.
I agree. Even encoding info in the commit message works fine, and
git-svn already does that.
> BTW. Have you checked git's native support for hg?[1]
That's been added after I played with this last, I'll have a look.
Cheers,
Thomas
^ permalink raw reply
* Re: Possible vulnerability to SHA-1 collisions
From: Andreas Ericsson @ 2012-11-28 9:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn Pearce, Michael Hirshleifer
In-Reply-To: <20121128002714.GA23224@sigill.intra.peff.net>
On 11/28/2012 01:27 AM, Jeff King wrote:
> On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote:
>
>> At 18:07 -0500 27 Nov 2012, Jeff King <peff@peff.net> wrote:
>>> PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
>>> easier said than done. We do not have SHA-1 collisions yet, but if
>>> the md5 attacks are any indication, the innocuous file will not be
>>> completely clean; it will need to have some embedded binary goo that
>>> is mutated randomly during the collision process (which is why the
>>> md5 attacks were demonstrated with postscript files which _rendered_
>>> to look good, but contained a chunk of random bytes in a spot ignored
>>> by the postscript interpreter).
>>
>> I don't think that really saves us though. Many formats have parts
>> of the file which will be ignored, such as comments in source code.
>
> Agreed, it does not save us unconditionally. It just makes it harder to
> execute the attack. Would you take a patch from a stranger that had a
> kilobyte of binary garbage in a comment?
>
> A more likely avenue would be a true binary file where nobody is
> expected to read the diff.
>
>> With the suggested type of attack, there isn't a requirement about
>> which version of the file is modified. So the attacker should be
>> able to generate a version of a file with an innocuous change, get
>> the SHA-1 for that, then add garbage comments to their malicious
>> version of the file to try to get the same SHA-1.
>
> That's not how birthday collision attacks usually work, though. You do
> not get to just mutate the malicious side and leave the innocuous side
> untouched. You are mutating both sides over and over and hoping to find
> a matching sha1 from the "good" and "evil" sides.
>
> Of course, I have not been keeping up too closely with the efforts to
> break sha-1. Maybe there is something more nefarious about the current
> attacks. I am just going off my recollection of the md5 collision
> attacks.
>
AFAIR, collision attacks can be executed with a 2^51 probability (with
a 2^80 claim, that's pretty bad), but preimage attacks are still stuck
very close to the claimed 2^160.
That means every attack involving SHA1 means Mr. Malicious creates
both the involved files or does exceptional research without sharing
it.
I think git's job is to make sure that write access to only one of
the repositories is insufficient to launch an attack. If the attacker
manages to change all repositories involved then the hash function
used is really quite irrelevant.
--
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: Millisecond precision in timestamps?
From: Andreas Ericsson @ 2012-11-28 10:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Shawn Pearce, Felipe Contreras, Eric Raymond, git
In-Reply-To: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>
On 11/28/2012 08:29 AM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> There is room for new headers, and older versions of git will ignore
>> them. You could add a new "committer-timestamp" field that elaborates on
>> the timestamp included on the committer line. Newer versions of git
>> would respect it, and older versions would fall back to using the
>> committer timestamp.
>>
>> But I really wonder if anybody actually cares about adding sub-second
>> timestamp support, or if it is merely "because SVN has it".
>
> Roundtrip conversions may benefit from sub-second timestamps, but
> personally I think negative timestamps are more interesting and of
> practical use. Prehistoric projects need them even if they intend
> to switch to Git, never to go back to their original tarballs and
> collection of RCS ,v files.
>
> And if we were to add "committer-timestamp" and friends to support
> negative timestamps anyway (because older tools will not support
> them), supporting sub-second part might be something we want to
> think about at the same time.
>
> We would however need to be extra careful. How should we express
> half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)? Would we
> spell it 1354087456.5? 1354087456.500? Would we require decimal
> representation of floating point numbers to be normalized in some
> way (e.g. minimum number of digits without losing precision)? The
> same timestamp needs to be expressed the same way, or we will end up
> with different commit objects, which defeats the whole purpose of
> introducing subsecond timestamps to support round-trip conversions.
>
> If we were to use a separate "subsecond" fields, another thing we
> need to be careful about is the order of these extra fields, exactly
> for the same reason.
>
If we're going to support pre-epoch timestamps, we'll have to do that
for 2.0 anyway, since we'll otherwise have two conflicting dates in
the commit object.
Adding support for parsing them now and start writing them in 2.0
would make sense.
In that case, we'd have to print timestamps as
printf("%lu.%06lu", tv.tv_sec, tv.tv_usec);
I'm unsure how useful it is to support pre-epoch dates though. It's
hard to find software where anyone really cares about the code from
43 years ago with anything but historical interest, and for those
who take the museum road, I'm betting it's more interesting to see
how people worked back then than it is to see what they wrote.
Aside from that, it would be trivial to support museum style history
viewing with a special flag that treats the timestamps as minutes
since 1900-01-01 or some such, giving us plenty of time before even
the first punch-card was invented. It wouldn't be much harder to
let the user specify the timeunit and the start-point either, and
then we could store the history of carbon-based lifeforms on earth
in git.
--
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: Millisecond precision in timestamps?
From: Andreas Ericsson @ 2012-11-28 10:14 UTC (permalink / raw)
To: David Aguilar
Cc: esr, Junio C Hamano, Jeff King, Shawn Pearce, Felipe Contreras,
git
In-Reply-To: <CAJDDKr6n2KSZz5zPHeWiYHAP7Zr02Ti-e24AX1yR_XAXAKhscg@mail.gmail.com>
On 11/28/2012 09:04 AM, David Aguilar wrote:
> On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Junio C Hamano <gitster@pobox.com>:
>>> Roundtrip conversions may benefit from sub-second timestamps, but
>>> personally I think negative timestamps are more interesting and of
>>> practical use.
>>
>> You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?
>>
>> Interesting. I hadn't thought of that. I've never seen a software
>> project under version control with bits that old, which is significant
>> because I've probably done more digging into ancient software than
>> anybody other than a specialist historian or two.
>
> One example I've heard is someone wanting to throw the history
> of a country's laws into git so they can diff them.
>
That'll get tricky if you try it in Sweden. Our oldest written law
dates back to 1281. Quite fun reading. Apparently it was against the
law to shoot your slaves with stone arrows back then.
See my other proposal for how this could be done, which would only
affect the output layer (and some care would have to be taken with
the input, naturally).
--
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: git-svn: What is --follow-parent / --no-follow-parent for?
From: Steven Michalske @ 2012-11-28 10:18 UTC (permalink / raw)
To: Sebastian Leske; +Cc: git
In-Reply-To: <20121120073153.GA340@localhost>
On Nov 19, 2012, at 11:31 PM, Sebastian Leske <Sebastian.Leske@sleske.name> wrote:
>
> Commit graph of git-svn result:
>
> --follow-parent: --no-follow-parent:
>
>
> | |
> /| | |
> / | | |
> | | | |
> | | | |
> | | | |
> \ | | |
> \| | |
> | |
>
>
> (please excuse cheap ASCII art)
>
> Is that the only effect of --no-follow-parent? And again, why would I
> want that?
I suppose that you would want this for a SVN repo that holds many different and possibly loosely related projects.
The you can apply git filter branch then to split them up cleanly.
e.g. Imagine that the two root commits of the branches do not have true common history.
Steve
^ permalink raw reply
* Re: [PATCH] configure.ac: fix pthreads detection on Mac OS X
From: Max Horn @ 2012-11-28 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlidmi65n.fsf@alter.siamese.dyndns.org>
On 28.11.2012, at 07:38, Junio C Hamano wrote:
> Max Horn <max@quendi.de> writes:
>
>> The configure script checks whether certain flags are required to use
>> pthreads. But it did not consider that *none* might be needed (as is the
>> case on Mac OS X). This lead to configure adding "-mt" to the list of
>> flags (which does nothing on OS X except producing a warning). This in
>> turn triggered a compiler warning on every single file.
>>
>> To solve this, we now first check if pthreads work without extra flags.
>> This means the check is now order dependant, hence a comment is added
>> explaining this, and the reasons for it.
>>
>> Note that it might be possible to write an order independent test, but
>> it does not seem worth the extra effort required for implementing and
>> testing such a solution, when this simple solution exists and works.
>>
>> Signed-off-by: Max Horn <max@quendi.de>
>> ---
>>
>> This is actually a revised version from my patch
>> "Change configure to check if pthreads are usable without any extra flags"
>> from July. I simply had forgotten all about it :-(.
>
> Will queue,
OK
> but we would need wider testing to avoid "compiles well
> without an option but fails to link" issues similar to cea13a8
> (Improve test for pthreads flag, 2011-03-28) on other people's
> platforms (I know you tested on Mac OS X and over there it compiles
> and links well---I am worried about others).
Sure, understood. Though note that the test in question performs a compile & link test. So I have a hard time to see how this could break something. Then again, I dabbled in portable code long enough to never say never ;-).
BTW, is there such a thing as a build farm for git which automatically compiles and runs tests for pu / next / main, across a variety of platforms? Or does it all rely on devs test building everything regularly?
Cheers,
Max
^ permalink raw reply
* Re: git config key bug or by design?
From: Peter van der Does @ 2012-11-28 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <20121128033408.GE27772@sigill.intra.peff.net>
On Tue, 27 Nov 2012 22:34:09 -0500
Jeff King <peff@peff.net> wrote:
>
> I don't recall ever discussing it. But what is it that you want to
> store in a key starting with a number? Git does not respect any such
> config values[1].
>
> Are you writing a new tool that will store its config alongside git's?
> Even if the behavior is loosened, you would probably want to avoid
> starting your config keys with numbers, as older git versions would be
> around for a while and would choke on it.
>
> -Peff
>
> [1] You can still store arbitrary bytes in the subsection name (e.g.,
> "foo.123.bar").
I am writing a tool, it needs to store branch names in a separate config
file.
It's clear git doesn't respect those values, hence my question. I
understand how to work around the problem, I would just prefix the key.
I was just wondering if it was by design, which I guess it is as the
parsing of the file will die if the key starts with a non-alpha
character.
--
Peter van der Does
GPG key: CB317D6E
IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes
^ permalink raw reply
* Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option (summary)
From: W. Trevor King @ 2012-11-28 13:09 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121109162919.GA922@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 5531 bytes --]
On Tue, Nov 27, 2012 at 09:42:05PM -0500, W. Trevor King wrote:
> On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:
> > https://github.com/hvoigt/git/commits/hv/floating_submodules_draft
>
> I looked over this before, but maybe not thoroughly enough ;).
Heiko pointed out that I likely hadn't looked at this branch at all,
which is true. I'd confused it with his earlier:
On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote:
> https://github.com/hvoigt/git/commits/hv/floating_submodules
but the new floating_submodules_draft branch adds Heiko's function
reorganization and floating submodule pull (with 'update --branch') on
top of my v4 commits (instead of my branch-checkout with 'update
--branch').
> This looks fine, but my current --branch implementation (which doesn't
> pull) is only a thin branch-checkout layer on top of the standard
> `update` functionality. I'm still unsure if built-in pulls are worth
> the configuration trouble. I'll sleep on it. Maybe I'll feel better
> about them tomorrow ;).
I do feel better about them today. To get a better feel for how
people see this going forward, here is a summary of proposals to date:
v1. Record submodule.<name>.branch with 'submodule add --branch …',
leave interpretation up to the user.
Feedback (paraphrased):
Phil Hord: that clobbers a configure option used by Gerritt and
possibly others, rename to --record-branch. Maybe we should
export submodule.<name>.* as $submodule_* in 'foreach'?
Nahor: what about corner cases (e.g. upstream renames branches)?
Jens Lehmann: if you record it, people will expect Git to use
it. What about automatic pulls & commits?
v2. Add --record instead of using --branch to address Phil's v1
comment.
Feedback (paraphrased):
Jens Lehmann: this is still a tiny optimization over using 'git
config'. People still use this option in different ways.
Shawn Pearce: the Gerrit use is basically the same as Ævar's,
but Gerrit has special handling for '.'.
Jeff King: if we set up submodule.<name>.branch, we should
either use it in Git, or make it very clear that we do not use
it. If we use Phil's $submodule_* export, we should clear the
variables for recursive submodules.
v3. Renamed Added $submodule_* export to v2. Give an example of
Ævar's pull workflow when explaining that Git does not use the
value internally.
Feedback (paraphrased):
Heiko Voigt: what about automatic pulls & commits? You should
allow .git/config overrides of the .gitmodules settings. if
we set up submodule.<name>.branch, we should use it in Git.
How does the submodule know which remote branch to track?
Junio's proposed 'diff' changes may hide $sha1 information.
Junio C Hamano: if we set up submodule.<name>.branch, we should
use it in Git. Use something more specific than --record.
Update 'git diff [$path]' and friends in the superproject
compares the HEAD of the checkout of the submodule at $path
with the tip of the branch named by submodule.$name.branch in
.gitmodules of the superproject, instead of the commit that is
recorded in the index of the superproject.
Sascha Cunz: you can use 'git shortlog $OLD_SHA1..$NEW_SHA1' for
the automatic commit message.
Trevor King: actually, Ævar's update command only specifies the
local branch name. The remote is recorded for that branch in
.git/modules/<name>/config.
v4. Rename --record to --local-branch. Remove $submodule_* export.
Add .git/config overrides for submodule.<name>.branch. Add
'submodule update --branch' to check out $sha1 as
submodule.<name>.branch.
Feedback (paraphrased):
Heiko Voigt: who cares about the local branch name? You should
be pulling origin/$branch, but still using
.git/modules/<name>/config to record the tracked branch. You
should also use 'submodule add --branch[=branch]' instead of
'--local-branch'. You should pull the 'update --branch'
functionality out into a sub-function like
'handle_tracked_branch_update'.
Jens Lehmann: .git/config overrides are nice, but they should be
optional.
Trevor King: floating branches are following the submodule's
remote, while 'update --rebase/--merge' are following the
superproject's recorded $sha1. Bundling remote-following and
superproject-following in the same command may be confusing.
Here's what I think we need in v5:
* Jens' optional .git/config overrides.
* Return --local-branch handling to a side effect of --branch (as in
v1).
* A new 'submodule pull' for tracking the submodule's remote, which is
pulling --ff-only origin/$branch into a whatever state the submodule
is currently in. If any changes were made to submodule $shas,
optionally commit them with a shortlog-generated commit message.
* Remove my current 'submodule update --branch' functionality.
Thoughs? Do we need any more information for an automatic pull, or is
$ git pull --ff-only origin/$branch
on a headless checkout sufficient?
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: git-prompt.sh vs leading white space in __git_ps1()::printf_format
From: Simon Oosthoek @ 2012-11-28 13:20 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: git
In-Reply-To: <CAA01Cso1E4EC4W667FEU_af2=uGOfPuaWEB3y+zPCpB+bPzoaA@mail.gmail.com>
* Piotr Krukowiecki <piotr.krukowiecki@gmail.com> [2012-11-28 11:03:29 +0100]:
> Hi,
>
> when I set PROMPT_COMMAND to __git_ps1 I get a space at the beginning:
>
Is your setting?:
PROMPT_COMMAND=__git_ps1
I believe you need to give 2 parameters in order to use it in PROMPT_COMMAND mode.
In my .bashrc I have:
if [ -f ~/.gitprompt.sh ]
then
. ~/.gitprompt.sh
GIT_PS1_SHOWDIRTYSTATE=true
GIT_PS1_SHOWCOLORHINTS=true
GIT_PS1_SHOWUNTRACKEDFILES=true
PROMPT_COMMAND="__git_ps1 '\u@\[\e[1;34m\]\h\[\e[0m\]:\w' '\\\$ '"
fi
> (master)pkruk@foobar ~/dir$
> ^ space
>
> Is there a reason for this? It looks like a waste of space. If I'm not in
> git repository I don't have the space:
>
> pkruk@foobar ~/other$
>
> I noticed the space is explicitly specified in printf_format in
> git-prompt.sh. Is it needed? If I remove it, everything seems to work fine
> (no leading space)...
>
> --- /usr/local/src/git/git/contrib/completion/git-prompt.sh 2012-11-28
> 10:27:05.728939201 +0100
> +++ /home/pkruk/.git-prompt.sh 2012-11-28 10:52:56.852629745 +0100
> @@ -218,7 +218,7 @@ __git_ps1 ()
> local detached=no
> local ps1pc_start='\u@\h:\w '
> local ps1pc_end='\$ '
> - local printf_format=' (%s)'
> + local printf_format='(%s)'
>
> case "$#" in
> 2) pcmode=yes
These last 2 lines say: if 2 arguments are given, use pcmode. Otherwise you get command-subtitution mode, which gives weird effects when being called from PROMPT_COMMAND.
Cheers
Simon
^ permalink raw reply
* git fetch pack freezes
From: Ivan Kanis @ 2012-11-28 14:12 UTC (permalink / raw)
To: git
Hello,
We are using git with the smart HTTP protocol. We are seeing the client
freeze with Jenkins poll. It stops the continuous build which is a bit
of a pain. It happens with the latest release 1.8.0 on the client side.
The server is using 1.7.0.4.
On the server we are seeing the following error message:
var/log/apache2/error.log.1:[Mon Nov 19 15:17:12 2012] [error] [client 192.168.50.15] fatal: git upload-pack: not our ref aa92ca2076c2421433f89ee0b0ae89cd36d27481 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
The error is located in upload-pack.c:
* Hmph. We may later want to allow "want" line that
* asks for something like "master~10" (symbolic)...
* would it make sense? I don't know.
*/
o = lookup_object(sha1_buf);
if (!o || !(o->flags & OUR_REF))
die("git upload-pack: not our ref %s", line+5);
It calls die with I believe is doing the right thing(TM).
On the client side I compiled git with debugging symbols. I then
attached the debugger to the process that gets hosed. I get the
following backtrace:
#0 0x00007fff85389af0 in read ()
#1 0x000000010f900913 in xread (fd=0, buf=0x7fff6f376e2c, len=4) at wrapper.c:142
#2 0x000000010f900a11 in read_in_full (fd=0, buf=0x7fff6f376e2c, count=4) at wrapper.c:171
#3 0x000000010f8a14e4 in safe_read (fd=0, buffer=0x7fff6f376e2c, size=4, return_line_fail=0) at pkt-line.c:140
#4 0x000000010f8a110e in packet_read_internal (fd=0, buffer=0x10f981eb0 "", size=1000, return_line_fail=0) at pkt-line.c:183
#5 0x000000010f8a1246 in packet_read_line (fd=0, buffer=0x10f981eb0 "", size=1000) at pkt-line.c:211
#6 0x000000010f7b5196 in get_ack (fd=0, result_sha1=0x7fff6f377450 "") at builtin/fetch-pack.c:227
#7 0x000000010f7b4074 in find_common (fd=0x7fff6f377668, result_sha1=0x7fff6f377450 "", refs=0x0) at builtin/fetch-pack.c:416
#8 0x000000010f7b32a5 in do_fetch_pack (fd=0x7fff6f377668, orig_ref=0x10fb007a0, sought=0x7fff6f377670, pack_lockfile=0x7fff6f377660)
at builtin/fetch-pack.c:832
#9 0x000000010f7b2cbd in fetch_pack (my_args=0x10f973fe8, fd=0x7fff6f377668, conn=0x0, ref=0x10fb007a0,
dest=0x7fff6f377a78 "https://foo.visionobjects.com/git/a-project-name/", sought=0x7fff6f377670, pack_lockfile=0x7fff6f377660)
at builtin/fetch-pack.c:1069
#10 0x000000010f7b2a25 in cmd_fetch_pack (argc=7, argv=0x7fff6f377890, prefix=0x0) at builtin/fetch-pack.c:1012
#11 0x000000010f77aa5b in run_builtin (p=0x10f971990, argc=7, argv=0x7fff6f377890) at git.c:306
#12 0x000000010f779ac7 in handle_internal_command (argc=7, argv=0x7fff6f377890) at git.c:467
#13 0x000000010f77a299 in run_argv (argcp=0x7fff6f377858, argv=0x7fff6f377850) at git.c:513
#14 0x000000010f7798fd in main (argc=7, argv=0x7fff6f377890) at git.c:588
The file descriptor being 0 in #6 seems a bit suspicious. I am not
familiar with the git protocol. Could I get some guidance on how to
troubleshoot some more so that I come up with a patch?
--
Ivan Kanis, Release Manager, Vision Objects,
Tel +33 2 28 01 49 50, Fax +33 2 40 25 89 20
http://www.visionobjects.com
The essence of science: ask an impertinent question, and you are on
the way to a pertinent answer.
-- Jacob Bronowski
^ permalink raw reply
* Re: [PATCH 1/4] git-svn: Document branches with at-sign(@).
From: Michael J Gruber @ 2012-11-28 14:43 UTC (permalink / raw)
To: Sebastian Leske, Git Mailing List; +Cc: Eric Wong
In-Reply-To: <b115a546fa783b4121d118bb8fdb9270443f90fa.1353691892.git.Sebastian.Leske@sleske.name>
Sebastian Leske venit, vidit, dixit 18.11.2012 18:08:
> git svn will sometimes create branches with an at-sign in the name
> (branchname@revision). These branches confuse many users and it is a FAQ
> why they are created. Document when git svn will create them.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
>
> I found various important features of git-svn that are not documented.
> Thus I created a series of patches to add and update documentation for
> git-svn. I am sending this as four patches (of which this mail is the
> first). I have tried my best to make the patches ready for inclusion
> into git, but if there's any feedback, I'll gladly incorporate it.
>
>
> Documentation/git-svn.txt | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 8b0d3ad..482d60d 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -881,6 +881,32 @@ different name spaces. For example:
> branches = stable/*:refs/remotes/svn/stable/*
> branches = debug/*:refs/remotes/svn/debug/*
>
> +If 'git svn' is configured to fetch branches (and --follow-branches
> +is in effect), it will sometimes create multiple branches for one SVN
> +branch, where the addtional branches have names of the form
> +'branchname@nnn' (with nnn an SVN revision number). These additional
> +branches are created if 'git svn' cannot find a parent commit for the
> +first commit in the branch, to connect the branch to the history of the
> +other branches. Normally, 'git svn' will find the git commit that
> +corresponds to the SVN revision a branch was created (copied) from and
> +use that as the parent. However, it is possible that there is no
> +suitable git commit to serve as parent. This will happen, among other
> +reasons, if the SVN branch is a copy of a revision that was not fetched
> +by 'git svn' (e.g. because it is an old revision that was skipped with
> +'--revision'), or if in SVN a directory was copied that is not tracked
> +by 'git svn' (a branch that is not tracked at all, or a subdirectory of
> +a tracked branch). In these cases, 'git svn' will still create a git
> +branch, but the branch will not be connected to the history of the other
> +branches. 'git svn' will also create a commit from the SVN revision the
> +branch was copied from, and use that as the parent commit of the branch
> +(this is indicated by the message "Initializing parent: <branchname>").
> +Additionally, it will create a special branch named
> +'<branchname>@<SVN-Revision>', where <SVN-Revision> is the SVN revision
> +number the branch was copied from. This branch will point to the
> +specially created parent commit.
> +If in SVN the branch was deleted and later recreated from a different
> +version, there will be multiple such branches with an '@'.
> +
> BUGS
> ----
>
>
In fact, the most typical reason for at-branches is a botched branching
or tagging operation on the svn side: since they are simply "copy"
operations it's too easy to copy a tree into the wrong directory.
Michael
^ permalink raw reply
* Re: [PATCH 2/4] Recommend use of structure options for git svn.
From: Michael J Gruber @ 2012-11-28 14:46 UTC (permalink / raw)
To: Sebastian Leske, Git Mailing List; +Cc: Eric Wong
In-Reply-To: <a4de87e8d09c26221eff116c3209b0a3606dfc21.1353691892.git.Sebastian.Leske@sleske.name>
Sebastian Leske venit, vidit, dixit 21.11.2012 08:13:
> Document that when using git svn, one should usually either use the
> directory structure options to import branches as branches, or only
> import one subdirectory. The default behaviour of cloning all branches
> and tags as subdirectories in the working copy is usually not what the
> user wants.
"Usually" assumes that usually svn repos follow a branch/tag structure.
That may be quite true nowadays (but wasn't in the beginning).
In fact I would suggest to emphasize "--stdlayout" as the most standard
choice nowadays, followed by specifying a specific branch (usually
trunk) as the repo uri.
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 482d60d..928a961 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -871,6 +871,16 @@ already dcommitted. It is considered bad practice to --amend commits
> you've already pushed to a remote repository for other users, and
> dcommit with SVN is analogous to that.
>
> +When cloning an SVN repository, if none of the options for describing
> +the repository layout is used (--trunk, --tags, --branches,
> +--stdlayout), 'git svn clone' will create a git repository with
> +completely linear history, where branches and tags appear as separate
> +folders in the working copy. For projects with many branches this will
> +lead to a working copy many times larger than just the trunk. It is
> +recommended to either use the the options for trunk / tag / branch
> +directory, or to only clone the trunk (or a subdirectory of the
> +trunk).
> +
> When using multiple --branches or --tags, 'git svn' does not automatically
> handle name collisions (for example, if two branches from different paths have
> the same name, or if a branch and a tag have the same name). In these cases,
>
^ permalink raw reply
* Re: [PATCH 3/4] git-svn: Expand documentation for --follow-parent
From: Michael J Gruber @ 2012-11-28 14:48 UTC (permalink / raw)
To: Sebastian Leske, Git Mailing List; +Cc: Eric Wong
In-Reply-To: <a9748faec2a18231ad588c1a2dedb82e74685d74.1353691892.git.Sebastian.Leske@sleske.name>
Sebastian Leske venit, vidit, dixit 23.11.2012 08:13:
> Describe what the option --follow-parent does, and what happens if it is
> set or unset.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 928a961..92780ef 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -628,11 +628,19 @@ ADVANCED OPTIONS
> Default: "svn"
>
> --follow-parent::
> + This option is only relevant if we are tracking branches (using
> + one of the repository layout options --trunk, --tags,
> + --branches, --stdlayout). For each tracked branch, try to find
> + out where its revision was copied (i.e. branched) from, and set
> + a suitable parent in the first git commit for the branch.
> This is especially helpful when we're tracking a directory
> - that has been moved around within the repository, or if we
> - started tracking a branch and never tracked the trunk it was
> - descended from. This feature is enabled by default, use
> - --no-follow-parent to disable it.
> + that has been moved around within the repository (note that you
> + must track both the old and the new name for the whole history
> + to be imported). If this feature is disabled, the branches
> + created by 'git svn' will all be linaear and not share any
linear
> + history, meaning that there will be no information on where
> + branches where branched off or merged. This feature is enabled
> + by default, use --no-follow-parent to disable it.
> +
> [verse]
> config key: svn.followparent
>
^ permalink raw reply
* Re: [PATCH 4/4] git-svn: Note about tags.
From: Michael J Gruber @ 2012-11-28 14:58 UTC (permalink / raw)
To: Sebastian Leske, Git Mailing List; +Cc: Eric Wong
In-Reply-To: <c72bc0d2a4f2681d27247c6f7510c4ada8e83aec.1353691892.git.Sebastian.Leske@sleske.name>
Sebastian Leske venit, vidit, dixit 23.11.2012 08:29:
> Document that 'git svn' will import SVN tags as branches.
>
> Signed-off-by: Sebastian Leske <sebastian.leske@sleske.name>
> ---
> Documentation/git-svn.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 92780ef..6212b24 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -938,6 +938,12 @@ the possible corner cases (git doesn't do it, either). Committing
> renamed and copied files is fully supported if they're similar enough
> for git to detect them.
>
> +In SVN, it is possible (though discouraged) to commit changes to a tag
> +(because a tag is just a directory copy, thus technically the same as a
> +branch). When cloning an SVN repository, 'git svn' cannot know if such a
> +commit to a tag will happen in the future. Thus it acts conservatively
> +and imports all SVN tags as branches, prefixing the tag name with 'tags/'.
> +
If git-svn turned SVN tags in git lightweight tags it would be just as
conservative, because they can be rewritten also... It's just a ref.
Note that the above assumes standard refspecs.
But, importing SVN tags as branches conveys their character much more
precisely. If r8 is being tagged then svn creates r9, which may or may
not be treesame to r8; different projects do different things in this step.
Even if they are treesame, r9 still carries a separate commit message.
This is probably the most typical case, and converting the r9 commit
into a git tag object would be appropriate (but is left to the user of
git-svn).
A lightweight tag pointing to an "off-branch" commit (r9) would be a
strange thing, so git-svn creates a new branch instead, pointing at r9,
branching off r8.
> CONFIGURATION
> -------------
>
>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Magnus Bäck @ 2012-11-28 15:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <CAMP44s10krOPD73dL0Ancie=kussk89jK7V5adR3hw=a73CVWw@mail.gmail.com>
On Tuesday, November 27, 2012 at 19:10 EST,
Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck <baeck@google.com> wrote:
>
> > While "constant traffic" probably overstates the issue, these are
> > not theoretical problems. I recall at least three cases in the last
> > year or so where Git has seen breakage with Solaris or Mac OS X
> > because of sed or tr incompatibilities, and I don't even read this
> > list that thoroughly.
>
> Most of the *constant* traffic is about *theoretical*
> incompatibilities, how much of that are real incompatibilities, it's
> not known. _Some_ of the traffic is about real incompatibilities,
> sure, but you could count only three cases *in a year*. It's not a
> huge amount. And then, how man this year?
>
> Also, I would like references to those incompatibilities.
I don't remember the details of the Mac OS X problem, but just searching
the archives for "xpg4" revealed the following Solaris problems since
April:
http://article.gmane.org/gmane.comp.version-control.git/195010
http://article.gmane.org/gmane.comp.version-control.git/195966
http://article.gmane.org/gmane.comp.version-control.git/207944
--
Magnus Bäck
baeck@google.com
^ permalink raw reply
* Re: git fetch pack freezes
From: Shawn Pearce @ 2012-11-28 16:41 UTC (permalink / raw)
To: Ivan Kanis; +Cc: git
In-Reply-To: <87624pizoe.fsf@googlemail.com>
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis <ivan.kanis@googlemail.com> wrote:
> We are using git with the smart HTTP protocol. We are seeing the client
> freeze with Jenkins poll. It stops the continuous build which is a bit
> of a pain. It happens with the latest release 1.8.0 on the client side.
> The server is using 1.7.0.4.
>
> On the server we are seeing the following error message:
>
> var/log/apache2/error.log.1:[Mon Nov 19 15:17:12 2012] [error] [client 192.168.50.15] fatal: git upload-pack: not our ref aa92ca2076c2421433f89ee0b0ae89cd36d27481 multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
Upgrade your server. What happened here is a race condition that is
only possible in the smart HTTP protocol. The client makes an initial
request to ask where the branches are. Then it makes a second (and
possibly more) subsequent request to negotiate a common ancestor and
actually obtain the necessary objects. If a branch is updated between
that initial request and any subsequent request, the server fails with
this error message.
More recent servers handle this more gracefully by looking to see if
the object the client wants is reachable within some reasonable
distance from a current branch. If so, the request is still allowed to
continue, rather than die() with a failure.
> On the client side I compiled git with debugging symbols. I then
> attached the debugger to the process that gets hosed. I get the
> following backtrace:
>
> #5 0x000000010f8a1246 in packet_read_line (fd=0, buffer=0x10f981eb0 "", size=1000) at pkt-line.c:211
> #6 0x000000010f7b5196 in get_ack (fd=0, result_sha1=0x7fff6f377450 "") at builtin/fetch-pack.c:227
> #7 0x000000010f7b4074 in find_common (fd=0x7fff6f377668, result_sha1=0x7fff6f377450 "", refs=0x0) at builtin/fetch-pack.c:416
>
> The file descriptor being 0 in #6 seems a bit suspicious. I am not
> familiar with the git protocol. Could I get some guidance on how to
> troubleshoot some more so that I come up with a patch?
There is actually a parent process in front of this one called
git-remote-http (or git-remote-https depending on protocol). That
parent is doing the HTTP transport and is sending whatever the server
provides into this child's stdin. I'm not surprised there is yet
another deadlock condition in here, its a rather heinous process setup
and way to handle the protocol.
fd in frame #7 is an address of an int array. fd in frame #6 is an
actual fd, the one to read from, which in this case should be 0 to
read from stdin, because its trying to get data from the HTTP server
by way of reading it from the pipe the parent supplied to it on stdin.
So the stack frames are correct. Its just a problem that the parent
didn't identify the server crashing and closing its side of the pipe
on stdin to force it to EOF to prevent the child from getting hung
here in a read.
^ permalink raw reply
* Re: [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Junio C Hamano @ 2012-11-28 16:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Kacper Kornet, git, Aaron Schrab
In-Reply-To: <50B5B599.3020105@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Am 11/28/2012 0:00, schrieb Kacper Kornet:
>> When the changes are pushed upstream, and in the meantime someone else
>> updated upstream branch git advises to use git pull. This results in
>> history:
>>
>> ---A---B---C--
>> \ /
>> D---E
>
> The commit message will say:
>
> Merge branch 'master' of /that/remote
>
> * 'master' of /that/remote:
> E
> D
>
>> where B is the local commit. D, E are commits pushed by someone else
>> when the developer was working on B. However sometimes the following
>> history is preferable:
>>
>> ---A---D---C'--
>> \ /
>> '-B-'
>
> Better:
>
> ---A--D--E--C'
> \ /
> `----B
Yup, that topology is what Kacper's workflow wants.
Stepping back a bit, however, I am not sure if that is really true.
The goal of this topic seems to be to keep one integration branch
and always merge *into* that integration branch, never *from* it,
but for what purpose? Making the "log --first-parent" express the
integration branch as a linear series of progress? If so, I suspect
a project with such a policy would dictate that D and E also be on a
side branch, i.e. the history would look more like this:
D---E
/ \
--A-------X---C---
\ /
`-------B
with X being a --no-ff merge of the topic that consists of these two
commits.
> In this case, the commit message should say... what? Certainly not the
> same thing. But I do not see that you changed anything in this regard.
True. If the goal is to emulate a merge of B from a side branch
into _the_ integration branch, the summary should also emulate the
message that would be given when the remote pulled from your current
branch.
^ permalink raw reply
* Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option (summary)
From: W. Trevor King @ 2012-11-28 16:53 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121128130903.GB15786@odin.tremily.us>
On Wed, Nov 28, 2012 at 08:09:03AM -0500, W. Trevor King wrote:
> * A new 'submodule pull' for tracking the submodule's remote, which is
> pulling --ff-only origin/$branch into a whatever state the submodule
> is currently in. If any changes were made to submodule $shas,
> optionally commit them with a shortlog-generated commit message.
I thought of a better idea on the train. How about adding `--remote`
to `submodule update` that overrides the gitlinked SHA-1 with the
SHA-1 for origin/$branch? All of the other checkout/merge/rebase
functionality is untouched. The only thing that changes is where we
look for the update. I'm working up the patch now, and will submit v5
shortly.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ permalink raw reply
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Junio C Hamano @ 2012-11-28 16:57 UTC (permalink / raw)
To: Christian Couder; +Cc: Felipe Contreras, Christian Couder, git
In-Reply-To: <CAP8UFD08LhywQ9KaNoeG1nORZwtK8MNWqwjfRJPyT2vLkNgs9A@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> On Wed, Nov 28, 2012 at 9:03 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Wed, Nov 28, 2012 at 8:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Christian Couder <chriscool@tuxfamily.org> writes:
>>>
>>>> All the python scripts except contrib/svn-fe/svnrdump_sim.py
>>>> start with "#!/usr/bin/env python".
>>>>
>>>> This patch fix contrib/svn-fe/svnrdump_sim.py to do the same.
>>>
>>> I suspect you need a bit more than that.
>>>
>>> $ make git-p4
>>> $ diff -u git-p4.py git-p4
>>>
>>> shows you how we tell the scripts how to find their interpreters
>>> (that way, there is no need to rely on the existence of
>>> /usr/bin/env).
>>
>> That works if somebody managed to export PYTHON_PATH, which very very
>> often is not the case for me.
>
> Yeah, and even if PYTHON_PATH is used, in t9020-remote-svn.sh,
> svnrdump.py is used as is.
You need a fix for that; didn't I already say "you need a bit more
than that"?
^ permalink raw reply
* Re: [PATCH] push: cleanup push rules comment
From: Junio C Hamano @ 2012-11-28 16:58 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1354079933-2488-1-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> ---
>
> I ended up rewriting most of the comment. The new version removes
> inter-rule dependencies (e.g., rule 5 overrides rule 3) which I think
> makes it more readable.
Nice; thanks.
^ permalink raw reply
* Re: git fetch pack freezes
From: Ivan Kanis @ 2012-11-28 17:25 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJvGNUtT+z_E7rSaOr77=7dSo1N+7QiEoHNdEQDV3n7JWw@mail.gmail.com>
Hi Shawn,
Thanks for the quick reply.
Shawn Pearce <spearce@spearce.org> wrote:
> On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis <ivan.kanis@googlemail.com> wrote:
>>
>> On the server we are seeing the following error message:
>
> Upgrade your server.
OK we'll look into it. I have a question: will a 1.8 server still serve
1.7 git client?
> So the stack frames are correct. Its just a problem that the parent
> didn't identify the server crashing and closing its side of the pipe
> on stdin to force it to EOF to prevent the child from getting hung
> here in a read.
It sounds like a bug on the client, doesn't it?
--
Ivan Kanis, Release Manager, Vision Objects,
Tel +33 2 28 01 49 50, Fax +33 2 40 25 89 20
http://www.visionobjects.com
Let a fool hold his tongue and he will pass for a sage.
-- Publilius Syrus
^ permalink raw reply
* Re: [PATCH v3 5/7] remote-bzr: add simple tests
From: Junio C Hamano @ 2012-11-28 17:36 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <1352643598-8500-6-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> contrib/remote-helpers/test-bzr.sh | 111 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 111 insertions(+)
> create mode 100755 contrib/remote-helpers/test-bzr.sh
>
> diff --git a/contrib/remote-helpers/test-bzr.sh b/contrib/remote-helpers/test-bzr.sh
> new file mode 100755
> index 0000000..8594ffc
> --- /dev/null
> +++ b/contrib/remote-helpers/test-bzr.sh
> @@ -0,0 +1,111 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2012 Felipe Contreras
> +#
> +
> +test_description='Test remote-bzr'
> +
> +. ./test-lib.sh
> +
> +if ! test_have_prereq PYTHON; then
> + skip_all='skipping remote-bzr tests; python not available'
> + test_done
> +fi
> +
> +if ! "$PYTHON_PATH" -c 'import bzrlib'; then
> + skip_all='skipping remote-bzr tests; bzr not available'
> + test_done
> +fi
> +cmd=<<EOF
> +import bzrlib
> +bzrlib.initialize()
> +import bzrlib.plugin
> +bzrlib.plugin.load_plugins()
> +import bzrlib.plugins.fastimport
> +EOF
> +if ! "$PYTHON_PATH" -c "$cmd"; then
I cannot see how this could have ever worked. It could be that you
wrote it for zsh and tested only with the version of zsh you have;
zsh I have here does not grok it (and of course dash and bash won't).
In any case, I do not think this is a POSIX shell. Just replace
"=<<EOF" and "EOF" with single quote and everybody's shell should be
able to read it.
> + echo "consider setting BZR_PLUGIN_PATH=$HOME/.bazaar/plugins" 1>&2
> + skip_all='skipping remote-bzr tests; bzr-fastimport not available'
> + test_done
> +fi
> +
> +check () {
> + (cd $1 &&
> + git log --format='%s' -1 &&
> + git symbolic-ref HEAD) > actual &&
> + (echo $2 &&
> + echo "refs/heads/$3") > expected &&
Style: s/> expected/>expected/;
I won't repeat this but there are many others in this file.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 4/7] remote-bzr: update working tree
From: Junio C Hamano @ 2012-11-28 17:38 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <1352643598-8500-5-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> contrib/remote-helpers/git-remote-bzr | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
> index 2c05f35..5b89a05 100755
> --- a/contrib/remote-helpers/git-remote-bzr
> +++ b/contrib/remote-helpers/git-remote-bzr
> @@ -571,6 +571,8 @@ def do_export(parser):
> repo.generate_revision_history(revid, marks.get_tip('master'))
> revno, revid = repo.last_revision_info()
> peer.import_last_revision_info_and_tags(repo, revno, revid)
> + wt = peer.bzrdir.open_workingtree()
> + wt.update()
> print "ok %s" % ref
> print
Shouldn't this be squashed as part of one of the earlier patches?
The split between 1/7 (import first) and 2/7 (then support export)
makes sense, but this one looks more like "oops, we forgot to touch
the working tree while updating the history in the previous steps
and here is a fix" to me.
^ 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