* Re: pull/push inconsistencies
From: Martin Langhoff @ 2007-05-16 22:35 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90705151851i9027e01x993300b1b50d0285@mail.gmail.com>
On 5/16/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> I'm probably in a bad-communication day :-/
Ok - I just repro'd the problem -- maybe this helps clarify...
I have a checkout of http://git.catalyst.net.nz/git/moodle-r2.git (
see http://git.catalyst.net.nz/gitweb ) where I have the following
tracking branches:
$ git branch
mdl17-polhn
* mdl18-local
I know that I am "all pushed out" - no local commits to push here. So
I start my day and do
$ git-pull
# brings some commits, but nothing to mdl18-local
$ git-merge origin/MOODLE_18_STABLE
# messy merge from the upstream branch I track...
$ git-commit
$ git-push
$ git-push
updating 'refs/heads/mdl18-local'
from f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463
to 3af93dafbd9162423e5f0a720d4d2081313789e2
updating 'refs/remotes/origin/MOODLE_18_STABLE'
from 52abd5d7c4f0ac54cfc0463d5276c159a02a76c0
to 4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
updating 'refs/remotes/origin/cvshead'
from 7bf579b243717c470770b1457a7d1c50f6a8dff6
to e835361626c5cd27cabdc046fc0e23a2c6ff98db
updating 'refs/remotes/origin/mdl18-ldc'
from eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea
to af4c6ee952057d11b2dbf55103a5c3134640b70f
updating 'refs/remotes/origin/mdl18-topnz'
from a08fdb4decfa7b92c3030801c08378ee629c038d
to 347bc44adbfdf7b800334cbb532d436fa73e87ac
(removed some tag-related noise)
Generating pack...
Done counting 212 objects.
Result has 72 objects.
Deltifying 72 objects...
100% (72/72) done
Writing 72 objects...
Unpacking 72 objects
100% (72/72) done
Total 72 (delta 65), reused 0 (delta 0)
refs/heads/mdl18-local: f3f1ae5c9f73fe6e0872dfe0e072521b6fe26463 ->
3af93dafbd9162423e5f0a720d4d2081313789e2
refs/remotes/origin/MOODLE_18_STABLE:
52abd5d7c4f0ac54cfc0463d5276c159a02a76c0 ->
4cfaa3c85ee54ec8c0891157a6becdd8db34eb52
refs/remotes/origin/cvshead:
7bf579b243717c470770b1457a7d1c50f6a8dff6 ->
e835361626c5cd27cabdc046fc0e23a2c6ff98db
refs/remotes/origin/mdl18-ldc:
eb91f220ccbbeb1e8b43496d0172e6cd1b6549ea ->
af4c6ee952057d11b2dbf55103a5c3134640b70f
refs/remotes/origin/mdl18-topnz:
a08fdb4decfa7b92c3030801c08378ee629c038d ->
347bc44adbfdf7b800334cbb532d436fa73e87ac
As you can see, it talks about updating lots of refs. Nonsense -- I
think it's a bug. The only ref being updated is origin/mdl18-local on
the remote repo, and it should update the local
refs/remotes/origin/mdl18-local.
cheers,
m
^ permalink raw reply
* Re: newby question about merge.
From: Johannes Schindelin @ 2007-05-16 22:39 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660705161235k130fabc2i6acb45d71b85891e@mail.gmail.com>
Hi,
On Wed, 16 May 2007, Christian MICHON wrote:
> On 5/16/07, Johannes Schindelin wrote:
> > [please, Christian, do not cut the Cc: list. In particular, do _not_
> > cut the person you are _responding_ to from the Cc: list]
>
> [ oops. I thought some of us sometimes receive doublets of emails,
> being in reply_to and cc of git@vger.kernel.org. point *taken* ]
Actually, I get doublets. Which is good, since I am more unlikely to just
delete _two_ copies of the same mail.
> I know the API changes frequently. But engineers don't like too many
> changes usually, and like to carry a portable/stable way. "git cat-file"
> at least behaves as it was in 1.4.x :)
Those changes were good changes. "git-show" is here to stay.
"git-cat-file" only appeals to Unix zealots who even sleep in their
command line.
> > > As far as I can tell, using git-1.4.4.4 or ealier, you would still
> > > need git-cat-file -p... to fix this merge conflict.
> >
> > If you are using pre-1.5 Git, you should really, really upgrade.
>
> While in principle I'd agree, in practice I do not. Git API changes
> increased learning curve for people who actually started with git a year
> ago.
I think I can pretty much guarantee that git-cat-file will stay plumbing.
As much as it will keep its not-exactly-user-friendly command line
arguments.
And I can pretty much guarantee that git-show will always be the good
thing for an end user to call.
> > And most importantly: if you suggest a change in the man pages, it
> > should reflect the new Git versions, _not_ the old ones.
>
> nope, I would not dare to suggest. I'm not a git developer: just a git
> user :)
You are right: for general help, this list is open for older versions of
Git. What triggered my response, though, was the suggestion to put that
particular command line, which indeed scares people away from Git (I tried
it on somebody), into a man page.
git-show <revision>:<path>
is so much nicer.
Ciao,
Dscho
^ permalink raw reply
* [0/4] What's not in 1.5.2 (overview)
From: Junio C Hamano @ 2007-05-16 22:47 UTC (permalink / raw)
To: git
Upcoming release 1.5.2 is nearing completion, so let's look at
the issues that are specifically excluded from it.
Before listing topics there is one thing.
* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit
+ Optimized cvsexportcommit: calling 'cvs status' once instead of
once per touched file.
This should really be 1.5.2. Real-world users of cvsexport, if
you were burned by this, please NAK as soon as possible. I'll
merge it to 1.5.2 unless I hear from anybody in a day or two.
The messages that follow this are:
[1/4] Easy-to-decide ones; what's been cooking in next.
[2/4] The ones to be cooked in next after 1.5.2
[3/4] Things we do not have code for yet.
[4/4] Leftover bits
^ permalink raw reply
* [1/4] What's not in 1.5.2 (have been cooking in next)
From: Junio C Hamano @ 2007-05-16 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
Here are the first batch that will be in 'master' after 1.5.2
happens.
They all have been cooking in 'next', or were not compelling
enough feature enhancements to be included after -rc1.
* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit
+ Add colour support in rebase and merge tree diff stats output.
* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit
+ Add --aggressive option to 'git gc'
* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits
+ deprecate the new loose object header format
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused.
* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit
+ git-update-ref: add --no-deref option for overwriting/detaching
ref
* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit
+ connect: display connection progress
* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits
+ Custom compression levels for objects and packs
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused
^ permalink raw reply
* [2/4] What's not in 1.5.2 (will cook in next)
From: Junio C Hamano @ 2007-05-16 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
These have been cooking in 'pu'; will be in 'next' after 1.5.2
happens.
* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
. Update local tracking refs when pushing
. Add handlers for fetch-side configuration of remotes.
. Move refspec parser from connect.c and cache.h to remote.{c,h}
. Move remote parsing into a library file out of builtin-push.
+ git-update-ref: add --no-deref option for overwriting/detaching
ref
This was rebased on to Sven's change to lock_any_ref_for_update();
* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits
. git-repack --max-pack-size: add option parsing to enable feature
. git-repack --max-pack-size: split packs as asked by
write_{object,one}()
. git-repack --max-pack-size: write_{object,one}() respect pack
limit
. git-repack --max-pack-size: new file statics and code
restructuring
. Alter sha1close() 3rd argument to request flush only
+ Custom compression levels for objects and packs
+ deprecate the new loose object header format
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused
This follows the "custom compression levels" series from the
same author.
^ permalink raw reply
* [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-16 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
Here are random things that I'd like to see happen during 1.5.3
cycle.
* git-clone should become a very thin wrapper around
init/remote/fetch/checkout.
- it may be necessary to teach git-remote about --bare
layout.
- by getting rid of 'fetch' logic from git-clone as much as
possible, it would hopefully become easier to freeze what
git-fetch needs to do and help rewriting the latter in C.
- update native protocol with an extension to carry which
branch HEAD (or any symref) points at, instead of guessing.
We already know this information when clone is done over
HTTP, but we are discarding that information in git-clone
for the sake of implementation simplicity and having it
also guess.
* more superproject support in Porcelain-ish.
- superproject support in Porcelain-ish is mostly about
checking things out. One possible scenario:
$ git clone --recursive $url_of_superproject
may instruct "clone that, and also clone any projects that
the superproject uses, and check everything out". I would
imagine that lThis would be carried out in the following
steps.
(1) The usual "git-clone" dance, determining the directory
name to create, running mkdir and init-db, setting up
tracking refspec specification in the config, and
running the initial fetch.
(2) Because the command was not given '-n' ("do not
checkout"), HEAD is checked out. git-checkout notices
that there are commits bound to some directories in its
tree.
(3) git-checkout finds there is .gitmodules file in the
tree (and the checked-out working file), which
describes these subprojects. It looks at the config
and notices that it does not yet know about them
(obviously this is true, as this is the first checkout
after clone, but I am trying to outline how checkout
after a merge should work in the general case).
It determines where to fetch that subproject from,
perhaps it uses the default URL described in
.gitmodules file to, while asking the user for
confirmation and giving the user a chance to override
it. And it records something in the config -- now that
project is known to this repository.
(4) git-checkout then calls git-clone recursively in that
subdirectory for the subproject (which may further
contain subprojects of its own, but that would
naturally work).
- Another scenario, after "git clone" of the superproject
_without_ the above "--recursive" behaviour. There needs
to be a way to later clone and checkout a named subproject
(and that subproject alone). Perhaps
$ git checkout --populate-subproject subdir
would notice that subdir corresponds to a subproject that
is "not known" to this repository.
I am assuming .gitmodules from the upstream describes it,
but the default is not to recurse into any subproject,
which would leave the subdir _without_ its own .git
directory. A subproject becomes "known" to your repository
when you tell git that you care about it (e.g. "clone
--recursive" above), and that decision would be recorded
somewhere in .git/config of the superproject. .gitmodules
would give the default URL and probably the branch to
follow. The URL definitely needs to be overridable by
per-repository configuration as network reachability would
be different for everybody; I am not sure about the need to
make it overridable which branch the subproject should
follow, but my gut feeling is that we do not have to.
Then it does the same as (3) and (4) in "clone --reference"
above (in fact, I am envisioning that that scenario would
call "git checkout --populate-subproject" in those steps).
- We might want to have a way to tell it to stop tracking an
already "known" subproject, which means that the section in
.git/config that would track the status of the subproject
(e.g. "is it known", "what's the URL", etc.) needs another
variable that says "are we still interested in it?".
- There may be obvious "frills" we would want to eventually
have, such as defaulting the repository to find the
subproject that corresponds to subdir/ to $URL/subdir (iow
if http://repo.or.cz/cgit.git binds git.git at its src/
directory, we would expect that the repository to house
that subproject is found at http://repo.or/cz/cgit.git/src
by default), but during the first round, I think it is
better to leave things explicit. So, for the above
example, instead of defaulting the $URL/$subdir location,
always require .gitmodules to say where to fetch the
subproject from.
- "git diff", "git status" and friends might want to learn
recursive behaviour. These should be much easier than any
of the above.
Note: I am not trying to dictate the overall superproject
Porcelain design should follow the above literally, but just
throwing out a strawman. As I do not expect to be a heavy
user of superproject support myself yet, other people who
have thought about the problem longer (much longer) than I
have will certainly have better ideas.
* Perhaps add 'tree' entries in the index. This may make the
current cache-tree extension unnecessary, and I suspect it
will simplify various paths that deal with D/F conflicts in
the current codebase.
I suspect this might need 1.6, as it is a one-way backward
incompatible change for the 'index', but 'index' is local so
it might not be such a big deal. In the worst case, when the
users find "git checkout" from 1.5.2 does not work in a
repository checked out with such an updated index format, we
could ask them to "rm -f .git/index && git checkout HEAD".
* make merge-recursive and read-tree -u more robust when D/F
conflict is involved.
I think that the use of current_{file,directory}_set is
misguided and it should just ask the index if there are
conflicts. unpack-trees.c::check_updates() logic probably is
the right place to deal with what to do with the working tree
when the merge result contains D/F conflicts (i.e.
merge-recursive wants to create file~branchname instead of
not touching the working tree).
^ permalink raw reply
* [4/4] What's not in 1.5.2 (other bits and pieces)
From: Junio C Hamano @ 2007-05-16 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
Here are the leftover pieces I have in todo:TODO file that I did
not mention in the earlier messages. I left them out from the
third message of this series, as (1) some are more of "trivial
fix" category, and (2) others are heavier and would probably not
fit for a single release cycle such as 1.5.3.
The easier ones
---------------
* parse-remote.sh has POSIXLY incorrect shell construct.
Message-ID: <20070505080313.GA12170@gondor.apana.org.au>
* Use 'git diff' not 'git diff-tree' in merge and rebase
From: James Bowes <jbowes@dangerouslyinc.com>
Message-ID: <1178398134288-git-send-email-jbowes@dangerouslyinc.com>
* gitk --left-right
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0705051524300.17381@woody.linux-foundation.org>
From: Junio C Hamano <junkio@cox.net>
Message-ID: <7vabwifl23.fsf@assigned-by-dhcp.cox.net>
* Handling pushing into non-bare repository more gracefully.
When git-push is done to a non-bare repository and updates the
branch that is currently checked out, we currently do not do
anything special.
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <Pine.LNX.4.64.0704160931550.5473@woody.linux-foundation.org>
* git-daemon bug?
From: Franck Bui-Huu <vagabon.xyz@gmail.com>
Message-ID: <450EABD0.1040102@innova-card.com>
Repeated requests against git-daemon makes it stuck under --syslog
[jc: does not reproduce easily for me; has anybody seen it?]
* AsciiDoc 8 would break our documentation.
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Message-ID: <4523EC14.6070806@s5r6.in-berlin.de>
AsciiDoc 8 does not grok documents written for AsciiDoc 7 out of
the box.
[jc: limbo?]
* Delegate gitweb part to somebody else.
* Use gitattributes for more things.
- 'precious' files that are not tracked but not
build-products. Currently people seem to put them in
.gitignore, but that is not quite right, as .gitignore is
meant for ignoring things that can be lost (build products,
editor backup files). "git clean -x" and "git checkout" to
another branch that has a file where the current branch has a
directory could lose such 'precious' files.
- Customized "diff -p" markers per path (Johannes, on #git
2007-04-30).
I think it makes sense to give an extra parameter to xdiff
machinery to affect how "diff -p" markers are constructed (as
opposed to teach xdiff machinery to read gitattributes -- the
code does not have path information at that level). The
simplest interface would be to pass a regexp and have the
existing code always look for that regexp backwards. A more
complex one would involve a callback function, but I do not
know if that kind of complexity is worth it.
- Others???
* upload-pack support for start fetching from any valid point on
the history, not just published refs. (Erik W. Biederman
<m164jc9ekx.fsf@ebiederm.dsl.xmission.com>)
* Give --stdin to git-log, similar to git-rev-list
From: "Marco Costalba" <mcostalba@gmail.com>
Message-ID: <e5bfff550705110413q28aef3d8k3aeb0d342eeb2016@mail.gmail.com>
* Update the lockfile protocol so that closing and renaming are
done inside lockfile commit time. Some filesystems do not
like an open file renamed and then closed. Come up with a
patch and pass Alex for an Ack.
Probably not so important ones
------------------------------
* daemon --strict-symlink.
* Maybe grok PGP signed text/plain in applymbox as well.
* Mbx (not mbox) support for git-mailsplit.
* git-proxy should be spawned with sh -c 'command' $1 $2.
[jc: should it? -- deciding if it should may not be "trivial",
but if it turns out to be the right thing to do, the change
itself is trivial.]
* Maybe a true git-proxy command that reads the first request
pkt-line, and redirects the request to its real destination.
* test scripts for the relative directory path stuff.
The heavier ones
----------------
* Use blame machinery to track a single file (not path) in a finer
grained way.
From: Linus Torvalds <torvalds@linux-foundation.org>
Message-ID: <alpine.LFD.0.98.0704201554550.9964@woody.linux-foundation.org>
[jc: I have a fixed-up one parked in 'pu' and also outlined what
other things I think are needed in my response:
Message-ID: <7vwt06wqv8.fsf@assigned-by-dhcp.cox.net>
]
* "git fetch" should be able to use foreign SCM import backends
such as svnimport and cvsimport.
* git-clone fails .git/refs/foo (Yann Dirson <ydirson@altern.org>)
<20060610225040.GA7766@nowhere.earth>
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-05-17 0:21 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pmgqrut.fsf@assigned-by-dhcp.cox.net>
It probably would be more interesting to look at the earlier
"What's not in 1.5.2" messages, but here is the current status
of my tree on the 'stable' front.
I'd expect to have 1.5.1.5 from 'maint' perhaps on Saturday, and
1.5.2 from 'master' hopefully on Sunday if everything goes well.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Andy Whitcroft (1):
git name-rev writes beyond the end of malloc() with large generations
Frank Lichtenheld (3):
builtin-log.c: Fix typo in comment
Documentation: format-patch has no --mbox option
git-am: Clean up the asciidoc documentation
Jakub Narebski (1):
gitweb: Add a few comments about %feature hash
Jeff King (1):
format-patch: add MIME-Version header when we add content-type.
Johannes Schindelin (1):
import-tars: Use the "Link indicator" to identify directories
Junio C Hamano (2):
Fix git-clone buglet for remote case.
Prepare for 1.5.1.5 Release Notes
Quy Tonthat (1):
Documentation/branch: fix small typo in -D example
Steffen Prohaska (1):
Fixed link in user-manual
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (1):
Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
Frank Lichtenheld (1):
cvsserver: Don't send mixed messages to clients
Jakub Narebski (5):
gitweb: Fix "Use of unitialized value" warnings in empty repository
Documentation: Split description of pretty formats of commit log
gitweb: Do not use absolute font sizes
gitweb: Separate search regexp from search text
gitweb: Empty patch for merge means trivial merge, not no differences
Jeff King (1):
Documentation/git-add: clarify -u with path limiting
Johan Herland (2):
Fix signedness on return value from xread()
Ensure return value from xread() is always stored into an ssize_t
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-05-17 0:21 UTC (permalink / raw)
To: git
In-Reply-To: <7v646wqrvm.fsf@assigned-by-dhcp.cox.net>
It probably would be more interesting to look at the earlier
"What's not in 1.5.2" messages, but here is the current status
of my tree on the 'next' and 'pu' front.
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit
+ connect: display connection progress
* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
- Update local tracking refs when pushing
- Add handlers for fetch-side configuration of remotes.
- Move refspec parser from connect.c and cache.h to remote.{c,h}
- Move remote parsing into a library file out of builtin-push.
+ git-update-ref: add --no-deref option for overwriting/detaching
ref
* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits
- git-repack --max-pack-size: add option parsing to enable feature
- git-repack --max-pack-size: split packs as asked by
write_{object,one}()
- git-repack --max-pack-size: write_{object,one}() respect pack
limit
- git-repack --max-pack-size: new file statics and code
restructuring
- Alter sha1close() 3rd argument to request flush only
+ Custom compression levels for objects and packs
+ deprecate the new loose object header format
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused
* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit
+ Optimized cvsexportcommit: calling 'cvs status' once instead of
once per touched file.
* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits
+ Custom compression levels for objects and packs
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused
* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit
+ Add --aggressive option to 'git gc'
* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits
+ deprecate the new loose object header format
+ make "repack -f" imply "pack-objects --no-reuse-object"
+ allow for undeltified objects not to be reused
* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit
+ git-update-ref: add --no-deref option for overwriting/detaching
ref
* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit
+ Add colour support in rebase and merge tree diff stats output.
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Johannes Schindelin @ 2007-05-17 0:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jan Hudec, git
In-Reply-To: <46a038f90705161426n3b928086t2d3e68749557f866@mail.gmail.com>
Hi,
On Thu, 17 May 2007, Martin Langhoff wrote:
> On 5/16/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 16 May 2007, Martin Langhoff wrote:
> > > Do the indexes have enough info to use them with http ranges? It'd be
> > > chunkier than a smart protocol, but it'd still work with dumb servers.
> > It would not be really performant, would it? Besides, not all Web servers
> > speak HTTP/1.1...
>
> Performant compared to downloading a huge packfile to get 10% of it?
> Sure! It'd probably take a few trips, and you'd end up fetching 20% of
> the file, still better than 100%.
Don't forget that those 10% probably do not do you the favour to be in
large chunks. Chances are that _every_ _single_ wanted object is separate
from the others.
> > Besides, not all Web servers speak HTTP/1.1...
>
> Are there any interesting webservers out there that don't? Hand-rolled
> purpose-built webservers often don't but those don't serve files, they
> serve web apps. When it comes to serving files, any webserver that is
> supported (security-wise) these days is HTTP/1.1.
>
> And for services like SF.net it'd be a safe low-cpu way of serving git
> files. 'cause the git protocol is quite expensive server-side (io+cpu)
> as we've seen with kernel.org. Being really smart with a cgi is
> probably going to be expensive too.
It's probably better and faster than relying on a feature which does not
exactly help.
Ciao,
Dscho
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Shawn O. Pearce @ 2007-05-17 1:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0705170152470.6410@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Don't forget that those 10% probably do not do you the favour to be in
> large chunks. Chances are that _every_ _single_ wanted object is separate
> from the others.
That's completely possible. Assuming the objects even are packed
in the first place. Its very unlikely that you would be able to
fetch very large of a range from an existing packfile, you would be
submitting most of your range requests for very very small sections.
> > And for services like SF.net it'd be a safe low-cpu way of serving git
> > files. 'cause the git protocol is quite expensive server-side (io+cpu)
> > as we've seen with kernel.org. Being really smart with a cgi is
> > probably going to be expensive too.
>
> It's probably better and faster than relying on a feature which does not
> exactly help.
Yes. Packing more often and pack v4 may help a lot there.
The other thing is kernel.org should really try to encourage the
folks with repositories there to try and share against one master
repository, so the poor OS has a better chance at holding the bulk
of linux-2.6.git in buffer cache.
I'm not suggesting they share specifically against Linus' repository;
maybe hpa and the other admins can host one seperately from Linus and
enourage users to use that repository when on a system they maintain.
In an SF.net type case this doesn't help however. Most of SF.net
is tiny projects with very few, if any, developers. Hence most
of that is going to be unsharable, infrequently accessed, and uh,
not needed to be stored in buffer cache. For the few projects that
are hosted there that have a large developer base they could use
a shared repository approach as I just suggested for kernel.org.
aka the "forks" thing in gitweb, and on repo.or.cz...
--
Shawn.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: david @ 2007-05-17 1:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Martin Langhoff, Jan Hudec, git
In-Reply-To: <20070517010335.GU3141@spearce.org>
On Wed, 16 May 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>>> And for services like SF.net it'd be a safe low-cpu way of serving git
>>> files. 'cause the git protocol is quite expensive server-side (io+cpu)
>>> as we've seen with kernel.org. Being really smart with a cgi is
>>> probably going to be expensive too.
>>
>> It's probably better and faster than relying on a feature which does not
>> exactly help.
>
> Yes. Packing more often and pack v4 may help a lot there.
>
> The other thing is kernel.org should really try to encourage the
> folks with repositories there to try and share against one master
> repository, so the poor OS has a better chance at holding the bulk
> of linux-2.6.git in buffer cache.
do you mean more precisely share against one object store or do you really
mean repository?
David Lang
> I'm not suggesting they share specifically against Linus' repository;
> maybe hpa and the other admins can host one seperately from Linus and
> enourage users to use that repository when on a system they maintain.
>
> In an SF.net type case this doesn't help however. Most of SF.net
> is tiny projects with very few, if any, developers. Hence most
> of that is going to be unsharable, infrequently accessed, and uh,
> not needed to be stored in buffer cache. For the few projects that
> are hosted there that have a large developer base they could use
> a shared repository approach as I just suggested for kernel.org.
>
> aka the "forks" thing in gitweb, and on repo.or.cz...
>
>
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Shawn O. Pearce @ 2007-05-17 1:26 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, Martin Langhoff, Jan Hudec, git
In-Reply-To: <Pine.LNX.4.64.0705161803580.1280@asgard.lang.hm>
david@lang.hm wrote:
> On Wed, 16 May 2007, Shawn O. Pearce wrote:
> >
> >The other thing is kernel.org should really try to encourage the
> >folks with repositories there to try and share against one master
> >repository, so the poor OS has a better chance at holding the bulk
> >of linux-2.6.git in buffer cache.
>
> do you mean more precisely share against one object store or do you really
> mean repository?
Sorry, I did mean "object store". ;-)
Repository is insanity, as the refs and tags namespaces are suddenly
shared. What a nightmare that would become.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix few 'use of undefined value' warnings
From: Petr Baudis @ 2007-05-17 1:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070427164352.396.54191.stgit@rover>
On Fri, Apr 27, 2007 at 06:43:53PM CEST, Petr Baudis wrote:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b67ce41..b51103e 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1057,6 +1058,7 @@ sub git_get_project_description {
> open my $fd, "$projectroot/$path/description" or return undef;
> my $descr = <$fd>;
> close $fd;
> + $descr or return undef;
> chomp $descr;
> return $descr;
> }
It looks like this hunk has been skipped...?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Shawn O. Pearce @ 2007-05-17 1:45 UTC (permalink / raw)
To: david; +Cc: Johannes Schindelin, Martin Langhoff, Jan Hudec, git
In-Reply-To: <20070517012602.GV3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> david@lang.hm wrote:
> > On Wed, 16 May 2007, Shawn O. Pearce wrote:
> > >
> > >The other thing is kernel.org should really try to encourage the
> > >folks with repositories there to try and share against one master
> > >repository, so the poor OS has a better chance at holding the bulk
> > >of linux-2.6.git in buffer cache.
> >
> > do you mean more precisely share against one object store or do you really
> > mean repository?
>
> Sorry, I did mean "object store". ;-)
And even there, I don't mean symlink objects to a shared database,
I mean use the objects/info/alternates file to point to the shared,
read-only location.
Its not perfect. The hotter parts of the object database is almost
always the recent stuff, as that's what people are actively trying
to fetch, or are using as a base when they are trying to fetch from
someone else. The hotter parts are also probably too new to be
in the shared store offered by kernel.org admins, which means you
cannot get good IO buffering. Back to the current set of problems.
A single shared object directory that everyone can write new files
into, but cannot modify or delete from, would help that problem quite
a bit. But it opens up huge problems about pruning, as there is no
way to perform garbage collection on that database without scanning
every ref on the system, and that's just not simply possible on a
busy system like kernel.org.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gui: Build even if tclsh is not available
From: Petr Baudis @ 2007-05-17 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
As of now, git fails to build with default config if tclsh is not
available, thus requiring manual config tweaking just because of some
optimizations done at build time; this is a needless hassle when building
git on any kind of a server.
This patch makes git-gui's build process to handle this gracefully; unless
TCL_PATH is explicitly set, if tclsh cannot be executed only a warning is
printed and the build goes on. I have tested this only on that server with
no tclsh, but hopefully it shouldn't break the build process with tclsh
available either.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 8 +++++---
git-gui/Makefile | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 07411ff..ed12577 100644
--- a/Makefile
+++ b/Makefile
@@ -178,10 +178,12 @@ AR = ar
TAR = tar
INSTALL = install
RPMBUILD = rpmbuild
-TCL_PATH = tclsh
-TCLTK_PATH = wish
-export TCL_PATH TCLTK_PATH
+# If TCL_PATH is not defined here, it will default to tclsh later
+# with the exception that if tclsh cannot be executed, the optimization
+# step is skipped.
+# export TCL_PATH = tclsh
+export TCLTK_PATH = wish
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e73b645..2b1bc18 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -34,7 +34,7 @@ ifndef V
QUIET_INDEX = @echo ' ' INDEX $(dir $@);
endif
-TCL_PATH ?= tclsh
+TCL_PATH ?= tclsh || echo "Warning: Cannot execute tclsh, not optimizing git-gui" >&2
TCLTK_PATH ?= wish
ifeq ($(findstring $(MAKEFLAGS),s),s)
^ permalink raw reply related
* [PATCH] git-gui: Build even if tclsh is not available
From: Petr Baudis @ 2007-05-17 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
As of now, git fails to build with default config if tclsh is not
available, thus requiring manual config tweaking just because of some
optimizations done at build time; this is a needless hassle when building
git on any kind of a server.
This patch makes git-gui's build process to handle this gracefully; unless
TCL_PATH is explicitly set, if tclsh cannot be executed only a warning is
printed and the build goes on. I have tested this only on that server with
no tclsh, but hopefully it shouldn't break the build process with tclsh
available either.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 8 +++++---
git-gui/Makefile | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 07411ff..ed12577 100644
--- a/Makefile
+++ b/Makefile
@@ -178,10 +178,12 @@ AR = ar
TAR = tar
INSTALL = install
RPMBUILD = rpmbuild
-TCL_PATH = tclsh
-TCLTK_PATH = wish
-export TCL_PATH TCLTK_PATH
+# If TCL_PATH is not defined here, it will default to tclsh later
+# with the exception that if tclsh cannot be executed, the optimization
+# step is skipped.
+# export TCL_PATH = tclsh
+export TCLTK_PATH = wish
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e73b645..2b1bc18 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -34,7 +34,7 @@ ifndef V
QUIET_INDEX = @echo ' ' INDEX $(dir $@);
endif
-TCL_PATH ?= tclsh
+TCL_PATH ?= tclsh || echo "Warning: Cannot execute tclsh, not optimizing git-gui" >&2
TCLTK_PATH ?= wish
ifeq ($(findstring $(MAKEFLAGS),s),s)
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Daniel Barkalow @ 2007-05-17 2:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net>
On Wed, 16 May 2007, Junio C Hamano wrote:
> It probably would be more interesting to look at the earlier
> "What's not in 1.5.2" messages, but here is the current status
> of my tree on the 'next' and 'pu' front.
>
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'. The topics list the commits in reverse chronological
> order.
>
> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits
> - Update local tracking refs when pushing
> - Add handlers for fetch-side configuration of remotes.
> - Move refspec parser from connect.c and cache.h to remote.{c,h}
> - Move remote parsing into a library file out of builtin-push.
> + git-update-ref: add --no-deref option for overwriting/detaching
> ref
AFAICT, this isn't really in my topic. Rebased too much, perhaps?
I've also got one more patch ready, which moves refspec pattern matching
into match_refs, for a net reduction of 50 lines and much simpler logic.
I've also started making Julian Phillips' builtin-fetch use my parser, so
I might have something ready before too long.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-gui: Build even if tclsh is not available
From: Petr Baudis @ 2007-05-17 2:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070517020616.4722.33946.stgit@rover>
As of now, git fails to build with default config if tclsh is not
available, thus requiring manual config tweaking just because of some
optimizations done at build time; this is a needless hassle when building
git on any kind of a server.
This patch makes git-gui's build process to handle this gracefully; unless
TCL_PATH is explicitly set, if tclsh cannot be executed only a warning is
printed and the build goes on. I have tested this only on that server with
no tclsh, but hopefully it shouldn't break the build process with tclsh
available either.
Version 2, sorry - the previous version of the patch had the install hunk
missing. And apologies for the duplicate submission... :-)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Makefile | 8 +++++---
git-gui/Makefile | 4 ++--
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 07411ff..ed12577 100644
--- a/Makefile
+++ b/Makefile
@@ -178,10 +178,12 @@ AR = ar
TAR = tar
INSTALL = install
RPMBUILD = rpmbuild
-TCL_PATH = tclsh
-TCLTK_PATH = wish
-export TCL_PATH TCLTK_PATH
+# If TCL_PATH is not defined here, it will default to tclsh later
+# with the exception that if tclsh cannot be executed, the optimization
+# step is skipped.
+# export TCL_PATH = tclsh
+export TCLTK_PATH = wish
# sparse is architecture-neutral, which means that we need to tell it
# explicitly what architecture to check for. Fix this up for yours..
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e73b645..be3cfbb 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -34,7 +34,7 @@ ifndef V
QUIET_INDEX = @echo ' ' INDEX $(dir $@);
endif
-TCL_PATH ?= tclsh
+TCL_PATH ?= tclsh || echo "Warning: Cannot execute tclsh, not optimizing git-gui" >&2
TCLTK_PATH ?= wish
ifeq ($(findstring $(MAKEFLAGS),s),s)
@@ -92,7 +92,7 @@ install: all
$(INSTALL) git-gui '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(foreach p,$(GITGUI_BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(libdir_SQ)'
- $(INSTALL) -m644 lib/tclIndex '$(DESTDIR_SQ)$(libdir_SQ)'
+ [ ! -e lib/tclIndex ] || $(INSTALL) -m644 lib/tclIndex '$(DESTDIR_SQ)$(libdir_SQ)'
$(foreach p,$(ALL_LIBFILES), $(INSTALL) -m644 $p '$(DESTDIR_SQ)$(libdir_SQ)' ;)
dist-version:
^ permalink raw reply related
* Re: [PATCH] gitweb: Change base font size to "small"
From: Petr Baudis @ 2007-05-17 2:17 UTC (permalink / raw)
To: junkio, Jakub Narebski; +Cc: git, Jan Hudec, David K??gedal
In-Reply-To: <200705161251.38729.jnareb@gmail.com>
On Wed, May 16, 2007 at 12:51:38PM CEST, Jakub Narebski wrote:
> Proposed-by: Jan Hudec <bulb@ucw.cz>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
just for the record, since it seems to be already applied anyway. By the
way, I think this commit message is more optimal than what ended up for
some reason (Jakub wasn't fast enough? ;-) as
b211c320eb5d753a7a44a03eccb9a15cfbcc563b - especially the subject of
that commit is really weird.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] git-gui: Build even if tclsh is not available
From: Shawn O. Pearce @ 2007-05-17 2:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20070517021448.24022.8282.stgit@rover>
Petr Baudis <pasky@suse.cz> wrote:
> As of now, git fails to build with default config if tclsh is not
> available, thus requiring manual config tweaking just because of some
> optimizations done at build time; this is a needless hassle when building
> git on any kind of a server.
>
> This patch makes git-gui's build process to handle this gracefully; unless
> TCL_PATH is explicitly set, if tclsh cannot be executed only a warning is
> printed and the build goes on. I have tested this only on that server with
> no tclsh, but hopefully it shouldn't break the build process with tclsh
> available either.
>
> Version 2, sorry - the previous version of the patch had the install hunk
> missing. And apologies for the duplicate submission... :-)
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> Makefile | 8 +++++---
> git-gui/Makefile | 4 ++--
> 2 files changed, 7 insertions(+), 5 deletions(-)
I have a couple of problems with the patch as-is. The first is
of course that the patch needs to be split into two; one patch for
the git-gui subdirectory itself and one for git.git.
My other problem is
> ifeq ($(findstring $(MAKEFLAGS),s),s)
> @@ -92,7 +92,7 @@ install: all
> $(INSTALL) git-gui '$(DESTDIR_SQ)$(gitexecdir_SQ)'
> $(foreach p,$(GITGUI_BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
> $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(libdir_SQ)'
> - $(INSTALL) -m644 lib/tclIndex '$(DESTDIR_SQ)$(libdir_SQ)'
> + [ ! -e lib/tclIndex ] || $(INSTALL) -m644 lib/tclIndex '$(DESTDIR_SQ)$(libdir_SQ)'
> $(foreach p,$(ALL_LIBFILES), $(INSTALL) -m644 $p '$(DESTDIR_SQ)$(libdir_SQ)' ;)
git-gui won't work if lib/tclIndex is missing or invalid. So not
installing it means we should just disable git-gui entirely.
--
Shawn.
^ permalink raw reply
* [PATCH] Move refspec pattern matching to match_refs().
From: Daniel Barkalow @ 2007-05-17 2:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This means that send-pack and http-push will support pattern refspecs,
so builtin-push.c doesn't have to expand them, and also git push can
just turn --tags into "refs/tags/*", further simplifying builtin-push.c
check_ref_format() gets a third "conditionally okay" result for
something that's valid as a pattern but not as a particular ref.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
builtin-push.c | 133 +++++++++----------------------------------------------
refs.c | 25 +++++++---
remote.c | 35 +++++++++++++-
send-pack.c | 1 +
4 files changed, 72 insertions(+), 122 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 6084899..2612f07 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -9,7 +9,7 @@
static const char push_usage[] = "git-push [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]";
-static int all, tags, force, thin = 1, verbose;
+static int all, force, thin = 1, verbose;
static const char *receivepack;
static const char **refspec;
@@ -23,114 +23,24 @@ static void add_refspec(const char *ref)
refspec_nr = nr;
}
-static int expand_one_ref(const char *ref, const unsigned char *sha1, int flag, void *cb_data)
-{
- /* Ignore the "refs/" at the beginning of the refname */
- ref += 5;
-
- if (!prefixcmp(ref, "tags/"))
- add_refspec(xstrdup(ref));
- return 0;
-}
-
-static void expand_refspecs(void)
-{
- if (all) {
- if (refspec_nr)
- die("cannot mix '--all' and a refspec");
-
- /*
- * No need to expand "--all" - we'll just use
- * the "--all" flag to send-pack
- */
- return;
- }
- if (!tags)
- return;
- for_each_ref(expand_one_ref, NULL);
-}
-
-struct wildcard_cb {
- const char *from_prefix;
- int from_prefix_len;
- const char *to_prefix;
- int to_prefix_len;
- int force;
-};
-
-static int expand_wildcard_ref(const char *ref, const unsigned char *sha1, int flag, void *cb_data)
-{
- struct wildcard_cb *cb = cb_data;
- int len = strlen(ref);
- char *expanded, *newref;
-
- if (len < cb->from_prefix_len ||
- memcmp(cb->from_prefix, ref, cb->from_prefix_len))
- return 0;
- expanded = xmalloc(len * 2 + cb->force +
- (cb->to_prefix_len - cb->from_prefix_len) + 2);
- newref = expanded + cb->force;
- if (cb->force)
- expanded[0] = '+';
- memcpy(newref, ref, len);
- newref[len] = ':';
- memcpy(newref + len + 1, cb->to_prefix, cb->to_prefix_len);
- strcpy(newref + len + 1 + cb->to_prefix_len,
- ref + cb->from_prefix_len);
- add_refspec(expanded);
- return 0;
-}
-
-static int wildcard_ref(const char *ref)
-{
- int len;
- const char *colon;
- struct wildcard_cb cb;
-
- memset(&cb, 0, sizeof(cb));
- if (ref[0] == '+') {
- cb.force = 1;
- ref++;
- }
- len = strlen(ref);
- colon = strchr(ref, ':');
- if (! (colon && ref < colon &&
- colon[-2] == '/' && colon[-1] == '*' &&
- /* "<mine>/<asterisk>:<yours>/<asterisk>" is at least 7 bytes */
- 7 <= len &&
- ref[len-2] == '/' && ref[len-1] == '*') )
- return 0 ;
- cb.from_prefix = ref;
- cb.from_prefix_len = colon - ref - 1;
- cb.to_prefix = colon + 1;
- cb.to_prefix_len = len - (colon - ref) - 2;
- for_each_ref(expand_wildcard_ref, &cb);
- return 1;
-}
-
static void set_refspecs(const char **refs, int nr)
{
- if (nr) {
- int i;
- for (i = 0; i < nr; i++) {
- const char *ref = refs[i];
- if (!strcmp("tag", ref)) {
- char *tag;
- int len;
- if (nr <= ++i)
- die("tag shorthand without <tag>");
- len = strlen(refs[i]) + 11;
- tag = xmalloc(len);
- strcpy(tag, "refs/tags/");
- strcat(tag, refs[i]);
- ref = tag;
- }
- else if (wildcard_ref(ref))
- continue;
- add_refspec(ref);
+ int i;
+ for (i = 0; i < nr; i++) {
+ const char *ref = refs[i];
+ if (!strcmp("tag", ref)) {
+ char *tag;
+ int len;
+ if (nr <= ++i)
+ die("tag shorthand without <tag>");
+ len = strlen(refs[i]) + 11;
+ tag = xmalloc(len);
+ strcpy(tag, "refs/tags/");
+ strcat(tag, refs[i]);
+ ref = tag;
}
+ add_refspec(ref);
}
- expand_refspecs();
}
static int do_push(const char *repo)
@@ -149,11 +59,9 @@ static int do_push(const char *repo)
sprintf(rp, "--receive-pack=%s", remote->receivepack);
receivepack = rp;
}
- if (!refspec && !all && !tags && remote->push_refspec_nr) {
- for (i = 0; i < remote->push_refspec_nr; i++) {
- if (!wildcard_ref(remote->push_refspec[i]))
- add_refspec(remote->push_refspec[i]);
- }
+ if (!refspec && !all && remote->push_refspec_nr) {
+ refspec = remote->push_refspec;
+ refspec_nr = remote->push_refspec_nr;
}
argv = xmalloc((refspec_nr + 10) * sizeof(char *));
@@ -240,7 +148,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--tags")) {
- tags = 1;
+ add_refspec("refs/tags/*");
continue;
}
if (!strcmp(arg, "--force") || !strcmp(arg, "-f")) {
@@ -266,5 +174,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
usage(push_usage);
}
set_refspecs(argv + i, argc - i);
+ if (all && refspec)
+ usage(push_usage);
+
return do_push(repo);
}
diff --git a/refs.c b/refs.c
index 2ae3235..cd63f37 100644
--- a/refs.c
+++ b/refs.c
@@ -603,15 +603,18 @@ int get_ref_sha1(const char *ref, unsigned char *sha1)
static inline int bad_ref_char(int ch)
{
- return (((unsigned) ch) <= ' ' ||
- ch == '~' || ch == '^' || ch == ':' ||
- /* 2.13 Pattern Matching Notation */
- ch == '?' || ch == '*' || ch == '[');
+ if (((unsigned) ch) <= ' ' ||
+ ch == '~' || ch == '^' || ch == ':')
+ return 1;
+ /* 2.13 Pattern Matching Notation */
+ if (ch == '?' || ch == '*' || ch == '[')
+ return 2;
+ return 0;
}
int check_ref_format(const char *ref)
{
- int ch, level;
+ int ch, level, bad_type;
const char *cp = ref;
level = 0;
@@ -622,13 +625,19 @@ int check_ref_format(const char *ref)
return -1; /* should not end with slashes */
/* we are at the beginning of the path component */
- if (ch == '.' || bad_ref_char(ch))
+ if (ch == '.')
return -1;
+ bad_type = bad_ref_char(ch);
+ if (bad_type) {
+ return (bad_type == 2 && !*cp) ? -3 : -1;
+ }
/* scan the rest of the path component */
while ((ch = *cp++) != 0) {
- if (bad_ref_char(ch))
- return -1;
+ bad_type = bad_ref_char(ch);
+ if (bad_type) {
+ return (bad_type == 2 && !*cp) ? -3 : -1;
+ }
if (ch == '/')
break;
if (ch == '.' && *cp == '.')
diff --git a/remote.c b/remote.c
index 46fe8d9..05b16ad 100644
--- a/remote.c
+++ b/remote.c
@@ -415,6 +415,10 @@ static int match_explicit_refs(struct ref *src, struct ref *dst,
struct ref *matched_src, *matched_dst;
const char *dst_value = rs[i].dst;
+
+ if (rs[i].pattern)
+ continue;
+
if (dst_value == NULL)
dst_value = rs[i].src;
@@ -497,23 +501,48 @@ static struct ref *find_ref_by_name(struct ref *list, const char *name)
return NULL;
}
+static int check_pattern_match(struct refspec *rs, int rs_nr, struct ref *src)
+{
+ int i;
+ if (!rs_nr)
+ return 1;
+ for (i = 0; i < rs_nr; i++) {
+ if (rs[i].pattern && !prefixcmp(src->name, rs[i].src))
+ return 1;
+ }
+ return 0;
+}
+
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
int nr_refspec, char **refspec, int all)
{
struct refspec *rs =
parse_ref_spec(nr_refspec, (const char **) refspec);
- if (nr_refspec)
- return match_explicit_refs(src, dst, dst_tail, rs, nr_refspec);
+ if (nr_refspec) {
+ if (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))
+ return -1;
+ }
/* pick the remainder */
for ( ; src; src = src->next) {
struct ref *dst_peer;
if (src->peer_ref)
continue;
+ if (!check_pattern_match(rs, nr_refspec, src))
+ continue;
+
dst_peer = find_ref_by_name(dst, src->name);
- if ((dst_peer && dst_peer->peer_ref) || (!dst_peer && !all))
+ if (dst_peer && dst_peer->peer_ref) {
+ /* We're already sending something to this ref. */
+ continue;
+ }
+ if (!dst_peer && !nr_refspec && !all) {
+ /* Remote doesn't have it, and we have no
+ * explicit pattern, and we don't have
+ * --all. */
continue;
+ }
if (!dst_peer) {
/* Create a new one and link it */
int len = strlen(src->name) + 1;
diff --git a/send-pack.c b/send-pack.c
index 59352c8..697dbbc 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -354,6 +354,7 @@ static void verify_remote_names(int nr_heads, char **heads)
case -2: /* ok but a single level -- that is fine for
* a match pattern.
*/
+ case -3: /* ok but ends with a pattern-match character */
continue;
}
die("remote part of refspec is not a valid name in %s",
--
1.5.2.rc2.90.gc593-dirty
^ permalink raw reply related
* [PATCH] gitweb: Normalize searchbar font size
From: Petr Baudis @ 2007-05-17 2:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently, searchbar font was as big as the page heading font, because
font-size was made relative - but to the parent element, which was for some
reason indeed page_header. Since that seems to be illogical to me, I just
moved the div.search outside of div.page_header. I'm no CSS/DOM expert but
no adverse effects were observed by me.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ff2f25b..4a1a423 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1988,6 +1988,8 @@ EOF
}
print "\n";
}
+ print "</div>\n";
+
my ($have_search) = gitweb_check_feature('search');
if ((defined $project) && ($have_search)) {
if (!defined $searchtext) {
@@ -2017,7 +2019,6 @@ EOF
"</div>" .
$cgi->end_form() . "\n";
}
- print "</div>\n";
}
sub git_footer_html {
^ permalink raw reply related
* [PATCH] gitweb: Allow arbitrary strings to be dug with pickaxe
From: Petr Baudis @ 2007-05-17 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Currently, there are rather draconian restrictions on the strings accepted
by the pickaxe search, which degrades its usefulness for digging in code
significantly. This patch remedies mentioned limitation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a1a423..8dc009a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -404,7 +404,7 @@ if (defined $searchtype) {
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
- if ($searchtype ne 'grep' and $searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
+ if ($searchtype ne 'grep' and $searchtype ne 'pickaxe' and $searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
die_error(undef, "Invalid search parameter");
}
if (length($searchtext) < 2) {
@@ -4794,8 +4794,10 @@ sub git_search {
my $alternate = 1;
$/ = "\n";
my $git_command = git_cmd_str();
+ my $searchqtext = $searchtext;
+ $searchqtext =~ s/'/'\\''/;
open my $fd, "-|", "$git_command rev-list $hash | " .
- "$git_command diff-tree -r --stdin -S\'$searchtext\'";
+ "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
undef %co;
my @files;
while (my $line = <$fd>) {
^ permalink raw reply related
* [PATCH] gitweb: Add support for grep searches
From: Petr Baudis @ 2007-05-17 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The 'grep' type of search greps the currently selected tree for given
regexp and shows the results in a fancy table with links into blob view.
The number of shown matches is limited to 1000 and the whole feature
can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
unhappy).
This second revision makes it in documentation explicit that grep accepts
regexps, and makes grep accept extended regexps instead of basic regexps.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.css | 4 ++
gitweb/gitweb.perl | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 125 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 02623cb..9f0822f 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -484,3 +484,7 @@ span.atnight {
span.match {
color: #e00000;
}
+
+div.binary {
+ font-style: italic;
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 549e027..f37fa0c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -146,6 +146,19 @@ our %feature = (
'override' => 0,
'default' => [1]},
+ # Enable grep search, which will list the files in currently selected
+ # tree containing the given string. Enabled by default. This can be
+ # potentially CPU-intensive, of course.
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'grep'}{'default'} = [1];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'grep'}{'override'} = 1;
+ # and in project config gitweb.grep = 0|1;
+ 'grep' => {
+ 'override' => 0,
+ 'default' => [1]},
+
# Enable the pickaxe search, which will list the commits that modified
# a given string in a file. This can be practical and quite faster
# alternative to 'blame', but still potentially CPU-intensive.
@@ -245,6 +258,18 @@ sub gitweb_have_snapshot {
return $have_snapshot;
}
+sub feature_grep {
+ my ($val) = git_get_project_config('grep', '--bool');
+
+ if ($val eq 'true') {
+ return (1);
+ } elsif ($val eq 'false') {
+ return (0);
+ }
+
+ return ($_[0]);
+}
+
sub feature_pickaxe {
my ($val) = git_get_project_config('pickaxe', '--bool');
@@ -364,10 +389,17 @@ if (defined $page) {
}
}
+our $searchtype = $cgi->param('st');
+if (defined $searchtype) {
+ if ($searchtype =~ m/[^a-z]/) {
+ die_error(undef, "Invalid searchtype parameter");
+ }
+}
+
our $searchtext = $cgi->param('s');
our $search_regexp;
if (defined $searchtext) {
- if ($searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
+ if ($searchtype ne 'grep' and $searchtext =~ m/[^a-zA-Z0-9_\.\/\-\+\:\@ ]/) {
die_error(undef, "Invalid search parameter");
}
if (length($searchtext) < 2) {
@@ -1923,7 +1955,7 @@ EOF
$cgi->hidden(-name => "a") . "\n" .
$cgi->hidden(-name => "h") . "\n" .
$cgi->popup_menu(-name => 'st', -default => 'commit',
- -values => ['commit', 'author', 'committer', 'pickaxe']) .
+ -values => ['commit', 'grep', 'author', 'committer', 'pickaxe']) .
$cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
" search:\n",
$cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
@@ -4615,6 +4647,12 @@ sub git_search {
die_error('403 Permission denied', "Permission denied");
}
}
+ if ($searchtype eq 'grep') {
+ my ($have_grep) = gitweb_check_feature('grep');
+ if (!$have_grep) {
+ die_error('403 Permission denied', "Permission denied");
+ }
+ }
git_header_html();
@@ -4731,6 +4769,73 @@ sub git_search {
print "</table>\n";
}
+
+ if ($searchtype eq 'grep') {
+ git_print_page_nav('','', $hash,$co{'tree'},$hash);
+ git_print_header_div('commit', esc_html($co{'title'}), $hash);
+
+ print "<table cellspacing=\"0\">\n";
+ my $alternate = 1;
+ my $matches = 0;
+ $/ = "\n";
+ open my $fd, "-|", git_cmd(), 'grep', '-n', '-i', '-E', $searchtext, $co{'tree'};
+ my $lastfile = '';
+ while (my $line = <$fd>) {
+ chomp $line;
+ my ($file, $lno, $ltext, $binary);
+ last if ($matches++ > 1000);
+ if ($line =~ /^Binary file (.+) matches$/) {
+ $file = $1;
+ $binary = 1;
+ } else {
+ (undef, $file, $lno, $ltext) = split(/:/, $line, 4);
+ }
+ if ($file ne $lastfile) {
+ $lastfile and print "</td></tr>\n";
+ if ($alternate++) {
+ print "<tr class=\"dark\">\n";
+ } else {
+ print "<tr class=\"light\">\n";
+ }
+ print "<td class=\"list\">".
+ $cgi->a({-href => href(action=>"blob", hash=>$co{'hash'},
+ file_name=>"$file"),
+ -class => "list"}, esc_path($file));
+ print "</td><td>\n";
+ $lastfile = $file;
+ }
+ if ($binary) {
+ print "<div class=\"binary\">Binary file</div>\n";
+ } else {
+ $ltext = untabify($ltext);
+ if ($ltext =~ m/^(.*)($searchtext)(.*)$/i) {
+ $ltext = esc_html($1, -nbsp=>1);
+ $ltext .= '<span class="match">';
+ $ltext .= esc_html($2, -nbsp=>1);
+ $ltext .= '</span>';
+ $ltext .= esc_html($3, -nbsp=>1);
+ } else {
+ $ltext = esc_html($ltext, -nbsp=>1);
+ }
+ print "<div class=\"pre\">" .
+ $cgi->a({-href => href(action=>"blob", hash=>$co{'hash'},
+ file_name=>"$file").'#l'.$lno,
+ -class => "linenr"}, sprintf('%4i', $lno))
+ . ' ' . $ltext . "</div>\n";
+ }
+ }
+ if ($lastfile) {
+ print "</td></tr>\n";
+ if ($matches > 1000) {
+ print "<div class=\"diff nodifferences\">Too many matches, listing trimmed</div>\n";
+ }
+ } else {
+ print "<div class=\"diff nodifferences\">No matches found</div>\n";
+ }
+ close $fd;
+
+ print "</table>\n";
+ }
git_footer_html();
}
@@ -4741,6 +4846,20 @@ sub git_search_help {
<dl>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given string.</dd>
+EOT
+ my ($have_grep) = gitweb_check_feature('grep');
+ if ($have_grep) {
+ print <<EOT;
+<dt><b>grep</b></dt>
+<dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
+ a different one) are searched for the given
+<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
+(POSIX extended) and the matches are listed. On large
+trees, this search can take a while and put some strain on the server, so please use it with
+some consideration.</dd>
+EOT
+ }
+ print <<EOT;
<dt><b>author</b></dt>
<dd>Name and e-mail of the change author and date of birth of the patch will be scanned for the given string.</dd>
<dt><b>committer</b></dt>
^ 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