* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Jeff King @ 2009-03-26 2:12 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49CA6A17.6050903@gmail.com>
On Wed, Mar 25, 2009 at 12:29:59PM -0500, Mike Gaffney wrote:
> I am trying to setup a git repo internally at my work. I would like to
> make the repo accessable via https for both read and write so that we may
> access it from customer locations which don't allow anything but https. I
> would also like to host it via SSH because that protocol is much faster. I
> know that when you push with http it runs 'git update-server-info', would
> I have to make the ssh pushes do the same? Will this even work?
Yes, it should work just fine. All pushes, no matter how they arrive at
the repository, will need to run "git update-server-info", which is what
allows "dumb" protocols like http to read from the repository. The
default post-update hook does this; you just need to enable it by "cd
.git/hooks && mv post-update.sample post-update".
-Peff
^ permalink raw reply
* Re: [PATCH] Grammar fixes to "merge" and "patch-id" docs
From: Jeff King @ 2009-03-26 2:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7vocvp310v.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 11:33:52AM -0700, Junio C Hamano wrote:
> Wincent Colaiuta <win@wincent.com> writes:
>
> > If you tried a merge which resulted in a complex conflicts and
> > -would want to start over, you can recover with 'git-reset'.
> > +want to start over, you can recover with 'git-reset'.
>
> Reads Ok to me either way...
Wincent gave a more complete explanation, and I think he is right about
this change. But while reading this I also noticed "... a complex
conflicts ..." in the context line which should be just "complex
conflicts".
-Peff
^ permalink raw reply
* Re: Reference for git.git release process
From: Jeff King @ 2009-03-26 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Raman Gupta, git
In-Reply-To: <7viqlxz9go.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:
> I do not answer "generally" part, but in git.git, I do not publish heads
> of individual topic branches. I could, but simply I don't, because that
> has been the way I've operated so far, and I am too lazy to change my
> configuration.
I don't think it is a big problem in practice. But every once in a while
I have had to dig through pu to re-create a topic branch manually. And I
believe Thomas Rast posted a script to do so automatically. So I think
there is some indication that people might find this information useful,
but I don't feel too strongly about it.
> Also I suspect it would make my life more cumbersome
> because I have to prune stale topics from the public repositories from
> time to time.
Mirror mode would handle this automatically, but it unfortunately also
ignores your push refspec. So any cruft or work-in-progress refs in your
repository would be pushed.
-Peff
^ permalink raw reply
* Re: Importing Bzr revisions
From: David Reitter @ 2009-03-26 3:05 UTC (permalink / raw)
To: Teemu Likonen; +Cc: bazaar, git, Junio C Hamano
In-Reply-To: <87zlfcz62g.fsf@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]
On Mar 23, 2009, at 10:07 AM, Teemu Likonen wrote:
>> I'm just experimenting with "bzr fast-export", which converts to git,
>> and it seems to take about 4 minutes for 1000 revisions on our
>> (modern) server. That would be around 7 hours for my emacs
>> repository;
>> I can't do that daily.
>>
>> I wonder if there's a way for (bzr) fast-export / (git) fast-import
>> to
>> work incrementally, i.e. for selected or most recent revisions.
>
> They can or should work incrementally, and actually I have succesfully
> done that. The idea is to use --import-marks and --export-marks
> options
> with "git fast-import" and --marks option with "bzr fast-export.
>
> I noticed some problems with newer versions of "bzr fast-export",
> though
> (since it was converted to a proper Bzr command). It seems to corrupt
> the marks file when doing the first incremental export after the
> initial
> export. At least the revisions are not in right order in the marks
> file
> anymore. "git fast-import" can't continue to import from the same
> revision where it left last time and it seems to create alternative
> history -- or something.
>
> Really I don't know if this is a bug in Bzr or in Git and haven't
> figured out how to file a useful bug report.
I'm experiencing pretty much the same problem.
Looking at the code (marks_file.py) I don't see why the order would
matter (even though it would be nicer if the order was consistent). I
actually changed this so that it's always sorted, just to help me debug.
Now, I'm getting these errors back from git:
fatal: mark :96985 not declared
fast-import: dumping crash report to .git/fast_import_crash_74262
bzr: broken pipe
I couldn't reproduce this with a simple repository.
However, if one inspects the output of bzr fast-export, one finds
stuff like this:
commit refs/heads/master
mark :96984
committer <dann> 1237847130 +0000
data 205
....
from :96985
M 644 inline lisp/ChangeLog
data 741178
--- ... --- ... --- ... ---
commit refs/heads/master
mark :96985
committer <jhd> 1237849747 +0000
...
from :96984
M 644 inline src/gtkutil.c
data 135796
I'm not sure about the structure of these files, but my educated guess
would be that this is a circular reference.
Strange. One would think that this should never happen.
That said, I get the same errors in other cases as well without
circular reference.
As an experiment, I deleted the last 1000 or so revisions from the bzr
marks file, so that they would be output again.
A couple of minutes and 430MB in output later, I imported this on the
git side, which, after a few seconds, came back with this:
---------------------------------------------------------------------
Alloc'd objects: 105000
Total objects: 5 ( 5063 duplicates )
blobs : 0 ( 1549 duplicates 0 deltas)
trees : 2 ( 2505 duplicates 0 deltas)
commits: 3 ( 1009 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 1 ( 1 loads )
marks: 1048576 ( 97012 unique )
atoms: 1937
Memory total: 5380 KiB
pools: 2098 KiB
objects: 3281 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 33554432
pack_report: core.packedGitLimit = 268435456
pack_report: pack_used_ctr = 104764
pack_report: pack_mmap_calls = 6
pack_report: pack_open_windows = 4 / 4
pack_report: pack_mapped = 100666262 / 100666262
---------------------------------------------------------------------
So, it seems like there were 3 commits that were missing from previous
transfers. The final lines of the marks files for bzr and git seem
coherent. Hard to identify the culprit.
Further changes resulted in good conversion so far. Deleting a good
number of the most recent marks entries seems to be the right thing to
recover.
A "bzr uncommit" seemed not to make its way to the git side. No
good. I wonder if that is going to create a lasting inconsistency. I
did get this subsequently:
warning: Not updating refs/heads/master (new tip
6c81ccc916026d020eadeb0ad6e5b12c18aeccd3 does not contain
3222cfee5bc00412b6f5e52a420f93564f586ee9)
This "not contained" revision resolved to the uncommitted one - that
makes sense.
But what consequences does the warning have...?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-26 3:13 UTC (permalink / raw)
To: Jeff King; +Cc: Raman Gupta, git
In-Reply-To: <20090326022757.GC5835@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Mirror mode would handle this automatically, but it unfortunately also
> ignores your push refspec. So any cruft or work-in-progress refs in your
> repository would be pushed.
Exactly.
Incidentally, that is why I usually favor the current 'matching' default.
If I decide to push something to the other repository, the other
repository remembers my wish, so I do not have to keep track (of course,
for that to work effectively, you have to _own_ the other side; it does
not work well for a shared public repository and that is why we had a
lengthy discussion on push.default).
^ permalink raw reply
* Re: Reference for git.git release process
From: Jeff King @ 2009-03-26 3:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Raman Gupta, git
In-Reply-To: <7vtz5hugc6.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:
> Incidentally, that is why I usually favor the current 'matching' default.
> If I decide to push something to the other repository, the other
> repository remembers my wish, so I do not have to keep track (of course,
> for that to work effectively, you have to _own_ the other side; it does
> not work well for a shared public repository and that is why we had a
> lengthy discussion on push.default).
So if I understand correctly, you would actually like "push matching,
delete missing" behavior?
-Peff
^ permalink raw reply
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-26 3:26 UTC (permalink / raw)
To: Raman Gupta; +Cc: git
In-Reply-To: <7vocvpw4q1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Raman Gupta <rocketraman@fastmail.fm> writes:
> ...
>> ... The only
>> concern I had with this workflow was the difficult to understand
>> visualization of the history. So to repeat my earlier question: Are
>> there some canned gitk invocations, or other tips/tricks/approaches,...
>
> I do not share the difficulty, and there is no answer from me to your
> "earlier" question. Perhaps other people have some tips.
This may deserve a but more explanation as to why I do not share that
difficulty. In short, I never look at gitk output to see how next is
doing, and that is why many repeated merges to next does not bother me.
On my main integration branches ('master' and 'maint'), new development
never happens directly (I do apply trivially correct patches to them, but
they are exceptions). Because of this, you can get a pretty good overview
by running "git log --oneline --first-parent" starting from the tip of
these branches to see what topics have graduated.
My primary gitk replacement is the periodical "What's in git" and "What's
cooking in git" messages. I use a few custom scripts (Meta/WC,
Meta/git-topic.perl and Meta/UWC) to manage the latter (the production of
the former is merely "git shortlog --no-merges <last-issue>..master").
After accumulating new patches on top of topics and merging more topics to
integration branches (such as master and next), I run Meta/WC which in
turn runs Meta/UWC to read the last issue of "What's cooking", and the raw
material that should go in the next issue of the message (generated by
Meta/git-topic.perl), and the comments on each topic in the last issue is
merged to produce the draft of the next issue. I add further text to it
to describe new deveolopment to existing topics and comment on new topics
before sending it out, and another cycle begins.
^ permalink raw reply
* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Mike Gaffney @ 2009-03-26 3:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090326021259.GA5835@coredump.intra.peff.net>
Does this go for JGit as well?
-Mike
Jeff King wrote:
> On Wed, Mar 25, 2009 at 12:29:59PM -0500, Mike Gaffney wrote:
>
>> I am trying to setup a git repo internally at my work. I would like to
>> make the repo accessable via https for both read and write so that we may
>> access it from customer locations which don't allow anything but https. I
>> would also like to host it via SSH because that protocol is much faster. I
>> know that when you push with http it runs 'git update-server-info', would
>> I have to make the ssh pushes do the same? Will this even work?
>
> Yes, it should work just fine. All pushes, no matter how they arrive at
> the repository, will need to run "git update-server-info", which is what
> allows "dumb" protocols like http to read from the repository. The
> default post-update hook does this; you just need to enable it by "cd
> .git/hooks && mv post-update.sample post-update".
>
> -Peff
--
-Mike Gaffney (http://rdocul.us)
^ permalink raw reply
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-26 3:28 UTC (permalink / raw)
To: Jeff King; +Cc: Raman Gupta, git
In-Reply-To: <20090326031521.GA7984@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Mar 25, 2009 at 08:13:13PM -0700, Junio C Hamano wrote:
>
>> Incidentally, that is why I usually favor the current 'matching' default.
>> If I decide to push something to the other repository, the other
>> repository remembers my wish, so I do not have to keep track (of course,
>> for that to work effectively, you have to _own_ the other side; it does
>> not work well for a shared public repository and that is why we had a
>> lengthy discussion on push.default).
>
> So if I understand correctly, you would actually like "push matching,
> delete missing" behavior?
Hmm, that would be good. That would allow me to start publishing the
individual topics with ease.
I never thought of that.
^ permalink raw reply
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-26 3:34 UTC (permalink / raw)
To: Jeff King; +Cc: Raman Gupta, git
In-Reply-To: <20090326022757.GC5835@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Mar 25, 2009 at 12:30:31PM -0700, Junio C Hamano wrote:
>
>> I do not answer "generally" part, but in git.git, I do not publish heads
>> of individual topic branches. I could, but simply I don't, because that
>> has been the way I've operated so far, and I am too lazy to change my
>> configuration.
>
> I don't think it is a big problem in practice.
Both times Shawn took over the maintainership from me in October for the
past few years (and I will ask him to this year, too, although I do not
know if he is willing to take it again yet), it would have made his life
(and possibly everybody who had his topic in flight) much easier if they
were public. Last year I sent him for-each-ref output offline before I
took off to make it a bit easier on him (my disappearance two years ago
was unscheduled and I couldn't do that).
^ permalink raw reply
* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Jeff King @ 2009-03-26 3:36 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49CAF607.1020905@gmail.com>
On Wed, Mar 25, 2009 at 10:27:03PM -0500, Mike Gaffney wrote:
> Does this go for JGit as well?
The hook must be enabled on the server side; are you running JGit on the
server, or regular git?
-Peff
^ permalink raw reply
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: Junio C Hamano @ 2009-03-26 3:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Elijah Newren, git, gitster
In-Reply-To: <alpine.DEB.1.00.0903252312460.26370@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 25 Mar 2009, newren@gmail.com wrote:
>
>> From: Elijah Newren <newren@gmail.com>
>>
>> When exporting a subset of commits on a branch that do not go back to a
>> root commit (e.g. master~2..master), we still want each exported commit to
>> have the same files in the exported tree as in the original tree.
>>
>> Signed-off-by: Elijah Newren <newren@gmail.com>
>> ---
>
> Makes sense.
Hmm, does it?
Shouldn't an export with a bottom commit be always considered an
incremental? Why special case --import-marks?
When you say "I want to export master~2..master", isn't the intention
(unstated, because it is too obvious) that follows it "... because I do
have master~2 already and I would want to replay the export on top of that
state"? If all of master~2, master~1 and master have a file "frotz" with
exactly the same contents, I thought you wouldn't even have to have that
same contents repeated in the export datastream.
Or am I (again) entirely misunderstanding the intended use case?
^ permalink raw reply
* [PATCH] Documentation: Remove spurious uses of "you" in git-bisect.txt.
From: David J. Mellor @ 2009-03-26 3:44 UTC (permalink / raw)
To: gitster; +Cc: git, bfields
In-Reply-To: <20090324220201.GM19389@fieldses.org>
These were added by accident in a42dea3.
This patch also rewords the description of how ranges of commits can be
skipped.
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-bisect.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index a356a2b..ffc02c7 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -151,7 +151,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
# was suggested
------------
-Then you compile and test the chosen revision. Afterwards you mark
+Then compile and test the chosen revision, and afterwards mark
the revision as good or bad in the usual manner.
Bisect skip
@@ -175,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
$ git bisect skip v2.5..v2.6
------------
-This tells the bisect process that no commit between `v2.5` excluded and
-`v2.6` included should be tested.
+This tells the bisect process that no commit after `v2.5`, up to and
+including `v2.6`, should be tested.
Note that if you also want to skip the first commit of the range you
would issue the command:
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] Documentation: Remove spurious uses of "you" in git-bisect.txt.
From: Junio C Hamano @ 2009-03-26 3:48 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git, bfields
In-Reply-To: <1238039084-4810-1-git-send-email-dmellor@whistlingcat.com>
"David J. Mellor" <dmellor@whistlingcat.com> writes:
> These were added by accident in a42dea3.
>
> This patch also rewords the description of how ranges of commits can be
> skipped.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index a356a2b..ffc02c7 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -151,7 +151,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
> # was suggested
> ------------
>
> -Then you compile and test the chosen revision. Afterwards you mark
> +Then compile and test the chosen revision, and afterwards mark
> the revision as good or bad in the usual manner.
>
> Bisect skip
> @@ -175,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example:
> $ git bisect skip v2.5..v2.6
> ------------
>
> -This tells the bisect process that no commit between `v2.5` excluded and
> -`v2.6` included should be tested.
> +This tells the bisect process that no commit after `v2.5`, up to and
> +including `v2.6`, should be tested.
Thanks; this part is much easier to read now. These 'excluded/included'
have always bothered me.
^ permalink raw reply
* Re: Reference for git.git release process
From: Jeff King @ 2009-03-26 3:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Raman Gupta, git
In-Reply-To: <7v8wmtufn4.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 25, 2009 at 08:28:15PM -0700, Junio C Hamano wrote:
> > So if I understand correctly, you would actually like "push matching,
> > delete missing" behavior?
>
> Hmm, that would be good. That would allow me to start publishing the
> individual topics with ease.
>
> I never thought of that.
I'm not sure of the best way to implement it. Is it a new behavior on
par with matching, tracking, current, etc; or is "delete missing"
orthogonal to what is being pushed? Should "delete missing" attempt to
match according to your refspecs, or according to the whole repo (like
mirror)?
I was thinking "orthogonal, limited to your refspec". So configure via
git config remote.origin.prune-push true
and then you can
# pseudo-mirror following your refspec or matching behavior
git push origin
# push foo if it exists, or delete it if it doesn't
git push origin foo
# sync some subset of your refs
git push origin refs/heads/jk/*:refs/heads/jk/*
-Peff
^ permalink raw reply
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: Elijah Newren @ 2009-03-26 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vy6utt0op.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, Mar 25, 2009 at 9:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Hmm, does it?
>
> Shouldn't an export with a bottom commit be always considered an
> incremental? Why special case --import-marks?
>
> When you say "I want to export master~2..master", isn't the intention
> (unstated, because it is too obvious) that follows it "... because I do
> have master~2 already and I would want to replay the export on top of that
> state"? If all of master~2, master~1 and master have a file "frotz" with
> exactly the same contents, I thought you wouldn't even have to have that
> same contents repeated in the export datastream.
No, without the --import-marks it doesn't make sense to make it an
incremental. Think of it this way: git-fast-export converts all
sha1's into integer identifiers (marks). When you export
master~2..master, then when fast-export comes across master~1, it
notices that there's nothing to convert it's parent sha1sum into since
no information was output for master~2 in the export stream. The way
around it would be to simply export master~2 anyway, and master~3,
and...
(An alternate way around it, I guess, would be using the sha1sum in
the export stream instead of a mark...but do you have any way of
knowing whether the destination repository you import into will have
that commit? Using --import-marks seems like a nice way to specify
whether you have that information or not.)
It's perhaps a gotcha, as I know I had the same initial assumption
even after reading the manpage. Perhaps
Documentation/git-fast-export.txt could be made a bit clearer on this
point.
> Or am I (again) entirely misunderstanding the intended use case?
Exporting master~2..master without specifying --import-marks is a way
of squashing history, essentially. Perhaps you don't like it serving
this purpose, but it was intentional; looking at the master~2..master
testcase in t/t9301-fast-export.sh, you'll see
git fast-export master~2..master | sed "s/master/partial/" |
<snip some other boilerplate> && test_must_fail git rev-parse partial~2
^ permalink raw reply
* Re: [PATCH] Documentation: minor consistency fixes in git-difftool.txt.
From: David Aguilar @ 2009-03-26 4:17 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <49CA05B2.7020207@drmicha.warpmail.net>
On 0, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Junio C Hamano venit, vidit, dixit 25.03.2009 08:17:
> > David Aguilar <davvid@gmail.com> writes:
> >
> >> --- a/Documentation/git-difftool.txt
> >> +++ b/Documentation/git-difftool.txt
> >> @@ -12,7 +12,7 @@ SYNOPSIS
> >> DESCRIPTION
> >> -----------
> >> 'git-difftool' is a git command that allows you to compare and edit files
> >> -between revisions using common diff tools. 'git difftool' is a frontend
> >> +between revisions using common diff tools. 'git-difftool' is a frontend
> >
> > I thought that the recent trend is to spell these as 'git difftool' (two
> > separate words), although I didn't follow the discussion on quoting styles
> > closely, so I do not know which of sq, dq or backtick is preferred.
> >
> > Can somebody help me out here?
> >
>
> I'd say it's backticks for commands/code, but I think discussion about a
> style guide is still on.
>
> Michael
Cool, I'll keep my eye on it.
I was merely going for consistency with the existing
documentation (such as git-mergetool.txt).
Once a consensus is reached I'll go ahead and follow suite.
Thanks,
--
David
^ permalink raw reply
* Re: Use alternate GIT servers to share traffic
From: Andrew Wang @ 2009-03-26 4:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Koch, git
In-Reply-To: <alpine.DEB.1.00.0903252356160.26370@intel-tinevez-2-302>
On Wed, Mar 25, 2009 at 6:57 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 25 Mar 2009, Thomas Koch wrote:
>
>> we host a public GIT repository on our high availability company
>> cluster. Cloning the repo causes a trafic volume of 326 MB. We'd like to
>> avoid that much trafic while still leaving the GIT repo where it is.
>>
>> I could imagine the following conversation between the GIT client and
>> server:
>>
>> Client: Wanna clone!
>> Server: You're welcome. Please note, that while I serve the most current
>> state, you can get objects much faster from my collegue Server
>> CHEAPHOST.
>> Client: Thank you. Will take all the objects I can get from CHEAPHOST
>> and come back if I should need anything else!
>>
>> The enduser should not need to specify anything, but only the regular
>> git clone EXPENSIVEHOST line.
>>
>> Your thoughts?
>
> That sounds a lot like the mirror-sync idea.
>
> Ciao,
> Dscho
> --
> 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
>
Yea, that would definitely fall under mirror-sync functionality. I
wrote up my GSoC proposal for implementing this to the list
(http://marc.info/?l=git&m=123795365411979&w=2), comments and
criticism welcome.
Andrew
^ permalink raw reply
* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Mike Gaffney @ 2009-03-26 4:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090326033623.GA8031@coredump.intra.peff.net>
I'm actually trying to take what Sean did with gerrit and extract a full Java/MinaSSHD based server that doesn't require a real user account and is configurable by spring. So yes, I'm using JGit on the server.
-Mike
Jeff King wrote:
> On Wed, Mar 25, 2009 at 10:27:03PM -0500, Mike Gaffney wrote:
>
>> Does this go for JGit as well?
>
> The hook must be enabled on the server side; are you running JGit on the
> server, or regular git?
>
> -Peff
--
-Mike Gaffney (http://rdocul.us)
^ permalink raw reply
* [PATCH 01/10] refs: add "for_each_bisect_ref" function
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
refs.c | 5 +++++
refs.h | 1 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index 8d3c502..2b21148 100644
--- a/refs.c
+++ b/refs.c
@@ -662,6 +662,11 @@ int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, 0, cb_data);
}
+int for_each_bisect_ref(each_ref_fn fn, void *cb_data)
+{
+ return do_for_each_ref("refs/bisect/", fn, 12, 0, cb_data);
+}
+
int for_each_rawref(each_ref_fn fn, void *cb_data)
{
return do_for_each_ref("refs/", fn, 0,
diff --git a/refs.h b/refs.h
index 29bdcec..e5d6e80 100644
--- a/refs.h
+++ b/refs.h
@@ -23,6 +23,7 @@ extern int for_each_ref(each_ref_fn, void *);
extern int for_each_tag_ref(each_ref_fn, void *);
extern int for_each_branch_ref(each_ref_fn, void *);
extern int for_each_remote_ref(each_ref_fn, void *);
+extern int for_each_bisect_ref(each_ref_fn, void *);
/* can be used to learn about broken ref and symref */
extern int for_each_rawref(each_ref_fn, void *);
--
1.6.2.1.317.g3d804
^ permalink raw reply related
* [PATCH 02/10] rev-list: make "bisect_list" variable local to "cmd_rev_list"
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
The "bisect_list" variable was static for no reason as it is only used
in the "cmd_rev_list" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 40d5fcb..28fe2dc 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -52,7 +52,6 @@ static const char rev_list_usage[] =
static struct rev_info revs;
-static int bisect_list;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
@@ -618,6 +617,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
struct commit_list *list;
int i;
int read_from_stdin = 0;
+ int bisect_list = 0;
int bisect_show_vars = 0;
int bisect_find_all = 0;
int quiet = 0;
--
1.6.2.1.317.g3d804
^ permalink raw reply related
* [PATCH 03/10] rev-list: move bisect related code into its own file
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
This patch creates new "bisect.c" and "bisect.h" files and move
bisect related code into these files.
While at it, we also remove some include directives that are not
needed any more from the beginning of "builtin-rev-list.c".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Makefile | 1 +
bisect.c | 388 ++++++++++++++++++++++++++++++++++++++++++++++++++++
bisect.h | 8 +
builtin-rev-list.c | 388 +---------------------------------------------------
4 files changed, 398 insertions(+), 387 deletions(-)
create mode 100644 bisect.c
create mode 100644 bisect.h
diff --git a/Makefile b/Makefile
index 320c897..9fa2928 100644
--- a/Makefile
+++ b/Makefile
@@ -420,6 +420,7 @@ LIB_OBJS += archive-tar.o
LIB_OBJS += archive-zip.o
LIB_OBJS += attr.o
LIB_OBJS += base85.o
+LIB_OBJS += bisect.o
LIB_OBJS += blob.o
LIB_OBJS += branch.o
LIB_OBJS += bundle.o
diff --git a/bisect.c b/bisect.c
new file mode 100644
index 0000000..27def7d
--- /dev/null
+++ b/bisect.c
@@ -0,0 +1,388 @@
+#include "cache.h"
+#include "commit.h"
+#include "diff.h"
+#include "revision.h"
+#include "bisect.h"
+
+/* bits #0-15 in revision.h */
+
+#define COUNTED (1u<<16)
+
+/*
+ * This is a truly stupid algorithm, but it's only
+ * used for bisection, and we just don't care enough.
+ *
+ * We care just barely enough to avoid recursing for
+ * non-merge entries.
+ */
+static int count_distance(struct commit_list *entry)
+{
+ int nr = 0;
+
+ while (entry) {
+ struct commit *commit = entry->item;
+ struct commit_list *p;
+
+ if (commit->object.flags & (UNINTERESTING | COUNTED))
+ break;
+ if (!(commit->object.flags & TREESAME))
+ nr++;
+ commit->object.flags |= COUNTED;
+ p = commit->parents;
+ entry = p;
+ if (p) {
+ p = p->next;
+ while (p) {
+ nr += count_distance(p);
+ p = p->next;
+ }
+ }
+ }
+
+ return nr;
+}
+
+static void clear_distance(struct commit_list *list)
+{
+ while (list) {
+ struct commit *commit = list->item;
+ commit->object.flags &= ~COUNTED;
+ list = list->next;
+ }
+}
+
+#define DEBUG_BISECT 0
+
+static inline int weight(struct commit_list *elem)
+{
+ return *((int*)(elem->item->util));
+}
+
+static inline void weight_set(struct commit_list *elem, int weight)
+{
+ *((int*)(elem->item->util)) = weight;
+}
+
+static int count_interesting_parents(struct commit *commit)
+{
+ struct commit_list *p;
+ int count;
+
+ for (count = 0, p = commit->parents; p; p = p->next) {
+ if (p->item->object.flags & UNINTERESTING)
+ continue;
+ count++;
+ }
+ return count;
+}
+
+static inline int halfway(struct commit_list *p, int nr)
+{
+ /*
+ * Don't short-cut something we are not going to return!
+ */
+ if (p->item->object.flags & TREESAME)
+ return 0;
+ if (DEBUG_BISECT)
+ return 0;
+ /*
+ * 2 and 3 are halfway of 5.
+ * 3 is halfway of 6 but 2 and 4 are not.
+ */
+ switch (2 * weight(p) - nr) {
+ case -1: case 0: case 1:
+ return 1;
+ default:
+ return 0;
+ }
+}
+
+#if !DEBUG_BISECT
+#define show_list(a,b,c,d) do { ; } while (0)
+#else
+static void show_list(const char *debug, int counted, int nr,
+ struct commit_list *list)
+{
+ struct commit_list *p;
+
+ fprintf(stderr, "%s (%d/%d)\n", debug, counted, nr);
+
+ for (p = list; p; p = p->next) {
+ struct commit_list *pp;
+ struct commit *commit = p->item;
+ unsigned flags = commit->object.flags;
+ enum object_type type;
+ unsigned long size;
+ char *buf = read_sha1_file(commit->object.sha1, &type, &size);
+ char *ep, *sp;
+
+ fprintf(stderr, "%c%c%c ",
+ (flags & TREESAME) ? ' ' : 'T',
+ (flags & UNINTERESTING) ? 'U' : ' ',
+ (flags & COUNTED) ? 'C' : ' ');
+ if (commit->util)
+ fprintf(stderr, "%3d", weight(p));
+ else
+ fprintf(stderr, "---");
+ fprintf(stderr, " %.*s", 8, sha1_to_hex(commit->object.sha1));
+ for (pp = commit->parents; pp; pp = pp->next)
+ fprintf(stderr, " %.*s", 8,
+ sha1_to_hex(pp->item->object.sha1));
+
+ sp = strstr(buf, "\n\n");
+ if (sp) {
+ sp += 2;
+ for (ep = sp; *ep && *ep != '\n'; ep++)
+ ;
+ fprintf(stderr, " %.*s", (int)(ep - sp), sp);
+ }
+ fprintf(stderr, "\n");
+ }
+}
+#endif /* DEBUG_BISECT */
+
+static struct commit_list *best_bisection(struct commit_list *list, int nr)
+{
+ struct commit_list *p, *best;
+ int best_distance = -1;
+
+ best = list;
+ for (p = list; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (flags & TREESAME)
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ if (distance > best_distance) {
+ best = p;
+ best_distance = distance;
+ }
+ }
+
+ return best;
+}
+
+struct commit_dist {
+ struct commit *commit;
+ int distance;
+};
+
+static int compare_commit_dist(const void *a_, const void *b_)
+{
+ struct commit_dist *a, *b;
+
+ a = (struct commit_dist *)a_;
+ b = (struct commit_dist *)b_;
+ if (a->distance != b->distance)
+ return b->distance - a->distance; /* desc sort */
+ return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
+}
+
+static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
+{
+ struct commit_list *p;
+ struct commit_dist *array = xcalloc(nr, sizeof(*array));
+ int cnt, i;
+
+ for (p = list, cnt = 0; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (flags & TREESAME)
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ array[cnt].commit = p->item;
+ array[cnt].distance = distance;
+ cnt++;
+ }
+ qsort(array, cnt, sizeof(*array), compare_commit_dist);
+ for (p = list, i = 0; i < cnt; i++) {
+ struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ struct object *obj = &(array[i].commit->object);
+
+ sprintf(r->name, "dist=%d", array[i].distance);
+ r->next = add_decoration(&name_decoration, obj, r);
+ p->item = array[i].commit;
+ p = p->next;
+ }
+ if (p)
+ p->next = NULL;
+ free(array);
+ return list;
+}
+
+/*
+ * zero or positive weight is the number of interesting commits it can
+ * reach, including itself. Especially, weight = 0 means it does not
+ * reach any tree-changing commits (e.g. just above uninteresting one
+ * but traversal is with pathspec).
+ *
+ * weight = -1 means it has one parent and its distance is yet to
+ * be computed.
+ *
+ * weight = -2 means it has more than one parent and its distance is
+ * unknown. After running count_distance() first, they will get zero
+ * or positive distance.
+ */
+static struct commit_list *do_find_bisection(struct commit_list *list,
+ int nr, int *weights,
+ int find_all)
+{
+ int n, counted;
+ struct commit_list *p;
+
+ counted = 0;
+
+ for (n = 0, p = list; p; p = p->next) {
+ struct commit *commit = p->item;
+ unsigned flags = commit->object.flags;
+
+ p->item->util = &weights[n++];
+ switch (count_interesting_parents(commit)) {
+ case 0:
+ if (!(flags & TREESAME)) {
+ weight_set(p, 1);
+ counted++;
+ show_list("bisection 2 count one",
+ counted, nr, list);
+ }
+ /*
+ * otherwise, it is known not to reach any
+ * tree-changing commit and gets weight 0.
+ */
+ break;
+ case 1:
+ weight_set(p, -1);
+ break;
+ default:
+ weight_set(p, -2);
+ break;
+ }
+ }
+
+ show_list("bisection 2 initialize", counted, nr, list);
+
+ /*
+ * If you have only one parent in the resulting set
+ * then you can reach one commit more than that parent
+ * can reach. So we do not have to run the expensive
+ * count_distance() for single strand of pearls.
+ *
+ * However, if you have more than one parents, you cannot
+ * just add their distance and one for yourself, since
+ * they usually reach the same ancestor and you would
+ * end up counting them twice that way.
+ *
+ * So we will first count distance of merges the usual
+ * way, and then fill the blanks using cheaper algorithm.
+ */
+ for (p = list; p; p = p->next) {
+ if (p->item->object.flags & UNINTERESTING)
+ continue;
+ if (weight(p) != -2)
+ continue;
+ weight_set(p, count_distance(p));
+ clear_distance(list);
+
+ /* Does it happen to be at exactly half-way? */
+ if (!find_all && halfway(p, nr))
+ return p;
+ counted++;
+ }
+
+ show_list("bisection 2 count_distance", counted, nr, list);
+
+ while (counted < nr) {
+ for (p = list; p; p = p->next) {
+ struct commit_list *q;
+ unsigned flags = p->item->object.flags;
+
+ if (0 <= weight(p))
+ continue;
+ for (q = p->item->parents; q; q = q->next) {
+ if (q->item->object.flags & UNINTERESTING)
+ continue;
+ if (0 <= weight(q))
+ break;
+ }
+ if (!q)
+ continue;
+
+ /*
+ * weight for p is unknown but q is known.
+ * add one for p itself if p is to be counted,
+ * otherwise inherit it from q directly.
+ */
+ if (!(flags & TREESAME)) {
+ weight_set(p, weight(q)+1);
+ counted++;
+ show_list("bisection 2 count one",
+ counted, nr, list);
+ }
+ else
+ weight_set(p, weight(q));
+
+ /* Does it happen to be at exactly half-way? */
+ if (!find_all && halfway(p, nr))
+ return p;
+ }
+ }
+
+ show_list("bisection 2 counted all", counted, nr, list);
+
+ if (!find_all)
+ return best_bisection(list, nr);
+ else
+ return best_bisection_sorted(list, nr);
+}
+
+struct commit_list *find_bisection(struct commit_list *list,
+ int *reaches, int *all,
+ int find_all)
+{
+ int nr, on_list;
+ struct commit_list *p, *best, *next, *last;
+ int *weights;
+
+ show_list("bisection 2 entry", 0, 0, list);
+
+ /*
+ * Count the number of total and tree-changing items on the
+ * list, while reversing the list.
+ */
+ for (nr = on_list = 0, last = NULL, p = list;
+ p;
+ p = next) {
+ unsigned flags = p->item->object.flags;
+
+ next = p->next;
+ if (flags & UNINTERESTING)
+ continue;
+ p->next = last;
+ last = p;
+ if (!(flags & TREESAME))
+ nr++;
+ on_list++;
+ }
+ list = last;
+ show_list("bisection 2 sorted", 0, nr, list);
+
+ *all = nr;
+ weights = xcalloc(on_list, sizeof(*weights));
+
+ /* Do the real work of finding bisection commit. */
+ best = do_find_bisection(list, nr, weights, find_all);
+ if (best) {
+ if (!find_all)
+ best->next = NULL;
+ *reaches = weight(best);
+ }
+ free(weights);
+ return best;
+}
+
diff --git a/bisect.h b/bisect.h
new file mode 100644
index 0000000..60b2fe1
--- /dev/null
+++ b/bisect.h
@@ -0,0 +1,8 @@
+#ifndef BISECT_H
+#define BISECT_H
+
+extern struct commit_list *find_bisection(struct commit_list *list,
+ int *reaches, int *all,
+ int find_all);
+
+#endif
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 28fe2dc..b1e8200 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -1,20 +1,12 @@
#include "cache.h"
-#include "refs.h"
-#include "tag.h"
#include "commit.h"
-#include "tree.h"
-#include "blob.h"
-#include "tree-walk.h"
#include "diff.h"
#include "revision.h"
#include "list-objects.h"
#include "builtin.h"
#include "log-tree.h"
#include "graph.h"
-
-/* bits #0-15 in revision.h */
-
-#define COUNTED (1u<<16)
+#include "bisect.h"
static const char rev_list_usage[] =
"git rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
@@ -195,384 +187,6 @@ static void show_edge(struct commit *commit)
printf("-%s\n", sha1_to_hex(commit->object.sha1));
}
-/*
- * This is a truly stupid algorithm, but it's only
- * used for bisection, and we just don't care enough.
- *
- * We care just barely enough to avoid recursing for
- * non-merge entries.
- */
-static int count_distance(struct commit_list *entry)
-{
- int nr = 0;
-
- while (entry) {
- struct commit *commit = entry->item;
- struct commit_list *p;
-
- if (commit->object.flags & (UNINTERESTING | COUNTED))
- break;
- if (!(commit->object.flags & TREESAME))
- nr++;
- commit->object.flags |= COUNTED;
- p = commit->parents;
- entry = p;
- if (p) {
- p = p->next;
- while (p) {
- nr += count_distance(p);
- p = p->next;
- }
- }
- }
-
- return nr;
-}
-
-static void clear_distance(struct commit_list *list)
-{
- while (list) {
- struct commit *commit = list->item;
- commit->object.flags &= ~COUNTED;
- list = list->next;
- }
-}
-
-#define DEBUG_BISECT 0
-
-static inline int weight(struct commit_list *elem)
-{
- return *((int*)(elem->item->util));
-}
-
-static inline void weight_set(struct commit_list *elem, int weight)
-{
- *((int*)(elem->item->util)) = weight;
-}
-
-static int count_interesting_parents(struct commit *commit)
-{
- struct commit_list *p;
- int count;
-
- for (count = 0, p = commit->parents; p; p = p->next) {
- if (p->item->object.flags & UNINTERESTING)
- continue;
- count++;
- }
- return count;
-}
-
-static inline int halfway(struct commit_list *p, int nr)
-{
- /*
- * Don't short-cut something we are not going to return!
- */
- if (p->item->object.flags & TREESAME)
- return 0;
- if (DEBUG_BISECT)
- return 0;
- /*
- * 2 and 3 are halfway of 5.
- * 3 is halfway of 6 but 2 and 4 are not.
- */
- switch (2 * weight(p) - nr) {
- case -1: case 0: case 1:
- return 1;
- default:
- return 0;
- }
-}
-
-#if !DEBUG_BISECT
-#define show_list(a,b,c,d) do { ; } while (0)
-#else
-static void show_list(const char *debug, int counted, int nr,
- struct commit_list *list)
-{
- struct commit_list *p;
-
- fprintf(stderr, "%s (%d/%d)\n", debug, counted, nr);
-
- for (p = list; p; p = p->next) {
- struct commit_list *pp;
- struct commit *commit = p->item;
- unsigned flags = commit->object.flags;
- enum object_type type;
- unsigned long size;
- char *buf = read_sha1_file(commit->object.sha1, &type, &size);
- char *ep, *sp;
-
- fprintf(stderr, "%c%c%c ",
- (flags & TREESAME) ? ' ' : 'T',
- (flags & UNINTERESTING) ? 'U' : ' ',
- (flags & COUNTED) ? 'C' : ' ');
- if (commit->util)
- fprintf(stderr, "%3d", weight(p));
- else
- fprintf(stderr, "---");
- fprintf(stderr, " %.*s", 8, sha1_to_hex(commit->object.sha1));
- for (pp = commit->parents; pp; pp = pp->next)
- fprintf(stderr, " %.*s", 8,
- sha1_to_hex(pp->item->object.sha1));
-
- sp = strstr(buf, "\n\n");
- if (sp) {
- sp += 2;
- for (ep = sp; *ep && *ep != '\n'; ep++)
- ;
- fprintf(stderr, " %.*s", (int)(ep - sp), sp);
- }
- fprintf(stderr, "\n");
- }
-}
-#endif /* DEBUG_BISECT */
-
-static struct commit_list *best_bisection(struct commit_list *list, int nr)
-{
- struct commit_list *p, *best;
- int best_distance = -1;
-
- best = list;
- for (p = list; p; p = p->next) {
- int distance;
- unsigned flags = p->item->object.flags;
-
- if (flags & TREESAME)
- continue;
- distance = weight(p);
- if (nr - distance < distance)
- distance = nr - distance;
- if (distance > best_distance) {
- best = p;
- best_distance = distance;
- }
- }
-
- return best;
-}
-
-struct commit_dist {
- struct commit *commit;
- int distance;
-};
-
-static int compare_commit_dist(const void *a_, const void *b_)
-{
- struct commit_dist *a, *b;
-
- a = (struct commit_dist *)a_;
- b = (struct commit_dist *)b_;
- if (a->distance != b->distance)
- return b->distance - a->distance; /* desc sort */
- return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
-}
-
-static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
-{
- struct commit_list *p;
- struct commit_dist *array = xcalloc(nr, sizeof(*array));
- int cnt, i;
-
- for (p = list, cnt = 0; p; p = p->next) {
- int distance;
- unsigned flags = p->item->object.flags;
-
- if (flags & TREESAME)
- continue;
- distance = weight(p);
- if (nr - distance < distance)
- distance = nr - distance;
- array[cnt].commit = p->item;
- array[cnt].distance = distance;
- cnt++;
- }
- qsort(array, cnt, sizeof(*array), compare_commit_dist);
- for (p = list, i = 0; i < cnt; i++) {
- struct name_decoration *r = xmalloc(sizeof(*r) + 100);
- struct object *obj = &(array[i].commit->object);
-
- sprintf(r->name, "dist=%d", array[i].distance);
- r->next = add_decoration(&name_decoration, obj, r);
- p->item = array[i].commit;
- p = p->next;
- }
- if (p)
- p->next = NULL;
- free(array);
- return list;
-}
-
-/*
- * zero or positive weight is the number of interesting commits it can
- * reach, including itself. Especially, weight = 0 means it does not
- * reach any tree-changing commits (e.g. just above uninteresting one
- * but traversal is with pathspec).
- *
- * weight = -1 means it has one parent and its distance is yet to
- * be computed.
- *
- * weight = -2 means it has more than one parent and its distance is
- * unknown. After running count_distance() first, they will get zero
- * or positive distance.
- */
-static struct commit_list *do_find_bisection(struct commit_list *list,
- int nr, int *weights,
- int find_all)
-{
- int n, counted;
- struct commit_list *p;
-
- counted = 0;
-
- for (n = 0, p = list; p; p = p->next) {
- struct commit *commit = p->item;
- unsigned flags = commit->object.flags;
-
- p->item->util = &weights[n++];
- switch (count_interesting_parents(commit)) {
- case 0:
- if (!(flags & TREESAME)) {
- weight_set(p, 1);
- counted++;
- show_list("bisection 2 count one",
- counted, nr, list);
- }
- /*
- * otherwise, it is known not to reach any
- * tree-changing commit and gets weight 0.
- */
- break;
- case 1:
- weight_set(p, -1);
- break;
- default:
- weight_set(p, -2);
- break;
- }
- }
-
- show_list("bisection 2 initialize", counted, nr, list);
-
- /*
- * If you have only one parent in the resulting set
- * then you can reach one commit more than that parent
- * can reach. So we do not have to run the expensive
- * count_distance() for single strand of pearls.
- *
- * However, if you have more than one parents, you cannot
- * just add their distance and one for yourself, since
- * they usually reach the same ancestor and you would
- * end up counting them twice that way.
- *
- * So we will first count distance of merges the usual
- * way, and then fill the blanks using cheaper algorithm.
- */
- for (p = list; p; p = p->next) {
- if (p->item->object.flags & UNINTERESTING)
- continue;
- if (weight(p) != -2)
- continue;
- weight_set(p, count_distance(p));
- clear_distance(list);
-
- /* Does it happen to be at exactly half-way? */
- if (!find_all && halfway(p, nr))
- return p;
- counted++;
- }
-
- show_list("bisection 2 count_distance", counted, nr, list);
-
- while (counted < nr) {
- for (p = list; p; p = p->next) {
- struct commit_list *q;
- unsigned flags = p->item->object.flags;
-
- if (0 <= weight(p))
- continue;
- for (q = p->item->parents; q; q = q->next) {
- if (q->item->object.flags & UNINTERESTING)
- continue;
- if (0 <= weight(q))
- break;
- }
- if (!q)
- continue;
-
- /*
- * weight for p is unknown but q is known.
- * add one for p itself if p is to be counted,
- * otherwise inherit it from q directly.
- */
- if (!(flags & TREESAME)) {
- weight_set(p, weight(q)+1);
- counted++;
- show_list("bisection 2 count one",
- counted, nr, list);
- }
- else
- weight_set(p, weight(q));
-
- /* Does it happen to be at exactly half-way? */
- if (!find_all && halfway(p, nr))
- return p;
- }
- }
-
- show_list("bisection 2 counted all", counted, nr, list);
-
- if (!find_all)
- return best_bisection(list, nr);
- else
- return best_bisection_sorted(list, nr);
-}
-
-static struct commit_list *find_bisection(struct commit_list *list,
- int *reaches, int *all,
- int find_all)
-{
- int nr, on_list;
- struct commit_list *p, *best, *next, *last;
- int *weights;
-
- show_list("bisection 2 entry", 0, 0, list);
-
- /*
- * Count the number of total and tree-changing items on the
- * list, while reversing the list.
- */
- for (nr = on_list = 0, last = NULL, p = list;
- p;
- p = next) {
- unsigned flags = p->item->object.flags;
-
- next = p->next;
- if (flags & UNINTERESTING)
- continue;
- p->next = last;
- last = p;
- if (!(flags & TREESAME))
- nr++;
- on_list++;
- }
- list = last;
- show_list("bisection 2 sorted", 0, nr, list);
-
- *all = nr;
- weights = xcalloc(on_list, sizeof(*weights));
-
- /* Do the real work of finding bisection commit. */
- best = do_find_bisection(list, nr, weights, find_all);
- if (best) {
- if (!find_all)
- best->next = NULL;
- *reaches = weight(best);
- }
- free(weights);
- return best;
-}
-
static inline int log2i(int n)
{
int log2 = 0;
--
1.6.2.1.317.g3d804
^ permalink raw reply related
* [PATCH 04/10] rev-list: move code to show bisect vars into its own function
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
This is a straightforward clean up to make "cmd_rev_list" function
smaller.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 83 ++++++++++++++++++++++++++++------------------------
1 files changed, 45 insertions(+), 38 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index b1e8200..74d22b4 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -226,6 +226,49 @@ static int estimate_bisect_steps(int all)
return (e < 3 * x) ? n : n - 1;
}
+static int show_bisect_vars(int reaches, int all, int bisect_find_all)
+{
+ int cnt;
+ char hex[41];
+
+ if (!revs.commits)
+ return 1;
+
+ /*
+ * revs.commits can reach "reaches" commits among
+ * "all" commits. If it is good, then there are
+ * (all-reaches) commits left to be bisected.
+ * On the other hand, if it is bad, then the set
+ * to bisect is "reaches".
+ * A bisect set of size N has (N-1) commits further
+ * to test, as we already know one bad one.
+ */
+ cnt = all - reaches;
+ if (cnt < reaches)
+ cnt = reaches;
+ strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+
+ if (bisect_find_all) {
+ traverse_commit_list(&revs, show_commit, show_object);
+ printf("------\n");
+ }
+
+ printf("bisect_rev=%s\n"
+ "bisect_nr=%d\n"
+ "bisect_good=%d\n"
+ "bisect_bad=%d\n"
+ "bisect_all=%d\n"
+ "bisect_steps=%d\n",
+ hex,
+ cnt - 1,
+ all - reaches - 1,
+ reaches - 1,
+ all,
+ estimate_bisect_steps(all));
+
+ return 0;
+}
+
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
@@ -313,44 +356,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
revs.commits = find_bisection(revs.commits, &reaches, &all,
bisect_find_all);
- if (bisect_show_vars) {
- int cnt;
- char hex[41];
- if (!revs.commits)
- return 1;
- /*
- * revs.commits can reach "reaches" commits among
- * "all" commits. If it is good, then there are
- * (all-reaches) commits left to be bisected.
- * On the other hand, if it is bad, then the set
- * to bisect is "reaches".
- * A bisect set of size N has (N-1) commits further
- * to test, as we already know one bad one.
- */
- cnt = all - reaches;
- if (cnt < reaches)
- cnt = reaches;
- strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
-
- if (bisect_find_all) {
- traverse_commit_list(&revs, show_commit, show_object);
- printf("------\n");
- }
-
- printf("bisect_rev=%s\n"
- "bisect_nr=%d\n"
- "bisect_good=%d\n"
- "bisect_bad=%d\n"
- "bisect_all=%d\n"
- "bisect_steps=%d\n",
- hex,
- cnt - 1,
- all - reaches - 1,
- reaches - 1,
- all,
- estimate_bisect_steps(all));
- return 0;
- }
+ if (bisect_show_vars)
+ return show_bisect_vars(reaches, all, bisect_find_all);
}
traverse_commit_list(&revs,
--
1.6.2.1.317.g3d804
^ permalink raw reply related
* [PATCH 05/10] rev-list: make "show_bisect_vars" non static
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
and declare it in "bisect.h" as we will use this function later.
While at it, rename its last argument "show_all" instead of
"bisect_find_all".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
bisect.h | 2 ++
builtin-rev-list.c | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/bisect.h b/bisect.h
index 60b2fe1..860a15c 100644
--- a/bisect.h
+++ b/bisect.h
@@ -5,4 +5,6 @@ extern struct commit_list *find_bisection(struct commit_list *list,
int *reaches, int *all,
int find_all);
+extern int show_bisect_vars(int reaches, int all, int show_all);
+
#endif
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 74d22b4..c700c34 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -226,7 +226,7 @@ static int estimate_bisect_steps(int all)
return (e < 3 * x) ? n : n - 1;
}
-static int show_bisect_vars(int reaches, int all, int bisect_find_all)
+int show_bisect_vars(int reaches, int all, int show_all)
{
int cnt;
char hex[41];
@@ -246,9 +246,10 @@ static int show_bisect_vars(int reaches, int all, int bisect_find_all)
cnt = all - reaches;
if (cnt < reaches)
cnt = reaches;
+
strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
- if (bisect_find_all) {
+ if (show_all) {
traverse_commit_list(&revs, show_commit, show_object);
printf("------\n");
}
--
1.6.2.1.317.g3d804
^ permalink raw reply related
* [PATCH 06/10] rev-list: pass "revs" to "show_bisect_vars"
From: Christian Couder @ 2009-03-26 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
instead of using static "revs" data
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
bisect.h | 3 ++-
builtin-rev-list.c | 13 +++++++------
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/bisect.h b/bisect.h
index 860a15c..31c99fe 100644
--- a/bisect.h
+++ b/bisect.h
@@ -5,6 +5,7 @@ extern struct commit_list *find_bisection(struct commit_list *list,
int *reaches, int *all,
int find_all);
-extern int show_bisect_vars(int reaches, int all, int show_all);
+extern int show_bisect_vars(struct rev_info *revs, int reaches, int all,
+ int show_all);
#endif
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index c700c34..cdb0f9d 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -226,16 +226,16 @@ static int estimate_bisect_steps(int all)
return (e < 3 * x) ? n : n - 1;
}
-int show_bisect_vars(int reaches, int all, int show_all)
+int show_bisect_vars(struct rev_info *revs, int reaches, int all, int show_all)
{
int cnt;
char hex[41];
- if (!revs.commits)
+ if (!revs->commits)
return 1;
/*
- * revs.commits can reach "reaches" commits among
+ * revs->commits can reach "reaches" commits among
* "all" commits. If it is good, then there are
* (all-reaches) commits left to be bisected.
* On the other hand, if it is bad, then the set
@@ -247,10 +247,10 @@ int show_bisect_vars(int reaches, int all, int show_all)
if (cnt < reaches)
cnt = reaches;
- strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+ strcpy(hex, sha1_to_hex(revs->commits->item->object.sha1));
if (show_all) {
- traverse_commit_list(&revs, show_commit, show_object);
+ traverse_commit_list(revs, show_commit, show_object);
printf("------\n");
}
@@ -358,7 +358,8 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
revs.commits = find_bisection(revs.commits, &reaches, &all,
bisect_find_all);
if (bisect_show_vars)
- return show_bisect_vars(reaches, all, bisect_find_all);
+ return show_bisect_vars(&revs, reaches, all,
+ bisect_find_all);
}
traverse_commit_list(&revs,
--
1.6.2.1.317.g3d804
^ 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