* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Johannes Schindelin @ 2009-08-24 16:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908241333130.11375@intel-tinevez-2-302>
Hi,
On Mon, 24 Aug 2009, Johannes Schindelin wrote:
> On Mon, 24 Aug 2009, Nicolas Pitre wrote:
>
> > On Tue, 18 Aug 2009, Johannes Schindelin wrote:
> >
> > > On Mon, 17 Aug 2009, Nicolas Pitre wrote:
> > >
> > > > They are both slower than the new BLK_SHA1 implementation, so it is
> > > > pointless to keep them around.
> > > >
> > > > Signed-off-by: Nicolas Pitre <nico@cam.org> ---
> > > >
> > > > Someone else would need to make the call for the PPC version.
> > >
> > > If I don't forget, I can test tomorrow on 2 different 32-bit PPCs and
> > > possibly one 64-bit PPC.
> >
> > Did you forget? ;-)
>
> Yes.
At long last (XTools took a real long time to install here; it is an old
PowerPC running MacOSX):
Best of 10 "git rev-list --all" runs on a full Git repository (including
my own tree):
before 30ae47b4
1.85 real, 1.52 user, 0.28 sys
after 30ae47b4
1.86 real, 1.52 user, 0.28 sys
To be frank, the 1.85 looks like an outlier, so I think there is exactly 0
difference between the two.
If you want me to perform other tests, please let me know; I'll be back at
this computer tomorrow.
Ciao,
Dscho
^ permalink raw reply
* Possible regression: overwriting untracked files in a fresh repo
From: Johannes Schindelin @ 2009-08-24 16:31 UTC (permalink / raw)
To: git
Hi,
I _think_ that this used to complain about untracked files being
overwritten:
$ git init
$ git remote add -f origin <url>
$ git checkout -b blub origin/master
It does not do that here (any longer, IIAC). Intended?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Daniel Barkalow @ 2009-08-24 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Schindelin, git
In-Reply-To: <7vocq5q0j7.fsf@alter.siamese.dyndns.org>
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > If all refs sent by the remote repo during a fetch are reachable
> > locally, then no further conversation is performed with the remote. This
> > check is skipped when the --depth argument is provided to allow the
> > deepening of a shallow clone which corresponding remote repo has no
> > changed.
> >
> > However, some additional filtering was added in commit c29727d5 to
> > remove those refs which are equal on both sides. If the remote repo has
> > not changed, then the list of refs to give the remote process becomes
> > empty and simply attempting to deepen a shallow repo always fails.
> >
> > Let's stop being smart in that case and simply send the whole list over
> > when that condition is met. The remote will do the right thing anyways.
> >
> > Test cases for this issue are also provided.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
>
> Thanks. The fix looks correct (as usual with patches from you).
>
> But it makes me wonder if this logic to filter refs is buying us anything.
>
> > for (rm = refs; rm; rm = rm->next) {
> > + nr_refs++;
> > if (rm->peer_ref &&
> > !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
> > continue;
> ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
> heads[nr_heads++] = rm;
> }
>
> What is the point of not asking for the refs that we know are the same?
This code is part of the original C implementation of fetch; I suspect the
optimization was somehow in the shell version and made sense there,
perhaps because there wasn't a quickfetch in the shell version or that
there was some non-negligable per-ref cost in the code around there, since
it was calling helper programs and such.
Anyway, I think it makes sense to remove the filtering from
transport_fetch_refs(), like your patch does.
If it makes a difference for the actual protocol, fetch_refs_via_pack()
could filter them at that stage.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: gitosis-lite
From: Jakub Narebski @ 2009-08-24 15:43 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240735n5f754c87u960493c92769c0a8@mail.gmail.com>
On Mon, 24 August 2009, Sitaram Chamarty wrote:
> On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>
> > Could you add information about this tool (perhaps after confirmation
> > / deciding on project name[1]) to Git Wiki page
> > http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> > somewhere below Gitosis? Please do not forget to include that it is
> > written in Perl; see other entries for example.
>
> Will do; though I'll probably wait until at least one person
> other than me has used it :)
On the other hand having the link in IFAT wiki page could help you
gain more users of gitosis-lite (name pending ;-)
> > You wrote in project's README.markdown that you were inspired by
> > Gitosis (which requires Python and python-setuptools) and
> > Documentation/howto/update-hook-example.txt (which uses bash).
> > Why not contrib/hooks/update-paranoid (which is written in Perl)?
>
> Hmmm several reasons. To start with, it appears to me that
> update-paranoid assumes each user has his own ACL file, and
> I'm going the other way -- you'll notice I have exactly one
> file as a single ACL source for many *projects*, leave alone
> users.
Well, gitosis uses single SSH user: 'git' (by default, at least).
Also from what I understand update-paranoid uses the same set of ACLs
for all projects (well, depending how $acl_git and $acl_branch are
defined).
> Secondly, I want to stick to the gitosis philosophy -- it
> has served very well, and I'm not sure how "in use"
> update-paranoid is.
I wonder about this too.
> Thirdly, I'm not comfortable having a hook be so complex.
> The whole thing is 10 lines shorter than all my code put
> together :)
The update-paranoid hook has inline POD documentation, which adds to
its size (I think that your gitosis-lite (name pending) should also
use this Perl literate programming convention). On the other hand
this documentation is not, unfortunately, up to date; for example
it allows to control which directories you can change, which is not
documented in POD.
> And finally, it's far too complex for me, leave alone some
> of my users. I count 6 pipe opens in there, and the ACLs
> are read by git cat-file or something :)
That's because update-paranoid, like gitosis, uses configuration in
$scl_repo repository. git-cat-file is low level (plumbing) equivalent
of git-show (porcelain).
Those pipelines are required for strict (paranoid) access control that
update-paranoid uses: checking that committers are on allowed list,
that taggers are on allowed list, that branches points to commits, that
tags points to tag objects, etc.
> I'll be honest: I
> came away feeling very stupid after trying to read and
> understand that program. It was... humbling :(
On the other hand it uses subroutine prototypes (unnecessary, and not
recommended), old-style bareword filehandles instead of lexically scoped
filehandles ("open I, ..." vs "open my $fh, ...")
> > Using Perl code for configuration is simple and fast, but not very
> > secure. Why not use git config format (via "git config -l -z" like in
>
> Not secure in what sense? Only the "git admin" (whoever
> owns the account in which gitosis-lite is running) will be
> able to generate it, and only scripts that run with his
> authority (by way of hooks in repos he owns) can run it.
>
> It cannot do what he did not intend to do, and what he wants
> to do he can do anyway, whether it's JSON or perl.
>
> Except for umasking the file, I don't see anything I missed.
> Could you help me understand?
Ah, thats O.K. then.
>
> > gitweb), or YAML or JSON (or Storable)? Well, YAML might be overkill.
>
> One of the objectives is to work *as is* on any Unix system
> that managed to install git (which implies Perl). So, no
> JSON or YAML. Storable would be fine (I think it's also
> part of core perl) so if I find a compelling reason I don't
> mind switching to that.
One reason to not use Storable is that it is binary. Another that format
is not exactly stable (but it contains version info, so it is backwards
compatibile I think).
As for dependencies: some people on #perl told me to not worry about
dependencies because there is PAR :-)
>
> All I really have is a nested hash to be saved and restored
> -- nothing more complex, no objects, no blessed refs, etc.
JSON would be good then ;-)
>
> > BTW. if you blog about gitosis-lite (http://sitaramc.blogspot.com/)
> > it could be picked up by Perl Iron Man Blogging challenge, and you
> > could get wider review.
>
> Will do; thanks. I did not know my blog got picked up by
> anything; till date it has never come up on a google search
> or a blog search anywhere, and it's more of a rant-box +
> annotated bookmarking service for myself :)
I don't know if it would be picked; still, you can try to submit it to
(join) http://ironman.enlightenedperl.org; note that only posts which
contain one of magic words ('perl', 'ironman', ...) would get picked by
this planet.
>
> > [1]: gitosis-lite doesn't look like CPAN-y name. Git::Admin perlhaps?
>
> Too presumptuous for someone like me -- makes it sound like
> the "one true way to Admin git" :)
Git::Auth perhaps (authentication and authorization)?
Git::AccessControl?
You can always ask on #perl (also on freenode).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Johan Herland @ 2009-08-24 15:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
On Monday 24 August 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-08-13) 3 commits
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: put option parsing code in seperate functions
>
> What is this used by?
I'm planning to use it in the CVS remote helper, as a somewhat cleaner
replacement of this one:
> * db/vcs-helper (2009-08-09) 17 commits
> - Allow helpers to request marks for fast-import
In other words, I need one or the other, and I currently find the
gfi-options solution somewhat more elegant than adding the 'marks
<filename>' command to the foreign remote API.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: gitosis-lite
From: Shawn O. Pearce @ 2009-08-24 15:10 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jakub Narebski, Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240735n5f754c87u960493c92769c0a8@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > Why not contrib/hooks/update-paranoid (which is written in Perl)?
>
> Hmmm several reasons. To start with, it appears to me that
> update-paranoid assumes each user has his own ACL file, and
> I'm going the other way -- you'll notice I have exactly one
> file as a single ACL source for many *projects*, leave alone
> users.
That is true, update-paranoid uses an ACL file per user, because
we approached it from the perspective of "what can this user do"
rather than "what is allowed in this project".
We later ran into needing groups, which meant that in practice the
per-user ACL files really just enumerated what groups they were
a member of, and the group ACL files enumerated what they were
allowed to do in projects.
I can certainly see how this might be backwards, and someone would
prefer the other direction, a per-project listing or something.
> Secondly, I want to stick to the gitosis philosophy -- it
> has served very well, and I'm not sure how "in use"
> update-paranoid is.
Well, my prior job used it heavily, and I think is still using it,
a year after I left. My current job would use it, except that we
went and wrote Gerrit Code Review instead. :-)
> Thirdly, I'm not comfortable having a hook be so complex.
> The whole thing is 10 lines shorter than all my code put
> together :)
Yes, update-paranoid is a big script. It does a lot. It not only
checks "can you write in this repository, on this branch" but it
also checks that every commit matches your own email address(es),
and it can also check file path edits, to see if you can modify
the files that were changed.
> And finally, it's far too complex for me, leave alone some
> of my users. I count 6 pipe opens in there,
Not surprised, it needs to read a lot of data from git to do its
job correctly. It has to enumerate all new commits, any commits
which may be discarded by the update (non-fast-forward), as well
as scan the diff to see which paths were affected.
> and the ACLs
> are read by git cat-file or something
Because I didn't want to check out a copy of the ACLs to the local
disk just to read them into the hook. The hook pulls them directly
out of a bare "admin" repository, making it easier to push changes
into the repository and have them take effect immediately.
I know Gitosis handles this by having a magic hook in the admin
repository that copies the file out. update-paranoid just reads
it from git.
> I'll be honest: I
> came away feeling very stupid after trying to read and
> understand that program. It was... humbling :(
*sigh* That's not good, the hook is meant as a practical example,
if it was too complex to understand, I did a poor job of writing it.
--
Shawn.
^ permalink raw reply
* sr/gfi-options, was Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Johannes Schindelin @ 2009-08-24 14:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> * sr/gfi-options (2009-08-13) 3 commits
> - fast-import: test the new option command
> - fast-import: add option command
> - fast-import: put option parsing code in seperate functions
>
> What is this used by?
By a hg-fast-import Sverre was writing for me:
http://github.com/SRabbelier/hg-git/tree/fast-export
Sverre hinted at the possibility of ripping this out of hg-git and putting
it into a hg:// helper.
Ciao,
Dscho
^ permalink raw reply
* Git workflow: Managing topic branches.
From: Thomas Adam @ 2009-08-24 14:44 UTC (permalink / raw)
To: git list
Hello all,
I've a question regarding a specific workflow which we're currently using
here at work, but I am not convinced it's particularly brilliant -- and
there's a number of oddities about it which I'd like to discus -- perhaps
with a way of coming up with a new solution.
We have a work-flow such as this:
o---o---o---o--o--o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
Master is where all our stable code lives after a release -- and also where
bug-fixes for released code is put. When we're working on a new feature,
almost all developers here will push (in this case) to "featureA" ---
eventually this branch will get merged into master, tagged and the code
released. Then a new branch, "featureB" is created off it, and process
continues. (Yes, we're using Git in a very CVS-like way, alas.)
Periodically though we need to release updates for our product. This the
area which is where my question lies about whether the workflow is good or
not. Here's how we do that:
We have a branch called "stable" which contains all of our released code
plus any updates release. When we wish to create a new update, we create a
new branch off the tip of stable:
o---o---o---o (updateN)
/
o---o---o---o--o--o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
Because bug-fixes happen on Master, we now want those fixes to appear on the
updateN branch so we can create a tarball from them (to release to our
customers). We're using "git cherry" to get a list of SHA1s that are
relevant between updateN and master, as in:
git cherry updateN master
... and then manually deciding (based on it's "+"/"-" output whether that
SHA1 needs to be used and then:
git cherry-pick SHA1
... onto updateN as appropriate. This branch is then pushed to our
"central" server as a public branch, is checked out elsewhere on another
macine to build this update. If that's successful, various other bits and
bobs in terms of meta data is added into the commits onto the updateN branch
and it is merged into stable:
o---o---o---o (updateN)
/ / <-- (merge updateN to stable)
o---o---o---o--o--o------------o (stable)
/
o---o---o---o---o---o---o (master)
\
o---o--o---o---o---o (featureA)
The "stable" branch is then merged into master so that when we create
another "featureX" branch, it's at a point where it's on a known set of
released code.
So my questions: I am not convinced this workflow is very elegant, or
indeed a particularly good solution to what we're wanting to do. Because
the cherry-picking that happens to the "updateN" branch happens from
"master" which itself will have had several local topic-branches merged into
it from other developers -- I've found "git-cherry" to give unreliable
results -- in some cases, the same two commits with the same data appear on
the "updateN" branch -- using git patch-id manually with processing on top
of that seems to give a much shorter and succient set of SHA1s to
cherry-pick. (But this is kind of peripheral to my question).
I am interested to know if this branch and merge scenario is the right one.
I also don't believe we're using git-cherry in the right way to isolate the
correct commits. I have toyed with the idea of rebasing, but am hesitant on
this idea, and unsure if that would even be the right way to go --
especially seeing as all the branches mentioned are tracking branches.
The eventual aim of all of this is to try and automate building of these
updates -- but we sure as hell can't do that at the moment with our current
workflow. If anyone has any suggestions on any of this, I'd appreciate it.
If I've not explained things adequately. shout and I'll try and clarify.
Thanks in advance,
Thomas Adam
^ permalink raw reply
* Re: Announcement: cvs2svn 2.3.0 released
From: Michael Haggerty @ 2009-08-24 14:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0908241632470.11375@intel-tinevez-2-302>
Johannes Schindelin wrote:
> On Sun, 23 Aug 2009, Michael Haggerty wrote:
>> I am happy to announce release 2.3.0 of cvs2svn/cvs2git/cvs2bzr.
>
> Does it support incremental operation yet? (I.e. do not bother to
> re-import what was imported already?)
No, sorry, incremental conversion is not likely to be developed in the
absence of new volunteers or sponsorship. (But I'd be happy to help a
willing volunteer get started!)
Michael
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: Johannes Sixt @ 2009-08-24 14:42 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090824140549.GA3973@debian.b2j>
bill lam schrieb:
> Sometimes during rebase -i, it stopped with an unmerged file but that
> file did not have any sections of conflict marked. ls-files showed it
> had :1: and :2: but no :3: I suspected that file was git-rm in that
> commit. Will it be possible for git status or rebase to give hint
> that unmerged file was actually removed?
Rebase -i emitted used to write merge-recursive's conflict hints that said
"modify/delete", "modify/rename", "content", etc. I think that's what you
were looking for. But these hints have vanished since quite some time now.
I haven't taken the time, yet, to track down when this happened and why.
-- Hannes
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: Jeff King @ 2009-08-24 14:36 UTC (permalink / raw)
To: git
In-Reply-To: <20090824140549.GA3973@debian.b2j>
On Mon, Aug 24, 2009 at 10:05:49PM +0800, bill lam wrote:
> Sometimes during rebase -i, it stopped with an unmerged file but that
> file did not have any sections of conflict marked. ls-files showed it
> had :1: and :2: but no :3: I suspected that file was git-rm in that
> commit. Will it be possible for git status or rebase to give hint
> that unmerged file was actually removed?
The version of "git status" in next (and presumably what will be in
v1.6.5) shows unmerged paths with more information. In this case,
you would see something like:
$ echo content >foo && git add foo && git commit -m 'base foo'
$ echo changes >>foo && git add foo && git commit -m 'change foo'
$ git checkout -b other HEAD^
$ git rm foo && git commit -m 'remove foo'
$ git rebase master
$ git status
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add <file>..." to mark resolution)
#
# deleted by them: foo
#
-Peff
^ permalink raw reply
* Re: gitosis-lite
From: Sitaram Chamarty @ 2009-08-24 14:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, Tommi Virtanen
In-Reply-To: <m3ab1pmk1c.fsf@localhost.localdomain>
On Mon, Aug 24, 2009 at 6:43 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> Could you add information about this tool (perhaps after confirmation
> / deciding on project name[1]) to Git Wiki page
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
> somewhere below Gitosis? Please do not forget to include that it is
> written in Perl; see other entries for example.
Will do; though I'll probably wait until at least one person
other than me has used it :)
> You wrote in project's README.markdown that you were inspired by
> Gitosis (which requires Python and python-setuptools) and
> Documentation/howto/update-hook-example.txt (which uses bash).
> Why not contrib/hooks/update-paranoid (which is written in Perl)?
Hmmm several reasons. To start with, it appears to me that
update-paranoid assumes each user has his own ACL file, and
I'm going the other way -- you'll notice I have exactly one
file as a single ACL source for many *projects*, leave alone
users.
Secondly, I want to stick to the gitosis philosophy -- it
has served very well, and I'm not sure how "in use"
update-paranoid is.
Thirdly, I'm not comfortable having a hook be so complex.
The whole thing is 10 lines shorter than all my code put
together :)
And finally, it's far too complex for me, leave alone some
of my users. I count 6 pipe opens in there, and the ACLs
are read by git cat-file or something :) I'll be honest: I
came away feeling very stupid after trying to read and
understand that program. It was... humbling :(
> Using Perl code for configuration is simple and fast, but not very
> secure. Why not use git config format (via "git config -l -z" like in
Not secure in what sense? Only the "git admin" (whoever
owns the account in which gitosis-lite is running) will be
able to generate it, and only scripts that run with his
authority (by way of hooks in repos he owns) can run it.
It cannot do what he did not intend to do, and what he wants
to do he can do anyway, whether it's JSON or perl.
Except for umasking the file, I don't see anything I missed.
Could you help me understand?
> gitweb), or YAML or JSON (or Storable)? Well, YAML might be overkill.
One of the objectives is to work *as is* on any Unix system
that managed to install git (which implies Perl). So, no
JSON or YAML. Storable would be fine (I think it's also
part of core perl) so if I find a compelling reason I don't
mind switching to that.
All I really have is a nested hash to be saved and restored
-- nothing more complex, no objects, no blessed refs, etc.
> BTW. if you blog about gitosis-lite (http://sitaramc.blogspot.com/)
> it could be picked up by Perl Iron Man Blogging challenge, and you
> could get wider review.
Will do; thanks. I did not know my blog got picked up by
anything; till date it has never come up on a google search
or a blog search anywhere, and it's more of a rant-box +
annotated bookmarking service for myself :)
> [1]: gitosis-lite doesn't look like CPAN-y name. Git::Admin perlhaps?
Too presumptuous for someone like me -- makes it sound like
the "one true way to Admin git" :)
Thank you very much for your comments!
--
Sitaram
^ permalink raw reply
* Re: Announcement: cvs2svn 2.3.0 released
From: Johannes Schindelin @ 2009-08-24 14:33 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Git Mailing List
In-Reply-To: <4A9074C7.4080002@alum.mit.edu>
Hi,
On Sun, 23 Aug 2009, Michael Haggerty wrote:
> I am happy to announce release 2.3.0 of cvs2svn/cvs2git/cvs2bzr.
>
> cvs2svn is a tool for migrating a CVS repository to Subversion, git,
> Bazaar, or Mercurial. The main design goals are robustness and 100% data
> preservation. cvs2svn can convert just about any CVS repository we've
> ever seen, including gcc, Mozilla, FreeBSD, KDE, and GNOME.
>
> Release 2.3.0 primarily improves the support for converting to git and
> Bazaar (including explicit cvs2git and cvs2bzr scripts). This release
> also adds a few other minor features and fixes a bug when converting to
> git with non-inline blobs.
Does it support incremental operation yet? (I.e. do not bother to
re-import what was imported already?)
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Makefile: Add NEEDS_CRYPTO_WITH_SSL
From: Brian Gernhardt @ 2009-08-24 14:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git List, Junio C Hamano
In-Reply-To: <81b0412b0908240245l33b04322l923084362197406a@mail.gmail.com>
On Aug 24, 2009, at 5:45 AM, Alex Riesen wrote:
> As imap-send is the only one which uses the symbols, why not just add
> LIB_4_CRYPTO
> to its linking command? Like in the broken GMail-patch below:
I didn't do this because I didn't know if all platforms needed
libcrypto to compile imap-send. If it is, then this is obviously the
simpler solution.
> diff --git a/Makefile b/Makefile
> index 02ff867..33971f3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1503,7 +1503,7 @@ git-%$X: %.o $(GITLIBS)
>
> git-imap-send$X: imap-send.o $(GITLIBS)
> $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,
> $^) \
> - $(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
> + $(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
>
> http.o http-walker.o http-push.o: http.h
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Johan Herland @ 2009-08-24 14:20 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Junio C Hamano, Daniel Barkalow,
Johannes Schindelin
In-Reply-To: <alpine.LFD.2.00.0908240946390.6044@xanadu.home>
On Monday 24 August 2009, Nicolas Pitre wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
> > Nicolas Pitre <nico@cam.org> writes:
> > > If all refs sent by the remote repo during a fetch are reachable
> > > locally, then no further conversation is performed with the
> > > remote. This check is skipped when the --depth argument is
> > > provided to allow the deepening of a shallow clone which
> > > corresponding remote repo has no changed.
> > >
> > > However, some additional filtering was added in commit c29727d5
> > > to remove those refs which are equal on both sides. If the
> > > remote repo has not changed, then the list of refs to give the
> > > remote process becomes empty and simply attempting to deepen a
> > > shallow repo always fails.
> > >
> > > Let's stop being smart in that case and simply send the whole
> > > list over when that condition is met. The remote will do the
> > > right thing anyways.
> > >
> > > Test cases for this issue are also provided.
> > >
> > > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > > ---
> >
> > Thanks. The fix looks correct (as usual with patches from you).
> >
> > But it makes me wonder if this logic to filter refs is buying us
> > anything.
> >
> > > for (rm = refs; rm; rm = rm->next) {
> > > + nr_refs++;
> > > if (rm->peer_ref &&
> > > !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
> > > continue;
> >
> > ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
> > heads[nr_heads++] = rm;
> > }
> >
> > What is the point of not asking for the refs that we know are the
> > same?
>
> I could see the advantage if the number of refs is really huge.
> Wasn't some converted repositories producing a lot of branches and/or
> tags significantly slowing down a fetch operation? Granted that was
> long ago when that issue got "fixed" so the details are fuzzy to me.
I'm converting several CVS repos to Git with ~50 000 refs, so I'm happy
with any change that can speed things up for repos with many refs.
Right now, my biggest gripe is that a 'git push --mirror' on such a repo
can easily take ~10 min. even though the actual pack generation and
transfer only takes a couple of seconds. It seems like it needs ~10
minutes to generate the list of changed/added/deleted refs...
Unfortunately I haven't had time to look properly into it, yet...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-24 14:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7viqgdoikz.fsf@alter.siamese.dyndns.org>
Junio C Hamano (gitster@pobox.com) wrote on Aug 24, 2009:
> Thell Fowler <git@tbfowler.name> writes:
>
> > It passed every test I threw at it, although it seemed to be a tad bit
> > slower than the previous revision on my sample data so I ran the following
> > command several times for both the previous and current version:
> >
>
> Do you mean by "previous version" the one that was broken, or the one I
> sent as a "how about" patch?
>
A quick test shows the version merged to pu is the one that had the
fastest times. I'll be away from a connection most of today, but will
test the different versions against the tests and some sample data and
post back.
--
Thell
^ permalink raw reply
* rebase hint unmerged file removed
From: bill lam @ 2009-08-24 14:05 UTC (permalink / raw)
To: git
Sometimes during rebase -i, it stopped with an unmerged file but that
file did not have any sections of conflict marked. ls-files showed it
had :1: and :2: but no :3: I suspected that file was git-rm in that
commit. Will it be possible for git status or rebase to give hint
that unmerged file was actually removed?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Nicolas Pitre @ 2009-08-24 13:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <7vocq5q0j7.fsf@alter.siamese.dyndns.org>
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > If all refs sent by the remote repo during a fetch are reachable
> > locally, then no further conversation is performed with the remote. This
> > check is skipped when the --depth argument is provided to allow the
> > deepening of a shallow clone which corresponding remote repo has no
> > changed.
> >
> > However, some additional filtering was added in commit c29727d5 to
> > remove those refs which are equal on both sides. If the remote repo has
> > not changed, then the list of refs to give the remote process becomes
> > empty and simply attempting to deepen a shallow repo always fails.
> >
> > Let's stop being smart in that case and simply send the whole list over
> > when that condition is met. The remote will do the right thing anyways.
> >
> > Test cases for this issue are also provided.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
>
> Thanks. The fix looks correct (as usual with patches from you).
>
> But it makes me wonder if this logic to filter refs is buying us anything.
>
> > for (rm = refs; rm; rm = rm->next) {
> > + nr_refs++;
> > if (rm->peer_ref &&
> > !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
> > continue;
> ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
> heads[nr_heads++] = rm;
> }
>
> What is the point of not asking for the refs that we know are the same?
I could see the advantage if the number of refs is really huge. Wasn't
some converted repositories producing a lot of branches and/or tags
significantly slowing down a fetch operation? Granted that was long ago
when that issue got "fixed" so the details are fuzzy to me.
> In other words, what breaks (not necessarily in the correctness sense, but
> also in the performance sense) if we get rid of this filtering altogether?
If you really want to get rid of that filtering, I'd still do it in a
separate patch. That way if any issue appears because of that then
bissection will point directly to that removal alone.
Nicolas
^ permalink raw reply
* Re: [PATCH] block-sha1: Use mozilla-sha1 copyright and license information
From: Ulrik Sverdrup @ 2009-08-24 13:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0908240923360.6044@xanadu.home>
2009/8/24 Nicolas Pitre <nico@cam.org>:
>
> The Mozilla SHA1 is already removed from the tree in "next", and
> block-sha1/sha1.c header modified accordingly.
>
> As there is nothing remaining from the Mozilla SHA1 code, I don't think
> copying that Mozilla License block verbatim is appropriate. As Linus
> has put it himself, the Mozilla SHA1 code was more inspirational than
> anything else.
>
> And even if some license claim could be made, the MPL section was
> deleted anyway (as explicitly allowed), meaning that only the GPL (by
> vertu of being included in a GPL project) would then apply.
>
> A question was recently sent to all contributors (see the mail
> archive) to determine if they
> would agree
> to a relicensing of that code to make wider license compatibility.
> George Spelvin even rewrote that code as well with the goal of
> putting his version in the public domain. No definitive conclusion
> emerged so far though.
>
> Therefore I don't think this patch is appropriate.
Agreed. I just didn't look into next.
Ulrik
^ permalink raw reply
* Re: [PATCH] block-sha1: Use mozilla-sha1 copyright and license information
From: Nicolas Pitre @ 2009-08-24 13:45 UTC (permalink / raw)
To: Ulrik Sverdrup; +Cc: git
In-Reply-To: <20090824120756.GA17146@ulrik-ibook>
On Mon, 24 Aug 2009, Ulrik Sverdrup wrote:
> block-sha1 needs an independent copyright and license header, in the
> case that the original mozilla SHA-1 implementation is removed from
> the tree.
The Mozilla SHA1 is already removed from the tree in "next", and
block-sha1/sha1.c header modified accordingly.
As there is nothing remaining from the Mozilla SHA1 code, I don't think
copying that Mozilla License block verbatim is appropriate. As Linus
has put it himself, the Mozilla SHA1 code was more inspirational than
anything else.
And even if some license claim could be made, the MPL section was
deleted anyway (as explicitly allowed), meaning that only the GPL (by
vertu of being included in a GPL project) would then apply.
A question was recently sent to all contributors (see the mail
archive) to determine if they
would agree
to a relicensing of that code to make wider license compatibility.
George Spelvin even rewrote that code as well with the goal of
putting his version in the public domain. No definitive conclusion
emerged so far though.
Therefore I don't think this patch is appropriate.
Nicolas
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Don Zickus @ 2009-08-24 14:02 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <20090824073147.GG3526@vidovic>
On Mon, Aug 24, 2009 at 09:31:47AM +0200, Nicolas Sebrecht wrote:
> ( cc'ing Don Zickus )
>
> The 23/08/09, Junio C Hamano wrote:
> > Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> >
> > >> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
> > >> the way?
>From what I remember, I used p_hdr to designate primary headers, ie the
original mail headers. s_hdr was supposed to represent the secondary
headers, ie the embedded mail headers in the body of the email that could
override the original primary mail headers.
I hope that clears things up. Let me know if you have more questions and
I will try my best to remember what I did. :-)
Cheers,
Don
> > >
> > > Has been added by 87ab799234639c .
> >
> > That much I know ;-), thanks anyway.
> >
> > The commit does not _explain_ what they are for, what they mean, and what
> > these mysteriously named variables do.
>
> --
> Nicolas Sebrecht
^ permalink raw reply
* Re: gitosis-lite
From: Jakub Narebski @ 2009-08-24 13:13 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List, Tommi Virtanen
In-Reply-To: <2e24e5b90908240528v56fdf30cq4c046fca321a3b17@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> Hello all,
>
> I created a new project called gitosis-lite, which combines
> the essential pieces of gitosis with the per-branch
> permissions stuff in the example in the howto directory of
> git.git.
>
> The config file is different, (there's an annotated example
> you can look at).
>
> The "why" and the "what" are all at
> http://github.com/sitaramc/gitosis-lite
Could you add information about this tool (perhaps after confirmation
/ deciding on project name[1]) to Git Wiki page
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
somewhere below Gitosis? Please do not forget to include that it is
written in Perl; see other entries for example.
You wrote in project's README.markdown that you were inspired by
Gitosis (which requires Python and python-setuptools) and
Documentation/howto/update-hook-example.txt (which uses bash).
Why not contrib/hooks/update-paranoid (which is written in Perl)?
Using Perl code for configuration is simple and fast, but not very
secure. Why not use git config format (via "git config -l -z" like in
gitweb), or YAML or JSON (or Storable)? Well, YAML might be overkill.
BTW. if you blog about gitosis-lite (http://sitaramc.blogspot.com/)
it could be picked up by Perl Iron Man Blogging challenge, and you
could get wider review.
[1]: gitosis-lite doesn't look like CPAN-y name. Git::Admin perlhaps?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH 3/3] gitweb: add test cases for snapshot settings
From: Jakub Narebski @ 2009-08-24 12:36 UTC (permalink / raw)
To: Mark Rada; +Cc: Junio C Hamano, git
In-Reply-To: <4A91BA53.1040800@mailservices.uwaterloo.ca>
On Sun, 23 Aug 2009, Mark Rada wrote:
> This commit adds a new test file (t9501) that is used for gitweb test
> cases that parse gitweb output to verify the HTTP status code or
> message.
>
> Signed-off-by: Mark Rada <marada@uwaterloo.ca>
> ---
I would rather put emphasis on the fact that new test is created, which
is meant to check that gitweb produces expected HTTP status codes.
-- >8 --
Subject: gitweb: Add t9501 test for gitweb's HTTP status codes
This commit adds a new test file (t9501), that is used for gitweb test
cases that parse gitweb output to verify the HTTP status code or
message.
Currently the only tests are about 'snapshot' feature settings
-- [end cut] --
Or something like that.
--
Jakub Narebski
Poland
^ permalink raw reply
* gitosis-lite
From: Sitaram Chamarty @ 2009-08-24 12:28 UTC (permalink / raw)
To: Git Mailing List; +Cc: Tommi Virtanen
[Tommi: I chose this name to reflect that it really owes its existence to
gitosis for the basic ideas etc. However, if you have any objections I
would be quite happy to find another name. Just let me know...]
Hello all,
I created a new project called gitosis-lite, which combines
the essential pieces of gitosis with the per-branch
permissions stuff in the example in the howto directory of
git.git.
The config file is different, (there's an annotated example
you can look at).
The "why" and the "what" are all at
http://github.com/sitaramc/gitosis-lite
--
Sitaram
^ permalink raw reply
* [PATCH] block-sha1: Use mozilla-sha1 copyright and license information
From: Ulrik Sverdrup @ 2009-08-24 12:07 UTC (permalink / raw)
To: git
block-sha1 needs an independent copyright and license header, in the
case that the original mozilla SHA-1 implementation is removed from
the tree.
The Contributor(s) list in the header is not in the git style, but
it is copied as well, and augmented with git contributors to
block-sha1.
Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
---
block-sha1/sha1.{ch} simply say this:
/*
* Based on the Mozilla SHA1 (see mozilla-sha1/sha1.c),
* optimized to do word accesses rather than byte accesses,
* and to avoid unnecessary copies into the context array.
*/
This means that if mozilla-sha1 is removed, we need to copy the
license information back to block-sha1.
block-sha1/sha1.c | 38 +++++++++++++++++++++++++++++++++++++-
block-sha1/sha1.h | 37 ++++++++++++++++++++++++++++++++++---
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..34c7415 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -1,5 +1,41 @@
/*
- * Based on the Mozilla SHA1 (see mozilla-sha1/sha1.c),
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Reference Implementation (Compact version)
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ * Linus Torvalds
+ * Nicolas Pitre
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
+ */
+/*
+ * Based on the Mozilla SHA1, this implementation is
* optimized to do word accesses rather than byte accesses,
* and to avoid unnecessary copies into the context array.
*/
diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h
index c1ae74d..dc72ccf 100644
--- a/block-sha1/sha1.h
+++ b/block-sha1/sha1.h
@@ -1,7 +1,38 @@
/*
- * Based on the Mozilla SHA1 (see mozilla-sha1/sha1.h),
- * optimized to do word accesses rather than byte accesses,
- * and to avoid unnecessary copies into the context array.
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Header File
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ * Linus Torvalds
+ * Nicolas Pitre
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
*/
typedef struct {
--
1.6.4
^ 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