* 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
* [RFC] git-float
From: Michael S. Tsirkin @ 2007-05-17 21:18 UTC (permalink / raw)
To: git, Junio C Hamano
Hi!
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?
Would it make sense to have something like this in git tree?
Drop me a note.
############################################################
#!/bin/bash
check_revision() {
case $# in
2)
true
;;
*)
echo "Unable to float $1: it does not match a single non-merge commit" >&2
exit 2
;;
esac
}
ref=`git-rev-list --no-merges $1~1..$1`
check_revision "$1" $ref
git-rebase --onto $ref~1 $ref && git-cherry-pick $ref
--
MST
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: david @ 2007-05-17 21:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jan Hudec, Johannes Schindelin, Shawn O. Pearce, Martin Langhoff,
git
In-Reply-To: <alpine.LFD.0.99.0705171618410.24220@xanadu.home>
On Thu, 17 May 2007, Nicolas Pitre wrote:
> On Thu, 17 May 2007, Jan Hudec wrote:
>
>> On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
>>> On Thu, 17 May 2007, Johannes Schindelin wrote:
>>>> On Wed, 16 May 2007, 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.
>>
>> Of course your suggestion which moves the logic to client-side is a good one,
>> but even the cgi with logic on server side would help in some situations.
>
> You could simply wrap git-bundle within a cgi. That is certainly easy
> enough.
isn't this (or something very similar) exactly what we want for a smalrt
fetch via http?
after all, we're completely in control of the client software, and the
useual reason for HTTP-only access is on the client side rather then the
server side. so http access that wraps the git protocol in http would make
life much cleaner for lots of people
there are a few cases where all you have is static web space, but I don't
think it's worth trying to optimize that too much as you still have the
safety issues to worry about
David Lang
^ permalink raw reply
* Re: [StGIT PATCH] Don't use patches/<branch>/current
From: Catalin Marinas @ 2007-05-17 20:51 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070517145724.GA905@diana.vm.bytemark.co.uk>
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 the reason for the hide/unhide commands. Anyway, I'm not yet
prepared to give up my current workflow.
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. 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?).
> 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.
--
Catalin
^ permalink raw reply
* [RFC PATCH] Add new git-cp command, transposed from stgit.
From: Yann Dirson @ 2007-05-17 20:49 UTC (permalink / raw)
To: git
This git-cp command is recursive when acting on directories, but only
copies files under git control.
---
Addition of this command would be along the lines of "move into git
things from stgit that are not specific to stgit".
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...
git-cp.py | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/git-cp.py b/git-cp.py
new file mode 100755
index 0000000..8df2e73
--- /dev/null
+++ b/git-cp.py
@@ -0,0 +1,141 @@
+#!/usr/bin/python
+#
+# This tool is copyright (c) 2007, Yann Dirson.
+# Parts copyright (c) 2005 Catalin Marinas.
+# It is released under the Gnu Public License, version 2.
+#
+
+import os, sys, getopt, popen2, re
+from shutil import copyfile
+
+def usage():
+ print "USAGE: git-cp <source>... <destination>"
+ sys.exit(1)
+
+## functions copied from stgit.git 0.12
+
+def _output_lines(cmd):
+ p=popen2.Popen3(cmd, True)
+ lines = p.fromchild.readlines()
+ if p.wait():
+ raise Exception, '%s failed (%s)' % (str(cmd),
+ p.childerr.read().strip())
+ return lines
+
+def __run(cmd, args=None):
+ """__run: runs cmd using spawnvp.
+
+ Runs cmd using spawnvp. The shell is avoided so it won't mess up
+ our arguments. If args is very large, the command is run multiple
+ times; args is split xargs style: cmd is passed on each
+ invocation. Unlike xargs, returns immediately if any non-zero
+ return code is received.
+ """
+
+ args_l=cmd.split()
+ if args is None:
+ args = []
+ for i in range(0, len(args)+1, 100):
+ r=os.spawnvp(os.P_WAIT, args_l[0], args_l + args[i:min(i+100, len(args))])
+ if r:
+ return r
+ return 0
+
+# functions adapted from stgit.git 0.12
+
+def addfiles(names):
+ """Add the files
+ """
+ # check the file list
+ for i in names:
+ if not os.path.exists(i):
+ raise Exception, 'Unknown file: %s' % i
+ if not os.path.isfile(i):
+ raise Exception, '%s is not a plain file' % i
+
+ if names:
+ if __run('git-update-index --add --', names):
+ raise Exception, 'Unable to add file'
+
+# core "git-cp" implementation
+
+def __copy_singlefile(source, target, target2=''):
+ """Copy file or dir named 'source' to name target+target2"""
+
+ # "source" (file or dir) must match one or more git-controlled file
+ realfiles = _output_lines(['git-ls-files', source])
+ if len(realfiles) == 0:
+ raise Exception, '"%s" matches no git-controled files' % source
+
+ if os.path.isdir(source):
+ # physically copy the files, and record them to add them in one run
+ newfiles = []
+ re_string='^'+source+'/(.*)$'
+ prefix_regexp = re.compile(re_string)
+ for f in [f.strip() for f in realfiles]:
+ m = prefix_regexp.match(f)
+ if not m:
+ print '"%s" does not match "%s"' % (f, re_string)
+ assert(m)
+ newname = target+target2+'/'+m.group(1)
+ if not os.path.exists(os.path.dirname(newname)):
+ os.makedirs(os.path.dirname(newname))
+ copyfile(f, newname)
+ newfiles.append(newname)
+
+ addfiles(newfiles)
+ else: # files, symlinks, ...
+ newname = target+target2
+ copyfile(source, newname)
+ addfiles([newname])
+
+
+def copy(filespecs, target):
+ if os.path.isdir(target):
+ # target is a directory: copy each entry on the command line,
+ # with the same name, into the target
+ target = target.rstrip('/')
+
+ # first, check that none of the children of the target
+ # matching the command line aleady exist
+ for filespec in filespecs:
+ entry = target+ '/' + os.path.basename(filespec.rstrip('/'))
+ if os.path.exists(entry):
+ raise Exception, 'Target "%s" already exists' % entry
+
+ for filespec in filespecs:
+ filespec = filespec.rstrip('/')
+ basename = '/' + os.path.basename(filespec)
+ __copy_singlefile(filespec, target, basename)
+
+ elif os.path.exists(target):
+ raise Exception, 'Target "%s" exists but is not a directory' % target
+ elif len(filespecs) != 1:
+ raise Exception, 'Cannot copy more than one file to non-directory'
+
+ else:
+ # at this point: len(filespecs)==1 and target does not exist
+
+ # check target directory
+ targetdir = os.path.dirname(target)
+ if targetdir != '' and not os.path.isdir(targetdir):
+ raise Exception, 'Target directory "%s" does not exist' % targetdir
+
+ __copy_singlefile(filespecs[0].rstrip('/'), target)
+
+## main
+
+try:
+ opts, args = getopt.getopt(sys.argv[1:], "h", ["help"])
+except getopt.GetoptError:
+ usage()
+
+for o, a in opts:
+ if o in ("-h", "--help"):
+ usage()
+
+try:
+ copy(args[0:-1], args[-1])
+except Exception, ex:
+ print "git-cp error: %s" % ex
+ sys.exit(1)
^ permalink raw reply related
* Re: Smart fetch via HTTP?
From: Nicolas Pitre @ 2007-05-17 20:38 UTC (permalink / raw)
To: Jan Hudec; +Cc: Petr Baudis, git
In-Reply-To: <20070517202655.GB3079@efreet.light.src>
On Thu, 17 May 2007, Jan Hudec wrote:
> A particular case would be a group of students wanting to publish their
> software project (I mean the PRG023 or equivalent). Private computers in the
> hostel are not allowed to serve anything, so they'd use some of the lab
> servers (eg. artax, ss1000...). All of them allow full CGI, but running
> daemons is forbiden.
And wouldn't the admin authority for those lab servers be amenable to
install a Git daemon service? That'd be a much better solution to me.
Nicolas
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Nicolas Pitre @ 2007-05-17 20:31 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Shawn O. Pearce, Martin Langhoff, git
In-Reply-To: <20070517200431.GA3079@efreet.light.src>
On Thu, 17 May 2007, Jan Hudec wrote:
> On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
> > On Thu, 17 May 2007, Johannes Schindelin wrote:
> > > On Wed, 16 May 2007, 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.
>
> Of course your suggestion which moves the logic to client-side is a good one,
> but even the cgi with logic on server side would help in some situations.
You could simply wrap git-bundle within a cgi. That is certainly easy
enough.
> > On the other hand, if the client does all the work and provides the
> > server with a list of ranges within a pack it wants to be sent, then you
> > simply have zero special setup to perform on the hosting server and you
> > keep the server load down due to not running pack-objects there. That,
> > at least, is different enough from the Git daemon to be worth
> > considering. Not only does it provide an advantage to those who cannot
> > do anything but http out of their segregated network, but it also
> > provide many advantages on the server side too while the cgi approach
> > doesn't.
> >
> > And actually finding out the list of objects the remote has that you
> > don't have is not that complex. It could go as follows:
> >
> > 1) Fetch every .idx files the remote has.
>
> ... for git it's 1.2 MiB. And that definitely isn't a huge source tree.
> Of course the local side could remember which indices it already saw during
> previous fetch from that location and not re-fetch them.
Right. The name of the pack/index plus its time stamp can be cached.
If the remote doesn't repack too often then the overhead would be
minimal.
> > 2) From those .idx files, keep only a list of objects that are unknown
> > locally. A good starting point for doing this really efficiently is
> > the code for git-pack-redundant.
> >
> > 3) From the .idx files we got in (1), create a reverse index to get each
> > object's size in the remote pack. The code to do this already exists
> > in builtin-pack-objects.c.
> >
> > 4) With the list of missing objects from (2) along with their offset and
> > size within a given pack file, fetch those objects from the remote
> > server. Either perform multiple requests in parallel, or as someone
> > mentioned already, provide the server with a list of ranges you want
> > to be sent.
>
> Does the git server really have to do so much beyond that?
Yes it does. The real thing perform a full object reachability walk and
only the objects that are needed for the wanted branch(es) are sent in a
custom pack meaning that the data transfer is really optimal.
> > 5) Store the received objects as loose objects locally. If a given
> > object is a delta, verify if its base is available locally, or if it
> > is listed amongst those objects to be fetched from the server. If
> > not, add it to the list. In most cases, delta base objects will be
> > objects already listed to be fetched anyway. To greatly simplify
> > things, the loose delta object type from 2 years ago could be revived
> > (commit 91d7b8afc2) since a repack will get rid of them.
> >
> > 6 Repeat (4) and (5) until everything has been fetched.
>
> Unless I am really seriously missing something, there is no point in
> repeating. For each pack you need to unpack a delta either:
> - you have it => ok.
> - you don't have it, but the server does =>
> but than it's already in the fetch set calculated in 2.
> - you don't have it and nor does server =>
> the repository at server is corrupted and you can't fix it.
You're right of course.
Nicolas
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jan Hudec @ 2007-05-17 20:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20070517124006.GO4489@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]
On Thu, May 17, 2007 at 14:40:06 +0200, Petr Baudis wrote:
> On Tue, May 15, 2007 at 10:10:06PM CEST, Jan Hudec wrote:
> > - Can be run on shared machine. If you have web space on machine shared
> > by many people, you can set up your own gitweb, but cannot/are not allowed
> > to start your own network server for git native protocol.
>
> You need to have CGI-enabled hosting, set up the CGI script etc. -
> overally, the setup is similarly complicated as git-daemon setup, so
> it's not "zero-setup" solution anymore.
>
> Again, I'm not sure just how many people are in the situation that
> they can run real CGI (not just PHP) but not git-daemon.
A particular case would be a group of students wanting to publish their
software project (I mean the PRG023 or equivalent). Private computers in the
hostel are not allowed to serve anything, so they'd use some of the lab
servers (eg. artax, ss1000...). All of them allow full CGI, but running
daemons is forbiden.
> > - Less things to set up. If you are setting up gitweb anyway, you'd not need
> > to set up additional thing for providing fetch access.
>
> Except, well, how do you "set it up"? You need to make sure
> git-update-server-info is run, yes, but that shouldn't be a problem (I'm
> not so sure if git does this for you automagically - Cogito would...).
No. If it worked similar to git-upload-pack, only over http, it would work
without update-server-info, no?
> I think 95% of people don't set up gitweb.cgi either for their small
> HTTP repositories. :-)
>
> Then again, it's not that it would be really technically complicated -
> adding "give me a bundle" support to gitweb should be pretty easy.
> However, this support has some "social" costs as well: no compatibility
> with older git versions, support cost, confusion between dumb HTTP and
> gitweb HTTP transports, more lack of motivation for improving dumb HTTP
> transport...
The dumb transport is definitely useful. Extending it to use ranges if
possible would be useful as well (and maybe more than upload-pack-over-http).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Smart fetch via HTTP?
From: Jan Hudec @ 2007-05-17 20:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Shawn O. Pearce, Martin Langhoff, git
In-Reply-To: <alpine.LFD.0.99.0705170954200.24220@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 4738 bytes --]
On Thu, May 17, 2007 at 10:41:37 -0400, Nicolas Pitre wrote:
> On Thu, 17 May 2007, Johannes Schindelin wrote:
> > On Wed, 16 May 2007, 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.
Of course your suggestion which moves the logic to client-side is a good one,
but even the cgi with logic on server side would help in some situations.
> On the other hand, if the client does all the work and provides the
> server with a list of ranges within a pack it wants to be sent, then you
> simply have zero special setup to perform on the hosting server and you
> keep the server load down due to not running pack-objects there. That,
> at least, is different enough from the Git daemon to be worth
> considering. Not only does it provide an advantage to those who cannot
> do anything but http out of their segregated network, but it also
> provide many advantages on the server side too while the cgi approach
> doesn't.
>
> And actually finding out the list of objects the remote has that you
> don't have is not that complex. It could go as follows:
>
> 1) Fetch every .idx files the remote has.
... for git it's 1.2 MiB. And that definitely isn't a huge source tree.
Of course the local side could remember which indices it already saw during
previous fetch from that location and not re-fetch them.
A slight problem is, that git-repack normally recombines everything to
a single pack, so the index would have to be re-fetched again anyway.
> 2) From those .idx files, keep only a list of objects that are unknown
> locally. A good starting point for doing this really efficiently is
> the code for git-pack-redundant.
>
> 3) From the .idx files we got in (1), create a reverse index to get each
> object's size in the remote pack. The code to do this already exists
> in builtin-pack-objects.c.
>
> 4) With the list of missing objects from (2) along with their offset and
> size within a given pack file, fetch those objects from the remote
> server. Either perform multiple requests in parallel, or as someone
> mentioned already, provide the server with a list of ranges you want
> to be sent.
Does the git server really have to do so much beyond that? I didn't look at
the algorithm that finds what deltas should be based on, but depending on
that it might (or might not) be possible to proof the client has everything to
understand if the server sends the objects as it currently has them.
> 5) Store the received objects as loose objects locally. If a given
> object is a delta, verify if its base is available locally, or if it
> is listed amongst those objects to be fetched from the server. If
> not, add it to the list. In most cases, delta base objects will be
> objects already listed to be fetched anyway. To greatly simplify
> things, the loose delta object type from 2 years ago could be revived
> (commit 91d7b8afc2) since a repack will get rid of them.
>
> 6 Repeat (4) and (5) until everything has been fetched.
Unless I am really seriously missing something, there is no point in
repeating. For each pack you need to unpack a delta either:
- you have it => ok.
- you don't have it, but the server does =>
but than it's already in the fetch set calculated in 2.
- you don't have it and nor does server =>
the repository at server is corrupted and you can't fix it.
> 7) Run git-pack-objects with the list of fetched objects.
>
> 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. So each approach has it's own advantages.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow the ident attribute to include a length specifier
From: Junio C Hamano @ 2007-05-17 19:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705171453.32093.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
>> There is no change to existing behaviour. With no parameter, the
>> expansion is all 40 hex digits.
>
> Were there any thoughts on this patch? I think it might have got drowned in
> the noise I made about $ident$ -> $Id$.
I was kind of hoping that I can avoid the decision and also I
can avoid having to remember it, by waiting long enough and
either seeing nobody on the list bring it up again, in which
case we can safely forget it, or somebody asks "what happened to
this, I want it too!", in which case the original submitter
would resubmit after the dust settles after 1.5.2, possibly with
a necessary rebase and clean-up. I'll see which one is the case
in the coming few weeks ;-).
^ permalink raw reply
* Sorry, git-send-email test went wrong
From: Eric Wong @ 2007-05-17 19:07 UTC (permalink / raw)
To: git
Sorry to all I Cc-ed, I forgot git-send-email would Cc
signed-off-bys :X
--
Eric Wong
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-17 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: Petr Baudis, Alex Riesen, Andy Parkins, git
In-Reply-To: <20070517134649.GA20853@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Instead, why not:
> 1. url location is supplied in configuration as
> [subproject "kernel/"]
> url = git://git.kernel.org/pub/linux-2.4.git
> 2. .gitmodules is simply read as a lower-priority version of
> configuration
That does not support seeking back and forth between appliance
release #1 and release #2 which wants to say they want to bind
two different things at the same kernel/ path, does it?
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Junio C Hamano @ 2007-05-17 18:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: Andy Parkins, git
In-Reply-To: <20070517110225.GA3334@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Thu, May 17, 2007 07:21:40 +0200:
>> 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
>
> So, assuming .gitmodules is versioned (afaics, it is), it would mean
> that after a some unlucky git-pull, where someone changed the upstream
> .gitmodules ("linux-2.4" for whatever reason is changed to just
> "linux"). And suddenly all such local configuration is useless:
See below.
>> (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"]
>
> isn't there a typo somewhere around "2.6"?
>
>> URL = http://www.kernel.org/pub/linux-2.6.git
>
> because there is no URL to map from.
The basic idea is that you keep mappings for all the URLs that
appear in versions of .gitmodules in the history you are
interested in checking out. If the upstream switches from 2.4
based one to 2.6 based one, .gitmodules would contain a new URL,
which is not yet known to your configuration. Then either the
UI would ask, with the default hint in the .gitmodules you just
pulled, refuse and have you manually add it to your config after
confirming, or just take the default (iow "trust the upstream").
So, no, it is not a reason to drop older mappings when your tip
was updated by a pull. It should still be possible to checkout
older version that depend on the older 2.4 based subproject.
> why can't I just have _repo_ configuration:
>
> [subproject "kernel/"]
> URL = http://www.kernel.org/pub/linux-2.6.git
> ?
> It can be first-time cloned from the upstream, but it stays after
> people change it to suit their systems. They can depend on it not to
> be broken by upstream.
But that is a wrong thing to do when you are forking from the
release #1 of the appliance project, which wanted to have 2.4
based on at that path.
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Johan Herland @ 2007-05-17 18:05 UTC (permalink / raw)
To: git; +Cc: Frank Lichtenheld, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070517174807.GM5272@planck.djpig.de>
On Thursday 17 May 2007, Frank Lichtenheld wrote:
> On Thu, May 17, 2007 at 06:57:22PM +0200, Johan Herland wrote:
> > Hmm, doesn't seem like git-tar-tree (or git-archive for that matter)
> > supports this out of the box. Maybe it's possible to achieve in combination
> > with the $Id$ construct?
>
> $Id$ contains the blob id, not the commit id.
Oops. My bad. In that case, your solution (to add another commandline switch
to git-archive) is definitely what Michael needs.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Frank Lichtenheld @ 2007-05-17 17:48 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <200705171857.22891.johan@herland.net>
On Thu, May 17, 2007 at 06:57:22PM +0200, Johan Herland wrote:
> Hmm, doesn't seem like git-tar-tree (or git-archive for that matter)
> supports this out of the box. Maybe it's possible to achieve in combination
> with the $Id$ construct?
$Id$ contains the blob id, not the commit id.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Jeff King @ 2007-05-17 17:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Riesen, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20070517173005.GS4489@pasky.or.cz>
On Thu, May 17, 2007 at 07:30:05PM +0200, Petr Baudis wrote:
> I think Junio's URL keying works fine. Their change of URL will override
> your change, but that is bad thing only when the old upstream's URL
> changed, but the upstream stays the same. Then either the problem is
> clearly visible or it will result only in somewhat suboptimal behaviour.
>
> OTOH, if the _upstream_ changed and your override scheme is at work, you
> won't notice at all and simply will continue to use the same old
> upstream.
Right. But I think it makes more sense for the error condition to go the
other way (that is, your override might get stale, but it will always be
an _override_). You'll notice eventually anyway when upstream moves to a
commit sha1 that you don't have in your submodule repo (or if they never
do, that means your override tree actually _is_ valid, and didn't need
to be changed anyway; this would be the case if upstream moved to a
different mirror, but you were already using an alternate source
anyway).
> But again - "kernel/" means nothing, only "kernel/ in tree X". kernel/
> might point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm
> in the experimental branch and freebsd tree in the weirdo branch. Such
> an override is _never_ going to work in the general situation, only when
> "kernel/" always in all commits on all branches points to the same
> single project. (You can work that around by at least making the setting
> branch-specific, but that still doens't take into account the history,
> and then newly created branches won't have the override you want, etc.)
My point is that we _already_ have a mechanism that unambiguously points
to the linked commit, and it's _not_ the URL; it's the commit sha1
embedded in the tree. Everything else is just a hint about where we
might find that commit.
-Peff
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Petr Baudis @ 2007-05-17 17:30 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20070517162542.GA28501@coredump.intra.peff.net>
On Thu, May 17, 2007 at 06:25:42PM CEST, Jeff King wrote:
> However, I think we _must_ have an override mechanism, since I don't
> necessarily use the same URLs that you do. I propose that such overrides
> should go into the local repo config. The only difference between what I
> have proposed and what Junio mentioned is that I would base the config
> override key on the directory name, not the URL. This means that if
> upstream changes their pointer to the URL, yours will change with it
> _unless you have an override_. With Junio's, their change of URL will
> override your change (since the key will no longer match your config).
>
> How do you propose to handle overrides?
I think Junio's URL keying works fine. Their change of URL will override
your change, but that is bad thing only when the old upstream's URL
changed, but the upstream stays the same. Then either the problem is
clearly visible or it will result only in somewhat suboptimal behaviour.
OTOH, if the _upstream_ changed and your override scheme is at work, you
won't notice at all and simply will continue to use the same old
upstream.
> > "kernel/" has _no_ meaning. Only a (treeid,"kernel/") pair has meaning,
> > nothing less - a particular tree contains a submodule in given subtree.
> > Different trees can have different submodules in different subtrees.
>
> Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since
> that tree has a particular .gitmodules. But I also think you should be
> able to override the submodule URL for kernel/ _for all time_ if you
> want.
But again - "kernel/" means nothing, only "kernel/ in tree X". kernel/
might point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm
in the experimental branch and freebsd tree in the weirdo branch. Such
an override is _never_ going to work in the general situation, only when
"kernel/" always in all commits on all branches points to the same
single project. (You can work that around by at least making the setting
branch-specific, but that still doens't take into account the history,
and then newly created branches won't have the override you want, etc.)
--
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: Commit ID in exported Tar Ball
From: Johan Herland @ 2007-05-17 17:28 UTC (permalink / raw)
To: git; +Cc: Frank Lichtenheld, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070517171150.GL5272@planck.djpig.de>
On Thursday 17 May 2007, Frank Lichtenheld wrote:
> On Thu, May 17, 2007 at 06:57:22PM +0200, Johan Herland wrote:
> > Of course, it all depends on whether the $Id$ conversion is triggered by
> > git-archive...
>
> Another possibility might be to add a commandline switch to git-archive
> so you can decide whether the commit id should be added as a header to
> the tar file (which it already supports) or as a ordinary file (which
> should be reasonable trivial to implement). The question if whether
> it would be worth to add that feature. Don't know if there are many
> other users out there that need it.
Although this efficiently solves Michael's problem, I still think the ideal
solution would be for git-archive to do the same conversions/filters as a
regular checkout would. Otherwise, we'll easily get into situations where
a git-archive tree is different enough from a "regular" working tree to
cause annoying differences in behaviour.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-17 17:14 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Johan Herland, git, Michael Gernoth
In-Reply-To: <20070517171150.GL5272@planck.djpig.de>
Hello,
> Another possibility might be to add a commandline switch to
> git-archive so you can decide whether the commit id should be added as
> a header to the tar file (which it already supports) or as a ordinary
> file (which should be reasonable trivial to implement). The question
> if whether it would be worth to add that feature. Don't know if there
> are many other users out there that need it.
that would be very good aproach I guess. At least from my point of view.
Because it doesn't break diffs, it concentrates on what matters and if
you don't like it you don't use it.
Thomas
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-17 17:13 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: GIT, Michael Gernoth
In-Reply-To: <59ad55d30705171002m503feb17l64fea9ffe2cf2297@mail.gmail.com>
Hello,
> $ gzip -cd snapshot.tar.gz | git-get-tar-commit-id
not good enough. What he wants is:
- user loads tar tree down from gitweb via the 'snapshot'
button.
- user extracts the tarball and types make
- The output of the produced binary contains a unique
identifier.
Thomas
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Frank Lichtenheld @ 2007-05-17 17:11 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Thomas Glanzmann, Michael Gernoth
In-Reply-To: <200705171857.22891.johan@herland.net>
On Thu, May 17, 2007 at 06:57:22PM +0200, Johan Herland wrote:
> Of course, it all depends on whether the $Id$ conversion is triggered by
> git-archive...
Another possibility might be to add a commandline switch to git-archive
so you can decide whether the commit id should be added as a header to
the tar file (which it already supports) or as a ordinary file (which
should be reasonable trivial to implement). The question if whether
it would be worth to add that feature. Don't know if there are many
other users out there that need it.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Kristian Høgsberg @ 2007-05-17 17:02 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT, Michael Gernoth
In-Reply-To: <20070517163803.GE4095@cip.informatik.uni-erlangen.de>
On 5/17/07, Thomas Glanzmann <thomas@glanzmann.de> wrote:
> Hello,
> Michae, a friend of mine, is in the phase of migrating from git to cvs.
> He releases tar balls of his software project using gitweb. He would
> love to have a way to have the commit-id of HEAD of the export contained
> in one of the files he exported that way. Is there infrastructure in git
> that makes that already possible or does he need to some kind of
> gerneration tool by himself? Maybe it would be helpful if the
> git-tar-tree would generate a file .commitid or something like that in
> the generated tar tree.
Use git-get-tar-commit-id:
$ gzip -cd snapshot.tar.gz | git-get-tar-commit-id
cheers,
Kristian
^ permalink raw reply
* Re: Commit ID in exported Tar Ball
From: Johan Herland @ 2007-05-17 16:57 UTC (permalink / raw)
To: git; +Cc: Thomas Glanzmann, Michael Gernoth
In-Reply-To: <20070517163803.GE4095@cip.informatik.uni-erlangen.de>
On Thursday 17 May 2007, Thomas Glanzmann wrote:
> Hello,
> Michae, a friend of mine, is in the phase of migrating from git to cvs.
^^^^^^^^^^^^^^^
Man... You are _definitely_ on the wrong list. ;)
> He releases tar balls of his software project using gitweb. He would
> love to have a way to have the commit-id of HEAD of the export contained
> in one of the files he exported that way. Is there infrastructure in git
> that makes that already possible or does he need to some kind of
> gerneration tool by himself? Maybe it would be helpful if the
> git-tar-tree would generate a file .commitid or something like that in
> the generated tar tree.
Hmm, doesn't seem like git-tar-tree (or git-archive for that matter)
supports this out of the box. Maybe it's possible to achieve in combination
with the $Id$ construct?
I guess it depends on whether git-tar-tree/git-archive actually does a
checkout from the repo from which the archive is made. If so, it should
be possible to store "$Id$" in .commitid, and check it in, and it should
automagically appear with the correct commit-id in your archive.
Of course, it all depends on whether the $Id$ conversion is triggered by
git-archive...
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Commit ID in exported Tar Ball
From: Thomas Glanzmann @ 2007-05-17 16:38 UTC (permalink / raw)
To: GIT, Michael Gernoth
Hello,
Michae, a friend of mine, is in the phase of migrating from git to cvs.
He releases tar balls of his software project using gitweb. He would
love to have a way to have the commit-id of HEAD of the export contained
in one of the files he exported that way. Is there infrastructure in git
that makes that already possible or does he need to some kind of
gerneration tool by himself? Maybe it would be helpful if the
git-tar-tree would generate a file .commitid or something like that in
the generated tar tree.
Thomas
^ permalink raw reply
* Re: [3/4] What's not in 1.5.2 (new topics)
From: Jeff King @ 2007-05-17 16:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Riesen, Junio C Hamano, Andy Parkins, git
In-Reply-To: <20070517161002.GR4489@pasky.or.cz>
On Thu, May 17, 2007 at 06:10:02PM +0200, Petr Baudis wrote:
> But, did you read what you actually quoted? Because I can only repeat my
> argument in the face of (1), and you didn't seem to dispute any part of
> it at all.
You said:
> Because kernel/ can get removed, moved around, or point at entirely
> *different* projects over time and branches - kernel/ can switch from
> linux-2.4 to linux-2.6, libc/ can switch between glibc and uClibc, ...
which I took to mean that we must be able to track changes to the URL
which is pointed to by the kernel/ submodule, and therefore this
configuration must be in a tracked file. Which is _precisely_ what I
advocated: it goes in a .gitmodules (or .gitconfig) file in the tracked
directory. This is counter to what Alex says, which is that one should
simply pull the config down during clone time and never change it.
However, I think we _must_ have an override mechanism, since I don't
necessarily use the same URLs that you do. I propose that such overrides
should go into the local repo config. The only difference between what I
have proposed and what Junio mentioned is that I would base the config
override key on the directory name, not the URL. This means that if
upstream changes their pointer to the URL, yours will change with it
_unless you have an override_. With Junio's, their change of URL will
override your change (since the key will no longer match your config).
How do you propose to handle overrides?
> "kernel/" has _no_ meaning. Only a (treeid,"kernel/") pair has meaning,
> nothing less - a particular tree contains a submodule in given subtree.
> Different trees can have different submodules in different subtrees.
Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since
that tree has a particular .gitmodules. But I also think you should be
able to override the submodule URL for kernel/ _for all time_ if you
want.
-Peff
^ 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