* 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: 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: [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: 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: 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: 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: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: [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
* [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: 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
* [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: [PATCH v3 0/7] New remote-bzr remote helper
From: Junio C Hamano @ 2012-11-27 23:32 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Jeff King, Johannes Schindelin
In-Reply-To: <CAMP44s1G3b3XQX+=5Ag2exdy83hULbz1m0Z6UFDrhZU2TGwBMg@mail.gmail.com>
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.
Thanks.
^ permalink raw reply
* Re: Possible vulnerability to SHA-1 collisions
From: Aaron Schrab @ 2012-11-27 23:30 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Michael Hirshleifer, git
In-Reply-To: <20121127230753.GA22730@sigill.intra.peff.net>
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. 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.
^ permalink raw reply
* Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: Heiko Voigt @ 2012-11-27 23:28 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Git, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121127190105.GQ10656@odin.tremily.us>
Hi,
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> The v4 series leaves the remote branch amigious, but it helps you
> point the local branch at the right hash so that future calls to
>
> $ git submodule foreach 'git pull'
>
> can use the branch's .git/modules/<name>/config settings.
But IMO thats the functionality which should be implemented in submodule
update and not left to the user.
> > I would think more of some convention like:
> >
> > $ git checkout -t origin/$branch
> >
> > when first initialising the submodule with e.g.
> >
> > $ git submodule update --init --branch
> >
> > Then later calls of
> >
> > $ git submodule update --branch
> >
> > would have a branch configured to pull from. I imagine that results in
> > a similar behavior gerrit is doing on the server side?
>
> That sounds like it's doing pretty much the same thing. Can you think
> of a test that would distinguish it from my current v4 implementation?
Well the main difference is that gerrit is automatically updating the
superproject AFAIK. I would like it if we could implement the same
workflow support in the submodule script. It seems to me that this is
already proven to be useful workflow.
I do not have a test but a small draft diff (completely untested, quick and
dirty) to illustrate the approach I am talking about.
You can find the whole change at
https://github.com/hvoigt/git/commits/hv/floating_submodules_draft
and the interesting patch for easy commenting below[1].
> > How about reusing the -b|--branch option for add? Since we only change
> > the behavior when submodule.$name.update is set to branch it seems
> > reasonable to me. Opinions?
>
> That was the approach I used in v1, but people were concerned that we
> would be stomping on previously unclaimed config space. Since noone
> has pointed out other uses besides Gerrit's very similar case, I'm not
> sure if that is still an issue.
Could you point me to that mail? I cannot seem to find it in my archive.
> > > Because you need to recurse through submodules for `update --branch`
> > > even if "$subsha1" == "$sha1", I had to amend the conditional
> > > controlling that block. This broke one of the existing tests, which I
> > > "fixed" in patch 4. I think a proper fix would involve rewriting
> > >
> > > (clear_local_git_env; cd "$sm_path" &&
> > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
> > > test -z "$rev") || git-fetch)) ||
> > > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
> > >
> > > but I'm not familiar enough with rev-list to want to dig into that
> > > yet. If feedback for the earlier three patches is positive, I'll work
> > > up a clean fix and resubmit.
> >
> > You probably need to separate your handling here. The comparison of the
> > currently checked out sha1 and the recorded sha1 is an optimization
> > which skips unnecessary fetching in case the submodules commits are
> > already correct. This code snippet checks whether the to be checked out
> > sha1 is already local and also skips the fetch if it is. We should not
> > break that.
>
> Agreed. However, determining if the target $sha1 is local should have
> nothing to do with the current checked out $subsha1.
See my draft or the diff below for an illustration of the splitup.
Cheers Heiko
[1]
diff --git a/git-submodule.sh b/git-submodule.sh
index 9ad4370..3fa1465 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -183,6 +183,7 @@ module_clone()
sm_path=$1
url=$2
reference="$3"
+ branch="$4"
quiet=
if test -n "$GIT_QUIET"
then
@@ -209,6 +210,8 @@ module_clone()
clear_local_git_env
git clone $quiet -n ${reference:+"$reference"} \
--separate-git-dir "$gitdir" "$url" "$sm_path"
+ test -n "$branch" && (cd $sm_path &&
+ git checkout -t origin/$branch)
) ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$sm_path' failed")"
fi
@@ -361,7 +364,7 @@ Use -f if you really want to add it." >&2
else
- module_clone "$sm_path" "$realrepo" "$reference" || exit
+ module_clone "$sm_path" "$realrepo" "$reference" "$local_branch" || exit
(
clear_local_git_env
cd "$sm_path" &&
@@ -577,6 +580,12 @@ handle_on_demand_update () {
fi
}
+handle_tracking_branch_update () {
+ (clear_local_git_env; cd "$sm_path" &&
+ git-checkout $branch && git-pull --ff-only) ||
+ die "$(eval_gettext "Unable to pull branch '\$branch' in submodule path '\$sm_path'")"
+}
+
#
# Update each submodule path to correct revision, using clone and checkout as needed
#
@@ -648,6 +657,7 @@ cmd_update()
cloned_modules=
module_list "$@" | {
err=
+ floating_submodules=
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
@@ -684,7 +694,7 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$url" "$reference"|| exit
+ module_clone "$sm_path" "$url" "$reference" "$branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -693,7 +703,13 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
fi
- handle_on_demand_update
+ if test "$update_module" = "branch"
+ then
+ handle_tracking_branch_update
+ floating_submodules="$floating_submodules $sm_path"
+ else
+ handle_on_demand_update
+ fi
if test -n "$recursive"
then
@@ -727,6 +743,11 @@ Maybe you want to use 'update --init'?")"
IFS=$OIFS
exit 1
fi
+ if test -n "$floating_submodules"
+ then
+ git add $floating_submodules &&
+ git commit -m "Updated submodules"
+ fi
}
}
^ permalink raw reply related
* [PATCH] configure.ac: fix pthreads detection on Mac OS X
From: Max Horn @ 2012-11-27 23:28 UTC (permalink / raw)
To: git; +Cc: Max Horn
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 :-(.
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'])
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* Re: [PATCH v4 2/4] git-submodule init: Record submodule.<name>.branch in repository config.
From: Jens Lehmann @ 2012-11-27 23:19 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Heiko Voigt, Junio C Hamano, Jeff King, Phil Hord,
Shawn Pearce, Nahor
In-Reply-To: <6734714e90064b3932126565e3027d7edcf45d51.1353962698.git.wking@tremily.us>
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.
Your intentions makes lots of sense, but your patch does more than
that. Copying the branch setting into .git/config sets the initial
branch setting into stone. That makes it impossible to have a branch
"foo" in the superproject using a branch "bar" in a submodule and
another superproject branch "frotz" using branch "nitfol" for the
same submodule. 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.
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/config.txt | 9 +++++----
> git-submodule.sh | 7 +++++++
> t/t7400-submodule-basic.sh | 18 ++++++++++++++++++
> 3 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 11f320b..1304499 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1994,10 +1994,11 @@ status.submodulesummary::
> submodule.<name>.path::
> submodule.<name>.url::
> submodule.<name>.update::
> - The path within this project, URL, and the updating strategy
> - for a submodule. These variables are initially populated
> - by 'git submodule init'; edit them to override the
> - URL and other values found in the `.gitmodules` file. See
> +submodule.<name>.branch::
> + The path within this project, URL, the updating strategy, and the
> + local branch name for a submodule. These variables are initially
> + populated by 'git submodule init'; edit them to override the URL and
> + other values found in the `.gitmodules` file. See
> linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 6eed008..c51b6ae 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -505,6 +505,13 @@ cmd_init()
> test -n "$(git config submodule."$name".update)" ||
> git config submodule."$name".update "$upd" ||
> die "$(eval_gettext "Failed to register update mode for submodule path '\$sm_path'")"
> +
> + # Copy "branch" setting when it is not set yet
> + branch="$(git config -f .gitmodules submodule."$name".branch)"
> + test -z "$branch" ||
> + test -n "$(git config submodule."$name".branch)" ||
> + git config submodule."$name".branch "$branch" ||
> + die "$(eval_gettext "Failed to register branch for submodule path '\$sm_path'")"
> done
> }
>
> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
> index fc08647..3dc8237 100755
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
> @@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch=<name> --branch' '
> )
> '
>
> +test_expect_success 'init should register submodule branch in .git/config' '
> + (
> + cd addtest &&
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "final"
> + )
> +'
> +
> +test_expect_success 'local config should override .gitmodules branch' '
> + (
> + cd addtest &&
> + rm -fr submod-follow &&
> + git config submodule.submod-follow.branch initial
> + git submodule init &&
> + test "$(git config submodule.submod-follow.branch)" = "initial"
> + )
> +'
> +
> test_expect_success 'setup - add an example entry to .gitmodules' '
> GIT_CONFIG=.gitmodules \
> git config submodule.example.url git://example.com/init.git
>
^ permalink raw reply
* [PATCH v2 0/3] Add option to change order of parents in merge commit
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab
The second version of patches introducing option to change order
of parents in merge commits. The changes in respect to the previous
version:
- I have divided the changes to the preparatory ones, which
only refactore the code without introducing new functionality, and
the commit which introduces the new option
- The documentation for the new options has been added
This is not yet a final version, as the tests are missing. But maybe while I'm working
on them there will be some comments.
Kacper Kornet (3):
Process MERGE_MODE before MERGE_HEAD
Allow for MERGE_MODE to specify more then one mode
Add option to transpose parents of merge commit
Documentation/merge-options.txt | 7 +++++++
builtin/commit.c | 22 ++++++++++++++--------
builtin/merge.c | 16 ++++++++++++----
commit.c | 11 +++++++++++
commit.h | 2 ++
git-pull.sh | 4 +++-
6 files changed, 49 insertions(+), 13 deletions(-)
--
1.8.0.1
^ permalink raw reply
* [PATCH v2 1/3] Process MERGE_MODE before MERGE_HEAD
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
It is in preparation to introduce --transpose-parents option to
git-merge, when the content of MERGE_MODE will dictate how the
MERGE_HEAD is interpreted.
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 1dd2ec5..273332f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1481,6 +1481,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;
+ }
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
@@ -1496,12 +1502,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
fclose(fp);
strbuf_release(&m);
- 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 (allow_fast_forward)
parents = reduce_heads(parents);
} else {
--
1.8.0.1
^ permalink raw reply related
* [PATCH v2 3/3] Add option to transpose parents of merge commit
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
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
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-'
The difference between C and C' is the order of parents. This change
allow for easier way to obtain this effect by introducing the option
--transpose-parents to git-merge and git-pull, which changes the order
of parents in resulting commit moving the original first parent to
the very end of list of parents.
The transposition is done just before the commit is finalized, so the
meaning of "our" and "their" for conflict resolution is not changed, so
"ours" denotes local version and "theirs" upstream.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
Documentation/merge-options.txt | 7 +++++++
builtin/commit.c | 8 +++++++-
builtin/merge.c | 16 ++++++++++++----
commit.c | 11 +++++++++++
commit.h | 2 ++
git-pull.sh | 4 +++-
6 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..b4fbfdc 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -88,6 +88,13 @@ option can be used to override --squash.
Synonyms to --stat and --no-stat; these are deprecated and will be
removed in the future.
+--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).
+
+
ifndef::git-pull[]
-q::
--quiet::
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;
if (!reflog_msg)
reflog_msg = "commit (merge)";
@@ -1484,10 +1485,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
while (strbuf_getline(&m, fp, '\n') != EOF) {
if (!strcmp(m.buf, "no-ff"))
allow_fast_forward = 0;
+ if (!strcmp(m.buf, "reversed-order"))
+ reversed_order = 1;
}
fclose(fp);
}
- pptr = &commit_list_insert(current_head, pptr)->next;
+ if (!reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1502,6 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
fclose(fp);
strbuf_release(&m);
+ if (reversed_order)
+ pptr = &commit_list_insert(current_head, pptr)->next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..41738a5 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
static int show_progress = -1;
static int default_to_upstream;
static const char *sign_commit;
+static int reversed_order=0;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key id"),
N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOLEAN(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
+ OPT_BOOLEAN(0, "transpose-parents", &reversed_order, N_("reverse order of parents")),
OPT_END()
};
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct commit_list *remoteheads)
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
- parent->item = head;
+ parent->item = reversed_order ? remoteheads->item : head;
parent->next = xmalloc(sizeof(*parent->next));
- parent->next->item = remoteheads->item;
+ parent->next->item = reversed_order ? head : remoteheads->item;
parent->next->next = NULL;
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parent, result_commit, NULL,
@@ -848,8 +850,12 @@ static int finish_automerge(struct commit *head,
free_commit_list(common);
parents = remoteheads;
- if (!head_subsumed || !allow_fast_forward)
+ if (!head_subsumed || !allow_fast_forward) {
+ if (reversed_order )
+ commit_list_insert_end(head, &parents);
+ else
commit_list_insert(head, &parents);
+ }
strbuf_addch(&merge_msg, '\n');
prepare_to_commit(remoteheads);
if (commit_tree(&merge_msg, result_tree, parents, result_commit,
@@ -994,7 +1000,9 @@ static void write_merge_state(struct commit_list *remoteheads)
die_errno(_("Could not open '%s' for writing"), filename);
strbuf_reset(&buf);
if (!allow_fast_forward)
- strbuf_addf(&buf, "no-ff");
+ strbuf_addf(&buf, "no-ff\n");
+ if (reversed_order)
+ strbuf_addf(&buf, "reversed-order\n");
if (write_in_full(fd, buf.buf, buf.len) != buf.len)
die_errno(_("Could not write to '%s'"), filename);
close(fd);
diff --git a/commit.c b/commit.c
index e8eb0ae..6e58994 100644
--- a/commit.c
+++ b/commit.c
@@ -363,6 +363,17 @@ struct commit_list *commit_list_insert(struct commit *item, struct commit_list *
return new_list;
}
+struct commit_list *commit_list_insert_end(struct commit *item, struct commit_list **list_p)
+{
+ struct commit_list *list_iter = *list_p;
+ while(list_iter->next)
+ list_iter = list_iter->next;
+ list_iter->next = xmalloc(sizeof(*list_iter->next));
+ list_iter->next->item = item;
+ list_iter->next->next = NULL;
+ return *list_p;
+}
+
unsigned commit_list_count(const struct commit_list *l)
{
unsigned c = 0;
diff --git a/commit.h b/commit.h
index b6ad8f3..17ae5e5 100644
--- a/commit.h
+++ b/commit.h
@@ -53,6 +53,8 @@ int find_commit_subject(const char *commit_buffer, const char **subject);
struct commit_list *commit_list_insert(struct commit *item,
struct commit_list **list);
+struct commit_list *commit_list_insert_end(struct commit *item,
+ struct commit_list **list);
struct commit_list **commit_list_append(struct commit *commit,
struct commit_list **next);
unsigned commit_list_count(const struct commit_list *l);
diff --git a/git-pull.sh b/git-pull.sh
index 266e682..d9c7591 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -84,6 +84,8 @@ do
no_ff=--no-ff ;;
--ff-only)
ff_only=--ff-only ;;
+ --transpose-parents)
+ transpose_parents=--transpose-parents;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -283,7 +285,7 @@ true)
eval="$eval --onto $merge_head ${oldremoteref:-$merge_head}"
;;
*)
- eval="git-merge $diffstat $no_commit $edit $squash $no_ff $ff_only"
+ eval="git-merge $diffstat $no_commit $edit $squash $no_ff $ff_only $transpose_parents"
eval="$eval $log_arg $strategy_args $merge_args $verbosity $progress"
eval="$eval \"\$merge_name\" HEAD $merge_head"
;;
--
1.8.0.1
^ permalink raw reply related
* [PATCH v2 2/3] Allow for MERGE_MODE to specify more then one mode
From: Kacper Kornet @ 2012-11-27 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Aaron Schrab, Kacper Kornet
In-Reply-To: <1354057217-65886-1-git-send-email-draenog@pld-linux.org>
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"))) {
+ while (strbuf_getline(&m, fp, '\n') != EOF) {
+ if (!strcmp(m.buf, "no-ff"))
+ allow_fast_forward = 0;
+ }
+ fclose(fp);
}
pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
--
1.8.0.1
^ permalink raw reply related
* Re: Possible vulnerability to SHA-1 collisions
From: Jeff King @ 2012-11-27 23:07 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Michael Hirshleifer, git
In-Reply-To: <CAJo=hJsZdduMdSbN+3Ei-7vx3_Q7tO88LywWj5Vw3Ngs0QgsZg@mail.gmail.com>
On Sat, Nov 24, 2012 at 10:09:31AM -0800, Shawn O. Pearce wrote:
> On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111mth@caltech.edu> wrote:
> > Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> > checksum (including Git header). Mr. Evil creates a local branch with an
> > innocuous name like “test-bugfix”, and adds a commit containing a reference
> > to the evil file. Separately, using a sockpuppet, Evil Guy creates an
> > innocuous bugfix (very likely to be accepted) containing the innocuous file,
> > and submits it to Good Guy. Before Good Guy can commit the bugfix, Evil Guy
> > pushes the evil branch to Github, and then immediately deletes it; or
> > equivalently --force pushes any innocuous commit on top of it. (This is
> > unlikely to arouse suspicion, and he can always say he deleted it because it
> > didn’t work.)
>
> Here you assume Evil Guy has write access to the same repository as
> Good Guy. Lets assume this is possible, e.g. Evil Guy is actually
> impersonating White Hat because he managed to steal White Hat's
> credentials through a compromised host. Typically Evil Guy doesn't
> have write access to Good Guy's repository, and thus can't introduce
> objects into it without Good Guy being the one that creates the
> objects.
>
> But lets just keep he assumption that Evil Guy can write to the same
> repository as Good Guy, and that he managed to create the bad branch
> and delete it, leaving the bad object in an unreachable state for 2
> weeks.
Actually, it is somewhat easier on GitHub, because we share objects
between forks of a repository via the alternates mechanism. So if you
can publicly fork the project and push a branch to your fork, you can
write to the shared object database. This applies not just to GitHub,
but to any hosting service which shares object databases between
projects (I do not know offhand if other hosting providers like Google
Code do this).
But as you noted later in your email, the byte-for-byte comparison on
object collision will let us detect this case when the good guy tries to
push and abort.
-Peff
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).
^ permalink raw reply
* Re: [PATCH 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
From: Max Horn @ 2012-11-27 23:06 UTC (permalink / raw)
Cc: git
In-Reply-To: <1354057407-83151-8-git-send-email-max@quendi.de>
Ouch. This one should *not* have been sent (the "[PATCH v2 6/6]" one is the correct one). Very sorry :(. I'll triple check next time.
Max
On 28.11.2012, at 00:03, Max Horn wrote:
> The documentation was misleading in that it gave the impression that
> 'for-push' could be used as a ref attribute in the output of the
> 'list' command. That is wrong.
>
> Also, explicitly point out the connection between the commands
> 'list' and 'options' on the one hand, and the sections
> 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
>
> Signed-off-by: Max Horn <max@quendi.de>
> ---
> Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 023dcca..e1df01d 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -227,6 +227,8 @@ Support for this command is mandatory.
> the name; unrecognized attributes are ignored. The list ends
> with a blank line.
> +
> +See REF LIST ATTRIBUTES for a list of currently defined options.
> ++
> Supported if the helper has the "fetch" or "import" capability.
>
> 'list for-push'::
> @@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
> for it). Options should be set before other commands,
> and may influence the behavior of those commands.
> +
> +See OPTIONS for a list of currently defined options.
> ++
> Supported if the helper has the "option" capability.
>
> 'fetch' <sha1> <name>::
> @@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
> per line, terminated with a blank line.
> Outputs a single blank line when all fetch commands in the
> same batch are complete. Only objects which were reported
> - in the ref list with a sha1 may be fetched this way.
> + in the output of 'list' with a sha1 may be fetched this way.
> +
> Optionally may output a 'lock <file>' line indicating a file under
> GIT_DIR/objects/pack which is keeping a pack until refs can be
> @@ -360,10 +364,9 @@ capabilities reported by the helper.
> REF LIST ATTRIBUTES
> -------------------
>
> -'for-push'::
> - The caller wants to use the ref list to prepare push
> - commands. A helper might chose to acquire the ref list by
> - opening a different type of connection to the destination.
> +The 'list' command produces a list of refs in which each ref
> +may be followed by a list of attributes. The following ref list
> +attributes are defined.
>
> 'unchanged'::
> This ref is unchanged since the last import or fetch, although
> @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
>
> OPTIONS
> -------
> +
> +The following options are defined and (under suitable circumstances)
> +set by git if the remote helper has the 'option' capability.
> +
> 'option verbosity' <n>::
> Changes the verbosity of messages displayed by the helper.
> A value of 0 for <n> means that processes operate
> --
> 1.8.0.393.gcc9701d
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-27 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vzk22lmz9.fsf@alter.siamese.dyndns.org>
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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* [PATCH v2 3/6] git-remote-helpers.txt: minor grammar fix
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index db63541..7eb43d7 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line.
'capabilities'::
Lists the capabilities of the helper, one per line, ending
with a blank line. Each capability may be preceded with '*',
- which marks them mandatory for git version using the remote
- helper to understand (unknown mandatory capability is fatal
- error).
+ which marks them mandatory for git versions using the remote
+ helper to understand. Any unknown mandatory capability is a
+ fatal error.
'list'::
Lists the refs, one per line, in the format "<value> <name>
--
1.8.0.393.gcc9701d
^ permalink raw reply related
* [PATCH v2 6/6] git-remote-helpers.txt: clarify options & ref list attributes
From: Max Horn @ 2012-11-27 23:03 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <1354057407-83151-1-git-send-email-max@quendi.de>
The documentation was misleading in that it gave the impression that
'for-push' could be used as a ref attribute in the output of the
'list' command. That is wrong.
Also, explicitly point out the connection between the commands
'list' and 'options' on the one hand, and the sections
'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand.
Signed-off-by: Max Horn <max@quendi.de>
---
Documentation/git-remote-helpers.txt | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 023dcca..e1df01d 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -227,6 +227,8 @@ Support for this command is mandatory.
the name; unrecognized attributes are ignored. The list ends
with a blank line.
+
+See REF LIST ATTRIBUTES for a list of currently defined options.
++
Supported if the helper has the "fetch" or "import" capability.
'list for-push'::
@@ -248,6 +250,8 @@ Supported if the helper has the "push" or "export" capability.
for it). Options should be set before other commands,
and may influence the behavior of those commands.
+
+See OPTIONS for a list of currently defined options.
++
Supported if the helper has the "option" capability.
'fetch' <sha1> <name>::
@@ -256,7 +260,7 @@ Supported if the helper has the "option" capability.
per line, terminated with a blank line.
Outputs a single blank line when all fetch commands in the
same batch are complete. Only objects which were reported
- in the ref list with a sha1 may be fetched this way.
+ in the output of 'list' with a sha1 may be fetched this way.
+
Optionally may output a 'lock <file>' line indicating a file under
GIT_DIR/objects/pack which is keeping a pack until refs can be
@@ -360,10 +364,9 @@ capabilities reported by the helper.
REF LIST ATTRIBUTES
-------------------
-'for-push'::
- The caller wants to use the ref list to prepare push
- commands. A helper might chose to acquire the ref list by
- opening a different type of connection to the destination.
+The 'list' command produces a list of refs in which each ref
+may be followed by a list of attributes. The following ref list
+attributes are defined.
'unchanged'::
This ref is unchanged since the last import or fetch, although
@@ -371,6 +374,10 @@ REF LIST ATTRIBUTES
OPTIONS
-------
+
+The following options are defined and (under suitable circumstances)
+set by git if the remote helper has the 'option' capability.
+
'option verbosity' <n>::
Changes the verbosity of messages displayed by the helper.
A value of 0 for <n> means that processes operate
--
1.8.0.393.gcc9701d
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox