* 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
* Re: [PATCH] configure.ac: fix pthreads detection on Mac OS X
From: Junio C Hamano @ 2012-11-28 6:38 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <1354058931-88873-1-git-send-email-max@quendi.de>
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, 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).
Thanks.
> Chers,
> Max
>
> configure.ac | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index ad215cc..41ac9a5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1021,7 +1021,17 @@ if test -n "$USER_NOPTHREAD"; then
> # -D_REENTRANT' or some such.
> elif test -z "$PTHREAD_CFLAGS"; then
> threads_found=no
> - for opt in -mt -pthread -lpthread; do
> + # Attempt to compile and link some code using pthreads to determine
> + # required linker flags. The order is somewhat important here: We
> + # first try it without any extra flags, to catch systems where
> + # pthreads are part of the C library, then go on testing various other
> + # flags. We do so to avoid false positives. For example, on Mac OS X
> + # pthreads are part of the C library; moreover, the compiler allows us
> + # to add "-mt" to the CFLAGS (although it will do nothing except
> + # trigger a warning about an unused flag). Hence if we checked for
> + # "-mt" before "" we would end up picking it. But unfortunately this
> + # would then trigger compiler warnings on every single file we compile.
> + for opt in "" -mt -pthread -lpthread; do
> old_CFLAGS="$CFLAGS"
> CFLAGS="$opt $CFLAGS"
> AC_MSG_CHECKING([for POSIX Threads with '$opt'])
^ permalink raw reply
* Re: [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Johannes Sixt @ 2012-11-28 6:56 UTC (permalink / raw)
To: Kacper Kornet; +Cc: git, Junio C Hamano, Aaron Schrab
In-Reply-To: <1354057217-65886-4-git-send-email-draenog@pld-linux.org>
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
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.
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Junio C Hamano @ 2012-11-28 7:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <CAMP44s23FfxQG6v+dfRGWHzxpWZ5BSGpAm=8Q8Bmj04tDwmwKw@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> 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.
There seems to be some misunderstanding.
I have never called them "fringe"; they are "early adopters" who are
expected to be capable of "git pull" to pick up fixes from
between-releases trees (or "git am" patches from the list) and
rebuild their Git.
We cannot expect that from the real end users (who do not exist yet,
luckily) who only follow tagged releases. Hitting them with bugs we
need to fix after the release is not "letting them notice and
report", but just "irresponsibly hurting the end users". "Letting
them notice and report" is what "early adopter" population who run
'next' are for. Quality expectations between these two populations
are quite different.
> ... 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. ...
> ... Either way it's doubtful there will be a v4
OK; thanks for clarification. If you are not using it actively, it
probably is a better idea to proceed with more caution, as low rate
of update necessity does not directly relate to maturity of the
tool. I'd feel better to cook it longer in 'next' to recruit early
adopters so that we can hear positive feedbacks (or negative ones
that can result in fixes to whatever is still uncovered, if any).
I hate reverting anything from 'next', but for the above to work
smoothly, it seems to me that reverting the merge of v2 and queuing
v3 plus remainder sounds like the best course.
> I'm confident about remote-hg though.
Meaning unlike remote-bzr, at least you are using it more actively
(or you know people who are), right? I've queued the two patches
(out of four) from you today, so we can merge it to 'master' before
1.8.1-rc0.
Thanks.
^ permalink raw reply
* Re: Operations on unborn branch
From: Junio C Hamano @ 2012-11-28 7:12 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6g2UQyvOWS+nuc6y=wzfFTVJ6G8OK14KOs5DJ3f-n5vOw@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>>
>>> simplify a lot of things (maybe I'm biased because of the things I
>>> have happened to work on?)
>>
>> Yes. Do not waste time on it.
>
> Yes, no way I would waste time on that; I was mostly just curious.
You have to special case the edges whichever way you go. You can
always add such a fixed parent commit whenever you create a new root
commit, but then the codepath that currently relies on the real root
commit not having any parent start needing to notice if the parent
is the fixed fake commit and exclude it from thee history. Or you
can create a new root commit as parent-less like we currently do,
and any history examination do not have to special case "ah, I
thought there is a parent commit, but that turns out to be the fake
one, so I need to ignore it." Creation of a root commit is a one-time
operation in any sane history; if we have to have special cases
somewhere anyway, it is better to have them in these one-time
operation codepaths.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Junio C Hamano @ 2012-11-28 7:29 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Felipe Contreras, Eric Raymond, git
In-Reply-To: <20121128011750.GA23498@sigill.intra.peff.net>
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.
^ permalink raw reply
* Re: [PATCH v2 2/3] Allow for MERGE_MODE to specify more then one mode
From: Junio C Hamano @ 2012-11-28 7:30 UTC (permalink / raw)
To: Kacper Kornet; +Cc: git, Aaron Schrab
In-Reply-To: <20121128043608.GA17470@camk.edu.pl>
Kacper Kornet <draenog@pld-linux.org> writes:
> 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.
Amen to that.
^ permalink raw reply
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Junio C Hamano @ 2012-11-28 7:36 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20121128025734.21231.47468.chriscool@tuxfamily.org>
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).
>
> 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.
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-28 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <7vhaoai533.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> 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.
>
> There seems to be some misunderstanding.
>
> I have never called them "fringe"; they are "early adopters" who are
> expected to be capable of "git pull" to pick up fixes from
> between-releases trees (or "git am" patches from the list) and
> rebuild their Git.
>
> We cannot expect that from the real end users (who do not exist yet,
> luckily) who only follow tagged releases. Hitting them with bugs we
> need to fix after the release is not "letting them notice and
> report", but just "irresponsibly hurting the end users". "Letting
> them notice and report" is what "early adopter" population who run
> 'next' are for. Quality expectations between these two populations
> are quite different.
Perhaps, but I still don't agree with the statement that the people
bitten by those bugs don't count. If those bugs are not fixed, they
will bite the "normal" population.
>> ... 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. ...
>> ... Either way it's doubtful there will be a v4
>
> OK; thanks for clarification. If you are not using it actively, it
> probably is a better idea to proceed with more caution, as low rate
> of update necessity does not directly relate to maturity of the
> tool. I'd feel better to cook it longer in 'next' to recruit early
> adopters so that we can hear positive feedbacks (or negative ones
> that can result in fixes to whatever is still uncovered, if any).
Perhaps, on the other hand it's not like any of their existing
functionality will break. Chances are they will be happy to have
anything that somehow works, even if it has bugs. In fact, the current
remote-bzr, even if it hasn't received so much testing, is probably
already more stable than other tools:
As an example there is this bug:
http://bugs.launchpad.net/bzr/+bug/541626
Which has been affecting users of 'bzr fast-export' for years (most of
bzr<->git bridges use this tool), and nobody does anything about it,
even though the developers thought the problem was in bzr itself (and
that it was actually fixed, despite the reports to the contrary). I
fixed the problem and added a reliable test case to reproduce the
issue in bzr's test suite itself, only to receive no feedback.
I think there are very few users of bazaar, and if you read the source
code you would be happy that's the case, so I'm not sure letting it
cook in 'next' is going to achieve much, most of them are going to see
it only when it hits master. Most likely the few bazaar users are
accustomed to different quality standards, and this tool doesn't even
have known bugs.
>> I'm confident about remote-hg though.
>
> Meaning unlike remote-bzr, at least you are using it more actively
> (or you know people who are), right? I've queued the two patches
> (out of four) from you today, so we can merge it to 'master' before
> 1.8.1-rc0.
I'm not using it actively, it seems some people are, but that's not
why I'm confident; it's because of the extensive automatic testing
that compares the output with hg-git (which is widely used).
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn Pearce, Felipe Contreras, git
In-Reply-To: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>
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.
They would have to have been restrospective dates from the get-go.
SCCS wasn't built until 1972.
> 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.
That seems eminently reasonable.
> 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.
I think minimum number of digits without losing precision is about the
only alternative that is future-proof - I was going to suggest it for
that reason.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH] svnrdump_sim: start the script with /usr/bin/env python
From: Felipe Contreras @ 2012-11-28 8:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git
In-Reply-To: <7vy5hmgovt.fsf@alter.siamese.dyndns.org>
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.
./git-p4
zsh: ./git-p4: bad interpreter: /usr/bin/python: no such file or directory
In this case git-p4.py is correct, and git-p4 is not.
Either way, this is for contrib, and we don't have a standard
procedure for python scripts there. /usr/bin/env is better than
nothing, and in the vast majority of cases, more than enough.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: David Aguilar @ 2012-11-28 8:04 UTC (permalink / raw)
To: esr; +Cc: Junio C Hamano, Jeff King, Shawn Pearce, Felipe Contreras, git
In-Reply-To: <20121128075807.GA9912@thyrsus.com>
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.
--
David
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Thomas Berg @ 2012-11-28 8:19 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 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.
In my opinion it would be a shame to sacrifice this compatibility just
to reduce the distance to svn, which is much larger anyway.
- Thomas
^ permalink raw reply
* 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
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