* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-18 9:18 UTC (permalink / raw)
To: Petr Baudis
Cc: Steven Grimm, Michael S. Tsirkin, Junio C Hamano, Andy Parkins,
git, Nicolas Pitre
In-Reply-To: <20070518045025.GT4489@pasky.or.cz>
On Friday 18 May 2007, Petr Baudis wrote:
> The problem is ugly too, though - suddenly, you have created a SINGLE
> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going
> to work well.
Actually, tags are already such a namespace. If you want to merge
two projects which have the same tag names, of course you still
preserve the different tag objects, but only one will appear in the
refs/tags namespace.
So what is the best identifier for a subprobject? It is one that
probably never clashes with any subproject identifier of another
superproject. At least, it should not clash between any superprojects
which ever could be a candidate for merging the two into one.
Junios proposal using an URL as identifier actually is quite good in
this regard, similar to JAVA package names.
However, I wonder whether the possible merge of two superprojects
into one is a real issue. When they use the same subprojects identifiers,
there is a workaround: instead of merging, make one superproject the
subproject of the other.
Josef
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Johannes Schindelin @ 2007-05-18 9:01 UTC (permalink / raw)
To: Jan Hudec; +Cc: Nicolas Pitre, Shawn O. Pearce, Martin Langhoff, git
In-Reply-To: <20070517200431.GA3079@efreet.light.src>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1567 bytes --]
Hi,
On Thu, 17 May 2007, Jan Hudec wrote:
> On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
>
> > And if you have 1) the permission and 2) the CPU power to execute such
> > a cgi on the server and obviously 3) the knowledge to set it up
> > properly, then why aren't you running the Git daemon in the first
> > place? After all, they both boil down to running git-pack-objects and
> > sending out the result. I don't think such a solution really buys
> > much.
>
> Yes, it does. I had 2 accounts where I could run CGI, but not separate
> server, at university while I studied and now I can get the same on
> friend's server. Neither of them would probably be ok for serving larger
> busy git repository, but something smaller accessed by several people is
> OK. I think this is quite common for university students.
1) This has nothing to do with the way the repo is served, but how much
you advertise it. The load will not be lower, just because you use a CGI
script.
2) you say yourself that git-daemon would have less impact on the load:
> > [...]
> >
> > Et voilà. Oh, and of course update your local refs from the
> > remote's.
> >
> > Actually there is nothing really complex in the above operations. And
> > with this the server side remains really simple with no special setup
> > nor extra load beyond the simple serving of file content.
>
> On the other hand the amount of data transfered is larger, than with the
> git server approach, because at least the indices have to be transfered
> in entirety.
Ciao,
Dscho
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-18 8:57 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705180857.18182.andyparkins@gmail.com>
...
> > As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.
> > if the superproject is at git://git.kernel.org/pub/super.git, the above
> > subproject would default to the URL
> > git://git.kernel.org/pub/super.git/subproject/linux24 which could be a
> > symlink on the server.
>
> I'm really uncomfortable with the idea of relying on directory structure
> passed the root repository path; from the
> git://git.kernel.org/pub/super.git/
> point onwards; we don't have any right to expect that this is a real directory
> tree. As an example; svn URLs don't match up with what's on disk:
>
> svn://svnhost/pub/repo/trunk/src
> ^^^^^^^^^^
>
> On disk there is no such directory as /trunk/src under the repository
> directory. In the same way, even technically what you suggest would work,
> the part of the URL under git://git.kernel.org/pub/super.git/ is git's own
> namespace - it's not the users to mess with. E.g. if I had a subproject
> called "refs" you'd be in trouble.
Oh, that's easily solvable: just stick a 'subprojects' directory in there.
That is, the default URL to find a subproject would be:
1. For non-bare repo foo/.git/, subproject bar will live in foo/bar/.git
or foo/bar.git.
2. For a bare repo foo.git/, subproject bar will live in
foo.git/subprojects/bar.git.
> > > 2. Suppose .gitmodules in upstream tree points at subproject repo at
> > > kernel.org, and I clone from there - my repo will point at kernel.org by
> > > default? But now, I'd like everyone who clones from *my* repo to get
> > > pointed at *my* server by default (e.g. for mirroring),
> > > but would not changing .gitmodules create a commit so my
> > > head will now differ from upstream - so it won't be signed properly
> > > etc... Did I misunderstand something?
> >
> > No, that is correct. Supporting a relative URL specification as proposed
> > above should solve this issue.
>
> I think that's the wrong solution. A change of source URL for a submodule
> from what upstream uses to your own server is a _fork_ from upstream,
> therefore you would fork your own branch in your supermodule and
> alter .gitmodules to point at your server. Everybody is happy, and the fork
> is recorded.
Why should I record it? If the content is the same, the commit name should
be the same, it shouldn't matter where did the content came from.
I wouldn't be happy: I have just cloned both project and superproject,
but to re-publish the superproject using my clone of subproject, I have
to create a new commit, which would have a different hash from the origin.
So how do people know they can trust my tree?
And what happens when the original super-project pulls from me -
it seems that his .gitmodules will now point to my server?
> The override system is only there for the local repository (which always takes
> precedence) not for the server provider to hide detail from those checking
> the repo out.
I really like it that currently, in git, there is no difference between a public
and local repository. If the override system is only for the local repository,
we create a difference here - doesn't this break the distributed nature of git?
Take offline work as an example:
So I have have cloned the supermodule and the submodule to my laptop -
it's enough to edit .git/config and I can use the history locally - that's good.
But now I try to clone the local tree - and a clone will try to go out
to the URL which I cloned - bad.
--
MST
^ permalink raw reply
* Re: [PATCH 5/7] gitweb: Prototyp for selecting diffs in JavaScript
From: Petr Baudis @ 2007-05-18 8:49 UTC (permalink / raw)
To: Martin Koegler; +Cc: Jakub Narebski, git
In-Reply-To: <481946c2e3cff09ed4a623b1b20b9889666aedb0.1176659095.git.mkoegler@auto.tuwien.ac.at>
Hi,
On Sun, Apr 15, 2007 at 10:46:08PM CEST, Martin Koegler wrote:
> ---
> This patch is only to test the other patches. I'm working on reimplementing it in perl.
I think this is something that I'd quite like to testdrive at
repo.or.cz, but I'm admittelly somewhat lost in all the patches,
resends, new versions, something got applied, etc. - if it's not too big
a hassle for you, would you please care to resend the latest series?
Thanks,
--
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
* git-rebase (1.5.0.6) errors
From: Ilpo Järvinen @ 2007-05-18 8:47 UTC (permalink / raw)
To: git
Hi,
ijjarvin@kivilampi-30:~/work/src/submit$ git-rebase net-2.6.22-origin
First, rewinding head to replay your work on top of it...
HEAD is now at d739437... [IPV4]: Correct rp_filter help text.
fatal: cannot convert from utf-8 to utf-8
ijjarvin@kivilampi-30:~/work/src/submit$ git-log -n 1 | cat
commit d739437207064cdcea8f9c81442284106cbcb67f
Author: Dave Jones <davej@redhat.com>
Date: Thu May 17 15:02:21 2007 -0700
[IPV4]: Correct rp_filter help text.
As mentioned in http://bugzilla.kernel.org/show_bug.cgi?id=5015
The helptext implies that this is on by default.
This may be true on some distros (Fedora/RHEL have it enabled
in /etc/sysctl.conf), but the kernel defaults to it off.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ijjarvin@kivilampi-30:~/work/src/submit$ git-rebase --abort
HEAD is now at e413863... [TCP] FRTO: Add missing ECN CWR sending to one of the responses
ijjarvin@kivilampi-30:~/work/src/submit$ git --version
git version 1.5.0.6
I find at least two problems in it...
- Non-sense error message: "convert from utf-8 to utf-8" ?!?
- It fails to rebase the e413863 changeset
--
i.
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-18 8:43 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Michael S. Tsirkin, Junio C Hamano, Nicolas Pitre
In-Reply-To: <200705180857.18182.andyparkins@gmail.com>
On Friday 18 May 2007, Andy Parkins wrote:
> Bear in mind that what you're suggesting is no different in implementation
> >from what Junio is suggesting but with one difference: in Junio's option
> the "identifier" will act as a default URL if no override is found.
Yes; actually, its exactly the same aside from the name used in .gitmodules
for it, as I proposed a default URL which is derived from the suproject identifier
if no config entry is found.
> > Again, we could have a default URL in the absence of this config entry
> > which is relative to the URL of the superproject, and which allows for the
> > superproject repository to act as proxy.
>
> This is why Junio's option of URL=Key is better.
It all depends on how we construct the default URL out of the subproject
identifier. Options:
(1) do not try to construct a default URL at all. Error out without a config
(2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
(3) automatically detect a senseful rewriting scheme
Let's start with (1). We can invent convenient default schemes later on.
Josef
^ permalink raw reply
* Re: Opinions on bug fix organisation
From: Johannes Sixt @ 2007-05-18 8:11 UTC (permalink / raw)
To: git
In-Reply-To: <200705162220.15417.andyparkins@gmail.com>
Andy Parkins wrote:
> What is your preference when, for example, you have already merged a
> topic to next but then a bug fix appears?
>
> * -- * -- * -- M -- F * -- * -- * -- M -- m (next)
> / or / /
> B -- * -- * B -- * -- * -- F (topic)
>
> F is certainly most appropriate to be on the topic branch, but we create
> a perhaps excessively verbose extra merge, m.
It depends on whether the topic branch is "closed": A topic branch is
"closed" after it is merged into all branches that it is intended to be
merged into.
For example, in our setup we sometimes create topic branches off of
'maint' because we want to keep the option alive to merge it into
'maint', although for the time being it is only merged into 'master'
(main development). If a bug fix appears, we have to add it to 'topic'
and merge into 'master' again (your second example). 'topic' may never
make it into 'maint', but this way we keep the option; hence, 'topic' is
_not_ "closed", yet.
-- Hannes
^ permalink raw reply
* Re: MinGW port: some questions
From: Johannes Sixt @ 2007-05-18 7:58 UTC (permalink / raw)
To: git; +Cc: Alon Ziv
In-Reply-To: <7vejlgegb9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Alon Ziv <alonz@nolaviz.org> writes:
>
> > I am referring, for example, to the changes from commit dc380d6, which
> > were reverted in Git mainline (actually in "next", they never reached
> > Git's "master"). Or to the changes from 4493e36, which had the same
> > fate.
>
> MinGW repository bases its work on my 'next', so it will not be
> pulled wholesale to my 'master'. The plan is to trickle down
> the platform independent bits of fixes and refactoring to the
> mainline, as well as #ifdef __MINGW32__ and $(findstring MINGW)
> parts, but that will most likely happen as a series of bite
> sized patch series to the list with public reviews.
>
> I do not know if you mistyped dc380d6 (I do not find it there),
> but reverting 4493e36 (merge of jc/3way) was intentional. The
> work in that commit that deviates from the mainline is the
> jc/3way topic, which turned out to be incomplete and not very
> usable. MinGW tree might not have synchronized with the latest
> from the mainline in which case it might not have merged the
> revert from me yet, and that may be why you are seeing the
> differences.
Sometime around 1.5.0 I decided to merge only 'master' into MinGW and I
didn't notice that there were some more or less important reversals in
'next'. (Note to myself: Pull 079f7cb27b into mingw before next update.)
-- Hannes
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Andy Parkins @ 2007-05-18 7:57 UTC (permalink / raw)
To: git; +Cc: Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Nicolas Pitre
In-Reply-To: <200705180141.06862.Josef.Weidendorfer@gmx.de>
On Friday 2007 May 18, Josef Weidendorfer wrote:
> However, I think the usage of "url"/"url hint" as the 1st level subproject
> identifier really is badly misleading and confusing for users; it would be
> better for this identifier to not look like a URL at all. But by naming it
> "url" in .gitmodules, the user is tempted to put an URL at this place.
Bear in mind that what you're suggesting is no different in implementation
from what Junio is suggesting but with one difference: in Junio's option
the "identifier" will act as a default URL if no override is found.
Yours:
.gitmodules:
kernel mykernelsubprojectid
.git/config
[subproject "mykernelsubprojectid"]
url = git://host/blah/blah.git
Junio's:
.gitmodules:
kernel git://oldhost/blah/blah.git
.git/config
[subproject "git://oldhost/blah/blah.git"]
url = git://host/blah/blah.git
There is no difference between these two in terms of implementation. Both
assign a key to the "kernel" submodule then use that key to look up an
override. The advantage of Junio's suggestion is that when an override is
not needed the key itself is used and therefore it Just Works (tm) with no
change to the .git/config necessary.
> And why not use the .gitattributes for the ".gitmodules" needs?
I can't think of a reason why not; I think that's a separate question though.
> Again, we could have a default URL in the absence of this config entry
> which is relative to the URL of the superproject, and which allows for the
> superproject repository to act as proxy.
This is why Junio's option of URL=Key is better. You are relying on the
default being correct in order for a simple clone to work. The relative path
scheme you propose as a default, while logical, doesn't match anything that
anyone does right now. Look at any server that hosts multiple projects; they
are stored flat not deep:
project1/
project2/
project3/
One advantage of submodule support is that multiple supermodules can contain
the same submodule, so you really can't force a hierarchical representation
on the world just to make the default URL correct.
project2/
project1/
project3/
project1/
Oops.
> As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie.
> if the superproject is at git://git.kernel.org/pub/super.git, the above
> subproject would default to the URL
> git://git.kernel.org/pub/super.git/subproject/linux24 which could be a
> symlink on the server.
I'm really uncomfortable with the idea of relying on directory structure
passed the root repository path; from the
git://git.kernel.org/pub/super.git/
point onwards; we don't have any right to expect that this is a real directory
tree. As an example; svn URLs don't match up with what's on disk:
svn://svnhost/pub/repo/trunk/src
^^^^^^^^^^
On disk there is no such directory as /trunk/src under the repository
directory. In the same way, even technically what you suggest would work,
the part of the URL under git://git.kernel.org/pub/super.git/ is git's own
namespace - it's not the users to mess with. E.g. if I had a subproject
called "refs" you'd be in trouble.
> To support different subproject repositories linked in at the
> same path of a superproject, Nicolas noted that we would have to replace
> the subproject repository at top/kernel/.git (taking my example above)
> whenever we cross the subproject change boundary in a checkout (e.g. from
> linux24 to linux26). The natural thing here would be to have
> subproject repositories at a seperate place, like inside of the
> superproject repository such as at ".git/subproject/linux24", which works
> well with my default interpretation of relative subproject paths above. At
> checkout, the correct repository would be bound by a symlink:
Your objection to the url=key scheme was lack of simplicity - to me the above
is significantly more complex and is relying far too much on the submodule
being on the same server as the supermodule. Big mistake. A typical use of
submodules would be to integrate someone else's project, not your own, nor
indeed your own checkout of that project. Why should I have to keep my own
copies of, say, kernel2.4 and kernel2.6 when there are perfectly acceptable
URLs to the real repositories?
> > 2. Suppose .gitmodules in upstream tree points at subproject repo at
> > kernel.org, and I clone from there - my repo will point at kernel.org by
> > default? But now, I'd like everyone who clones from *my* repo to get
> > pointed at *my* server by default (e.g. for mirroring),
> > but would not changing .gitmodules create a commit so my
> > head will now differ from upstream - so it won't be signed properly
> > etc... Did I misunderstand something?
>
> No, that is correct. Supporting a relative URL specification as proposed
> above should solve this issue.
I think that's the wrong solution. A change of source URL for a submodule
from what upstream uses to your own server is a _fork_ from upstream,
therefore you would fork your own branch in your supermodule and
alter .gitmodules to point at your server. Everybody is happy, and the fork
is recorded.
The override system is only there for the local repository (which always takes
precedence) not for the server provider to hide detail from those checking
the repo out.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC PATCH] Add new git-cp command, transposed from stgit.
From: Karl Hasselström @ 2007-05-18 7:57 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070517204129.17502.21864.stgit@gandelf.nowhere.earth>
On 2007-05-17 22:49:00 +0200, Yann Dirson wrote:
> A known annoying limitation of this version (very quickly adapted)
> is that quoted files in the "git ls-files" output trigger the
> assert() clause. I'd use "-z", but it looks like noone wrote a
> zero-separated file reader for python (how that makes me regret perl
> ;).
>
> I can surely write one, but do we want this to be in python after
> all ? At least in perl it would be easy to fix this issue, but do we
> even accept perl scripts for such features ? OTOH, I'm not sure it
> is worth rewriting in C...
I was under the impression that perl was somewhat acceptable, while
python is not used in git anymore?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: MinGW port status
From: Johannes Sixt @ 2007-05-18 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <1179339879.31213.24.camel@bruno.nolaviz.org>
Alon Ziv wrote:
> What is the current status of the MinGW port? Are there any plans to
> marge it into the Git main repository anytime soon?
Since I've now access to Windows outside normal work hours, I should be
able to advance the MinGW port 1.5.2 in the next weeks.
I plan to start over with the port, basing it on 'master' instead of
'next' as time permits. Until this work is complete, the current fork
will be updated with new git releases, of course. I may also decide to
give an installer priority over the rebasing work in order to broaden
the user base.
-- Hannes
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Karl Hasselström @ 2007-05-18 6:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0705171351j1a86a4f4ge0283c522a351645@mail.gmail.com>
On 2007-05-17 21:51:19 +0100, Catalin Marinas wrote:
> On 17/05/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > The only possibility I can think of that might explain this is
> > that some of your unapplied patches are attached to a place in the
> > commit DAG that's far away from the branch head (e.g. you have
> > rebased to some entirely different place since you last had them
> > applied), so that "git-rev-list patch ^branch" outputs a large
> > part of the commit DAG.
>
> That's probably the case. I have patches that I haven't rebased for
> months but I keep them in case they might be needed in the future.
That's probably it, then. I'll need to come up with a clever scheme to
make that case cheap again.
> That's the reason for the hide/unhide commands.
Ah.
> Anyway, I'm not yet prepared to give up my current workflow.
I didn't intend to make that workflow painful, so don't despair yet --
there might be a way to make it work.
> I haven't tried to understand your patch yet but the unapplied
> patches will never be in a linear DAG similar to the applied
> patches.
I know.
> Because of this, we need to keep their order in a file anyway and we
> might not need to run git-rev-list (BTW, how do you preserve the
> unapplied patches order with the DAG implementation?).
The order of _all_ patches is kept in the "patchorder" file. This file
is consulted only when the relative order of two unapplied patches
need to be established. (Applied patches are sorted by the DAG, and
applied patches always precede unapplied patches.)
I would like to avoid keeping a record of known-to-be-unapplied
patches; while this is nowhere near as important as not keeping a
record of applied patches, it would still provide an opening for the
user to confuse StGIT.
But I believe I have a cunning plan ...
> > Could you put counters in unapplied_patches() and
> > sort_applied_patches() to see how many lines each of them reads
> > from git-rev-list? The expected number (if it had taken just a
> > little time, like it did for me) is a small constant times the
> > number of patches in both cases.
>
> I'll do this tomorrow to confirm but that's probably the cause of
> the slow-down.
Thanks for hanging in there.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* merge summaries
From: Steffen Prohaska @ 2007-05-18 5:44 UTC (permalink / raw)
To: Git Mailing List
It took me some time to figure out how to get summaries of the merged
branch into merge messages. Finally I recognized that I simply need
to set
git-config merge.summary true
I have two questions:
1) Why isn't 'true' the default setting? The two probably most
prominent git repositories, git and kernel, both use merge summaries.
After some time working with git I started to wonder, how these guys
create the nicely formatted branch summaries. If merge summaries are
apparently best practice, why are they missing in my local merges?
2) Why does git-merge have a switch '--no-summary' to switch
summaries off, but doesn't have a switch '--summary' to switch them
on? After some time of searching for the solution I started to
believe that Linus and Junio might use some shell magic to create
their merge messages, which they pipe to git-merge's -m switch. This
inconsistency made finding the simple solution even harder.
- Steffen
^ permalink raw reply
* Re: Documentation (mainly user-manual) patches
From: Petr Baudis @ 2007-05-18 4:56 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20070518033746.GB30144@fieldses.org>
Hi,
On Fri, May 18, 2007 at 05:37:46AM CEST, J. Bruce Fields wrote:
> Please pull from the maint branch at
>
> git://linux-nfs.org/~bfields/git.git maint
>
> This is mainly revisions of the patches posted a few days ago, which
> were uncontraversial, so I won't resend them. (They did need more
> proofreading than usual, though--thanks to everyone who helped!)
>
> One final patch wasn't included before, so I'll follow up with that.
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). ;-)
Thanks,
--
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: [3/4] What's not in 1.5.2 (new topics)
From: Petr Baudis @ 2007-05-18 4:50 UTC (permalink / raw)
To: Steven Grimm
Cc: Josef Weidendorfer, Michael S. Tsirkin, Junio C Hamano,
Andy Parkins, git, Nicolas Pitre
In-Reply-To: <464CF435.1010405@midwinter.com>
On Fri, May 18, 2007 at 02:32:53AM CEST, Steven Grimm wrote:
> For example -- and yes, this is partially a rehash of other people's
> ideas -- instead of mapping a subproject path directly to revision@URL,
> instead map it to revision@symbolic name. The symbolic name is then
> separately mapped to a URL, and it's that symbolic name that can be
> locally overridden. The mappings of symbolic names to URLs is
> unversioned; the mapping of subprojects to revision@symbolic is
> versioned. Local overrides happen at the symbolic->URL mapping.
>
> So you'd have something like
>
> version 1: kernel-src/ -> kernel24
> version 2: kernel-src/ -> kernel26
> unversioned:
> kernel24 -> git://whatever/2.4
> kernel26 -> git://whatever/2.6
>
> And then locally, the override is:
>
> kernel24 -> git://myhost/2.4
Yes, this would be nice; in one of my first mails in this thread I
devoted a non-trivially large writeup to this, then proceeded to remove
it since this has a serious problem.
Actually, Git already has a nice mechanism to handle these unversionaed
pointers - tags. Just make refs/tags/subproject/kernel24 containing the
URL to fetch. It's even easily overridable locally (and not easily
overridable remotely...).
The problem is ugly too, though - suddenly, you have created a SINGLE
UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going
to work well. I think I don't have to elaborate too much - the
aforementioned FreeBSD people will have different ideas about kernels
than you, _you_ will have different idea about kernels in few tens of
years than now, then if you need to merge or probably even fetch, you
will get into big trouble.
Notice that we don't have any such namespace right now (except the
D(SHA1) namespace, which is however possible only because it's so huge
_and_ the names are assigned automagically in a way that virtually
guarantees uniqueness across the whole universe) - tags come closest,
but there is nothing that fundamentally breaks when a clash happens
inside the namespace - it's just UI thing. But subproject names are
etched to the history - once you name it, you just can't get rid of it
forever.
--
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
* [PATCH] user-manual: reorganize public git repo discussion
From: J. Bruce Fields @ 2007-05-18 3:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070518033746.GB30144@fieldses.org>
Helping a couple people set up public repos recently, I wanted to point
them at this piece of the user manual, but found it wasn't as helpful as
it could be:
- It starts with a big explanation of why you'd want a public
repository, not necessary in their case since they already knew
why they wanted that. So, separate that out.
- It skimps on some of the git-daemon details, and puts the http
export information first. Fix that.
Also group all the public repo subsections into a single section, and do
some miscellaneous related editing.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 90 +++++++++++++++++++++++------------------
1 files changed, 50 insertions(+), 40 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 735fea1..f4843f4 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1674,31 +1674,30 @@ The final result will be a series of commits, one for each patch in
the original mailbox, with authorship and commit log message each
taken from the message containing each patch.
-[[setting-up-a-public-repository]]
-Setting up a public repository
-------------------------------
+[[public-repositories]]
+Public git repositories
+-----------------------
-Another way to submit changes to a project is to simply tell the
-maintainer of that project to pull from your repository, exactly as
-you did in the section "<<getting-updates-with-git-pull, Getting
-updates with git pull>>".
+Another way to submit changes to a project is to tell the maintainer of
+that project to pull the changes from your repository using git-pull[1].
+In the section "<<getting-updates-with-git-pull, Getting updates with
+git pull>>" we described this as a way to get updates from the "main"
+repository, but it works just as well in the other direction.
-If you and maintainer both have accounts on the same machine, then
-then you can just pull changes from each other's repositories
-directly; note that all of the commands (gitlink:git-clone[1],
-git-fetch[1], git-pull[1], etc.) that accept a URL as an argument
-will also accept a local directory name; so, for example, you can
-use
+If you and the maintainer both have accounts on the same machine, then
+you can just pull changes from each other's repositories directly;
+commands that accepts repository URLs as arguments will also accept a
+local directory name:
-------------------------------------------------
$ git clone /path/to/repository
$ git pull /path/to/other/repository
-------------------------------------------------
-If this sort of setup is inconvenient or impossible, another (more
-common) option is to set up a public repository on a public server.
-This also allows you to cleanly separate private work in progress
-from publicly visible work.
+However, the more common way to do this is to maintain a separate public
+repository (usually on a different host) for others to pull changes
+from. This is usually more convenient, and allows you to cleanly
+separate private work in progress from publicly visible work.
You will continue to do your day-to-day work in your personal
repository, but periodically "push" changes from your personal
@@ -1717,32 +1716,52 @@ like this:
| they push V
their public repo <------------------- their repo
-Now, assume your personal repository is in the directory ~/proj. We
-first create a new clone of the repository:
+[[setting-up-a-public-repository]]
+Setting up a public repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Assume your personal repository is in the directory ~/proj. We
+first create a new clone of the repository and tell git-daemon that it
+is meant to be public:
-------------------------------------------------
$ git clone --bare ~/proj proj.git
+$ touch proj.git/git-daemon-export-ok
-------------------------------------------------
The resulting directory proj.git contains a "bare" git repository--it is
-just the contents of the ".git" directory, without a checked-out copy of
-a working directory.
+just the contents of the ".git" directory, without any files checked out
+around it.
Next, copy proj.git to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.
-If somebody else maintains the public server, they may already have
-set up a git service for you, and you may skip to the section
+[[exporting-via-git]]
+Exporting a git repository via the git protocol
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is the preferred method.
+
+If someone else administers the server, they should tell you what
+directory to put the repository in, and what git:// url it will appear
+at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
-Otherwise, the following sections explain how to export your newly
-created public repository:
+Otherwise, all you need to do is start gitlink:git-daemon[1]; it will
+listen on port 9418. By default, it will allow access to any directory
+that looks like a git directory and contains the magic file
+git-daemon-export-ok. Passing some directory paths as git-daemon
+arguments will further restrict the exports to those paths.
+
+You can also run git-daemon as an inetd service; see the
+gitlink:git-daemon[1] man page for details. (See especially the
+examples section.)
[[exporting-via-http]]
Exporting a git repository via http
------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The git protocol gives better performance and reliability, but on a
host with a web server set up, http exports may be simpler to set up.
@@ -1774,20 +1793,11 @@ link:howto/setup-git-server-over-http.txt[setup-git-server-over-http]
for a slightly more sophisticated setup using WebDAV which also
allows pushing over http.)
-[[exporting-via-git]]
-Exporting a git repository via the git protocol
------------------------------------------------
-
-This is the preferred method.
-
-For now, we refer you to the gitlink:git-daemon[1] man page for
-instructions. (See especially the examples section.)
-
[[pushing-changes-to-a-public-repository]]
Pushing changes to a public repository
---------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Note that the two techniques outline above (exporting via
+Note that the two techniques outlined above (exporting via
<<exporting-via-http,http>> or <<exporting-via-git,git>>) allow other
maintainers to fetch your latest changes, but they do not allow write
access, which you will need to update the public repository with the
@@ -1839,7 +1849,7 @@ details.
[[setting-up-a-shared-repository]]
Setting up a shared repository
-------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
@@ -1848,8 +1858,8 @@ link:cvs-migration.txt[git for CVS users] for instructions on how to
set this up.
[[setting-up-gitweb]]
-Allow web browsing of a repository
-----------------------------------
+Allowing web browsing of a repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The gitweb cgi script provides users an easy way to browse your
project's files and history without having to install git; see the file
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* Documentation (mainly user-manual) patches
From: J. Bruce Fields @ 2007-05-18 3:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Please pull from the maint branch at
git://linux-nfs.org/~bfields/git.git maint
This is mainly revisions of the patches posted a few days ago, which
were uncontraversial, so I won't resend them. (They did need more
proofreading than usual, though--thanks to everyone who helped!)
One final patch wasn't included before, so I'll follow up with that.
--b.
Documentation/glossary.txt | 228 +++--
Documentation/howto/dangling-objects.txt | 109 --
Documentation/howto/isolate-bugs-with-bisect.txt | 65 --
Documentation/howto/make-dist.txt | 52 -
Documentation/howto/using-topic-branches.txt | 296 ------
Documentation/user-manual.txt | 1192 +++++++++++++++++-----
6 files changed, 1046 insertions(+), 896 deletions(-)
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Steven Grimm @ 2007-05-18 0:32 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Michael S. Tsirkin, Junio C Hamano, Andy Parkins, git,
Nicolas Pitre
In-Reply-To: <200705180141.06862.Josef.Weidendorfer@gmx.de>
It seems like a lot of the friction here is because people are trying to
devise a single mechanism that will handle two distinct cases:
1. The location of a subproject's changed (the "public repository
relocated to a different host" problem). This is not temporally
sensitive -- if you check out an old version of the superproject, you
need to look in the new location for the subproject. A local override
for the subproject's location will likely still be perfectly valid.
2. The superproject no longer wants to use the same subproject; it wants
to replace it with something else at the same point in the tree (the
"version 2 of superproject uses the 2.6 kernel as opposed to the 2.4
kernel"). This is temporally sensitive -- if you check out an old
version of the superproject, you want to use the old location for the
subproject too. A single local override will most likely not be valid
for both versions.
I think these are fundamentally different operations and it's the desire
to fold them into one mechanism that's leading to a lot of the
discussion here. Would we simplify things by not conflating them?
For example -- and yes, this is partially a rehash of other people's
ideas -- instead of mapping a subproject path directly to revision@URL,
instead map it to revision@symbolic name. The symbolic name is then
separately mapped to a URL, and it's that symbolic name that can be
locally overridden. The mappings of symbolic names to URLs is
unversioned; the mapping of subprojects to revision@symbolic is
versioned. Local overrides happen at the symbolic->URL mapping.
So you'd have something like
version 1: kernel-src/ -> kernel24
version 2: kernel-src/ -> kernel26
unversioned:
kernel24 -> git://whatever/2.4
kernel26 -> git://whatever/2.6
And then locally, the override is:
kernel24 -> git://myhost/2.4
When version 2 gets pulled down, you start off using the upstream's URL,
which you know because you pulled down the new copy of the unversioned
symbolic->URL map. Maybe git-pull gives you a warning like, "I see you
have some overrides, so you might want to know about this new symbolic
name too." With an appropriate option it might even stop before doing
anything with the new symbolic name to give you a chance to override.
Maybe that has some problems I'm not seeing, but it seems like adding
one more layer of indirection which has different versioning semantics
would make this a more tractable problem.
-Steve
^ permalink raw reply
* Re: [RFC] git-float
From: Junio C Hamano @ 2007-05-18 0:31 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070517211805.GA29259@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
> Here's a simple script I use to float a commit up the history -
> similiar to what stg float does if I understand it correctly.
>
> Is this a good way to implement it?
> git-rebase --onto $ref~1 $ref && git-cherry-pick $ref
Because git-rebase or git-cherry-pick can be interrupted with a
conflict, this is not a good _implementation_. The whole script
needs to have the sequencing and continue logic similar to the
one git-rebase has.
> Would it make sense to have something like this in git tree?
Incidentally, this is closely related to something that people
have wanted to have for a long time, which is to cherry-pick
series of commits.
One step of rebase and cherry-pick can be thought of as a
"rotate a commit" operation. When you cherry-pick a commit C on
top of where you are, the resulting tree is computed by applying
the commit C's effect to the current tree via 3-way merge.
git-merge-recursive C^ HEAD C
git-rebase without -m does the equivalent of the above "rotate a
commit" operation using patch + apply (and fall back to merge if
the patch does not cleanly apply) for performance reasons, but
the principle is the same. And the commit message for the
result is taken from C itself.
git-rebase can be decomposed into three stages:
(1) find the sequence of commits to reapply;
(2) find the commit to start rebuilding onto and reset to it;
(3) one by one, rotate the commits you found in (1), with
the sequencing support (--abort, --skip and --continue).
There is no reason, other than the fact that there is no other
commit rotator in git suite that needs sequencing, that these
three needs to be in a single program git-rebase.
The only difference with the above outline and your float is
that after you finish step (1), you record "this commit also
needs to be replayed at the end" information to the sequence.
The implementation of cherry-pick that takes commit range is
also obvious; instead of the computation git-rebase does for
step (1) above, we would allow arbitrary series of commits to be
specified from the command line (most likely using the revision
list notation A..B) to be replayed with the sequencing
machinery.
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Josef Weidendorfer @ 2007-05-17 23:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Andy Parkins, git, Nicolas Pitre
In-Reply-To: <20070517215841.GB29259@mellanox.co.il>
On Thursday 17 May 2007, Michael S. Tsirkin wrote:
> > What I was "handwaving" (or "envisioning") was to have something
> > like this in .gitmodules:
> >
> > [subproject "kernel/"]
> > URL = git://git.kernel.org/pub/linux-2.4.git
> >
> > (or 2.6, depending on the revision of the superproject) and per
> > repository configuration would maps this with these two entries:
> >
> > [subproject "git://git.kernel.org/pub/linux-2.4.git"]
> > URL = http://www.kernel.org/pub/linux-2.4.git
> >
> > [subproject "git://git.kernel.org/pub/linux-2.6.git"]
> > URL = http://www.kernel.org/pub/linux-2.6.git
> >
> > The intent is
> >
> > (1) "kernel/" directory is found to be a gitlink in the
> > tree/index; .gitmodules is consulted to find the
> > "URL", which is just a handle and the initial hint
> >
> > (2) That "initial hint" is used to look up the
> > subproject entry from the configuration, to find the
> > "real" URL that is used by this repository
>
> I'm reading up on submodules, two questions on this:
>
> 1. I understand the usefulness of the hint for public repositories, (the user might
> need help discovering where to get submodules) but for private ones would this
> create a hassle: I start with a subproject in ~/subprojecttest and if that gets
> put in the URL hint, I have to maintain a map for ~/subprojecttest in my
> .git/config forever even after I move it to ~/subprojectproduction, just to make
> old releases build?
Yes, AFAICS that was the original idea; but that is no problem as we will need an
override scheme.
However, I think the usage of "url"/"url hint" as the 1st level subproject identifier
really is badly misleading and confusing for users; it would be better for this
identifier to not look like a URL at all. But by naming it "url" in .gitmodules, the
user is tempted to put an URL at this place.
IMHO it is by far better to simply talk about the "subproject name/identifier" which is
valid in the subproject namespace of the superproject.
And why not use the .gitattributes for the ".gitmodules" needs?
With linux 2.4 as subproject in "top/kernel/", there could be a "top/.gitattributes"
with
kernel subproject=linux24
We could have a default rule that in the absense of the attribute, we default to the
path of the submodule, ie. to
kernel subproject=top/kernel
In .git/config, there needs to be a config entry like
[subproject "linux24"]
URL = http://www.kernel.org/pub/linux-2.4.git
Again, we could have a default URL in the absence of this config entry which is
relative to the URL of the superproject, and which allows for the superproject
repository to act as proxy.
As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie. if
the superproject is at git://git.kernel.org/pub/super.git, the above subproject
would default to the URL git://git.kernel.org/pub/super.git/subproject/linux24
which could be a symlink on the server.
To support different subproject repositories linked in at the
same path of a superproject, Nicolas noted that we would have to replace
the subproject repository at top/kernel/.git (taking my example above)
whenever we cross the subproject change boundary in a checkout (e.g. from
linux24 to linux26). The natural thing here would be to have
subproject repositories at a seperate place, like inside of the superproject
repository such as at ".git/subproject/linux24", which works well with my
default interpretation of relative subproject paths above. At checkout,
the correct repository would be bound by a symlink:
top/kernel/.git -> .git/subproject/linux24
Instead of a symlink, a magically working linkage mechanisms would be better
(the .git/gitlink proposal).
> 2. Suppose .gitmodules in upstream tree points at subproject repo at kernel.org,
> and I clone from there - my repo will point at kernel.org by default?
> But now, I'd like everyone who clones from *my* repo to get
> pointed at *my* server by default (e.g. for mirroring),
> but would not changing .gitmodules create a commit so my
> head will now differ from upstream - so it won't be signed properly etc...
> Did I misunderstand something?
No, that is correct. Supporting a relative URL specification as proposed above
should solve this issue.
Josef
>
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jakub Narebski @ 2007-05-17 23:14 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90705170709j7eb23d4fy6811fc2985dd888d@mail.gmail.com>
Martin Langhoff wrote:
> On 5/18/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> If you have a solution for that problem, please enlighten me: I don't.
>
> Ok - worst case scenario - have a minimal hints file that tells me the
> ranges to fetch all commits and all trees. To reduce that Add to the
> hints file data to name the hashes (or even better - offsets) for the
> delta chains that contain commits+trees relevant to all the heads -
> minus 10, 20, 30, 40 commits and 1,2,4,8 and 16 days.
>
> So there's a good chance the client can get the commits+trees needed
> efficiently. For blobs, all you need is the index to mark the delta
> chains you need.
By the way, I think we always should get the whole delta chain, unless we
are absolutely sure that we have base object(s) in repo.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Fix error in git_patchset_body for deletion in merge commit
From: Jakub Narebski @ 2007-05-17 20:54 UTC (permalink / raw)
To: git
Checking if $diffinfo->{'status'} is equal 'D' is no longer the way to
check if the file was deleted in result. For merge commits
$diffinfo->{'status'} is reference to array of statuses for each
parent. Use the fact that $diffinfo->{'to_id'} is all zeros as sign
that file was deleted in result.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8c688be..fa8cc02 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2720,8 +2720,9 @@ sub git_patchset_body {
delete $from{'href'};
}
}
+
$to{'file'} = $diffinfo->{'to_file'} || $diffinfo->{'file'};
- if ($diffinfo->{'status'} ne "D") { # not deleted file
+ if ($diffinfo->{'to_id'} ne ('0' x 40)) { # file exists in result
$to{'href'} = href(action=>"blob", hash_base=>$hash,
hash=>$diffinfo->{'to_id'},
file_name=>$to{'file'});
--
1.5.1.4
^ permalink raw reply related
* Glossary: trivial, clean, evil merge
From: Jakub Narebski @ 2007-05-17 10:39 UTC (permalink / raw)
To: git
Glossary: trivial, clean, evil merge
or
Merge flavours, and how to recognize them
What is the definition of a trivial merge? Is it tree-level merge, for
which git-diff -c output would be empty?
What is the definition of clean merge? Is it merge without conflicts?
How to name merge for which git-diff --cc output is empty: simple merge
perhaps? I think it does not need to be clean merge in the "no
conflicts" meaning.
What is the definition of evil merge? Is it merge for which merge commit
is different from all the parents? How to name merge for which
git-diff --cc output is non empty, then?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-gui: Build even if tclsh is not available
From: Shawn O. Pearce @ 2007-05-17 22:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20070517023614.GL4489@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> (i) Makefile will autodecide on whether git-gui will be
> built+installed or not
>
> (ii) ./configure will, people not using configure and building on
> servers will be left to tweak config manually
>
> (iii) ./configure will, git-gui will default to not to be built and
> people not using configure and wanting git-gui will be left to tweak
> config manually
>
> I suspect that (ii) will be chosen, and even though I don't like it
> *personally* I guess it's the most reasonable approach for the general
> public. I didn't know that tclIndex is vital for git-gui when I
> submitted the patch, the /Makefile comment suggests otherwise.
(iv) git-gui 0.7.1, which is now available from repo.or.cz, and
I think you know where that is ;-), makes TCL_PATH strictly an
optimization at compile time.
If TCL_PATH is present and creates a valid tclIndex file then we
use the Tcl auto_load "optimization" to only load the Tcl code we
actually need when we run. But if it does fail for any reason we
hide the error (can be unhidden with make V=1) and we generate
a listing of the files instead. In this latter case we load
*everything* on git-gui startup.
This way git-gui works for the user either way, just like before,
but its startup may be slightly slower if the user didn't give us
a good TCL_PATH at build time.
Junio, would you consider merging 0.7.1 soon? No changes are
needed to git.git's own Makefile, just a subtree pull.
--
Shawn.
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Michael S. Tsirkin @ 2007-05-17 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v4pmcauu3.fsf@assigned-by-dhcp.cox.net>
> What I was "handwaving" (or "envisioning") was to have something
> like this in .gitmodules:
>
> [subproject "kernel/"]
> URL = git://git.kernel.org/pub/linux-2.4.git
>
> (or 2.6, depending on the revision of the superproject) and per
> repository configuration would maps this with these two entries:
>
> [subproject "git://git.kernel.org/pub/linux-2.4.git"]
> URL = http://www.kernel.org/pub/linux-2.4.git
>
> [subproject "git://git.kernel.org/pub/linux-2.6.git"]
> URL = http://www.kernel.org/pub/linux-2.6.git
>
> The intent is
>
> (1) "kernel/" directory is found to be a gitlink in the
> tree/index; .gitmodules is consulted to find the
> "URL", which is just a handle and the initial hint
>
> (2) That "initial hint" is used to look up the
> subproject entry from the configuration, to find the
> "real" URL that is used by this repository
I'm reading up on submodules, two questions on this:
1. I understand the usefulness of the hint for public repositories, (the user might
need help discovering where to get submodules) but for private ones would this
create a hassle: I start with a subproject in ~/subprojecttest and if that gets
put in the URL hint, I have to maintain a map for ~/subprojecttest in my
.git/config forever even after I move it to ~/subprojectproduction, just to make
old releases build?
Do you think it might make sense to support a mode where .gitmodules
is empty, and URLs come from the config directly?
2. Suppose .gitmodules in upstream tree points at subproject repo at kernel.org,
and I clone from there - my repo will point at kernel.org by default?
But now, I'd like everyone who clones from *my* repo to get
pointed at *my* server by default (e.g. for mirroring),
but would not changing .gitmodules create a commit so my
head will now differ from upstream - so it won't be signed properly etc...
Did I misunderstand something?
--
MST
^ permalink raw reply
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