* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 13:11 UTC (permalink / raw)
To: Lars Hjemli, Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <8c5c35580705240541j7f632fc4lbd308c9386c2bde6@mail.gmail.com>
On Thu, May 24, 2007 at 02:41:57PM +0200, Lars Hjemli wrote:
> I think the whole point of the 'remote config' stuff is to get an
> unversioned/out-of-tree .gitmodules file, right?
Yes.
> If so, one could put this file into the object db and refer to it with
> something like 'refs/tags/subproject-config' or even
> 'refs/misc/subproject-config'. Both of these refs will be found by
> ls-remote and point to the object containing the suggested subproject
> configuration.
That's a possibility, but then...
On Thu, May 24, 2007 at 01:43:54PM +0200, Sven Verdoolaege wrote:
> Or do you propose we put the URL in a blob and put the object sha1
> in there. If so, who's going to create these blobs for the git://
> and ssh:// protocols? upload-pack?
I don't think you can expect the user to this herself.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 13:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: skimo, git, Junio C Hamano, Martin Waitz, Alex Riesen
In-Reply-To: <20070524123841.GO4489@pasky.or.cz>
Hi,
On Thu, 24 May 2007, Petr Baudis wrote:
> On Thu, May 24, 2007 at 11:35:33AM CEST, Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> >
> > > On Thu, May 24, 2007 at 12:40:20AM +0100, Johannes Schindelin wrote:
> > > > On Thu, 24 May 2007, skimo@liacs.nl wrote:
> > > > > This patch series implements a mechanism for cloning submodules.
> > > > > Each submodule is specified by a 'submodule.<submodule>.url'
> > > > > configuration option, e.g.,
> > > > >
> > > > > bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
> > > > > submodule.cloog.url /home/sverdool/public_html/cloog.git
> > > > > submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
> > > >
> > > > I am sorry to complain so late in the game, but I am not really interested
> > > > in submodules. However, what you say here is not a task for git-config
> > > > IMHO, but rather for git-remote.
> > >
> > > Hmmm... git-remote does only local configuration and never gets
> > > any information from the other side.
> > > What would be the interface and how would you get the information?
> >
> > I was complaining that git-config, which is purely a local beast, gets
> > infected with even more obscure stuff. Junio mentions regularly that he
> > does not trust git-config that much, and given the number of fixes we
> > still get, I have to agree. So let's not put any more stuff into that
> > kitchen sink, especially if it has nothing to do with the configuration of
> > your repo.
>
> Then again, git-remote is purely a local beast too, isn't it?
No. Think "update" and "prune". Both access the remote site.
> We could use git-remote-config for accessing remote configuration (if
> it's a good idea at all, which I'm not totally convinced about)... (And
> hope people don't confuse it with stuff related to git-remote too much.)
As Junio _already_ said, people have no business looking in other people's
configuration.
If you have something to publish, do so. But don't make the tool publish
_everything_ by default.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 13:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Sven Verdoolaege, git
In-Reply-To: <465583C7.32BC66BB@eudaptics.com>
Hi,
On Thu, 24 May 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > I was more thinking about something like this:
> > 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
>
> where 3fa7ded... is the commit (gitlink) that appears in the tree?
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 13:17 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524123936.GO942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 01:16:38PM +0100, Johannes Schindelin wrote:
> > I was more thinking about something like this:
> > 3fa7ded19a8da868d3af7c942f86358e6720f0c7 refs/heads/submodule^{URL:/home/sverdool/public_html/cloog.git}
>
> As Johannes already indicated I don't think this rev makes sense.
You like to confuse me, don't you?
> I suppose we could just set it to 0.
> I also don't think the URL should be associated to a ref.
It does not need to be.
But then, it is sort of a "subref": You could just clone the submodule in
its own right, correct?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 13:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241415050.4648@racer.site>
On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > I suppose we could just set it to 0.
> > I also don't think the URL should be associated to a ref.
>
> It does not need to be.
>
> But then, it is sort of a "subref": You could just clone the submodule in
> its own right, correct?
Exactly, but the information we want is not associated to any
particular revision of the submodule. It just points to the repo.
It's also not associated with any revision of the supermodule.
That information should go in a tracked .gitmodules file.
skimo
^ permalink raw reply
* Re: [PATCH 17/22] entry.c: optionally checkout newly cloned submodules
From: Johannes Sixt @ 2007-05-24 13:28 UTC (permalink / raw)
To: git
In-Reply-To: <11799589931860-git-send-email-skimo@liacs.nl>
skimo@liacs.nl wrote:
> +static const char *relativize_path(const char *path, const char *dest)
> +{
> ...
> +}
I really get a head ache when I try to understand the purpose of this
function. A comment or two telling what it's trying to do would really
be helpful. But...
> +int attach_submodule(const char *submodule)
> +{
> + struct stat st;
> + const char *submodule_dir, *dest;
> +
> + submodule_dir = git_path("submodules/%s/.git", submodule);
> + if (lstat(submodule_dir, &st))
> + return error("submodule '%s' unavailable", submodule);
> +
> + dest = mkpath("%s/.git", submodule);
> + submodule_dir = relativize_path(submodule_dir, dest);
> +
> + return symlink(submodule_dir, dest);
> +}
I don't like this. Symlinks are a major nuisance on Windows (MinGW
port). Can't we just have this repo itself at this place instead of the
symlink?
-- Hannes
^ permalink raw reply
* Re: [PATCH 09/15] entry.c: optionally checkout submodules
From: Sven Verdoolaege @ 2007-05-24 13:29 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520211850.GJ5412@admingilde.org>
On Sun, May 20, 2007 at 11:18:50PM +0200, Martin Waitz wrote:
> hoi :)
>
> have you seen my patch to checkout submodules?
>
> The submodule checkout should really check that the requested commit
> is really available and have some other path for creating submodules
> which are not currently checked out / able to be checked out.
If you are talking about your May 5th patch, then you weren't doing
that either. You just checked if it _looked_ like a SHA1.
I check for the presence of the commit by calling git-cat-file.
Of course, this doesn't guarantee that the whole tree is available.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Lars Hjemli @ 2007-05-24 13:32 UTC (permalink / raw)
To: skimo
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano, git,
Martin Waitz, Alex Riesen
In-Reply-To: <20070524131108.GP942MdfPADPa@greensroom.kotnet.org>
On 5/24/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Thu, May 24, 2007 at 02:41:57PM +0200, Lars Hjemli wrote:
> > I think the whole point of the 'remote config' stuff is to get an
> > unversioned/out-of-tree .gitmodules file, right?
>
> Yes.
>
> > If so, one could put this file into the object db and refer to it with
> > something like 'refs/tags/subproject-config' or even
> > 'refs/misc/subproject-config'. Both of these refs will be found by
> > ls-remote and point to the object containing the suggested subproject
> > configuration.
>
> That's a possibility, but then...
>
> On Thu, May 24, 2007 at 01:43:54PM +0200, Sven Verdoolaege wrote:
> > Or do you propose we put the URL in a blob and put the object sha1
> > in there. If so, who's going to create these blobs for the git://
> > and ssh:// protocols? upload-pack?
>
> I don't think you can expect the user to this herself.
Well, my point would be that we already have the necessary plumbing to
solve the problem (discovery and distribution of out-of-tree objects).
Some porcelain support on top of this is all that is needed (well,
almost. I just tried downloading my own tarball, and got an error
about the ref not pointing to a commit. But that shouldn't be too hard
to fix)
--
larsh
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Martin Waitz @ 2007-05-24 13:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, skimo, git, Alex Riesen
In-Reply-To: <7vtzu3yrh9.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
hoi :)
On Wed, May 23, 2007 at 05:50:42PM -0700, Junio C Hamano wrote:
> Honestly speaking, I do not think people have no business
> peeking into configuratoin remote repository has, and it would
> be preferrable that supermodule Porcelain stuff does not rely on
> that.
yes.
I would greatly appreciate having one standard repository format,
also for subprojects so that it is not possible to look into the
remote configuration.
However I do see that the site administrator might want to physically
separate the different subprojects which is difficult to support
in one big monolithic repository. But if additional information
about the physical location of subprojects is neccessary, then
that should be stored in something like .git/info/subprojects or
similiar, instead of the .git/config.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ANNOUNCE] cgit v0.5
From: Lars Hjemli @ 2007-05-24 13:51 UTC (permalink / raw)
To: git
cgit v0.5 (a fast web interface for git) is now available for download at
the usual places:
tarballs - http://hjemli.net/git/cgit
git repo - git://hjemli.net/pub/git/cgit
Release highlights:
* path-filtering of log
* grouping of repositories
* external html files in index- and summary pages
* index page shows time since last update for all repos
* bugfixes
Many of the improvements and bugfixes are (or should have been) credited
to Kristian Høgsberg and his testing of cgit on
http://people.freedesktop.org/krh-cgi/cgit
--
larsh
[this is a resend, since vger dropped my previuos mail (probably due to
gmails decision to base64-encode it)]
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 13:52 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524132434.GQ942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > I suppose we could just set it to 0.
> > > I also don't think the URL should be associated to a ref.
> >
> > It does not need to be.
> >
> > But then, it is sort of a "subref": You could just clone the submodule in
> > its own right, correct?
>
> Exactly, but the information we want is not associated to any
> particular revision of the submodule. It just points to the repo.
> It's also not associated with any revision of the supermodule.
> That information should go in a tracked .gitmodules file.
It is not that expensive to just give the SHA-1 with the URL, and to
introduce a new namespace, say
3f... submodule/path^{URL:blablub}
to say that the submodule which is connected in "HEAD:path" is available
with the URL "blablub" and just so happens to be at commit "3f..." at the
moment. Heck, you can even use this instead of expensive fetches to verify
up-to-date, and even more, you can make sure that you are as up-to-date as
the remote supermodule.
But then, I do not care about that deeply. Like I said, I haven't followed
the discussions, but I really do not understand why an information as
essential to a superproject is not contained in something like
HEAD:.gitmodules. Git does not have to take it from there, it can still
continue to take it from a local config in .git/, but .gitmodules can live
in the tree happily, for the pleasure of the tools (if only to initialise
the first version of the local config after clone).
Without some very intrusive surgery into the transport code of Git, in 22
patches, which I am not at all comfortable with.
Ciao,
Dscho
^ permalink raw reply
* Re: HTTP trees trailing GIT trees
From: Johannes Schindelin @ 2007-05-24 13:57 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <loom.20070524T142358-608@post.gmane.org>
Hi,
On Thu, 24 May 2007, Panagiotis Issaris wrote:
> So, we're asking for /ffmpeg/info/refs, and the server is returning
> c30fa8391812..., but, using GitWeb one can see that c30fa839812... is
> not the last commit, this one is:
> http://git.mplayerhq.hu/?p=ffmpeg;a=commit;
> h=47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
So, info/refs is still old. This file should have been updated by
git-update-server-info. I am not sure how this repo is updated, but I
suspect that the wrong hook contains the call to update-server-info, or
that the correct hook is not activated, or it does not have write
permission.
Ciao,
Dscho
^ permalink raw reply
* Re: HTTP trees trailing GIT trees
From: Panagiotis Issaris @ 2007-05-24 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0705241456080.4648@racer.site>
Hi Dscho,
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> Hi,
>
> On Thu, 24 May 2007, Panagiotis Issaris wrote:
>
> > So, we're asking for /ffmpeg/info/refs, and the server is returning
> > c30fa8391812..., but, using GitWeb one can see that c30fa839812... is
> > not the last commit, this one is:
> > http://git.mplayerhq.hu/?p=ffmpeg;a=commit;
> > h=47d7dcb5a7d89f413064e7ef1b54d77e59fb8375
>
> So, info/refs is still old. This file should have been updated by
> git-update-server-info. I am not sure how this repo is updated, but I
> suspect that the wrong hook contains the call to update-server-info, or
> that the correct hook is not activated, or it does not have write
> permission.
Thanks! I've just reported this on the ffmpeg mailinglist.
Thanks again for your fast reply,
With friendly regards,
Takis
^ permalink raw reply
* How do we import patches from non-git sources?
From: Marc Singer @ 2007-05-24 14:30 UTC (permalink / raw)
To: git
It looks like it reduces to something very simple.
Git patches, as generated by git-format-patch, have a header with an
email address.
Cogito patches, as generated by cg-mkpatch, have no email address in the
header.
git-am doesn't like the cogito patches.
Is there a way to import patches that did not come from git? Remember
that we'd like to include the functionality of git-am that adds new
files to the index.
Cheers.
^ permalink raw reply
* [PATCH] Add option to cvs update before export
From: Robin Rosenberg @ 2007-05-24 15:06 UTC (permalink / raw)
To: junkio; +Cc: git
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-cvsexportcommit.txt | 5 ++++-
git-cvsexportcommit.perl | 8 ++++++--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index fd7f540..da5c242 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
-'git-cvsexportcommit' [-h] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
@@ -58,6 +58,9 @@ OPTIONS
Prepend the commit message with the provided prefix.
Useful for patch series and the like.
+-u::
+ Update affected files from cvs repository before attempting export.
+
-v::
Verbose.
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d6ae99b..42060ef 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -15,9 +15,9 @@ unless ($ENV{GIT_DIR} && -r $ENV{GIT_DIR}){
die "GIT_DIR is not defined or is unreadable";
}
-our ($opt_h, $opt_P, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m, $opt_d);
+our ($opt_h, $opt_P, $opt_p, $opt_v, $opt_c, $opt_f, $opt_a, $opt_m, $opt_d, $opt_u);
-getopts('hPpvcfam:d:');
+getopts('uhPpvcfam:d:');
$opt_h && usage();
@@ -178,6 +178,10 @@ foreach my $f (@files) {
my %cvsstat;
if (@canstatusfiles) {
+ if ($opt_u) {
+ my @updated = safe_pipe_capture(@cvs, 'update', @canstatusfiles);
+ print @updated;
+ }
my @cvsoutput;
@cvsoutput= safe_pipe_capture(@cvs, 'status', @canstatusfiles);
my $matchcount = 0;
^ permalink raw reply related
* Re: How do we import patches from non-git sources?
From: Johannes Schindelin @ 2007-05-24 15:29 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <1180017010.21181.2.camel@zealous.synapsedev.com>
Hi,
On Thu, 24 May 2007, Marc Singer wrote:
> It looks like it reduces to something very simple.
>
> Git patches, as generated by git-format-patch, have a header with an
> email address.
>
> Cogito patches, as generated by cg-mkpatch, have no email address in the
> header.
>
> git-am doesn't like the cogito patches.
What author should git-am assume?
> Is there a way to import patches that did not come from git? Remember
> that we'd like to include the functionality of git-am that adds new
> files to the index.
You can always use git-apply to apply patches. You have to commit them
yourself, though.
Ciao,
Dscho
^ permalink raw reply
* StGIT and conflicts
From: Karl Hasselström @ 2007-05-24 16:40 UTC (permalink / raw)
To: Catalin Marinas, Yann Dirson; +Cc: git
The current behavior of StGIT is to not use the index for conflicts
like git does. What advantages does this have that are great enough to
motivate a deviation from the git behavior?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Martin Waitz @ 2007-05-24 15:48 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, skimo, Alex Riesen, git
In-Reply-To: <20070522193706.GA4432@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 4232 bytes --]
On Tue, May 22, 2007 at 09:37:06PM +0200, Jan Hudec wrote:
> > We don't have to move the entire subproject.git into the superproject,
> > but we need to have all _referenced_ objects in the .git dir of the
> > superproject.
> >
> > There are several possibilities to do so:
> >
> > * move the entire .git dir
> > * move .git/objects
> > * explicitly copy all referenced objects
>
> I believe we really need entire .git dir. When the superporject checks out
> revision which does not reference that subproject, we still need to preserve
> not only the objects of subproject, but also the refs and config.
but all the other refs do not belong to the superproject.
For those who are working on the subproject there are of course a lot
of refs which they have to work with, but that can be dealt with
outside of the superproject scope. The subproject is still a normal
Git repository, after all.
That is, you can have remote entries, branches and what not.
But all that is not interesting in the superproject scope.
So I thing moving the entire subproject.git into the superproject.git is too
much. The superproject is only interested in the objects and in one
ref -- the one stored inside its tree.
> > I have some experimental code to configure a per-subproject directory
> > in the superproject/.git as alternate object store for the submodule
> > to make the last two solutions possible. Perhaps I should dig it out again
> > and adapt it to current git.
> >
> > If there is a 1:1 relationship between subproject and object store then
> > even efficient fsck and repack/prune are possible for the submodule without
> > loosing objects.
> > But such a 1:1 relationship is bad when you move subprojects to another
> > location (or include the same subproject several times in different
> > locations of the tree).
> > Perhaps the user should be able to choose which one he wants.
>
> That's why there should be the extra level of indirection using .gitmodules.
> It should map the directory name to the object store name, so you can
> relocate the subproject.
>
> Including the same project several times is indeed interesting. Maybe the
> subprojects should be "light checkouts" (I believe something like this was
> already discussed on the list sometime). Those would be .git dirs, that would
> only have HEAD and pointer to another .git dir with everything else.
Well, even if they might share a lot of objects they might be included
for completely different reasons and so might need to work with
different communities (remote entries, branches, etc.).
So sharing objects makes sense, sharing the rest of .git is not
neccessary.
> > I think it will be _very_ common to store super and subprojects in
> > related locations. First to be independent from third-party servers
> > while working on the superproject.
> > Second (and I think more important) because many times there will
> > be superproject related adaptations in the subproject. Yes they
> > are independent, and exactly for that reason the subproject upstream
> > maintainers may not take every change which is needed to satisfy the
> > superproject. We _now_ see that in all Linux distributions already.
> > So when you use superprojects to integrate several independent projects,
> > then the superproject maintainer/administrator should really keep a
> > clone of all subprojects handy on his site.
>
> Yes, repositories with distribution-specific patches will add a large class
> of cases requiring multiple sources support.
You don't really need multiple sources for it.
The subproject contains both upstream and local changes, but I think
it makes sense to keep the entire object store local (the same way
to keep all the entire history local even if you only want to add to it
in a normal repository). Those people who work on the subproject and
communicate with its upstream developers of course need remote entries
and have to synchronize the subproject with upstream. But that is
not related to the superproject at all.
So yes, you have different sources but you don't need extra support
in the subproject implementation for it.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-24 15:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070522215423.GI30871@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
hoi :)
On Tue, May 22, 2007 at 11:54:23PM +0200, Alex Riesen wrote:
> Martin Waitz, Mon, May 21, 2007 01:12:01 +0200:
> > On Mon, May 21, 2007 at 01:02:48AM +0200, Alex Riesen wrote:
> > > > If the user did commit and then you do a supermodule checkout -m you
> > > > will get a merge.
> > >
> > > Only if the user continue to use the last branch (or the detached
> > > head) the subproject was on. He don't have to, he can even return to
> > > the commit which does not conflict, unless he have to complicate
> > > things.
> >
> > just curious:
> > so you want to differenciate between a subproject HEAD which was
> > set by the superproject and other ones?
>
> No. Why do you think that I want to do that?
I think I simply was too tired to read. ;-)
Your 'Only if the user continues to use...' suggested that he has a
different option, namely going to a branch which is not controlled
by the superproject.
And of course the user can go back to another commit, after checkout -m
created a merge... ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 11/22] entry.c: optionally checkout submodules
From: Martin Waitz @ 2007-05-24 16:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Alex Riesen, skimo@liacs.nl, git, Junio C Hamano
In-Reply-To: <20070524071819.GN28023@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
hoi :)
On Thu, May 24, 2007 at 03:18:19AM -0400, Shawn O. Pearce wrote:
> I'm actually really unhappy with our !istty(2) means disable
> progress thing. git-gui knows how to read and show the progress
> meters, but nobody prints them anymore as 2 is a pipe. I have the
> same problem with a Java build tool that sometimes starts up an
> expensive Git operation (like a clone over SSH of a 60+ MiB project).
>
> I've been considering adding a GIT_ISTTY environment variable to
> forcefully override the istty result, just to get the progress
> meters turned back on...
or perhaps introduce GIT_PROGRESS to name a filedescriptor which then
_only_ gets all the progress information, in a format easily parseable
by other tools?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-svn and SVK mirror between two repositories
From: Vinubalaji Gopal @ 2007-05-24 17:04 UTC (permalink / raw)
To: git
Hi all,
I have been trying hard to find if it is possible to mirror (or
clone in git-svn terms) two svn repositories and update changes from
one to other or do even more complex operations with these two
repositories. I did check the git-svn man page, but was lost without a
proper example. Can someone please provide me with an example of using
two svn repositories in git-svn and doing merge operations, etc .
I have used SVK for a long time and it was very much possible to use
two svn repositories using the SVK FAQ entry as shown below:
Repository ONE in Paris, repository TWO in London and be able to
create 2 mirrors then smerge both, doing it on a node in Berlin and
using the mirror function?
Sure. Simply do this:
svk mirror svn://svn.paris.fr/ //paris
svk mirror svn://svn.london.uk/ //london
# pick a sensible base, or use --baseless
svk smerge --base=1234 //paris //london
# ... and smerge between them normally ...
svk smerge -I //london //paris
svk smerge -I //paris //london
--
Vinu
In a world without fences who needs Gates?
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Junio C Hamano @ 2007-05-24 17:13 UTC (permalink / raw)
To: Lars Hjemli
Cc: Johannes Schindelin, skimo, Shawn O. Pearce, git, Martin Waitz,
Alex Riesen
In-Reply-To: <8c5c35580705240541j7f632fc4lbd308c9386c2bde6@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> I think the whole point of the 'remote config' stuff is to get an
> unversioned/out-of-tree .gitmodules file, right?
Why does this have to be out-of-tree and unversioned to begin
with?
When you are bootstrapping, you will start by a fetch/clone of
the superproject. Why can't that tree contain necessary
information that is relevant to the superproject in question?
Isn't the information about which subprojects are used by the
superproject specific to each superproject, and also specific to
each version of the superproject (as a superproject can start
using more projects than it did before)?
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: david @ 2007-05-24 17:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Dana How, Git Mailing List
In-Reply-To: <20070524071235.GL28023@spearce.org>
On Thu, 24 May 2007, Shawn O. Pearce wrote:
> Now #3 is actually really important here. Don't forget that we
> *just* disabled the fancy "new loose object format". It doesn't
> exist. We can read the packfile-like loose objects, but we cannot
> write them anymore. So lets say we explode a megablob into a loose
> object, and its 800 MiB by itself. Now we have to send that object
> to a client. Yes, that's right, we must *RECOMPRESS* 800 MiB for
> no reason. Not the best choice. Maybe we shouldn't have deleted
> that packfile formatted loose object writer...
when did the object store get changed so that loose objects aren't
compressed?
if the problem is that the codepath for fetching does an uncompress
followed by a compress then it would seem that this is a fairly easy
problem to fix (how hard would it be to add the headers around the
compressed object to make it look to the receiver like it's a pack with
only one thing in it)
David Lang
^ permalink raw reply
* Re: [PATCH] Prevent megablobs from gunking up git packs
From: Johannes Schindelin @ 2007-05-24 17:29 UTC (permalink / raw)
To: david; +Cc: Shawn O. Pearce, Junio C Hamano, Dana How, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705241020450.21766@asgard.lang.hm>
Hi,
On Thu, 24 May 2007, david@lang.hm wrote:
> On Thu, 24 May 2007, Shawn O. Pearce wrote:
>
> > Now #3 is actually really important here. Don't forget that we
> > *just* disabled the fancy "new loose object format". It doesn't
> > exist. We can read the packfile-like loose objects, but we cannot
> > write them anymore. So lets say we explode a megablob into a loose
> > object, and its 800 MiB by itself. Now we have to send that object
> > to a client. Yes, that's right, we must *RECOMPRESS* 800 MiB for
> > no reason. Not the best choice. Maybe we shouldn't have deleted
> > that packfile formatted loose object writer...
>
> when did the object store get changed so that loose objects aren't
> compressed?
That never happened. But we had a different file format for loose objects,
which was meant to make it easier to copy as-is into a pack. That file
format went away, since it was not as useful as we hoped.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Lars Hjemli @ 2007-05-24 17:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, skimo, Shawn O. Pearce, git, Martin Waitz,
Alex Riesen
In-Reply-To: <7vabvuywix.fsf@assigned-by-dhcp.cox.net>
On 5/24/07, Junio C Hamano <junkio@cox.net> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > I think the whole point of the 'remote config' stuff is to get an
> > unversioned/out-of-tree .gitmodules file, right?
>
> Why does this have to be out-of-tree and unversioned to begin
> with?
Probably to cater for subprojects moving away from the url mentioned
in the versioned .gitmodules file.
> When you are bootstrapping, you will start by a fetch/clone of
> the superproject. Why can't that tree contain necessary
> information that is relevant to the superproject in question?
It sure can, and it would be the most natural solution. I just wanted
to mention an alternative to the 'git config --remote' solution.
--
larsh
^ 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