* Re: [PATCH] gitweb: Fix "Use of uninitialized value" warning in git_feed
From: Jakub Narebski @ 2007-05-19 2:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzu937t6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Initial (root) commit has no parents, and $co{'parent'} is
>> undefined. Use '--root' for initial commit.
>>
>> This fixes "Use of uninitialized value in open at gitweb/gitweb.perl
>> line 4925." warning.
[...]
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -4923,7 +4923,8 @@ XML
>>
>> # get list of changed files
>> open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
>> - $co{'parent'}, $co{'id'}, "--", (defined $file_name ? $file_name : ())
>> + $co{'parent'} || "--root",
>> + $co{'id'}, "--", (defined $file_name ? $file_name : ())
>> or next;
>> my @difftree = map { chomp; $_ } <$fd>;
>> close $fd
>
> I do not think you would need to make --root conditional...
I need at last make $co{'parent'} conditional, i.e. at least
"$co{'parent'} || ()" or equivalent (e.g. like for $file_name).
I cannot omit $co{'parent'} because parents might be rewritten;
feeds accept now path limiting. So why not this way?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Extra columns in blame
From: A Large Angry SCM @ 2007-05-19 2:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <7vy7jl3bu5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>>> Also the incremental thing using JavaScript does not seem to
>>> work for me incrementally for some reason, although if I wait
>>> long enough I get the fully blamed picture that seems to match
>>> nonincremental one. While I am waiting, the browser goes silent
>>> and does not even let me switch to other tabs, so it is not all
>>> that useful to me in its current shape.
>> Strange, what browser are you using?
>
> Firefox (I think it is 2.0) running on a W2k box behind two http
> proxies.
Same symptoms with FireFox 1.5.0.10 running on Suse 9.3.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix "Use of uninitialized value" warning in git_feed
From: Junio C Hamano @ 2007-05-19 2:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705190408.40702.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Initial (root) commit has no parents, and $co{'parent'} is
>>> undefined. Use '--root' for initial commit.
>>>
>>> This fixes "Use of uninitialized value in open at gitweb/gitweb.perl
>>> line 4925." warning.
> [...]
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -4923,7 +4923,8 @@ XML
>>>
>>> # get list of changed files
>>> open my $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
>>> - $co{'parent'}, $co{'id'}, "--", (defined $file_name ? $file_name : ())
>>> + $co{'parent'} || "--root",
>>> + $co{'id'}, "--", (defined $file_name ? $file_name : ())
>>> or next;
>>> my @difftree = map { chomp; $_ } <$fd>;
>>> close $fd
>>
>> I do not think you would need to make --root conditional...
>
> I need at last make $co{'parent'} conditional, i.e. at least
> "$co{'parent'} || ()" or equivalent (e.g. like for $file_name).
> I cannot omit $co{'parent'} because parents might be rewritten;
> feeds accept now path limiting. So why not this way?
Ah, clever (buuuuuuut misleading) ;-)
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Shawn O. Pearce @ 2007-05-19 3:58 UTC (permalink / raw)
To: david; +Cc: Linus Torvalds, Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0705181742470.20116@asgard.lang.hm>
david@lang.hm wrote:
> when a person browsing a hostile website will allow that website to take
> over the machine the demand is created for 'malware filters' for http, to
> do this the firewalls need to decode the http, and in the process limit
> you to only doing legitimate http.
>
> it's also the case that the companies that have firewalls paranoid enough
> to not let you get to the git port are highly likely to be paranoid enough
> to have a malware filtering http firewall.
I'm behind such a filter, and fetch git.git via HTTP just to keep
my work system current with Junio. ;-)
Of course we're really really really paranoid about our firewall,
but are also so paranoid that any other web browser *except*
Microsoft Internet Explorer is thought to be a security risk and
is more-or-less banned from the network.
The kicker is some of our developers create public websites, where
testing your local webpage with Firefox and Safari is pretty much
required... but those browsers still aren't as trusted as IE and
require special clearances. *shakes head*
We're pretty much limited to:
*) Running the native Git protocol SSL, where the remote system
is answering to port 443. It may not need to be HTTP at all,
but it probably has to smell enough like SSL to get it through
the malware filter. Oh, what's that? The filter cannot actually
filter the SSL data? Funny! ;-)
*) Using a single POST upload followed by response from server,
formatted with minimal HTTP headers. The real problem as people
have pointed out is not the HTTP headers, but it is the single
exchange.
One might think you could use HTTP pipelining to try and get a
bi-directional channel with the remote system, but I'm sure proxy
servers are not required to reuse the same TCP connection to the
remote HTTP server when the inside client piplines a new request.
So any sort of hack on pipelining won't work.
If you really want a stateful exchange you have to treat HTTP as
though it were IP, but with reliable (and much more expensive)
packet delivery, and make the Git daemon keep track of the protocol
state with the client. Yes, that means that when the client suddenly
goes away and doesn't tell you he went away you also have to garbage
collect your state. No nice messages from your local kernel. :-(
--
Shawn.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-19 3:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, git
In-Reply-To: <20070518224209.GG10475@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Sven Verdoolaege, Sat, May 19, 2007 00:08:26 +0200:
> ...
>> The reason for not putting this in shouldn't be that someone doesn't
>> think it is useful; the reason should be that my code is crap.
>
> The code is not a problem. It can be also discarded because you
> implemented something no one wants.
More specifically, at the very high level, what you do and what
people want to happen might share the description (e.g. "this
allows checkout of subprojects", or "this implements clone of
superproject to recurse") but with semantics that may be
different from what people would want (I am not saying that is
the case, as I do not think the current discussion concluded
yet). The _first_ implementation that goes in the mainline
pretty much sets the _semantics_ so we would need to be extra
careful, all the more so as this is a feature many people seem
to want.
> I just meant to say, that even if no one wants your subproject cloning
> code, _I_ support your checkout effort and I am asking for it to be
> put in.
>
> "First", as the cloning discussion does not seem to be finished (and,
> as I said, I am not interested in cloning anyway).
It was partly my fault that I mentioned "clone" example in the
original message, and then let the discussion drifted to a
tangent of the clone topic, namely, how the URL would be
determined to clone the subproject from.
I would agree that checkout is a more fundamental operation, and
I wanted to make that clear in my message, but checkout and
clone has certain chicken-and-egg factor between them. After
the clone of superproject, checking it out recursively would
need cloning the subprojects. Also after a clone of
superproject without the recursive behaviour, when the user
explicitly asks a subproject to be checked out, somebody needs
to do a clone before the subject can be checked out.
Having said that, let's throw out an strawman for checkout
proper and then merge.
The user may or may not want to deal with subprojects, and for
something truly large like the KDE case, which is where the
superproject support is really needed, a large On/Off switch
where an option --subproject makes everything checked out and no
subproject is checked out without it is not a usable option.
I've already outlined how the .git/config file can be used to
define which subprojects are of interested so that the Porcelain
layer can decide which ones to recurse into and which ones to
leave alone. The design is NOT the only possible/sensible one,
and I am sure other people will come up with much nicer
organization, but I would consider that is just the matter of
details.
Now, suppose "git checkout" needs to recurse into one
subdirectory that is to have a subproject. There are three
cases:
(1) There is no git repository yet (the plumbing layer already
makes sure there is a directory, but does not do anything
else).
(2) There already is a git repository there, which is the
correct repository (perhaps determined by .gitmodules and
.git/config in the superproject, or presense of the commit
that is recorded in the superproject's index).
(3) There is a git repository but it is not the correct one.
We've discussed in the other thread about what to do in case
(1) to some degree.
For case (2), I think what should happen there is an equivalent
of this:
$ commit=$(git-rev-parse :subproject)
$ cd subproject
$ git-rev-parse --verify $commit || git fetch || barf
$ git checkout $commit
That is,
- figure out what commit should be checked out from
superproject index;
- make sure the named commit exists, or fetch to make it exist.
- go there and check out that commit; this implies two things:
1. if there are local changes, it will be carried along and we
checkout the named commit;
2. the repository's HEAD becomes detached;
It is entirely possible that the repository is the _correct_ one
but not quite up to date, and you haven't fetched $commit. This
is really a variant of (1) -- before being able to check out,
somebody has to clone the subproject. Before being able to
check out to update the latest, somebody has to fetch in the
subproject.
If there are local changes, we would not at least lose them. If
you want to get to a clean slate, you can cd there and perform
"git reset --hard". If you want to mark that commit in the
subproject, you may want to do "git checkout -b branch" after
the recursive checkout from the superproject detached the HEAD
to the commit.
There is another variant that has already been suggested. The
superproject tree and index could record 0{40} object name for
the subproject, and say "whatever commit happens to be at the
tip of the branch of subproject" (and most likely that URL and
branch information would come from .gitmodules and confirmed in
the .git/config file). In such a case, the above outline would
be adjusted _BUT_ I think what would be checked out will not be
the named branch (e.g. refs/heads/master) itself, but the remote
branch that tracks it (e.g. refs/remotes/origin/master).
While I am at it, let me think aloud as to what I _think_ should
happen in a superproject merge.
- Carry out the tree-level 3-way merge. If it trivially
resolves at the tree-level, we are happy.
- There could be a case where the commit fetched/merged branch
has and what the current branch has are different. If one is
a fast forward of the other, take it.
- All other cases will leave the superproject index unmerged.
When the merge is cleanly done, the resulting commit is what we
should check out in the subproject directory (if we are
recursing into it, of course).
It is likely that in some cases you would want go to the
subproject directory and merge the commits at the subproject
from our branch and their branch in the superproject's index,
and make the resulting commit as the result of the merge for
that subproject path in the superproject, but I do not think it
is the only valid solution.
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: Shawn O. Pearce @ 2007-05-19 4:02 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20070518134316.GA21925@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Fri, May 18, 2007 at 06:56:35AM +0200, Petr Baudis wrote:
> > BTW, there is this nice git-request-pull tool which will prepare this
> > mail for you and additionally include the list of commits included in
> > that repository, which is somewhat more friendly to the readers (I
> > myself wondered). ;-)
>
> OK! I'll start including the shortlog. Appended, if anyone's still
> curious about this one.--b.
request-pull also does nice things like include the fetch URL, and
the branch name, and in a nice format that makes it very easy to
copy and paste into a "git pull" (or "git fetch") command line[*1*],
so its slightly more than just the shortlog. ;-)
[*1*] By popular demand from Git's creator.
--
Shawn.
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: J. Bruce Fields @ 2007-05-19 4:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20070519040212.GC3141@spearce.org>
On Sat, May 19, 2007 at 12:02:12AM -0400, Shawn O. Pearce wrote:
> request-pull also does nice things like include the fetch URL, and
> the branch name, and in a nice format that makes it very easy to
> copy and paste into a "git pull" (or "git fetch") command line[*1*],
> so its slightly more than just the shortlog. ;-)
I know, but that's not hard to do by hand. Which doesn't, of course,
mean I won't screw it up....
But, actually, I tried it just now and it only gave the url:
The following changes since commit 164b19893ab5bc66b531a26480149a0dff082969:
Michael Hendricks (1):
Document core.excludesfile for git-add
are found in the git repository at:
git://linux-nfs.org/~bfields/git.git
How's it supposed to figure out the branch name? (And I'm not sure
about that "change since commit..." stuff--that seems like slight
overkill.)
--b.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Shawn O. Pearce @ 2007-05-19 4:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, skimo, git
In-Reply-To: <7vd50x1n0r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Now, suppose "git checkout" needs to recurse into one
> subdirectory that is to have a subproject. There are three
> cases:
So I've implemented my own Git subproject support in a Java based
tool we use internally. Its actually driving the Git plumbing (as
JGit isn't complete enough to do the job) but applies quite a bit
to this discussion as it is a working system that implements this
"checkout in superproject and recurse into subproject".
First I don't use the subproject support in the core plumbing,
because that came along from Linus about 2 days after I wrote
this implementation. Our data file looks like:
use-component: subproject1 >=df8cfac815...
use-component: subproject2 >=af9b543820...
Or really anything that is a valid commit-ish, and often these are
actually just annotated tag names.
> (1) There is no git repository yet (the plumbing layer already
> makes sure there is a directory, but does not do anything
> else).
During our build process we scan the root project's data file,
and clone by the relative URL anything we cannot find locally:
$(git config remote.origin.url)/../component-links/subproject1.git
to get the subproject repository. We don't require that the
subproject1 directory actually be called subproject1 in the
superproject, its just a recommendation. That data file is also
our build-system driver and the build system driver is pretty darn
smart about guessing what is going on. ;-)
You'll notice however that we (more or less) have a very flat
structure. The component-links directory is really just a set of
symlinks pointing back up a level, as sometimes a component is not
stored in a repository named the component name, but the component
name matters to the build system.
> (2) There already is a git repository there, which is the
> correct repository (perhaps determined by .gitmodules and
> .git/config in the superproject, or presense of the commit
> that is recorded in the superproject's index).
>
> (3) There is a git repository but it is not the correct one.
>
> For case (2), I think what should happen there is an equivalent
> of this:
>
> $ commit=$(git-rev-parse :subproject)
> $ cd subproject
> $ git-rev-parse --verify $commit || git fetch || barf
> $ git checkout $commit
Yes. Except we do a few things differently:
- Only update the subproject if its a strict fast-forward.
- Abort on a dirty working directory in the subproject or if a merge
would be required to keep the current commit and the new commit.
Yes, we don't really support going "backwards".
- The merge aborting thing is probably wrong for some users,
but blindly switching to the target commit feels somewhat wrong
in our own uses. Sometimes you need the current version of the
subproject to help you debug an older version of the superproject,
or sibling subproject.
- You can't just checkout $commit if you can rev-parse it.
You need to verify it and its entire reachable object set exists.
See the local fetch fast-path thing you did recently in e3c6f240fd.
- We update the user's current branch. Because we are doing
a strict fast-forward we're also assuming the user wants the
current branch to stay correlated to the superproject branch. Why?
Most of our users keep the same branch name in all repositories.
--
Shawn.
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: Shawn O. Pearce @ 2007-05-19 4:32 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20070519041357.GA2679@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> But, actually, I tried it just now and it only gave the url:
>
> The following changes since commit 164b19893ab5bc66b531a26480149a0dff082969:
> Michael Hendricks (1):
> Document core.excludesfile for git-add
>
> are found in the git repository at:
>
> git://linux-nfs.org/~bfields/git.git
>
> How's it supposed to figure out the branch name?
It connects to the remote URL, lists the refs found there, and
finds any that has the commit you passed in as the 3rd argument
(defaults to HEAD). If none match it prints ..BRANCH.NOT.VERIFIED..
as the branch name, to signal no branch points at the given commit,
which means it cannot be (easily) pulled.
Not getting that means you have too old of a Git to have my branch
improvements. It was in ff06c743dc, which is in master and hence
should be in 1.5.2 final.
> (And I'm not sure
> about that "change since commit..." stuff--that seems like slight
> overkill.)
Yea, it can be a little overkill sometimes. But the maintainer
knows where you started from. If that commit is horribly old he
might wonder what is going on. ;-)
--
Shawn.
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: david @ 2007-05-19 4:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Matthieu Moy, git
In-Reply-To: <20070519035856.GB3141@spearce.org>
On Fri, 18 May 2007, Shawn O. Pearce wrote:
> david@lang.hm wrote:
>> when a person browsing a hostile website will allow that website to take
>> over the machine the demand is created for 'malware filters' for http, to
>> do this the firewalls need to decode the http, and in the process limit
>> you to only doing legitimate http.
>>
>> it's also the case that the companies that have firewalls paranoid enough
>> to not let you get to the git port are highly likely to be paranoid enough
>> to have a malware filtering http firewall.
>
> I'm behind such a filter, and fetch git.git via HTTP just to keep
> my work system current with Junio. ;-)
>
> Of course we're really really really paranoid about our firewall,
> but are also so paranoid that any other web browser *except*
> Microsoft Internet Explorer is thought to be a security risk and
> is more-or-less banned from the network.
>
> The kicker is some of our developers create public websites, where
> testing your local webpage with Firefox and Safari is pretty much
> required... but those browsers still aren't as trusted as IE and
> require special clearances. *shakes head*
this isn't paranoia, this is just bullheadedness
> We're pretty much limited to:
>
> *) Running the native Git protocol SSL, where the remote system
> is answering to port 443. It may not need to be HTTP at all,
> but it probably has to smell enough like SSL to get it through
> the malware filter. Oh, what's that? The filter cannot actually
> filter the SSL data? Funny! ;-)
we're actually paranoid enough to have devices that do man-in-the-middle
decryption for some sites, and are given copies of the encryption keys
that other sites (and browsers) use so that it can decrypt the SSL and
check it. I admit that this is far more paranoid then almost all sites
though :-)
> *) Using a single POST upload followed by response from server,
> formatted with minimal HTTP headers. The real problem as people
> have pointed out is not the HTTP headers, but it is the single
> exchange.
> If you really want a stateful exchange you have to treat HTTP as
> though it were IP, but with reliable (and much more expensive)
> packet delivery, and make the Git daemon keep track of the protocol
> state with the client. Yes, that means that when the client suddenly
> goes away and doesn't tell you he went away you also have to garbage
> collect your state. No nice messages from your local kernel. :-(
unfortunantly you are right about this.
David Lang
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: J. Bruce Fields @ 2007-05-19 5:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20070519043234.GE3141@spearce.org>
On Sat, May 19, 2007 at 12:32:34AM -0400, Shawn O. Pearce wrote:
> It connects to the remote URL, lists the refs found there, and
> finds any that has the commit you passed in as the 3rd argument
> (defaults to HEAD). If none match it prints ..BRANCH.NOT.VERIFIED..
> as the branch name, to signal no branch points at the given commit,
> which means it cannot be (easily) pulled.
>
> Not getting that means you have too old of a Git to have my branch
> improvements. It was in ff06c743dc, which is in master and hence
> should be in 1.5.2 final.
OK, that's very nifty.
> > (And I'm not sure
> > about that "change since commit..." stuff--that seems like slight
> > overkill.)
>
> Yea, it can be a little overkill sometimes. But the maintainer
> knows where you started from. If that commit is horribly old he
> might wonder what is going on. ;-)
Is that really helpful in practice? Well, what would I know.
--b.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-05-19 5:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcqccnbm.fsf@assigned-by-dhcp.cox.net>
I've done release 1.5.1.5, which hopefully would be the second
from the last release in 1.5.1 maintenance series (I somehow
ended up missing documentation formatting updates from Matthias
Kestenholz, which fix longstanding ugly formatting mistakes in
some manual pages).
The tip of 'master' will be tagged v1.5.2 hopefully in 24 hours.
Nothing earth shattering since the last message of this series.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
J. Bruce Fields (10):
user-manual: revise birdseye-view chapter
glossary: expand and clarify some definitions, prune cross-references
user-manual: move quick-start to an appendix
Documentation: remove howto's now incorporated into manual
user-manual: move howto/make-dist.txt into user manual
user-manual: move howto/using-topic-branches into manual
user-manual: add a "counting commits" example
user-manual: introduce git
user-manual: listing commits reachable from some refs not others
user-manual: reorganize public git repo discussion
Johannes Schindelin (1):
Add a birdview-on-the-source-code section to the user manual
Junio C Hamano (1):
GIT v1.5.1.5
Matthias Kestenholz (2):
Documentation: Added [verse] to SYNOPSIS where necessary
Documentation: Reformatted SYNOPSIS for several commands
Michael Hendricks (2):
git-send-email: allow leading white space on mutt aliases
Document core.excludesfile for git-add
Petr Baudis (1):
Documentation: git-rev-list's "patterns"
* The 'master' branch has these since the last announcement
in addition to the above.
Andy Parkins (1):
Fix crlf attribute handling to match documentation
Jakub Narebski (2):
gitweb: Fix error in git_patchset_body for deletion in merge commit
gitweb: Fix "Use of uninitialized value" warning in git_feed
Junio C Hamano (3):
gitweb: fix another use of undefined value
Add link to 1.5.1.5 release notes.
Documentation/git.txt: Update links to older documentation pages.
Petr Baudis (4):
gitweb: Normalize searchbar font size
gitweb: Add support for grep searches
gitweb: Allow arbitrary strings to be dug with pickaxe
gitweb: Remove redundant $searchtype setup
René Scharfe (1):
git-archive: convert archive entries like checkouts do
Shawn O. Pearce (1):
git-gui: Gracefully handle bad TCL_PATH at compile time
Steffen Prohaska (1):
Optimized cvsexportcommit: calling 'cvs status' once instead of once per touched file.
^ permalink raw reply
* Git branching & pulling
From: Wink Saville @ 2007-05-19 5:40 UTC (permalink / raw)
To: git
Hello,
I'm having trouble understanding branching and pull.
Using git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
I can create a branch off the master and do a pull:
wink@ic2d1:~/linux/linux-2.6$ git-checkout master
Switched to branch "master"
wink@ic2d1:~/linux/linux-2.6$ git-checkout -b test
Switched to a new branch "test"
wink@ic2d1:~/linux/linux-2.6$ git-pull
Already up-to-date.
But from some reason using
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
the following happens
wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout master
Already on branch "master"
wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout -b test
Switched to a new branch "test"
wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull
Warning: No merge candidate found because value of config option
"branch.test.merge" does not match any remote branch fetched.
No changes.
What I notice is that in kvm.git that .git/remotes is empty while on
linux-2.6.git
.git/remotes has origin and it contains:
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: refs/heads/master:refs/heads/origin
Another difference is that the .git/config file of kvm.git has quite a
few items:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
While linux-2.6.git is quite sparse:
[core]
repositoryformatversion = 0
filemode = true
Could someone give me some insight or point me at a url or doc
that could shed some light on what is happening and why git-pull
doesn't work on kvm.git.
Thanks,
Wink Saville
^ permalink raw reply
* Git Super Projects
From: Ryan Phillips @ 2007-05-19 5:39 UTC (permalink / raw)
To: git
After watching Linus' presentation on git at google. What are these super
projects? Has this feature been released, or is it still in development?
My guess these are like svn externals.
Thanks,
Ryan
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-05-19 5:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net>
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.
------------------------
To graduate immediately after 1.5.2, after 'maint' forks from
it.
* 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
------------------------
To be re-reviewed and then merged to 'next' after 1.5.2.
* 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.
* 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
------------------------
I've queued this series only because I trust Pasky, not because I
looked at the code deeply. I am not sure about this one's use
of JavaScript is acceptable (I haven't looked at the code and do
not even know if that is optional X-< Yes, I know, My Bad).
* pb/web (Sat May 19 02:13:39 2007 +0200) 6 commits
- gitweb: Clearly distinguish regexp / exact match searches
- gitweb: Lift any characters restriction on searched strings
- git-rev-list: Add regexp tuning options
- gitweb: Remove git_blame (superseded by git_blame2)
- gitweb: Extra columns in blame
- gitweb: Incremental blame
------------------------
On hold.
* 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: Git branching & pulling
From: J. Bruce Fields @ 2007-05-19 5:49 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <d4cf37a60705182240s414243a6wae69d26f70f64dd5@mail.gmail.com>
On Fri, May 18, 2007 at 10:40:17PM -0700, Wink Saville wrote:
> Hello,
>
> I'm having trouble understanding branching and pull.
>
> Using git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> I can create a branch off the master and do a pull:
>
> wink@ic2d1:~/linux/linux-2.6$ git-checkout master
> Switched to branch "master"
> wink@ic2d1:~/linux/linux-2.6$ git-checkout -b test
> Switched to a new branch "test"
> wink@ic2d1:~/linux/linux-2.6$ git-pull
> Already up-to-date.
>
>
>
> But from some reason using
> git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
> the following happens
>
> wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout master
> Already on branch "master"
> wink@ic2d1:~/linux/kvm-linux-2.6$ git-checkout -b test
> Switched to a new branch "test"
> wink@ic2d1:~/linux/kvm-linux-2.6$ git-pull
> Warning: No merge candidate found because value of config option
> "branch.test.merge" does not match any remote branch fetched.
> No changes.
The differences you describe are almost certainly due to differences in
the git version, not the cloned repository. Are you sure git wasn't
ugpraded between the two tests?
--b.
^ permalink raw reply
* Re: Git branching & pulling
From: Junio C Hamano @ 2007-05-19 6:00 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <d4cf37a60705182240s414243a6wae69d26f70f64dd5@mail.gmail.com>
"Wink Saville" <wink@saville.com> writes:
> Could someone give me some insight or point me at a url or doc
> that could shed some light on what is happening and why git-pull
> doesn't work on kvm.git.
DEFAULT BEHAVIOUR section of
http://www.kernel.org/pub/software/scm/git/docs/git-pull.html
would be the place to start. Recent git-clone (post 1.5.0, I think)
prepares the following configuration variables for you by default:
remote.origin.url
remote.origin.fetch
branch.master.remote
branch.master.merge
but repositories created by older git-clone didn't.
^ permalink raw reply
* Re: Git Super Projects
From: Junio C Hamano @ 2007-05-19 6:01 UTC (permalink / raw)
To: Ryan Phillips; +Cc: git
In-Reply-To: <20070519053955.GA27415@zeus.kimaker.com>
Ryan Phillips <ryan-kernel@trolocsis.com> writes:
> After watching Linus' presentation on git at google. What are these super
> projects? Has this feature been released, or is it still in development?
>
> My guess these are like svn externals.
Look at "What's not in 1.5.2" messages, please ;-).
^ permalink raw reply
* Re: Git branching & pulling
From: Junio C Hamano @ 2007-05-19 6:05 UTC (permalink / raw)
To: Wink Saville; +Cc: git
In-Reply-To: <7v8xblz71o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Wink Saville" <wink@saville.com> writes:
>
>> Could someone give me some insight or point me at a url or doc
>> that could shed some light on what is happening and why git-pull
>> doesn't work on kvm.git.
>
> DEFAULT BEHAVIOUR section of
>
> http://www.kernel.org/pub/software/scm/git/docs/git-pull.html
>
> would be the place to start. Recent git-clone (post 1.5.0, I think)
> prepares the following configuration variables for you by default:
>
> remote.origin.url
> remote.origin.fetch
> branch.master.remote
> branch.master.merge
>
> but repositories created by older git-clone didn't.
/me says "oops I did not finish the sentence".
but repositories created by older git-clone didn't get these
configuration variables set. If you set them appropriately,
taking example of your other repository (and probably you would
also want to remove .git/remotes/origin while you are at it),
you can omit saying which branch to pull from where.
I personally never understood why people would just want to say
"git pull" without saying anything else, but what described in
the DEFAULT BEHAVIOUR section is how it works.
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Eric Wong @ 2007-05-19 6:14 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <vpqtzuf46k9.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Lars Hjemli" <lh@elementstorage.no> writes:
>
> > Is this happening if you dcommit a file in a new directory?
>
> That's it indeed.
>
> The attached script seems to reproducibly trigger the problem on my
> box:
>
> $ ../git-svn-test.sh
> Checked out revision 0.
> A file
> Adding file
> Transmitting file data .
> Committed revision 1.
> Initialized empty Git repository in .git/
> moy@localhost's password:
> A file
> r1 = 4357177f2d927931d31c8c49c0237561648001a7 (git-svn)
>
> Checked out HEAD:
> svn+ssh://localhost//home/moy/tmp/test/test.26377/svnrepo r1
> Created commit aa2db5a: newdir
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 newdir/newfile
> moy@localhost's password:
> A newdir/newfile
> Network connection closed unexpectedly: Connection closed unexpectedly at /home/moy/bin/local/verimag/git-svn line 405
> $
Thanks to your script I can reproduce it.
svnserve (not git-svn) is segfaulting on me...
> #! /bin/sh
>
> mkdir test.$$
> cd test.$$
>
> svnadmin create svnrepo
>
> svn co file://$PWD/svnrepo svnco
>
> cd svnco
> echo content > file
> svn add file
> svn commit -m "added file"
> cd ../
>
> # This triggers the bug.
> git-svn clone svn+ssh://localhost/$PWD/svnrepo git-svn-co
>
> # while this doesn't
> # git-svn clone file://localhost/$PWD/svnrepo git-svn-co
>
> cd git-svn-co
>
> mkdir newdir
> echo othercontent > newdir/newfile
>
> git add newdir/newfile
>
> git commit -m "newdir"
>
> git-svn dcommit
Thanks. I didn't realize entirely new directories (and not empty
directories in svn but git thought were new) were what was causing
things to break.
--
Eric Wong
^ permalink raw reply
* Re: Git branching & pulling
From: Steven Grimm @ 2007-05-19 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wink Saville, git
In-Reply-To: <7vzm41xsa2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I personally never understood why people would just want to say
> "git pull" without saying anything else, but what described in
> the DEFAULT BEHAVIOUR section is how it works.
>
I do that all the time, e.g. when I'm syncing the satellite repo on my
laptop with the mothership repo in my account on my company's server.
The satellite only ever talks to the mothership and I am always
interested in pulling down all the changes I've committed to the
mothership during the day. So there's really no need to specify
anything; I always want to keep the two fully in sync, and there's never
any question about where I'm pulling from.
I do a plain "git pull" in my clone of git.git too. I want all the
latest updates and I'm only ever fetching them from the official git repo.
I can certainly imagine that if I were an integrator in charge of a
master repo, I'd always want to explicitly pull from particular places.
-Steve
^ permalink raw reply
* Re: Git branching & pulling
From: Junio C Hamano @ 2007-05-19 6:28 UTC (permalink / raw)
To: Steven Grimm; +Cc: Wink Saville, git
In-Reply-To: <464E97A4.4050702@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
>> I personally never understood why people would just want to say
>> "git pull" without saying anything else, but what described in
>> the DEFAULT BEHAVIOUR section is how it works.
>>
>
> I do that all the time, e.g. when I'm syncing the satellite repo on my
> laptop with the mothership repo in my account on my company's
> server. The satellite only ever talks to the mothership and I am
> always interested in pulling down all the changes I've committed to
> the mothership during the day. So there's really no need to specify
> anything; I always want to keep the two fully in sync, and there's
> never any question about where I'm pulling from.
>
> I do a plain "git pull" in my clone of git.git too. I want all the
> latest updates and I'm only ever fetching them from the official git
> repo.
Ah, if you ever interact with only single remote repository,
then that is certainly a valid reason not to say anything else.
And if you ever interact with only single branch of a single
remote repository while on one branch, the current config scheme
would let you do that on any branch.
^ permalink raw reply
* [PATCH 0/2] Avoid spending cycles to deltify binary guck
From: Junio C Hamano @ 2007-05-19 7:47 UTC (permalink / raw)
To: git
Somebody wondered on #git if there is a way to avoid spending
cycles and memory on certain objects in a repository, most
notably huge image files (or it might have been porn video
collection, but I do not recall the details).
Here is a quick-and-clean patch series to help such a repository.
[PATCH 1/2] pack-objects: pass fullname down to add_object_entry()
[PATCH 2/2] Teach "delta" attribute to pack-objects.
Although we give pack-objects the pathname for each blob, we
used to hash it down before registering the object to
object_entry array. The first one moves the call site to the
hash function a bit, to give add_object_entry() to inspect the
pathname.
The second patch teaches add_object_entry() to record if an
entry should be exempt from the deltification process, and use
the .gitattributes mechanism to tell which objects should be
marked as such.
The patches are based on np/pack series, and should apply
cleanly to 'next'.
^ permalink raw reply
* [PATCH 1/2] pack-objects: pass fullname down to add_object_entry()
From: Junio C Hamano @ 2007-05-19 7:48 UTC (permalink / raw)
To: git
Instead of giving a hash for grouping, pass fullname to add_object_entry().
I want to add "do not try deltifying this object" bit to object_entry based on
the settings in .gitattributes, and hashing the name down too early would
interfere with that plan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pack-objects.c | 27 ++++++++++++++-------------
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 5fa9813..12d9685 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -721,6 +721,9 @@ static unsigned name_hash(const char *name)
unsigned char c;
unsigned hash = 0;
+ if (!name)
+ return 0;
+
/*
* This effectively just creates a sortable number from the
* last sixteen non-whitespace characters. Last characters
@@ -735,12 +738,13 @@ static unsigned name_hash(const char *name)
}
static int add_object_entry(const unsigned char *sha1, enum object_type type,
- unsigned hash, int exclude)
+ const char *name, int exclude)
{
struct object_entry *entry;
struct packed_git *p, *found_pack = NULL;
off_t found_offset = 0;
int ix;
+ unsigned hash = name_hash(name);
ix = nr_objects ? locate_object_entry_hash(sha1) : -1;
if (ix >= 0) {
@@ -929,10 +933,9 @@ static void add_pbase_object(struct tree_desc *tree,
if (cmp < 0)
return;
if (name[cmplen] != '/') {
- unsigned hash = name_hash(fullname);
add_object_entry(entry.sha1,
S_ISDIR(entry.mode) ? OBJ_TREE : OBJ_BLOB,
- hash, 1);
+ fullname, 1);
return;
}
if (S_ISDIR(entry.mode)) {
@@ -992,10 +995,11 @@ static int check_pbase_path(unsigned hash)
return 0;
}
-static void add_preferred_base_object(const char *name, unsigned hash)
+static void add_preferred_base_object(const char *name)
{
struct pbase_tree *it;
int cmplen;
+ unsigned hash = name_hash(name);
if (!num_preferred_base || check_pbase_path(hash))
return;
@@ -1003,7 +1007,7 @@ static void add_preferred_base_object(const char *name, unsigned hash)
cmplen = name_cmp_len(name);
for (it = pbase_tree; it; it = it->next) {
if (cmplen == 0) {
- add_object_entry(it->pcache.sha1, OBJ_TREE, 0, 1);
+ add_object_entry(it->pcache.sha1, OBJ_TREE, NULL, 1);
}
else {
struct tree_desc tree;
@@ -1434,7 +1438,6 @@ static void read_object_list_from_stdin(void)
{
char line[40 + 1 + PATH_MAX + 2];
unsigned char sha1[20];
- unsigned hash;
for (;;) {
if (!fgets(line, sizeof(line), stdin)) {
@@ -1457,22 +1460,20 @@ static void read_object_list_from_stdin(void)
if (get_sha1_hex(line, sha1))
die("expected sha1, got garbage:\n %s", line);
- hash = name_hash(line+41);
- add_preferred_base_object(line+41, hash);
- add_object_entry(sha1, 0, hash, 0);
+ add_preferred_base_object(line+41);
+ add_object_entry(sha1, 0, line+41, 0);
}
}
static void show_commit(struct commit *commit)
{
- add_object_entry(commit->object.sha1, OBJ_COMMIT, 0, 0);
+ add_object_entry(commit->object.sha1, OBJ_COMMIT, NULL, 0);
}
static void show_object(struct object_array_entry *p)
{
- unsigned hash = name_hash(p->name);
- add_preferred_base_object(p->name, hash);
- add_object_entry(p->item->sha1, p->item->type, hash, 0);
+ add_preferred_base_object(p->name);
+ add_object_entry(p->item->sha1, p->item->type, p->name, 0);
}
static void show_edge(struct commit *commit)
--
1.5.2.rc3.87.g404f
^ permalink raw reply related
* [PATCH 2/2] Teach "delta" attribute to pack-objects.
From: Junio C Hamano @ 2007-05-19 7:48 UTC (permalink / raw)
To: git
In-Reply-To: <11795608912129-git-send-email-junkio@cox.net>
This teaches pack-objects to use .gitattributes mechanism so
that the user can specify certain blobs are not worth spending
CPU cycles to attempt deltification.
The name of the attrbute is "delta", and when it is set to
false, like this:
== .gitattributes ==
*.jpg -delta
they are always stored in the plain-compressed base object
representation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-pack-objects.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 12d9685..651011c 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1,5 +1,6 @@
#include "builtin.h"
#include "cache.h"
+#include "attr.h"
#include "object.h"
#include "blob.h"
#include "commit.h"
@@ -40,9 +41,10 @@ struct object_entry {
enum object_type in_pack_type; /* could be delta */
unsigned char in_pack_header_size;
unsigned char preferred_base; /* we do not pack this, but is available
- * to be used as the base objectto delta
+ * to be used as the base object to delta
* objects against.
*/
+ unsigned char no_try_delta;
};
/*
@@ -737,6 +739,28 @@ static unsigned name_hash(const char *name)
return hash;
}
+static void setup_delta_attr_check(struct git_attr_check *check)
+{
+ static struct git_attr *attr_delta;
+
+ if (!attr_delta)
+ attr_delta = git_attr("delta", 5);
+
+ check[0].attr = attr_delta;
+}
+
+static int no_try_delta(const char *path)
+{
+ struct git_attr_check check[1];
+
+ setup_delta_attr_check(check);
+ if (git_checkattr(path, ARRAY_SIZE(check), check))
+ return 0;
+ if (ATTR_FALSE(check->value))
+ return 1;
+ return 0;
+}
+
static int add_object_entry(const unsigned char *sha1, enum object_type type,
const char *name, int exclude)
{
@@ -801,6 +825,9 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
if (progress)
display_progress(&progress_state, nr_objects);
+ if (name && no_try_delta(name))
+ entry->no_try_delta = 1;
+
return 1;
}
@@ -1349,6 +1376,10 @@ static void find_deltas(struct object_entry **list, int window, int depth)
if (entry->size < 50)
continue;
+
+ if (entry->no_try_delta)
+ continue;
+
free_delta_index(n->index);
n->index = NULL;
free(n->data);
@@ -1376,6 +1407,8 @@ static void find_deltas(struct object_entry **list, int window, int depth)
m = array + other_idx;
if (!m->entry)
break;
+ if (m->entry->no_try_delta)
+ continue;
if (try_delta(n, m, max_depth) < 0)
break;
}
--
1.5.2.rc3.87.g404f
^ 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