* [RFH/Preview/PATCH] update "howto maintain git"
From: Junio C Hamano @ 2012-11-27 23:41 UTC (permalink / raw)
To: git; +Cc: peff
This is still incomplete without a documentation for two scripts,
Meta/Reintegrate and Meta/cook (both are found on my 'todo' branch
and meant to be checked out in the Meta subdirectory of git.git),
that are meant to help the maintainer workflow but can be used by
interested parties, but the old write-up of the procedure has become
really stale and no longer reflects the reality.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* It would help greatly if Peff can point out parts that he found
too sketchy to be useful, and even better fill these parts
himself, based on the recent "interim maintainer" experience.
Documentation/howto/maintain-git.txt | 176 +++++++++++++++++++++--------------
1 file changed, 106 insertions(+), 70 deletions(-)
diff --git c/Documentation/howto/maintain-git.txt w/Documentation/howto/maintain-git.txt
index ea6e4a5..a5713b4 100644
--- c/Documentation/howto/maintain-git.txt
+++ w/Documentation/howto/maintain-git.txt
@@ -12,20 +12,20 @@ How to maintain Git
The maintainer's git time is spent on three activities.
- - Communication (60%)
+ - Communication (45%)
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
suggesting alternatives to, and rejecting patches.
- - Integration (30%)
+ - Integration (50%)
Applying new patches from the contributors while spotting and
correcting minor mistakes, shuffling the integration and
testing branches, pushing the results out, cutting the
releases, and making announcements.
- - Own development (10%)
+ - Own development (5%)
Scratching my own itch and sending proposed patch series out.
@@ -39,6 +39,9 @@ The policy.
contain bugfixes and enhancements in any area, including
functionality, performance and usability, without regression.
+ - One release cycle for a feature release is expected to last for
+ eight to ten weeks.
+
- Maintenance releases are numbered as vX.Y.Z.W and are meant
to contain only bugfixes for the corresponding vX.Y.Z feature
release and earlier maintenance releases vX.Y.Z.V (V < W).
@@ -62,12 +65,15 @@ The policy.
- 'pu' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.
- - The tips of 'master', 'maint' and 'next' branches will always
- fast-forward, to allow people to build their own
- customization on top of them.
+ - The tips of 'master' and 'maint' branches will not be rewound to
+ allow people to build their own customization on top of them.
+ Early in a new development cycle, 'next' is rewound to the tip of
+ 'master' once, but otherwise it will not be rewound until the end
+ of the cycle.
- - Usually 'master' contains all of 'maint', 'next' contains all
- of 'master' and 'pu' contains all of 'next'.
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+ of 'master'. 'pu' contains all the topics merged to 'next', but
+ is rebuilt directly on 'master'.
- The tip of 'master' is meant to be more stable than any
tagged releases, and the users are encouraged to follow it.
@@ -80,11 +86,15 @@ The policy.
A typical git day for the maintainer implements the above policy
by doing the following:
- - Scan mailing list and #git channel log. Respond with review
- comments, suggestions etc. Kibitz. Collect potentially
- usable patches from the mailing list. Patches about a single
- topic go to one mailbox (I read my mail in Gnus, and type
- \C-o to save/append messages in files in mbox format).
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up solving. Send it out just like other
+ contributors do.
- Review the patches in the saved mailboxes. Edit proposed log
message for typofixes and clarifications, and add Acks
@@ -100,28 +110,25 @@ by doing the following:
- Obviously correct fixes that pertain to the tip of 'master'
are directly applied to 'master'.
+ - Other topics are not handled in this step.
+
This step is done with "git am".
$ git checkout master ;# or "git checkout maint"
$ git am -3 -s mailbox
$ make test
- - Merge downwards (maint->master):
-
- $ git checkout master
- $ git merge maint
- $ make test
-
- Review the last issue of "What's cooking" message, review the
topics scheduled for merging upwards (topic->master and
- topic->maint), and merge.
+ topic->maint), and merge. Use "Meta/cook -w" script (see later)
+ to aid this step.
$ git checkout master ;# or "git checkout maint"
$ git merge ai/topic ;# or "git merge ai/maint-topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD.. ;# final review
$ make test ;# final review
- $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
+XXX $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
- Merge downwards (maint->master) if needed:
@@ -142,9 +149,9 @@ by doing the following:
and not in 'master') is applied to a new topic branch that
is forked from the tip of 'master'. This includes both
enhancements and unobvious fixes to 'master'. A topic
- branch is named as ai/topic where "ai" is typically
- author's initial and "topic" is a descriptive name of the
- topic (in other words, "what's the series is about").
+ branch is named as ai/topic where "ai" is two-letter string
+ named after author's initial and "topic" is a descriptive name
+ of the topic (in other words, "what's the series is about").
- An unobvious fix meant for 'maint' is applied to a new
topic branch that is forked from the tip of 'maint'. The
@@ -162,6 +169,7 @@ by doing the following:
The above except the "replacement" are all done with:
+ $ git checkout ai/topic ;# or "git checkout -b ai/topic master"
$ git am -3 -s mailbox
while patch replacement is often done by:
@@ -170,6 +178,7 @@ by doing the following:
then replace some parts with the new patch, and reapplying:
+ $ git checkout ai/topic
$ git reset --hard ai/topic~$n
$ git am -3 -s 000*.txt
@@ -177,80 +186,107 @@ by doing the following:
after patch application; for topic branches the tests are run
as time permits.
- - Update "What's cooking" message to review the updates to
- existing topics, newly added topics and graduated topics.
+ - Review the last issue of "What's cooking" again and see if topics
+ that were scheduled to be merged to 'next' are still in good
+ shape (e.g. has there any new issue identified on the list with
+ the series?)
- This step is helped with Meta/cook script (where Meta/ contains
- a checkout of the 'todo' branch).
+ - Prepare 'jch' branch, which is used to represent somewhere
+ between 'master' and 'pu' and often mirrors 'next'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-jch.sh
+
+ The result is a script that lists topics to be merged in order to
+ rebuild 'pu' as the input to Meta/Reintegrate script. Remove
+ later topics that should not be in 'next' yet.
- Merge topics to 'next'. For each branch whose tip is not
merged to 'next', one of three things can happen:
- - The commits are all next-worthy; merge the topic to next:
+ - The commits are all next-worthy; merge the topic to next;
+ - The new parts are of mixed quality, but earlier ones are
+ next-worthy; merge the early parts to next;
+ - Nothing is next-worthy; do not do anything.
- $ git checkout next
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
- $ make test
+ This step is aided with Meta/redo-jch.sh script created earlier.
+ If a topic that was already in 'next' gained a patch, the script
+ would list it as "ai/topic~1". To include the new patch to the
+ updated 'next', drop the "~1" part; to keep it excluded, do not
+ touch the line. If a topic that was not in 'next' should be
+ merged to 'next', add it at the end of the list. Then:
- - The new parts are of mixed quality, but earlier ones are
- next-worthy; merge the early parts to next:
+ $ git checkout -B jch master
+ $ sh Meta/redo-jch.sh
+
+ to rebuild the 'jch' branch from scratch.
+
+ Then merge the same to 'next'
$ git checkout next
- $ git merge ai/topic~2 ;# the tip two are dubious
- $ make test
+ $ git merge master ;# may turn out to be "already up to date"
+ $ sh Meta/redo-jch.sh -e
- - Nothing is next-worthy; do not do anything.
+ The "-e" option allows the merge message that comes from the
+ history of the topic and the comments in the "What's cooking" to
+ be edited. The resulting tree should match 'jch' as the same set
+ of topics are merged on 'master'; otherwise there is a mismerge.
- - [** OBSOLETE **] Optionally rebase topics that do not have any commit
- in next yet, when they can take advantage of low-level framework
- change that is merged to 'master' already.
+ $ git diff jch next
- $ git rebase master ai/topic
+ When all is well, clean up the redo-jch.sh script with
- This step is helped with Meta/git-topic.perl script to
- identify which topic is rebaseable. There also is a
- pre-rebase hook to make sure that topics that are already in
- 'next' are not rebased beyond the merged commit.
+ $ sh Meta/redo-jch.sh -u
- - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'.
+ This removes topics listed in the script that have already been
+ merged to 'master'.
- $ git checkout pu
- $ git reset --hard next
- $ git merge ai/topic ;# repeat for all remaining topics
- $ make test
+ - Rebuild 'pu'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-pu.sh
+
+ Edit the result by adding new topics that are not still in 'pu'
+ in the script. Then
- This step is helped with Meta/PU script
+ $ git checkout -B pu jch
+ $ sh Meta/redo-pu.sh
+
+ When all is well, clean up the redo-pu.sh script with
+
+ $ sh Meta/redo-pu.sh -u
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
+
+ This step is helped with Meta/cook script (where Meta/ contains
+ a checkout of the 'todo' branch).
- - Push four integration branches to a private repository at
- k.org and run "make test" on all of them.
+ $ Meta/cook
- - Push four integration branches to /pub/scm/git/git.git at
- k.org. This triggers its post-update hook which:
+ Look for lines enclosed in "<<" and ">>"; they hold contents from
+ old file that are replaced by this integration round. After
+ verifying them, remove the old part. Review the description for
+ each topic and update its doneness and plan as needed. To review
+ the updated plan, run
- (1) runs "git pull" in $HOME/git-doc/ repository to pull
- 'master' just pushed out;
+ $ Meta/cook -w
- (2) runs "make doc" in $HOME/git-doc/, install the generated
- documentation in staging areas, which are separate
- repositories that have html and man branches checked
- out.
+ which will pick up comments given to the topics, such as "Will
+ merge to 'next'", etc. (see Meta/cook script to learn what kind
+ of phrases are supported).
- (3) runs "git commit" in the staging areas, and run "git
- push" back to /pub/scm/git/git.git/ to update the html
- and man branches.
+ - Rebuild all four (five) integration branches; Meta/Dothem script
+ may aid this step.
- (4) installs generated documentation to /pub/software/scm/git/docs/
- to be viewed from http://www.kernel.org/
+ - Rebuild documentation if the 'master' branch was updated;
+ Meta/dodoc.sh script may aid this step.
- - Fetch html and man branches back from k.org, and push four
- integration branches and the two documentation branches to
- repo.or.cz and other mirrors.
+ - Push four integration branches to public places.
Some observations to be made.
* Each topic is tested individually, and also together with
- other topics cooking in 'next'. Until it matures, none part
+ other topics cooking in 'next'. Until it matures, no part
of it is merged to 'master'.
* A topic already in 'next' can get fixes while still in
^ permalink raw reply related
* Re: Millisecond precision in timestamps?
From: Shawn Pearce @ 2012-11-27 23:49 UTC (permalink / raw)
To: Eric Raymond; +Cc: Junio C Hamano, git
In-Reply-To: <20121127230419.GA26080@thyrsus.com>
On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 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.
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.
^ permalink raw reply
* [PATCH] Documentation/git-push.txt: clarify the "push from satellite" workflow
From: Junio C Hamano @ 2012-11-27 23:52 UTC (permalink / raw)
To: Brandon Casey; +Cc: git@vger.kernel.org, Brandon Casey
In-Reply-To: <50B41DF7.2000705@nvidia.com>
The context of the example to push into refs/remotes/satellite/
hierarchy of the other repository needs to be spelled out explicitly
for the value of this example to be fully appreciated. Make it so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Brandon Casey <bcasey@nvidia.com> writes:
>> So refs are correct. The context is not sufficiently explained.
>
> Ah, I see. Yeah, I think that is complex enough to merit an
> extended explanation.
Something like this?
Documentation/git-push.txt | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git c/Documentation/git-push.txt w/Documentation/git-push.txt
index 6d19d59..8b637d3 100644
--- c/Documentation/git-push.txt
+++ w/Documentation/git-push.txt
@@ -385,11 +385,23 @@ the ones in the examples below) can be configured as the default for
A handy way to push the current branch to the same name on the
remote.
-`git push origin master:satellite/master dev:satellite/dev`::
+`git push mothership master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
- `refs/remotes/satellite/master`) in the `origin` repository, then
+ `refs/remotes/satellite/master`) in the `mothership` repository;
do the same for `dev` and `satellite/dev`.
++
+This is to emulate `git fetch` run on the `mothership` using `git
+push` that is run in the opposite direction in order to integrate
+the work done on `satellite`, and is often necessary when you can
+only make connection in one way (i.e. satellite can ssh into
+mothership but mothership cannot initiate connection to satellite
+because the latter is behind a firewall or does not run sshd).
++
+After running this `git push` on the `satellite` machine, you would
+ssh into the `mothership` and run `git merge` there to complete the
+emulation of `git pull` that were run on `mothership` to pull changes
+made on `satellite`.
`git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the
^ permalink raw reply related
* Re: [PATCH v6 p2 3/9] transport-helper: trivial code shuffle
From: Felipe Contreras @ 2012-11-28 0:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Ilari Liusvaara, Sverre Rabbelier, Elijah Newren,
Thiago Farina
In-Reply-To: <7vk3t7nfql.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 6:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Just shuffle the die() part to make it more explicit, and cleanup the
>> code-style.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> transport-helper.c | 7 +++----
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/transport-helper.c b/transport-helper.c
>> index 32ad877..0c95101 100644
>> --- a/transport-helper.c
>> +++ b/transport-helper.c
>> @@ -775,6 +775,9 @@ static int push_refs_with_export(struct transport *transport,
>> char *private;
>> unsigned char sha1[20];
>>
>> + if (ref->deletion)
>> + die("remote-helpers do not support ref deletion");
>> +
>> if (!data->refspecs)
>> continue;
>
> 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.
--
Felipe Contreras
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-28 0:10 UTC (permalink / raw)
To: Magnus Bäck; +Cc: Michael Haggerty, Eric S. Raymond, git
In-Reply-To: <20121127143510.GA15831@google.com>
On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck <baeck@google.com> wrote:
> On Sunday, November 25, 2012 at 06:40 EST,
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>> On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty
>> <mhagger@alum.mit.edu> wrote:
>
> [...]
>
>> > On the contrary, there is *constant* traffic on the mailing list
>> > about incompatibilities between different shell implementations (sh,
>> > dash, bash, etc), not to mention those in other utilities (sed,
>> > grep, etc) that one is forced to work with in shell scripts.
>> > Compatibility is a *huge* pain when developing shell code for git.
>> > The fact that users typically don't encounter such problems is due
>> > to the hard work of POSIX lawyers on the mailing list correcting the
>> > compatibility errors of mortal programmers.
>>
>> *Theoretical* incompatibilities on probably obscure systems. *I* have
>> never seen such compatibility issues *in practice*.
>
> 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.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-28 0:12 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <CAJo=hJtOqRHcjWH1F71Qc5zvPkUAe+u1RrcC2pt_xQwLSUY0yg@mail.gmail.com>
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.
I'm being exploratory, here. No proposal to code anything is in the
offing.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: Python extension commands in git - request for policy change
From: Felipe Contreras @ 2012-11-28 0:16 UTC (permalink / raw)
To: esr; +Cc: Magnus Bäck, Michael Haggerty, git
In-Reply-To: <20121127183530.GB11845@thyrsus.com>
On Tue, Nov 27, 2012 at 7:35 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> As a general scripting language shell sucks *really badly* compared to
> anything new-school. Performance, portability, you name it, it's a
> mess. It's not so much the shell interpreters itself that are the
> portabilty problem, but (as Magnus implicitly points out) all those
> userland dependencies on sed and tr and awk and even variants of
> expr(!) that get dragged in the second you try to get any actual work
> done.
Somehow it has worked perfectly fine for us.
Also, you are ignoring all the advantages that shell has and python does not.
> Can we cease behaving like we're still pounding keys on 110-baud
> teletypes now? Some old-school Unix habits have persisted long past
> the point that they're even remotely sane. Shell programming at any
> volume above a few lines of throwaway code is one of them - it's
> *nuts* and we should *stop doing it*.
Yes, let's all switch to ruby! Nah, everybody is still using Unix and
shells, they work. If they didn't, we wouldn't be having this
conversation.
What is the big problem? Somebody said we hit a few issues per year?
I've already hit more than that writing code for python just the last
month.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Why is this known by git but not by gitk
From: Felipe Contreras @ 2012-11-28 0:19 UTC (permalink / raw)
To: Kevin O'Gorman; +Cc: git
In-Reply-To: <CAGVXcSYQprvqacDV_EjVSboiao3J8CcOoHwFeUgjJYoyos4e_A@mail.gmail.com>
On Tue, Nov 27, 2012 at 6:50 PM, Kevin O'Gorman <kogorman@gmail.com> wrote:
> I just converted a SourceForge CVS repo to git using cvs2svn. One
> directory in the result is named CVSROOT and everything would be fine,
> but I wan to know why gitk does not see it.
>
> Git itself does not report it either, but it lets me "git rm -r
> CVSROOT" and stages the change.
>
> I just want to know what's up with this before I commit myself to
> using this converted repo.
Is it present in the .gitignore file?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v3 0/7] New remote-bzr remote helper
From: Felipe Contreras @ 2012-11-28 0:23 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.
I was waiting on both to be merged, let me see what I have pending and
would be nice to have before the merge.
--
Felipe Contreras
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: David Lang @ 2012-11-28 0:22 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20121128001231.GA27971@thyrsus.com>
On Tue, 27 Nov 2012, Eric S. Raymond 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.
>
> I'm being exploratory, here. No proposal to code anything is in the
> offing.
Apologies if this was covered earlier in the thread (I missed the beginning)
remember that git is dealing with timestamps generated across different
machines, and since the times are not assumed to be in sync, let alone to the
millisecond level, there's not much value to git in that level of presision.
git routinely deals with timestamps that are off by days. If the timestamps are
within a minute or so, you are in pretty good shape.
David Lang
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Felipe Contreras @ 2012-11-28 0:26 UTC (permalink / raw)
To: esr; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <20121128001231.GA27971@thyrsus.com>
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.
--
Felipe Contreras
^ permalink raw reply
* Re: Possible vulnerability to SHA-1 collisions
From: Jeff King @ 2012-11-28 0:27 UTC (permalink / raw)
To: git; +Cc: Shawn Pearce, Michael Hirshleifer
In-Reply-To: <20121127233016.GC3937@pug.qqx.org>
On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote:
> At 18:07 -0500 27 Nov 2012, Jeff King <peff@peff.net> wrote:
> >PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
> > easier said than done. We do not have SHA-1 collisions yet, but if
> > the md5 attacks are any indication, the innocuous file will not be
> > completely clean; it will need to have some embedded binary goo that
> > is mutated randomly during the collision process (which is why the
> > md5 attacks were demonstrated with postscript files which _rendered_
> > to look good, but contained a chunk of random bytes in a spot ignored
> > by the postscript interpreter).
>
> I don't think that really saves us though. Many formats have parts
> of the file which will be ignored, such as comments in source code.
Agreed, it does not save us unconditionally. It just makes it harder to
execute the attack. Would you take a patch from a stranger that had a
kilobyte of binary garbage in a comment?
A more likely avenue would be a true binary file where nobody is
expected to read the diff.
> With the suggested type of attack, there isn't a requirement about
> which version of the file is modified. So the attacker should be
> able to generate a version of a file with an innocuous change, get
> the SHA-1 for that, then add garbage comments to their malicious
> version of the file to try to get the same SHA-1.
That's not how birthday collision attacks usually work, though. You do
not get to just mutate the malicious side and leave the innocuous side
untouched. You are mutating both sides over and over and hoping to find
a matching sha1 from the "good" and "evil" sides.
Of course, I have not been keeping up too closely with the efforts to
break sha-1. Maybe there is something more nefarious about the current
attacks. I am just going off my recollection of the md5 collision
attacks.
-Peff
^ permalink raw reply
* Re: [PATCH v4 2/4] git-submodule init: Record submodule.<name>.branch in repository config.
From: W. Trevor King @ 2012-11-28 0:40 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Phil Hord,
Shawn Pearce, Nahor
In-Reply-To: <50B54A68.60309@web.de>
[-- Attachment #1: Type: text/plain, Size: 808 bytes --]
On Wed, Nov 28, 2012 at 12:19:04AM +0100, Jens Lehmann wrote:
> Am 26.11.2012 22:00, schrieb W. Trevor King:
> > From: "W. Trevor King" <wking@tremily.us>
> >
> > This allows users to override the .gitmodules value with a
> > per-repository value.
>
> [snip problems]. You should use the branch setting from .git/config
> if present and fall back to the branch setting from .gitmodules if
> not, which would enable the user to have her own setting if she
> doesn't like what upstream provides but would still enable others to
> follow different submodule branches in different superproject
> branches.
Sounds good. Will fix in v5.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [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
* 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
* [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
* [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 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 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 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
* 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
* 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: 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: 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: 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
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