* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-28 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <7vpq2yihaq.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 3:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> 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.
>>
>> The fixes are affecting some people, that's why I did them. Some were
>> reported here in the mailing list, and some in my github's clone:
>>
>> https://github.com/felipec/git/issues?page=1&state=closed
>
> Are you talking about -hg or -bzr or both?
>
> In any case, I am mostly concerned about *my* next release, whose
> rc0 will be tagged sometime this week or the next week.
>
> People who have been bitten by bugs from *your* tree or versions in
> 'next' do not count. When I said "no existing users", I was talking
> about the end users who need rock solid stable "releases" because
> tagged versions are the only ones they use.
If users you call "fringe" have noticed these compatibility issues,
chances are your "existing users" are going to catch them as well.
Those issues were fixed right away, but I didn't sent them because I
wanted things to settle. I didn't see that v2 landed in next until
now.
> If the code of these topics is still in flux and needs constant
> fixes, probably it is a better idea to cook them longer in 'next',
> skipping the upcoming 1.8.1 release. If we are going to go that
> route, we can drop the v2 fc/remote-bzr and queue v3 when we rewind
> the tip of 'next' after 1.8.1 release (by that time you may have v4
> of the series, but then we can skip v3). Is that more preferrable
> than rushing these topics forward before they are ready for general
> audience?
They are not in constant flux, that's why I haven't send any new
re-rolls since v3, which was on November 11. I've been using v3 for
baseline since them, and the rest of the patches I've sent on top of
that.
In fact, these particular fixes were already sent on November 13 (on top of v3):
http://article.gmane.org/gmane.comp.version-control.git/209558
On November 10 Jeff threatened to to merge v2 to next on the "What's
cooking", and I told him I was about to sent a re-roll, he
acknowledged the same day, and I sent the next one.
Since v3 remote-bzr hasn't been on flux.
Now, what you do is up to you, but I think v3 plus the two patches I
sent on nov 13, and just resent today should be safe. That being said,
I don't use remote-bzr really, and I don't know how many people have
been using it, so I have no idea how ready it really is. If I were you
I would just merge v3 to next, or revert v2 and merge v3, and then
apply the two patches on top. Or if you want, revert v2, wait for
1.8.1, and then merge v3. Either way it's doubtful there will be a v4
(if there are next patches they will be on top of v3, as they have
been for quite some time now), so it's not clear what "existing users"
will gain by that.
I'm confident about remote-hg though.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Felipe Contreras @ 2012-11-28 3:10 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121128025928.GA27772@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 3:59 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 21, 2012 at 04:31:11AM +0100, Felipe Contreras wrote:
>
>> On Wed, Nov 21, 2012 at 1:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> > Here is a list of stalled topics I am having trouble deciding what
>> > to do (the default is to dismiss them around feature freeze).
>> >
>> > * fc/fast-export-fixes (2012-11-08) 14 commits
>> >
>> > Renaming of remote-testgit feels to be a mistake. It probably
>> > should keep its source in remote-testgit.bash and generate it,
>>
>> Why generate it? There's nothing to generate. python's source code
>> needs regeneration, bash's code doesn't.
>
> We fix up the #!-lines on all of the existing shell scripts (as well as
> python and perl). Wouldn't we want to do the same for people who have
> bash in an alternate location?
'#!/usr/bin/env bash' should take care of people who have bash in an
alternate location, no?
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Jeff King @ 2012-11-28 3:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <20121128025928.GA27772@sigill.intra.peff.net>
On Tue, Nov 27, 2012 at 09:59:28PM -0500, Jeff King wrote:
> > > Renaming of remote-testgit feels to be a mistake. It probably
> > > should keep its source in remote-testgit.bash and generate it,
> >
> > Why generate it? There's nothing to generate. python's source code
> > needs regeneration, bash's code doesn't.
>
> We fix up the #!-lines on all of the existing shell scripts (as well as
> python and perl). Wouldn't we want to do the same for people who have
> bash in an alternate location?
>
> As the series is now, people with bash in their PATH, but not in
> /bin/bash, will fail t5801 (the prereq to skip the test uses "type", but
> git-remote-testgit hardcodes /bin/bash).
We could improve the test in t5801, but it is nice to let people on such
systems test it, as well. And the infrastructure might be useful if we
ever acquire more bash scripts.
There's a fair bit of boilerplate, but I think this squashable patch
would do it:
diff --git a/.gitignore b/.gitignore
index 46595db..3b636bd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -124,6 +124,7 @@
/git-remote-ftps
/git-remote-fd
/git-remote-ext
+/git-remote-testgit
/git-remote-testsvn
/git-remote-testpy
/git-repack
diff --git a/Makefile b/Makefile
index 68f1ac2..19f6fd2 100644
--- a/Makefile
+++ b/Makefile
@@ -424,6 +424,7 @@ PROGRAM_OBJS =
PROGRAMS =
SCRIPT_PERL =
SCRIPT_PYTHON =
+SCRIPT_BASH =
SCRIPT_SH =
SCRIPT_LIB =
TEST_PROGRAMS_NEED_X =
@@ -473,9 +474,12 @@ SCRIPT_PERL += git-svn.perl
SCRIPT_PYTHON += git-remote-testpy.py
SCRIPT_PYTHON += git-p4.py
+SCRIPT_BASH += git-remote-testgit.bash
+
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+ $(patsubst %.bash,%,$(SCRIPT_BASH)) \
git-instaweb
ETAGS_TARGET = TAGS
@@ -571,9 +575,13 @@ endif
ifndef PYTHON_PATH
PYTHON_PATH = /usr/bin/python
endif
+ifndef BASH_PATH
+ BASH_PATH = /bin/bash
+endif
export PERL_PATH
export PYTHON_PATH
+export BASH_PATH
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
@@ -1931,6 +1939,10 @@ ifeq ($(PYTHON_PATH),)
NO_PYTHON=NoThanks
endif
+ifeq ($(BASH_PATH),)
+NO_BASH=NoThanks
+endif
+
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
QUIET_SUBDIR1 =
@@ -2006,6 +2018,7 @@ gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
+BASH_PATH_SQ = $(subst ','\'',$(BASH_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
DIFF_SQ = $(subst ','\'',$(DIFF))
@@ -2267,6 +2280,15 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
mv $@+ $@
endif # NO_PYTHON
+ifndef NO_BASH
+$(patsubst %.bash,%,$(SCRIPT_BASH)):
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1s|#!.*/bash|#!$(BASH_PATH_SQ)|' \
+ $@.bash >$@+ && \
+ chmod +x $@+ && \
+ mv $@+ $@
+endif
+
configure: configure.ac GIT-VERSION-FILE
$(QUIET_GEN)$(RM) $@ $<+ && \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
@@ -2599,6 +2621,7 @@ GIT-BUILD-OPTIONS: FORCE
@echo USE_LIBPCRE=\''$(subst ','\'',$(subst ','\'',$(USE_LIBPCRE)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
@echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@
+ @echo NO_BASH=\''$(subst ','\'',$(subst ','\'',$(NO_BASH)))'\' >>$@
@echo NO_UNIX_SOCKETS=\''$(subst ','\'',$(subst ','\'',$(NO_UNIX_SOCKETS)))'\' >>$@
ifdef GIT_TEST_OPTS
@echo GIT_TEST_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_TEST_OPTS)))'\' >>$@
diff --git a/git-remote-testgit b/git-remote-testgit.bash
similarity index 100%
rename from git-remote-testgit
rename to git-remote-testgit.bash
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 456303b..d6ebc5e 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-remote-helpers.sh
@@ -7,7 +7,7 @@ test_description='Test remote-helper import and export commands'
. ./test-lib.sh
-if ! type "${BASH-bash}" >/dev/null 2>&1; then
+if ! test_have_prereq BASH; then
skip_all='skipping remote-testgit tests, bash not available'
test_done
fi
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 489bc80..5300fa9 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -675,6 +675,7 @@ esac
( COLUMNS=1 && test $COLUMNS = 1 ) && test_set_prereq COLUMNS_CAN_BE_1
test -z "$NO_PERL" && test_set_prereq PERL
test -z "$NO_PYTHON" && test_set_prereq PYTHON
+test -z "$NO_BASH" && test_set_prereq BASH
test -n "$USE_LIBPCRE" && test_set_prereq LIBPCRE
test -z "$NO_GETTEXT" && test_set_prereq GETTEXT
^ permalink raw reply related
* Re: Topics currently in the Stalled category
From: Jeff King @ 2012-11-28 3:12 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <CAMP44s3F4MPm-kLAW67rZG8oZg76CGS32h44LnK05UT11TOnSA@mail.gmail.com>
On Wed, Nov 28, 2012 at 04:10:07AM +0100, Felipe Contreras wrote:
> >> Why generate it? There's nothing to generate. python's source code
> >> needs regeneration, bash's code doesn't.
> >
> > We fix up the #!-lines on all of the existing shell scripts (as well as
> > python and perl). Wouldn't we want to do the same for people who have
> > bash in an alternate location?
>
> '#!/usr/bin/env bash' should take care of people who have bash in an
> alternate location, no?
If that is where there env is. I do not recall offhand if that is a
problem for anyone. Still, I don't think it is that big a deal to treat
it like we do other scripts, and provide the usual boilerplate (which
also gets us NO_BASH if you have an old or broken bash and want to skip
the tests). I just sent a patch.
-Peff
^ permalink raw reply
* git config key bug or by design?
From: Peter van der Does @ 2012-11-28 3:14 UTC (permalink / raw)
To: git
I noticed today I can't create a key starting with a number.
The source code[1] confirms this, but is this a bug or is it by design?
[1]: https://github.com/git/git/blob/master/config.c#L1265
--
Peter van der Does
GPG key: CB317D6E
IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Felipe Contreras @ 2012-11-28 3:15 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121128031118.GB27772@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 27, 2012 at 09:59:28PM -0500, Jeff King wrote:
>
>> > > Renaming of remote-testgit feels to be a mistake. It probably
>> > > should keep its source in remote-testgit.bash and generate it,
>> >
>> > Why generate it? There's nothing to generate. python's source code
>> > needs regeneration, bash's code doesn't.
>>
>> We fix up the #!-lines on all of the existing shell scripts (as well as
>> python and perl). Wouldn't we want to do the same for people who have
>> bash in an alternate location?
>>
>> As the series is now, people with bash in their PATH, but not in
>> /bin/bash, will fail t5801 (the prereq to skip the test uses "type", but
>> git-remote-testgit hardcodes /bin/bash).
>
> We could improve the test in t5801, but it is nice to let people on such
> systems test it, as well. And the infrastructure might be useful if we
> ever acquire more bash scripts.
>
> There's a fair bit of boilerplate, but I think this squashable patch
> would do it:
Yeah, but I wonder what's the point of installing this script, it's
mostly for testing and reference, and to add a whole category for that
seems like overkill.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Jeff King @ 2012-11-28 3:22 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <CAMP44s3ZtCNsedJtsHDJx5d4Myjbbp+D6yT-rO-CmKOTtt91VQ@mail.gmail.com>
On Wed, Nov 28, 2012 at 04:15:12AM +0100, Felipe Contreras wrote:
> > We could improve the test in t5801, but it is nice to let people on such
> > systems test it, as well. And the infrastructure might be useful if we
> > ever acquire more bash scripts.
> >
> > There's a fair bit of boilerplate, but I think this squashable patch
> > would do it:
>
> Yeah, but I wonder what's the point of installing this script, it's
> mostly for testing and reference, and to add a whole category for that
> seems like overkill.
There's no point in installing it; I just didn't make the effort to
avoid doing so (note that testpy and testsvn are also installed, which
are in the same boat; it might make sense to split them all out like we
do for $TEST_PROGRAMS).
I agree it's an annoying amount of boilerplate, but it seems simpler
cognitively to me for it to behave as the other SCRIPT_* builds than to
do something simple but inconsistent.
I do not care enough to argue about it. We need to do something to fix
the impending test breakage on systems like Solaris. I have posted the
patch to handle BASH_PATH, so do what you want.
-Peff
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 3:23 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Felipe Contreras, Junio C Hamano, git
In-Reply-To: <20121128011750.GA23498@sigill.intra.peff.net>
Jeff King <peff@peff.net>:
> But I really wonder if anybody actually cares about adding sub-second
> timestamp support, or if it is merely "because SVN has it".
There's actually one possible other reason to care. 1-second granularity
isn't quite fine enough to guarantee that a (committer, timestamp)
pair is a unique key. 1 microsecond granularity would be.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Christian Couder @ 2012-11-28 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
contrib/svn-fe/svnrdump_sim.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/svn-fe/svnrdump_sim.py b/contrib/svn-fe/svnrdump_sim.py
index 1cfac4a..d219180 100755
--- a/contrib/svn-fe/svnrdump_sim.py
+++ b/contrib/svn-fe/svnrdump_sim.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
"""
Simulates svnrdump by replaying an existing dump from a file, taking care
of the specified revision range.
--
1.7.11.rc3.17.g55b3f8c
^ permalink raw reply related
* Re: Millisecond precision in timestamps?
From: Jeff King @ 2012-11-28 3:30 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Shawn Pearce, Felipe Contreras, Junio C Hamano, git
In-Reply-To: <20121128032337.GB1669@thyrsus.com>
On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:
> Jeff King <peff@peff.net>:
> > But I really wonder if anybody actually cares about adding sub-second
> > timestamp support, or if it is merely "because SVN has it".
>
> There's actually one possible other reason to care. 1-second granularity
> isn't quite fine enough to guarantee that a (committer, timestamp)
> pair is a unique key. 1 microsecond granularity would be.
You can't guarantee that such a pair is unique, anyway, due to clock
skew.
A much more compelling argument to me would be that you are doing some
bidirectional magic between git and svn, and you want to make make sure
that an svn->git->svn translation will result in the exact same bytes.
Then the argument is still "because SVN has it", but at least it is "and
we interoperate with it" and not simply chasing a cool but useless
feature.
-Peff
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Felipe Contreras @ 2012-11-28 3:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121128032245.GD27772@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 4:22 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 28, 2012 at 04:15:12AM +0100, Felipe Contreras wrote:
>
>> > We could improve the test in t5801, but it is nice to let people on such
>> > systems test it, as well. And the infrastructure might be useful if we
>> > ever acquire more bash scripts.
>> >
>> > There's a fair bit of boilerplate, but I think this squashable patch
>> > would do it:
>>
>> Yeah, but I wonder what's the point of installing this script, it's
>> mostly for testing and reference, and to add a whole category for that
>> seems like overkill.
>
> There's no point in installing it; I just didn't make the effort to
> avoid doing so (note that testpy and testsvn are also installed, which
> are in the same boat; it might make sense to split them all out like we
> do for $TEST_PROGRAMS).
>
> I agree it's an annoying amount of boilerplate, but it seems simpler
> cognitively to me for it to behave as the other SCRIPT_* builds than to
> do something simple but inconsistent.
>
> I do not care enough to argue about it. We need to do something to fix
> the impending test breakage on systems like Solaris. I have posted the
> patch to handle BASH_PATH, so do what you want.
I'm not objecting to the change, I'm simply wondering.
Personally I think switching to '/usr/bin/env bash' should be enough
for now. Doing a grep on my git installation throws this:
% grep '/usr/bin/env' -r /opt/git
/opt/git/lib/python2.7/site-packages/git_remote_helpers/git/git.py:#!/usr/bin/env
python
/opt/git/lib/python2.7/site-packages/git_remote_helpers/__init__.py:#!/usr/bin/env
python
/opt/git/lib/python2.7/site-packages/git_remote_helpers/util.py:#!/usr/bin/env
python
/opt/git/libexec/git-core/git-instaweb:#!/usr/bin/env ruby
So it's doubtful a lack of /usr/bin/env would cause any more breakages
than it already does for test-git.
And this just landed on 'pu', I don't think there's anything big
impending. If the /usr/bin/env solution turned out to be not enough
for some reason, we can deal with it then. That's my opinion.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git config key bug or by design?
From: Jeff King @ 2012-11-28 3:34 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20121127221446.7f2fbf71@Indy>
On Tue, Nov 27, 2012 at 10:14:46PM -0500, Peter van der Does wrote:
> I noticed today I can't create a key starting with a number.
>
> The source code[1] confirms this, but is this a bug or is it by design?
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").
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Eric S. Raymond @ 2012-11-28 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git
In-Reply-To: <7vobiijxol.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> 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?
Er, it depends on what you consider "usable".
Unicode integration turned out to have a lot messier edge cases than
anyone understood going in. First-cut support was in 1.6, but I'd say
it still has some pretty sharp edges *today*. Which is why 3.0 has
gone all-Unicode-all-the-time. The problems mostly come from having
two different notions of "string" that don't really mix well.
Me, I still avoid the hell out of Unicode in Python. And occasionally
fund myself cursing a library maintainer who didn't.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-28 3:44 UTC (permalink / raw)
To: Jeff King; +Cc: Eric S. Raymond, Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20121128033009.GA3931@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 4:30 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:
>
>> Jeff King <peff@peff.net>:
>> > But I really wonder if anybody actually cares about adding sub-second
>> > timestamp support, or if it is merely "because SVN has it".
>>
>> There's actually one possible other reason to care. 1-second granularity
>> isn't quite fine enough to guarantee that a (committer, timestamp)
>> pair is a unique key. 1 microsecond granularity would be.
>
> You can't guarantee that such a pair is unique, anyway, due to clock
> skew.
>
> A much more compelling argument to me would be that you are doing some
> bidirectional magic between git and svn, and you want to make make sure
> that an svn->git->svn translation will result in the exact same bytes.
> Then the argument is still "because SVN has it", but at least it is "and
> we interoperate with it" and not simply chasing a cool but useless
> feature.
But the same can be said of mercurial and bzr. This can be solved
attaching some external SCM information in notes, and somehow make
fast-export throw that info along with the commit.
For now the solution has been to append the extra information into the
commit message, which is ugly and hacky, but it works.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 3:47 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Felipe Contreras, Junio C Hamano, git
In-Reply-To: <20121128033009.GA3931@sigill.intra.peff.net>
Jeff King <peff@peff.net>:
> A much more compelling argument to me would be that you are doing some
> bidirectional magic between git and svn, and you want to make make sure
> that an svn->git->svn translation will result in the exact same bytes.
> Then the argument is still "because SVN has it", but at least it is "and
> we interoperate with it" and not simply chasing a cool but useless
> feature.
Er, well, that *is* in fact the exact reason I want it.
I didn't put it exactly that way because I didn't expect anyone here
to particularly care about round-tripping like that. But remember
that I do a lot of stuff with repo surgery and conversion tools.
As a matter of fact (and this list is the first to hear about it)
I'm working on code right now that massages a git import stream
into a Subversion dumpfile. Soon, unless I hit a blocker I'm
not expecting, I'll ship it.
Yes, there will be serious limitations and unavoidable metadata loss.
But in every case *except timestamps* that loss is Subversion's fault
for having a weak ontology. Timestamps are the one place git doesn't
hold up its end.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* git config key bug or by design?
From: Peter van der Does @ 2012-11-28 2:57 UTC (permalink / raw)
To: git
I noticed today I can't create a key starting with a number.
The source code[1] confirms this, but is this a bug or is it by design?
[1]: https://github.com/git/git/blob/master/config.c#L1265
--
Peter van der Does
GPG key: CB317D6E
IRC: Ganseki on irc.freenode.net
Twitter: @petervanderdoes
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Jeff King @ 2012-11-28 4:07 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Shawn Pearce, Felipe Contreras, Junio C Hamano, git
In-Reply-To: <20121128034700.GD1669@thyrsus.com>
On Tue, Nov 27, 2012 at 10:47:00PM -0500, Eric S. Raymond wrote:
> Jeff King <peff@peff.net>:
> > A much more compelling argument to me would be that you are doing some
> > bidirectional magic between git and svn, and you want to make make sure
> > that an svn->git->svn translation will result in the exact same bytes.
> > Then the argument is still "because SVN has it", but at least it is "and
> > we interoperate with it" and not simply chasing a cool but useless
> > feature.
>
> Er, well, that *is* in fact the exact reason I want it.
>
> I didn't put it exactly that way because I didn't expect anyone here
> to particularly care about round-tripping like that. But remember
> that I do a lot of stuff with repo surgery and conversion tools.
If that's what we really care about, then that opens up the
possibilities for how we store the data. An extension header in the
object might be convenient, but it opens up a lot of questions about
what git will do with such a header (e.g., would it be part of git-log
output?).
Felipe suggested using git-notes to add the metadata, which I think is a
reasonable first step. The git side of the code is already written, and
the concept is nicely modularized away from the core of git. Nobody has
to care about it but your importer, and anybody who wants to query it[1]
can do so by requesting the note.
-Peff
[1] And you do not have to limit yourself to timestamps, if there is
other metadata about each commit you end up wanting to store for a
clean bi-directional conversion.
^ permalink raw reply
* Re: [PATCH] fsck: warn about '.' and '..' in trees
From: Nguyen Thai Ngoc Duy @ 2012-11-28 4:22 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121128022736.GA3739@sigill.intra.peff.net>
On Wed, Nov 28, 2012 at 9:27 AM, Jeff King <peff@peff.net> wrote:
> A tree with meta-paths like '.' or '..' does not work well
> with git; the index will refuse to load it or check it out
> to the filesystem (and even if we did not have that safety,
> it would look like we were overwriting an untracked
> directory). For the same reason, it is difficult to create
> such a tree with regular git.
>
> Let's warn about these dubious entries during fsck, just in
> case somebody has created a bogus tree (and this also lets
> us prevent them from propagating when transfer.fsckObjects
> is set).
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I don't think this is happening in the wild, but I did see somebody
> playing around with libgit2 make such a tree (and it is easy to do with
> git-mktree, of course).
>
> Technically one could use git with such a tree as long as you never ever
> checked out the result, but I think it is sufficiently crazy that we
> should probably detect it, just in case.
Can we declare "." and ".." illegal? There's no room for extension in
tree objects and I'm thinking of using maybe "." entry as an extension
indicator. Not sure if it works, old gits may attempt to checkout "."
entries and fail...
--
Duy
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 4:25 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Felipe Contreras, Junio C Hamano, git
In-Reply-To: <20121128040739.GA4115@sigill.intra.peff.net>
Jeff King <peff@peff.net>:
> Felipe suggested using git-notes to add the metadata, which I think is a
> reasonable first step. The git side of the code is already written, and
> the concept is nicely modularized away from the core of git. Nobody has
> to care about it but your importer, and anybody who wants to query it[1]
> can do so by requesting the note.
>
> -Peff
>
> [1] And you do not have to limit yourself to timestamps, if there is
> other metadata about each commit you end up wanting to store for a
> clean bi-directional conversion.
I have actually wanted something like this quite badly. Not so much
for timestamps (though that would be nice), but it would be useful if
each commit could carry a fossil-ID attribute that points at the
Subversion commit it was derived from.
I've tried to make notes work for this, but couldn't beat it into
doing what I was after. Shawn, is there a way that the import stream
syntax can declare a note with in-line data attached to the commit where
it's declared?
I tried just using the mark of the current commit, but git throws an error
because it thinks that mark is not yet declared when the note fileop
is parsed.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] fsck: warn about '.' and '..' in trees
From: Jeff King @ 2012-11-28 4:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8DQCo9UzDadHJ2dF-eK20tFDTVn_ScwV+T7z-qLDJMytw@mail.gmail.com>
On Wed, Nov 28, 2012 at 11:22:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> > I don't think this is happening in the wild, but I did see somebody
> > playing around with libgit2 make such a tree (and it is easy to do with
> > git-mktree, of course).
> >
> > Technically one could use git with such a tree as long as you never ever
> > checked out the result, but I think it is sufficiently crazy that we
> > should probably detect it, just in case.
>
> Can we declare "." and ".." illegal? There's no room for extension in
> tree objects and I'm thinking of using maybe "." entry as an extension
> indicator. Not sure if it works, old gits may attempt to checkout "."
> entries and fail...
Yeah, current git fails pretty hard. Try this:
check() {
git init -q "$1" &&
(cd "$1" &&
blob=$(echo foo | git hash-object -w --stdin) &&
tree=$(printf '100644 blob %s\t%s' $blob "$2" | git mktree) &&
commit=$(echo foo | git commit-tree $tree) &&
git update-ref HEAD $commit &&
git clone -q . clone
)
}
$ check dot .
error: Invalid path '.'
$ check dotdot ..
error: Updating '..' would lose untracked files in it
$ check dotgit .git
error: Updating '.git' would lose untracked files in it
Interesting that we detect the first one while reading into the cache,
but apparently try much harder to checkout on the latter two. Not sure I
want to try "git checkout -f". :)
-Peff
^ permalink raw reply
* Re: [PATCH] fsck: warn about '.' and '..' in trees
From: Jeff King @ 2012-11-28 4:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <20121128043215.GA5362@sigill.intra.peff.net>
On Tue, Nov 27, 2012 at 11:32:16PM -0500, Jeff King wrote:
> $ check dot .
> error: Invalid path '.'
>
> $ check dotdot ..
> error: Updating '..' would lose untracked files in it
>
> $ check dotgit .git
> error: Updating '.git' would lose untracked files in it
>
> Interesting that we detect the first one while reading into the cache,
> but apparently try much harder to checkout on the latter two. Not sure I
> want to try "git checkout -f". :)
Actually, I take it back. The "untracked files" check comes _first_, and
if you do "-f", we end up in the verify_path check when trying to pull
the tree into the index. So I think the way git handles it makes sense.
-Peff
^ permalink raw reply
* Re: [PATCH v2 2/3] Allow for MERGE_MODE to specify more then one mode
From: Kacper Kornet @ 2012-11-28 4:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Aaron Schrab
In-Reply-To: <7v7gp6jwsn.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 06:17:28PM -0800, Junio C Hamano wrote:
> Kacper Kornet <draenog@pld-linux.org> writes:
> > Presently only one merge mode exists: non-fast-forward. But in future
> > the second one (transpose-parents) will be added, so the need to read
> > all lines of MERGE_MODE.
> > Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
> > ---
> > builtin/commit.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 273332f..ee0e884 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> > unsigned char sha1[20];
> > struct ref_lock *ref_lock;
> > struct commit_list *parents = NULL, **pptr = &parents;
> > - struct stat statbuf;
> > int allow_fast_forward = 1;
> > struct commit *current_head = NULL;
> > struct commit_extra_header *extra = NULL;
> > @@ -1481,11 +1480,12 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> > if (!reflog_msg)
> > reflog_msg = "commit (merge)";
> > - if (!stat(git_path("MERGE_MODE"), &statbuf)) {
> > - if (strbuf_read_file(&sb, git_path("MERGE_MODE"), 0) < 0)
> > - die_errno(_("could not read MERGE_MODE"));
> > - if (!strcmp(sb.buf, "no-ff"))
> > - allow_fast_forward = 0;
> > + if((fp = fopen(git_path("MERGE_MODE"), "r"))) {
> Style: s/if((fp/if ((fp/;
> > + while (strbuf_getline(&m, fp, '\n') != EOF) {
> > + if (!strcmp(m.buf, "no-ff"))
> > + allow_fast_forward = 0;
> > + }
> > + fclose(fp);
> This needs a bit more careful planning for interacting with other
> people's programs, I suspect.
> Your updated builtin/merge.c may write an extra LF after no-ff to
> make this parser to grok it, but it is entirely plausible that
> people have their own Porcelain that writes "no-ff" without LF
> (because that is what we read from this file, and I suspect the
> current code would ignore "no-ff\n").
> At least strbuf_getline() would give us "no-ff" when either "no-ff"
> or "no-ff\n" terminates the file, so updated code would be able to
> grok what other people would write, but if other people want to read
> MERGE_MODE we write, at least we shouldn't break them when we only
> write no-ff in it (once you start writing "reverse-parents" in the
> file, they will be broken anyway, as they do not currently expect
> such token in this file).
At this stage in the patch series the format of MERGE_MODE is not
changed - "no-ff" is printed without "\n". What should be changed is the
next patch. Relevant part should read:
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..5ceb291 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -993,6 +999,8 @@ static void write_merge_state(struct commit_list *remoteheads)
if (fd < 0)
die_errno(_("Could not open '%s' for writing"), filename);
strbuf_reset(&buf);
+ if (reversed_order)
+ strbuf_addf(&buf, "reversed-order\n");
if (!allow_fast_forward)
strbuf_addf(&buf, "no-ff");
if (write_in_full(fd, buf.buf, buf.len) != buf.len)
This way when only no-ff is specified all parsers should be happy. If
reversed-order is specified together no-ff the "external" parser
probably would fail. Which in my opinion is a good think at this point,
as it can't correctly interpret MERGE_MODE anyway.
--
Kacper
^ permalink raw reply related
* Re: [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Kacper Kornet @ 2012-11-28 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Aaron Schrab
In-Reply-To: <7vzk22ii7b.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 06:18:00PM -0800, Junio C Hamano wrote:
> Kacper Kornet <draenog@pld-linux.org> writes:
> > +--transpose-parents::
> > + Transpose the parents in the final commit. The change is made
> > + just before the commit so the meaning of 'our' and 'their'
> > + concepts remains the same (i.e. 'our' means current branch before
> > + the merge).
> > +
> How does this interact with Octopus merges?
It moves the original first parent to the last position. And nothing
more. I have forgotten to mention it in the documentation.
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index ee0e884..ab2b844 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> > } else if (whence == FROM_MERGE) {
> > struct strbuf m = STRBUF_INIT;
> > FILE *fp;
> > + int reversed_order=0;
> Style. s/=/ = /;
> > + OPT_BOOLEAN(0, "transpose-parents", &reversed_order, N_("reverse order of parents")
> It smells more like "--reverse-parents" (if you deal only with
> two-head merges), no?
I have changes to --transpose-parents because of the octopus merges.
Although it is not a mathematical transposition in this case, but a cycle
permutation.
--
Kacper
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Joshua Jensen @ 2012-11-28 5:08 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Felipe Contreras, Eric S. Raymond, git
In-Reply-To: <50B1F684.5020805@alum.mit.edu>
----- Original Message -----
From: Michael Haggerty
Date: 11/25/2012 3:44 AM
> * Startup time: Is the time to start the "X" interpreter prohibitive?
> (On my computer, "python -c pass", which starts the Python
> interpreter and does nothing, takes about 24ms.) This overhead would
> be incurred by every command that is not pure C.
FWIW, on Windows 7 running on a Core i7 1.6GHz quad core processor, a
cold run of "python -c pass" after a reboot results in 0.74 seconds.
The second run takes 0.13 seconds.
Because Lua was mentioned in another message of this thread, I'll
provide the following:
* A cold run of 'lua5.1 -e ""' takes 0.4 seconds. The second run takes
0.03 seconds.
* A cold run of LuaJIT takes the same.
-Josh
^ permalink raw reply
* [PATCH] push: cleanup push rules comment
From: Chris Rorvick @ 2012-11-28 5:18 UTC (permalink / raw)
To: git
Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras, Junio C Hamano
In-Reply-To: <7v7gp7nf5e.fsf@alter.siamese.dyndns.org>
---
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.
This patch applies on top of the latest patch series regarding
pushing tags. If will include this in a re-roll of that series if
these changes are deemed a good idea.
Also, I hand-edited the patch so that the changes were not interleaved
to make it much easier to read. Can this be done automatically?
Something like a minimum # of matching lines required between
differences?
Chris
remote.c | 32 +++++++++++++++++---------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/remote.c b/remote.c
index ee0c1e5..3fb1068 100644
--- a/remote.c
+++ b/remote.c
@@ -1319,27 +1319,29 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
continue;
}
- /* This part determines what can overwrite what.
- * The rules are:
- *
- * (0) you can always use --force or +A:B notation to
- * selectively force individual ref pairs.
- *
- * (1) if the old thing does not exist, it is OK.
- *
- * (2) if the destination is under refs/tags/ you are
- * not allowed to overwrite it; tags are expected
- * to be static once created
- *
- * (3) if you do not have the old thing, you are not allowed
- * to overwrite it; you would not know what you are losing
- * otherwise.
- *
- * (4) if old is a commit and new is a descendant of old
- * (implying new is commit-ish), it is OK.
- *
- * (5) regardless of all of the above, removing :B is
- * always allowed.
+ /*
+ * The below logic determines whether an individual
+ * refspec A:B can be pushed. The push will succeed
+ * if any of the following are true:
+ *
+ * (1) the remote reference B does not exist
+ *
+ * (2) the remote reference B is being removed (i.e.
+ * pushing :B where no source is specified)
+ *
+ * (3) the update meets all fast-forwarding criteria:
+ *
+ * (a) the destination is not under refs/tags/
+ * (b) the old is a commit
+ * (c) the new is a descendant of the old
+ *
+ * NOTE: We must actually have the old object in
+ * order to overwrite it in the remote reference,
+ * and that the new object must be commit-ish.
+ * These are implied by (b) and (c) respectively.
+ *
+ * (4) it is forced using the +A:B notation, or by
+ * passing the --force argument
*/
ref->not_forwardable = !is_forwardable(ref);
--
1.8.0.209.gf3828dc
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox