* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-28 2:09 UTC (permalink / raw)
To: esr; +Cc: Nguyen Thai Ngoc Duy, git, msysGit
In-Reply-To: <20121125215635.GA6937@thyrsus.com>
On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
> Please don't waste further time on quibbling. We all know that gitk is
> an uncomfortable special case and that the project would be far better
> off, maintainability-wise, if it were successfully ported to one if these
> other languages. Trying to catch me out by triumphantly pointing at gitk
> is...juvenile.
Another bit of information I just realized, 'man git' lists gitk as a
'Main porcelain command' as high level as any git command can get.
--
Felipe Contreras
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-28 2:06 UTC (permalink / raw)
To: Jeff King; +Cc: Magnus Bäck, Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <20121128013943.GA23776@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 2:39 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:
>
>> Sure, you will argue that we don't see the *real* issues, because they
>> were fixed preemptively, but the fact of the matter is that we will
>> never know. All we know is the reality we can observe, and the reality
>> is that we hit very few *real* issues outside the test system (feel
>> free to provide evidence to the contrary).
>
> I think reports of breakage in the test scripts are relevant, because
> they are indicative that people _do_ run platforms that care about these
> issues, and if we were to write a lot of shell scripts, we would run
> across them more frequently. But the fact of the matter is that we don't
> write a lot of non-test shell scripts these days, which is part of the
> reason limiting your search to the last 2 years did not turn up many
> fixes outside the tests.
If we were to write a lot of shell scripts, and we were to apply the
same standards as we do with the tests, which most likely wouldn't be
the case; end-user scripts are way more important, specially
porcelain.
> There was a big push in 2006 and 2007 to port some of the hairier
> scripts to C. Try:
>
> git log --no-renames --diff-filter=D \
> --diff-filter=D --format='%ad %s' --date=short \
> -- 'git-*.sh'
>
> A lot of it was motivated by portability and decent performance for
> common commands under Windows.
Good stuff indeed. I look forward to the day all main git porcelain
commands are written in C (git-rebase I'm looking at you), there are
not many left:
git-am
git-bisect
git-citool
git-gui
git-pull
git-rebase
git-stash
git-submodule
> Anyway, there is not much point in debating the exact level of pain that
> shell portability causes us. Even if you accept that there is some, it
> is clearly not a major problem for the project.
Indeed.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 0/4] remote-helpers: general fixes
From: Junio C Hamano @ 2012-11-28 2:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1354064495-23171-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> These are general fixes, some for old versions of bazaar, mercurial, and
> python. Some of these have already been sent, but here they go alone so they
> are not missed.
>
> The bazaar fixes are on top of the series v3 which is still not in 'pu'.
Please stop then. Its v2 has been cooking in 'next' and it won't be
replaced.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-28 2:01 UTC (permalink / raw)
To: esr; +Cc: Shawn Pearce, git
In-Reply-To: <20121127230419.GA26080@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Junio C Hamano <gitster@pobox.com>:
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional seconds).
>
> Is this architecturally significant? It sounds like another
> implementation detail.
No.
If you create a commit object that violatse it and have 47 million
existing users pull such a history, they not be able to use such a
history with the version of Git they have. Don't go there.
As somebody else mentioned, in distributed environment millisecond
timestamps won't have much meaning, so it looks like a very low
priority to me from Git's perspective.
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Junio C Hamano @ 2012-11-28 1:58 UTC (permalink / raw)
To: esr; +Cc: Michael Haggerty, git
In-Reply-To: <20121127175618.GA11845@thyrsus.com>
"Eric S. Raymond" <esr@thyrsus.com> writes:
> I agree that 2.4 is still quite OK. I'm a little concerned that dropping that
> far back might store up some transition problems for the day we decide to
> make the jump to Python 3.
>
> On the other hand, I think gating features on RHEL5 might be
> excessively cautious. According to [1], RHEL will red-zone within 30
> days if it hasn't done so already ([1] says "Q4"). And RHEL6 (with
> Python 2.6) has been shipping for two years.
I won't worry about Python 3 yet; in what timeframe did Python's
i18n/unicode support become usable? In 2.4, or 2.6?
^ permalink raw reply
* Re: Query for certain branches, but not the rest
From: Jeff King @ 2012-11-28 1:57 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s02=E3imOv00dwyXR13nQdo1XeZTjJb_y0EVQoyYMEcQw@mail.gmail.com>
On Sun, Nov 25, 2012 at 10:24:59AM +0100, Felipe Contreras wrote:
> Suppose I have these branches:
>
> fc/feature-a
> fc/feature-b
> master
> next
>
> I want to show this: fc/feature-a fc/feature-b ^master ^next. I can do
> 'git log --branches=fc' to show the branches that begin with fc/, but
> there's no way to specify the rest. If they were under a prefix, I
> could do '--not --branches=prefix', but they are not.
>
> Anybody knows a way to query branches that don't have any prefix?
I don't think there is a way. `--branches` can take a pattern (and there
is always `--glob`), but we do not pass FNM_PATHNAME to fnmatch, so "*"
will match across `/` boundaries.
You are stuck with:
git log --branches=fc --not $(
git for-each-ref --format='%(refname:short)' refs/heads |
grep -v /
)
which is at least robust due to the restrictions on refnames (i.e., no
whitespace).
As an aside, I noticed that:
git log --branches=does-not-exist
will see that we matched no refs and fall back to showing HEAD. That
seems a bit surprising to me.
-Peff
^ permalink raw reply
* Re: [PATCH] Support for git aliasing for tcsh completion
From: Felipe Contreras @ 2012-11-28 1:56 UTC (permalink / raw)
To: Marc Khouzam; +Cc: Junio C Hamano, git, SZEDER Gábor, Tuncer Ayaz
In-Reply-To: <CAFj1UpGipsewPRiumtuit5FKU2-CGMp3zgh48E3wdj=g4FWAOQ@mail.gmail.com>
On Wed, Nov 28, 2012 at 2:39 AM, Marc Khouzam <marc.khouzam@gmail.com> wrote:
> On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> The patch was linewrapped so I had to fix it up;
>
> Sorry about that. I don't know if it is gmail, or the fact that I use
> its web interface
> that causes these problems.
>
>> please double check
>> what will be queued on 'pu' to make sure that I did not miss
>> necessary whitespaces or added unnecessary ones when I rejoined long
>> lines.
>
> I just checked it and it looks great.
>
> I'm working on another improvement to the script but I don't have it working
> yet. But I should not bother you much after that.
You might want to use msmtp to send mails with Gmail, that's what I do:
https://git.wiki.kernel.org/index.php/GitTips#Using_msmtp_to_send_your_patches
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Junio C Hamano @ 2012-11-28 1:56 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <CAMP44s0swzsg1MkQHkPUtwZi71xaad3y4uY542jYvXAf8Ha5nQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master'
>> soonish, but I take the above to mean that fc/remote-hg is ready
>> while it is better to wait for updates to fc/remote-bzr before
>> merging it.
>
> I was waiting on both to be merged, let me see what I have pending and
> would be nice to have before the merge.
OK.
At this point, both have been cooking for a week or more in 'next',
there is no existing users, they are on the fringe so breakages in
them won't negatively affect anybody anyway. So it doesn't matter
much if they are merged to 'master' and then fixed up with follow up
patches after that, or fixed up with follow up patches while they
are in 'next', as they won't be rewound and restarted from scratch.
^ permalink raw reply
* Re: [PATCH v6 p2 3/9] transport-helper: trivial code shuffle
From: Junio C Hamano @ 2012-11-28 1:54 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Ilari Liusvaara, Sverre Rabbelier, Elijah Newren,
Thiago Farina
In-Reply-To: <CAMP44s0fmt+bHN-ycza8b+y8Ep-Cyqmg1U1PVas267fTY5iPPQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> This is not just "just shuffle the die to make it explicit" but it
>> does change the semantics; earlier ref->deletion was perfectly fine
>> as long as data->refspecs is not given, but the new code always
>> dies.
>>
>> If this semantic change is a good thing, please explain why it is so
>> in the log message. If the change is "it does not matter because
>> when data->refspecs is not given and ref->deletion is set, we die
>> later elsewhere in the code anyway", then it needs to be described.
>
> refspecs are optional, but when they are not present the code doesn't
> work at all. This patch changes the behavior that was totally broken
> anyway.
In case it was not clear, I did not request/expect responses in the
discussion thread, but a rerolled series with updated description.
Thanks.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-28 1:42 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Eric Raymond, Junio C Hamano, git
In-Reply-To: <20121128011750.GA23498@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 2:17 AM, Jeff King <peff@peff.net> wrote:
> But I really wonder if anybody actually cares about adding sub-second
> timestamp support, or if it is merely "because SVN has it".
I agree, I don't see any point.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Jeff King @ 2012-11-28 1:39 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Magnus Bäck, Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <CAMP44s0FiNRbFHbTtZJiWLDRQmy0VZ_FNGxE40eZrXwCFJ5P7A@mail.gmail.com>
On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:
> Sure, you will argue that we don't see the *real* issues, because they
> were fixed preemptively, but the fact of the matter is that we will
> never know. All we know is the reality we can observe, and the reality
> is that we hit very few *real* issues outside the test system (feel
> free to provide evidence to the contrary).
I think reports of breakage in the test scripts are relevant, because
they are indicative that people _do_ run platforms that care about these
issues, and if we were to write a lot of shell scripts, we would run
across them more frequently. But the fact of the matter is that we don't
write a lot of non-test shell scripts these days, which is part of the
reason limiting your search to the last 2 years did not turn up many
fixes outside the tests.
There was a big push in 2006 and 2007 to port some of the hairier
scripts to C. Try:
git log --no-renames --diff-filter=D \
--diff-filter=D --format='%ad %s' --date=short \
-- 'git-*.sh'
A lot of it was motivated by portability and decent performance for
common commands under Windows.
Anyway, there is not much point in debating the exact level of pain that
shell portability causes us. Even if you accept that there is some, it
is clearly not a major problem for the project.
-Peff
^ permalink raw reply
* Re: [PATCH] Support for git aliasing for tcsh completion
From: Marc Khouzam @ 2012-11-28 1:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Felipe Contreras, SZEDER Gábor, Tuncer Ayaz
In-Reply-To: <7v38zvnez8.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The patch was linewrapped so I had to fix it up;
Sorry about that. I don't know if it is gmail, or the fact that I use
its web interface
that causes these problems.
> please double check
> what will be queued on 'pu' to make sure that I did not miss
> necessary whitespaces or added unnecessary ones when I rejoined long
> lines.
I just checked it and it looks great.
I'm working on another improvement to the script but I don't have it working
yet. But I should not bother you much after that.
Thanks again!
Marc
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-28 1:36 UTC (permalink / raw)
To: esr; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20121128011136.GA29674@thyrsus.com>
On Wed, Nov 28, 2012 at 2:11 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> % git cat-file -p HEAD
>>
>> You'll see exactly how git stores commits. Changing anything in there
>> must be done carefully.
>
> Oh, I've seen *that* before. Are you telling me the database
> representation is actually textual?
http://git-scm.com/book/ch9-2.html
---
% ruby -e "require 'zlib'; puts
Zlib::Inflate.inflate(File.read('.git/objects/55/47f28602c9b07f69dfa4685945f71f660e8b25'))"
commit 382tree a14fe16bb9cb7d949d9eb7570bf56968b209f4a2
parent c3640f09011d969ac85753c8f0114ce9b9c86603
author Felipe Contreras <felipe.contreras@gmail.com> 1352767480 +0100
committer Felipe Contreras <felipe.contreras@gmail.com> 1354064281 +0100
remote-bzr: detect local repositories
So we don't create a clone unnecessarily.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Yes, that's what I'm telling you.
--
Felipe Contreras
^ permalink raw reply
* RE: Millisecond precision in timestamps?
From: Jason Pyeron @ 2012-11-28 1:29 UTC (permalink / raw)
To: 'git'
In-Reply-To: <20121128011750.GA23498@sigill.intra.peff.net>
> -----Original Message-----
> From: Jeff King
> Sent: Tuesday, November 27, 2012 20:18
>
> On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:
>
> > On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
> > <felipe.contreras@gmail.com> wrote:
> > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond
> <esr@thyrsus.com> wrote:
> > >> Shawn Pearce <spearce@spearce.org>:
> > >>> Well... if we added a fractional seconds to a commit, older
> > >>> versions of Git will scream loudly and refuse to work
> with the new
> > >>> commit. That would create a fork of Git.
> > >>
> > >> So much for that idea, I guess.
> > >>
> > >> Unless..I don't know how git's database representations
> work. Are
> > >> they version-stamped in any way? If so, some slightly painful
> > >> hackery would get around that problem.
> > >
> > > % git cat-file -p HEAD
> > >
> > > You'll see exactly how git stores commits. Changing anything in
> > > there must be done carefully.
> >
> > Apparently there is no room to change in these fields
> without breaking
> > compatibility with all current versions of Git. So its not
> just done
> > carefully... its deciding to make Git 2.0 that is not
> compatible with
> > any Git 1.x release.
>
> 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.
Suggestion add a ms offset field. Ex:
jpyeron@black /projects/git/git
$ git cat-file -p HEAD
tree 1e24acfbfcc05aa57e8cb2cfe3ffe01cb100961d
parent e98fa647aa5673cc95b6e9be1fdc13c0afa2cb37
author Junio C Hamano <gitster@pobox.com> 1350495361 -0700
committer Junio C Hamano <gitster@pobox.com> 1350495402 -0700
mstimestamps author 0 committer 1234
Git 1.7.12.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> But I really wonder if anybody actually cares about adding
> sub-second timestamp support, or if it is merely "because SVN has it".
Not because subversion has it but because date != git(precisedate) and some
automation using git in a larger enterprise workflow may assume that date
1354065991.1234 going in should be the same when queried.
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-28 1:22 UTC (permalink / raw)
To: Jeff King; +Cc: Magnus Bäck, Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <20121128005128.GB23224@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 1:51 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras 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.
>
> Try:
>
> git log --grep='portab' -- '*.sh'
% git log --oneline --grep='portab' --since='2 years ago' --no-merges -- '*.sh'
6eafa6d submodules: don't stumble over symbolic links when cloning recursively
Somebody mentioned 'portable', but no problem was hit.
2718781 t9400: fix gnuism in grep
It's a test, and nobody was hit by any problem.
0dbe659 t5704: fix nonportable sed/grep usages
Apparently there was an issue, but this is a test.
93d5e0c t7810: avoid unportable use of "echo"
A problem, but in tests.
482ce70 tests: avoid nonportable {foo,bar} glob
Again, tests.
77e5726 t0050: fix printf format strings for portability
Tests.
So, this search didn't throw a single issue that affected users in two
years. Moving git sub-commands to python wouldn't change a thing.
Maybe shell wasn't the right language for the test system, but I don't
see anybody proposing it to be changed.
> Not all of the hits are shell portability fixes, but most of them are,
> and they are all in response to real, reported issues. The usual
> culprits are Solaris, BSD (including OS X), and the occasional GNUism.
> And that is only the ones that we fixed in response to bug reports for
> commits in the wild. Many more have been caught in review before needing
> a separate patch (grepping the list archive for 'portable' and '\.sh'
> yields 1800 messages).
>
> So dealing with shell portability is definitely something we do, and it
> is a minor pain.
First you have to separate the issues with the test system, because
that's not going to be changed. And then you have to separate the
*potential* issues and the *real* ones. You can spend all your time
doing "shell portability", but does that mean that you actually have a
problem? Maybe if you hadn't done anything, nobody would have noticed
there was a problem.
Sure, you will argue that we don't see the *real* issues, because they
were fixed preemptively, but the fact of the matter is that we will
never know. All we know is the reality we can observe, and the reality
is that we hit very few *real* issues outside the test system (feel
free to provide evidence to the contrary).
> But like you, I think we have been getting along reasonably well with
> shell scripts (and where it is not powerful enough, writing C). No
> solution is going to be free of portability issues (whether because of
> differing versions, because the tool is uncommon on certain platforms,
> or whatever). And because git-core's official API is shell-executable
> commands, any other language you write ends up looking a lot like shell
> anyway.
Agreed.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Jeff King @ 2012-11-28 1:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Felipe Contreras, Eric Raymond, Junio C Hamano, git
In-Reply-To: <CAJo=hJuskvYaNTtCcTSqvU8YwEU=HwRpb_sqW-BSxfSr7xE57A@mail.gmail.com>
On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:
> On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> >> Shawn Pearce <spearce@spearce.org>:
> >>> Well... if we added a fractional seconds to a commit, older versions
> >>> of Git will scream loudly and refuse to work with the new commit. That
> >>> would create a fork of Git.
> >>
> >> So much for that idea, I guess.
> >>
> >> Unless..I don't know how git's database representations work. Are they
> >> version-stamped in any way? If so, some slightly painful hackery would
> >> get around that problem.
> >
> > % git cat-file -p HEAD
> >
> > You'll see exactly how git stores commits. Changing anything in there
> > must be done carefully.
>
> Apparently there is no room to change in these fields without breaking
> compatibility with all current versions of Git. So its not just done
> carefully... its deciding to make Git 2.0 that is not compatible with
> any Git 1.x release.
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".
-Peff
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 1:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <CAMP44s3hpuxbo7mfKAD2trOkezPrV3nKYpNAzXOs3sQym102LQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> % git cat-file -p HEAD
>
> You'll see exactly how git stores commits. Changing anything in there
> must be done carefully.
Oh, I've seen *that* before. Are you telling me the database
representation is actually textual?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Shawn Pearce @ 2012-11-28 1:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Eric Raymond, Junio C Hamano, git
In-Reply-To: <CAMP44s3hpuxbo7mfKAD2trOkezPrV3nKYpNAzXOs3sQym102LQ@mail.gmail.com>
On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Shawn Pearce <spearce@spearce.org>:
>>> Well... if we added a fractional seconds to a commit, older versions
>>> of Git will scream loudly and refuse to work with the new commit. That
>>> would create a fork of Git.
>>
>> So much for that idea, I guess.
>>
>> Unless..I don't know how git's database representations work. Are they
>> version-stamped in any way? If so, some slightly painful hackery would
>> get around that problem.
>
> % git cat-file -p HEAD
>
> You'll see exactly how git stores commits. Changing anything in there
> must be done carefully.
Apparently there is no room to change in these fields without breaking
compatibility with all current versions of Git. So its not just done
carefully... its deciding to make Git 2.0 that is not compatible with
any Git 1.x release.
^ permalink raw reply
* [PATCH 3/4] remote-bzr: add support for older versions of bzr
From: Felipe Contreras @ 2012-11-28 1:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1354064495-23171-1-git-send-email-felipe.contreras@gmail.com>
At least as old as 2.0.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-bzr | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index f8919f4..6cdfac6 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -17,7 +17,8 @@
import sys
import bzrlib
-bzrlib.initialize()
+if hasattr(bzrlib, "initialize"):
+ bzrlib.initialize()
import bzrlib.plugin
bzrlib.plugin.load_plugins()
@@ -553,7 +554,7 @@ def parse_commit(parser):
repo.lock_write()
try:
- builder = repo.get_commit_builder(parents, None, date, tz, committer, props, revid, False)
+ builder = repo.get_commit_builder(parents, None, date, tz, committer, props, revid)
try:
list(builder.record_iter_changes(mtree, mtree.last_revision(), changes))
builder.finish_inventory()
@@ -612,7 +613,10 @@ def do_export(parser):
if ref == 'refs/heads/master':
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)
+ if hasattr(peer, "import_last_revision_info_and_tags"):
+ peer.import_last_revision_info_and_tags(repo, revno, revid)
+ else:
+ peer.import_last_revision_info(repo.repository, revno, revid)
wt = peer.bzrdir.open_workingtree()
wt.update()
print "ok %s" % ref
@@ -646,12 +650,12 @@ def get_repo(url, alias):
global dirname, peer
clone_path = os.path.join(dirname, 'clone')
- origin = bzrlib.controldir.ControlDir.open(url)
+ origin = bzrlib.bzrdir.BzrDir.open(url)
remote_branch = origin.open_branch()
if os.path.exists(clone_path):
# pull
- d = bzrlib.controldir.ControlDir.open(clone_path)
+ d = bzrlib.bzrdir.BzrDir.open(clone_path)
branch = d.open_branch()
result = branch.pull(remote_branch, [], None, False)
else:
--
1.8.0
^ permalink raw reply related
* [PATCH 4/4] remote-bzr: detect local repositories
From: Felipe Contreras @ 2012-11-28 1:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1354064495-23171-1-git-send-email-felipe.contreras@gmail.com>
So we don't create a clone unnecessarily.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-bzr | 48 ++++++++++++++++++++---------------
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index 6cdfac6..c5822e4 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -24,6 +24,7 @@ import bzrlib.plugin
bzrlib.plugin.load_plugins()
import bzrlib.generate_ids
+import bzrlib.transport
import sys
import os
@@ -613,11 +614,14 @@ def do_export(parser):
if ref == 'refs/heads/master':
repo.generate_revision_history(revid, marks.get_tip('master'))
revno, revid = repo.last_revision_info()
- if hasattr(peer, "import_last_revision_info_and_tags"):
- peer.import_last_revision_info_and_tags(repo, revno, revid)
+ if peer:
+ if hasattr(peer, "import_last_revision_info_and_tags"):
+ peer.import_last_revision_info_and_tags(repo, revno, revid)
+ else:
+ peer.import_last_revision_info(repo.repository, revno, revid)
+ wt = peer.bzrdir.open_workingtree()
else:
- peer.import_last_revision_info(repo.repository, revno, revid)
- wt = peer.bzrdir.open_workingtree()
+ wt = repo.bzrdir.open_workingtree()
wt.update()
print "ok %s" % ref
print
@@ -649,24 +653,28 @@ def do_list(parser):
def get_repo(url, alias):
global dirname, peer
- clone_path = os.path.join(dirname, 'clone')
origin = bzrlib.bzrdir.BzrDir.open(url)
- remote_branch = origin.open_branch()
-
- if os.path.exists(clone_path):
- # pull
- d = bzrlib.bzrdir.BzrDir.open(clone_path)
- branch = d.open_branch()
- result = branch.pull(remote_branch, [], None, False)
+ branch = origin.open_branch()
+
+ if not isinstance(origin.transport, bzrlib.transport.local.LocalTransport):
+ clone_path = os.path.join(dirname, 'clone')
+ remote_branch = branch
+ if os.path.exists(clone_path):
+ # pull
+ d = bzrlib.bzrdir.BzrDir.open(clone_path)
+ branch = d.open_branch()
+ result = branch.pull(remote_branch, [], None, False)
+ else:
+ # clone
+ d = origin.sprout(clone_path, None,
+ hardlink=True, create_tree_if_local=False,
+ source_branch=remote_branch)
+ branch = d.open_branch()
+ branch.bind(remote_branch)
+
+ peer = remote_branch
else:
- # clone
- d = origin.sprout(clone_path, None,
- hardlink=True, create_tree_if_local=False,
- source_branch=remote_branch)
- branch = d.open_branch()
- branch.bind(remote_branch)
-
- peer = remote_branch
+ peer = None
return branch
--
1.8.0
^ permalink raw reply related
* [PATCH 2/4] remote-hg: fix for older versions of python
From: Felipe Contreras @ 2012-11-28 1:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1354064495-23171-1-git-send-email-felipe.contreras@gmail.com>
As Amit Bakshi reported, older versions of python (< 2.7) don't have
subprocess.check_output, so let's use subprocess.Popen directly as
suggested.
Suggested-by: Amit Bakshi <ambakshi@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-hg | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
index 62c39db..016cdad 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -56,6 +56,12 @@ def hgmode(mode):
m = { '0100755': 'x', '0120000': 'l' }
return m.get(mode, '')
+def get_config(config):
+ cmd = ['git', 'config', '--get', config]
+ process = subprocess.Popen(cmd, stdout=subprocess.PIPE)
+ output, _ = process.communicate()
+ return output
+
class Marks:
def __init__(self, path):
@@ -727,12 +733,10 @@ def main(args):
hg_git_compat = False
track_branches = True
try:
- cmd = ['git', 'config', '--get', 'remote-hg.hg-git-compat']
- if subprocess.check_output(cmd) == 'true\n':
+ if get_config('remote-hg.hg-git-compat') == 'true\n':
hg_git_compat = True
track_branches = False
- cmd = ['git', 'config', '--get', 'remote-hg.track-branches']
- if subprocess.check_output(cmd) == 'false\n':
+ if get_config('remote-hg.track-branches') == 'false\n':
track_branches = False
except subprocess.CalledProcessError:
pass
--
1.8.0
^ permalink raw reply related
* [PATCH 1/4] remote-hg: fix for files with spaces
From: Felipe Contreras @ 2012-11-28 1:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1354064495-23171-1-git-send-email-felipe.contreras@gmail.com>
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 07754bd..62c39db 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -565,7 +565,7 @@ def parse_commit(parser):
for line in parser:
if parser.check('M'):
- t, m, mark_ref, path = line.split(' ')
+ t, m, mark_ref, path = line.split(' ', 3)
mark = int(mark_ref[1:])
f = { 'mode' : hgmode(m), 'data' : blob_marks[mark] }
elif parser.check('D'):
--
1.8.0
^ permalink raw reply related
* [PATCH 0/4] remote-helpers: general fixes
From: Felipe Contreras @ 2012-11-28 1:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
Hi,
These are general fixes, some for old versions of bazaar, mercurial, and
python. Some of these have already been sent, but here they go alone so they
are not missed.
The bazaar fixes are on top of the series v3 which is still not in 'pu'.
Felipe Contreras (4):
remote-hg: fix for files with spaces
remote-hg: fix for older versions of python
remote-bzr: add support for older versions of bzr
remote-bzr: detect local repositories
contrib/remote-helpers/git-remote-bzr | 54 +++++++++++++++++++++--------------
contrib/remote-helpers/git-remote-hg | 14 +++++----
2 files changed, 42 insertions(+), 26 deletions(-)
--
1.8.0
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Jeff King @ 2012-11-28 0:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Magnus Bäck, Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <CAMP44s10krOPD73dL0Ancie=kussk89jK7V5adR3hw=a73CVWw@mail.gmail.com>
On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras 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.
Try:
git log --grep='portab' -- '*.sh'
Not all of the hits are shell portability fixes, but most of them are,
and they are all in response to real, reported issues. The usual
culprits are Solaris, BSD (including OS X), and the occasional GNUism.
And that is only the ones that we fixed in response to bug reports for
commits in the wild. Many more have been caught in review before needing
a separate patch (grepping the list archive for 'portable' and '\.sh'
yields 1800 messages).
So dealing with shell portability is definitely something we do, and it
is a minor pain.
But like you, I think we have been getting along reasonably well with
shell scripts (and where it is not powerful enough, writing C). No
solution is going to be free of portability issues (whether because of
differing versions, because the tool is uncommon on certain platforms,
or whatever). And because git-core's official API is shell-executable
commands, any other language you write ends up looking a lot like shell
anyway.
If people are really hankering to write sub-commands of git in python
(or whatever), I would suggest checking out libgit2 which has a nice set
of python bindings (and ruby bindings, and C# bindings, and so on). It
doesn't have feature parity with git-core yet, but they have been making
a lot of progress.
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-28 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <7vehjelizc.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
>>>> <felipe.contreras@gmail.com> wrote:
>>>>> This is a re-roll of the previous series to add support to fetch and push
>>>>> special modes, and refactor some related code.
>>>>
>>>> It seems this one got forgotten, I only see v2 in pu.
>>>
>>> Oops; I think that was fell through the cracks during the maintainer
>>> hand-off. As the previous one has already been cooking in 'next'
>>> for a week or so, I would appreciate if you send incremental updates
>>> to fix or enhance what is in there.
>>
>> Yes, that's what I have planned for the next patches, as I already did
>> for remote-hg, but the changes in remote-bzr were a bit bigger.
>
> OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master'
> soonish, but I take the above to mean that fc/remote-hg is ready
> while it is better to wait for updates to fc/remote-bzr before
> merging it.
Please update remote-bzr to series version 3. The rest of the patches
will be on top of that version.
--
Felipe Contreras
^ 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