* Re: [RFC] Submodules in GIT
From: Uwe Kleine-Koenig @ 2006-12-05 15:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Martin Waitz, Andy Parkins, git
In-Reply-To: <45754AFE.1070207@op5.se>
Hella Andreas,
Andreas Ericsson wrote:
> >>The only problem I'm seeing atm is that the supermodule somehow has to
> >>mark whatever commits it's using from the submodule inside the submodule
> >>repo so that they effectively become un-prunable, otherwise the
> >>supermodule may some day find itself with a history that it can't restore.
> >One could circumvent that by creating a separate repo for the submodule
> >at checkout time and pull the needed objects in the supermodule's odb
> >when commiting the supermodule. This way prune in the submodule cannot
> >do any harm, because in it's odb are no objects that are important for
> >the supermodule.
>
> Yes, but then you'd lose history connectivity (I'm assuming you'd only
> pull in the tree and blob objects from the submodule, and prefix the
> tree-entrys with whatever directory you're storing the submodul in).
That's the reason for me prefering to pull in the complete commit.
I don't understand what you mean with "prefix the tree-entrys with
whatever directory you're storing the submodul in".
Maybe one of us doesn't understand tree objects correctly. AFAICT they
don't store the location where they occur, so there is no need to store
a prefix. E.g.
zeisberg@cepheus:/tmp$ mkdir test-repo
zeisberg@cepheus:/tmp$ cd test-repo/
zeisberg@cepheus:/tmp/test-repo$ git-init-db
defaulting to local storage area
zeisberg@cepheus:/tmp/test-repo$ echo LD_FLAGS=-ltest > Makefile
zeisberg@cepheus:/tmp/test-repo$ git add Makefile
zeisberg@cepheus:/tmp/test-repo$ git commit -m 'test1'
Committing initial tree 754eadab39642175748bb02155d2959176bcf014
zeisberg@cepheus:/tmp/test-repo$ mkdir subdir
zeisberg@cepheus:/tmp/test-repo$ cp Makefile subdir/
zeisberg@cepheus:/tmp/test-repo$ git add subdir/
zeisberg@cepheus:/tmp/test-repo$ git commit -m 'test2'
zeisberg@cepheus:/tmp/test-repo$ git ls-tree HEAD
100644 blob 610bafd79f92c7e546b104d5b22795df1f099723 Makefile
040000 tree 754eadab39642175748bb02155d2959176bcf014 subdir
So the tree that only contains the Makefile specifing LD_FLAGS has the
sha1id 754eadab39642175748bb02155d2959176bcf014 independent of being the
root of my project or a subtree.
But maybe I misunderstood you?
Best regards
Uwe
--
Uwe Kleine-Koenig
If a lawyer and an IRS agent were both drowning, and you could only save
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Jakub Narebski @ 2006-12-05 15:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612051540230.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Dnia wtorek 5. grudnia 2006 15:48, Johannes Schindelin napisał:
>
> On Tue, 5 Dec 2006, Jakub Narebski wrote:
>
>> Hmmm... would it be possible to use xdl_merge() for recursion, and
>> graphical merge tool for result? <Checks out earlier discussion>. I
>> think yes, because of exposing xdl_merge() in git-merge-onefile...
>
> In "next", only git-merge-recursive is converted to use xdl_merge(), and
> it did not use git-merge-one-file to begin with. Since this is a shell
> script (with a different syntax than merge), it would have to be converted
> to a C builtin first. But feasible: git-merge-one-file takes 7 parameters,
> the first 3 being SHA1s or empty strings. "merge" takes 3 filenames, with
> possibly up to three "-L <name>" pairs before them.
I thought that Junio implemented (but perhaps not published) some script,
I thought that was git-merge-onefile with some non-standard options,
to function as replacement for RCS' merge, or Diffutils diff3.
Guess I was wrong (at least there is nothing I can find in pu about this).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Johannes Schindelin @ 2006-12-05 14:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612051526.12636.jnareb@gmail.com>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> Hmmm... is there a way to pass merge.tool / merge.onefile program the
> info if it is invoked in final stage (here it is nice to invoke
> graphical merge tool to resolve conflicts in working area before
> commiting merge result) and in recursive stage (here it would be better
> to leave conflict markers to be resolved later)?
In a sense, you get that information: "merge" is called as
$ merge -L new1 -L orig -L new2 fnew1 forig fnew2
where few1 is the filename of the _temporary_ file, and new1 is the name
that should be displayed instead. For every but the final stage, new1
begins with "Temporary merge branch".
> Hmmm... would it be possible to use xdl_merge() for recursion, and
> graphical merge tool for result? <Checks out earlier discussion>. I
> think yes, because of exposing xdl_merge() in git-merge-onefile...
In "next", only git-merge-recursive is converted to use xdl_merge(), and
it did not use git-merge-one-file to begin with. Since this is a shell
script (with a different syntax than merge), it would have to be converted
to a C builtin first. But feasible: git-merge-one-file takes 7 parameters,
the first 3 being SHA1s or empty strings. "merge" takes 3 filenames, with
possibly up to three "-L <name>" pairs before them.
Ciao,
Dscho
^ permalink raw reply
* Re: filesystem encodings and gitweb tests, was Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-05 14:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, git
In-Reply-To: <200612051529.57174.jnareb@gmail.com>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 5 Dec 2006, Jakub Narebski wrote:
> >
> >> No, the problem showed with stupid HFS+ which uses different encoding
> >> for creating file, and different for readdir.
> >
> > This is just one of the problems. I described another problem in this
> > thread, namely a repo on a usb stick being accessed from different hosts.
>
> That is not much a problem. Yes, the filenames on different hosts would
> _look_ different, but shouldn't be detected as new file.
Sorry, I should have been clearer. I meant a repo _and_ a working
directory going along with it, on a USB stick. They do look different on
different hosts, and git-status looks different as a consequence ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: filesystem encodings and gitweb tests, was Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-05 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0612051507170.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Tue, 5 Dec 2006, Jakub Narebski wrote:
>
>> No, the problem showed with stupid HFS+ which uses different encoding
>> for creating file, and different for readdir.
>
> This is just one of the problems. I described another problem in this
> thread, namely a repo on a usb stick being accessed from different hosts.
That is not much a problem. Yes, the filenames on different hosts would
_look_ different, but shouldn't be detected as new file.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Jakub Narebski @ 2006-12-05 14:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612051459380.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi!
On Tue 5 Dec 2006 Johannes Schindelin wrote:
>
> On Tue 5 Dec 2006 Jakub Narebski wrote:
>
>> By the way is it [ed: xdl_merge()] replacement for RCS merge i.e. is
>> it file-level merge tool merge.onefile rather than merge.tool?
Actually by "it" I meant here the value of merge.tool configuration
variable. I think the name of configuration variable should be
merge.onefile and not merge.tool, but this are just details.
> It is a C function but yes it does what RCS merge does.
And more if I remember correctly.
>> What happens if there are multiple merge [contents] conflicts: is
>> merge.tool invoked in parallel for each conflict or is it waiting for
>> earlier merge.tool to finish (well in which case we can always do set
>> merge.tool to "<program> &")?
>
> Recursively. It is merge-recursive so the merges are done sequentially.
> (Have to be since the result of one merge is reused as one input for the
> next merge.)
Hmmm... is there a way to pass merge.tool / merge.onefile program the
info if it is invoked in final stage (here it is nice to invoke graphical
merge tool to resolve conflicts in working area before commiting merge
result) and in recursive stage (here it would be better to leave conflict
markers to be resolved later)?
>> And is merge.tool invoked for recursive part of recursive merge
>> strategy?
>
> Yes.
Hmmm... would it be possible to use xdl_merge() for recursion, and
graphical merge tool for result? <Checks out earlier discussion>.
I think yes, because of exposing xdl_merge() in git-merge-onefile...
>> This merge startegy depended on resolving conflict markers i.e. had
>> built-in knowledge of 'merge'/'diff3 -E' output.
>
> No. git-merge-recursive never resolved conflict markers but treated them
> as text.
Hmmm... I wonder if anyone get in real life example conflict markers
to be resolved (in final file)...
>> Besides it would be useful not only to spawn interactive merge tools
>> but also to use mergers specific for file-type for example 3DM or
>> xmlcmp tools for merging XML files.
>
> If you need that write a wrapper script which detects the file type and
> execs the corresponding merge program.
That was meant as an example why one might want to use
merge.tool / merge.onefile feature.
--
Jakub Narebski
^ permalink raw reply
* filesystem encodings and gitweb tests, was Re: Moving a directory into another fails
From: Johannes Schindelin @ 2006-12-05 14:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, git
In-Reply-To: <200612051036.13645.jnareb@gmail.com>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Mon, 4 Dec 2006, Linus Torvalds wrote:
> >
> >> [core]
> >> escapefilenames = true
> >
> > I think this goes too far. The problem _only_ showed up with a made-up
> > test case for gitweb. Let's bite the apple when we _have_ to (which I
> > doubt will happen, because for the most part, developers understand that
> > spaces and umlauts have _no_ place in filenames, basically since UNIX was
> > invented by stupid US Americans who did not know anything about nice
> > filenames, let alone other languages than English and C).
>
> No, the problem showed with stupid HFS+ which uses different encoding
> for creating file, and different for readdir.
This is just one of the problems. I described another problem in this
thread, namely a repo on a usb stick being accessed from different hosts.
> Perhaps we should remove gitweb/test directory, and move testing gitweb
> to proper place, t/ directory.
If you do that, please make sure that these tests can be disabled (a la
svn tests), so that people not being interested in gitweb, or lacking the
programs to test it, do not have to suffer.
> By the way, would it be correct to use external tools (if they exist),
> namely HTMLtidy in gitweb output test to-be-written?
(Yes, they exist. HTMLtidy for example ;-)
IMHO if such a tool is common enough, you should use it. If anybody steps
forward providing automated HTTP tests, I will not complain, and certainly
not about testing with things like HTMLtidy.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Johannes Schindelin @ 2006-12-05 14:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612051123.33210.jnareb@gmail.com>
Hi,
On Tue, 5 Dec 2006, Jakub Narebski wrote:
> By the way, is it [ed: xdl_merge()] replacement for RCS merge, i.e. is
> it file-level merge tool, merge.onefile rather than merge.tool?
It is a C function, but yes, it does what RCS merge does.
> What happens if there are multiple merge [contents] conflicts: is
> merge.tool invoked in parallel for each conflict, or is it waiting for
> earlier merge.tool to finish (well, in which case we can always do set
> merge.tool to "<program> &")?
Recursively. It is merge-recursive, so the merges are done sequentially.
(Have to be, since the result of one merge is reused as one input for the
next merge.)
> And is merge.tool invoked for recursive part of recursive merge
> strategy?
Yes.
> This merge startegy depended on resolving conflict markers, i.e. had
> built-in knowledge of 'merge'/'diff3 -E' output.
No. git-merge-recursive never resolved conflict markers, but treated them
as text.
> Besides, it would be useful not only to spawn interactive merge tools,
> but also to use mergers specific for file-type, for example 3DM or
> xmlcmp tools for merging XML files.
If you need that, write a wrapper script, which detects the file type and
execs the corresponding merge program.
Ciao,
Dscho
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Uwe Kleine-Koenig @ 2006-12-05 12:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611301956l6f64b01ftee46971a18e3467b@mail.gmail.com>
Hello Jon,
Jon Smirl wrote:
> Anyone have a nice script for suppressing diffs caused by CVS keyword
> expansion when someone checked the kernel sources into CVS?
I have a little script (called rmcvsid) in my private path, that just
wraps a Perl oneliner:
#! /bin/sh
exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
This edits inplace all cvs keywords to be not expanded. If you call it
for all files *before* you throw them into git, you don't need to
suppress the diffs, because there are none.
You may have to add Source, Date and maybe others.
HTH
Uwe
--
Uwe Kleine-Koenig
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-05 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <45754AFE.1070207@op5.se>
Andreas Ericsson wrote:
> Uwe Kleine-Koenig wrote:
>
>> Andreas Ericsson wrote:
>>> The only problem I'm seeing atm is that the supermodule somehow has to
>>> mark whatever commits it's using from the submodule inside the submodule
>>> repo so that they effectively become un-prunable, otherwise the
>>> supermodule may some day find itself with a history that it can't restore.
>>>
>> One could circumvent that by creating a separate repo for the submodule
>> at checkout time and pull the needed objects in the supermodule's odb
>> when commiting the supermodule. This way prune in the submodule cannot
>> do any harm, because in it's odb are no objects that are important for
>> the supermodule.
>
> Yes, but then you'd lose history connectivity (I'm assuming you'd only
> pull in the tree and blob objects from the submodule, and prefix the
> tree-entrys with whatever directory you're storing the submodul in).
I thought that Uwe meant pulling (getting) _all_ the needed objects from
submodule object repository into supermodule object repository: commits,
trees and blobs, full history.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-05 11:09 UTC (permalink / raw)
To: git
In-Reply-To: <45754D27.9070701@op5.se>
Andreas Ericsson wrote:
> Torgil Svensson wrote:
>> On 12/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>>>
>>> So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
>>> actually think that users _want_ hacky. Exactly because "deep
>>> integration"
>>> ends up having so many _bad_ features, so it's better to have a thin and
>>> simple layer that you can actually see past if you want to.
>>
>> Thin and simple sounds very good. Let's try it with an example. Lets
>> say we have one apllication App1 and three librarys (Lib1, Lib2, Lib3)
>> with the following dependency-graph:
>>
>> App1
>> / \
>> / \
>> Lib1 Lib2
>> \ /
>> \ /
>> Lib3 (don't really needed for this example but looks nice)
>>
>> All components can be used individually and have their own upstream,
>> maintainer etc.
>>
>> To compile App1 however, I need some files from both Lib1 and Lib2
>> specifying it's API. To satisfy these dependencies, It sounds
>> reasonable to link Lib2 and Lib3 submodules from App1. In your
>> concept, can I construct a modules file to fetch the API files and
>> their history without checking out the whole Lib1 and Lib2 source?
>
> I think not. Then it wouldn't be a submodule anymore, but just some
> random sources from an upstream project. Not that it's an uncommon
> workflow or anything, but it's sort of akin to just importing the SHA1
> implementation (a few source-files with no real interest in the history
> of those source-files) from openssl into a different project rather than
> actually using the entire openssl lib (which would be nice to have as a
> submodule).
Note that this is what partial checkouts (another great idea nobody
implemented yet[*1*]; you can do partial checkout but there is no UI for
this, and working with partial checkouts is bit hard) is about, although it
would buy you only working area space, and not repository (object database
storage) space.
For now, you can imitate this by having in in Lib1 and Lib2 the 'includes'
branch which would contain only the API (and which you would have to keep
up to date with 'master', but it should be fairly easy: just merge changes
into 'includes', perhaps with help of git-rerere, or [nonexisting]
git-rerere2).
[*1*] Although with our track[*2*] I guess it is reasonable to think it
would get implemented soon.
[*2*] Out of four "great ideas": shallow clone / sparse clone, submodules
support, lazy clone / remote alternates, two are in example-implementation
(submodules support) and beta work (shallow clone is in 'next').
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-05 11:01 UTC (permalink / raw)
To: git
In-Reply-To: <45754C0E.3070904@op5.se>
Andreas Ericsson wrote:
> Indeed. With the "tight" integration option we'd also have to have the
> mechanism to rewrite the tree-entries with the location where the
> submodule is located in the working tree. This might be needed anyways,
> but it sure as hell seems a lot easier to just tack that part on when
> doing a checkout and actually creating all the files.
Excellent idea! This way most of the concerns for "separate repositories for
submodules" layout about ability to rename directory the submodule resides
in, or move submodule are resolved. The other part would be to use
submodule-aware git-mv to move submodule(s).
Perhaps the following solution would work best:
* refs/submodules/<module> holds sha1 of top commit in submodule
* objects/info/submodules is a file which can be automatically generated
(or at least automatically updated) on checkout, with the following
contents:
<module> TAB or SPC <path to submodule, or GIT_DIR of submodule, or
GIT_OBJECT_DIRECTORY of submodule>
with the usual rule that # and ; means comment, \ at end of line is used
for continuations, empty lines doesn't matter etc.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-05 10:42 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Linus Torvalds, sf-gmane, sf, git, Martin Waitz
In-Reply-To: <e7bda7770612041336s73e677ebh758b030f9f75c1d8@mail.gmail.com>
Torgil Svensson wrote:
> On 12/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>>
>> So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
>> actually think that users _want_ hacky. Exactly because "deep
>> integration"
>> ends up having so many _bad_ features, so it's better to have a thin and
>> simple layer that you can actually see past if you want to.
>
> Thin and simple sounds very good. Let's try it with an example. Lets
> say we have one apllication App1 and three librarys (Lib1, Lib2, Lib3)
> with the following dependency-graph:
>
> App1
> /\
> / \
> Lib1 Lib2
> \ /
> \ /
> Lib3 (don't really needed for this example but looks nice)
>
> All components can be used individually and have their own upstream,
> maintainer etc.
>
> To compile App1 however, I need some files from both Lib1 and Lib2
> specifying it's API. To satisfy these dependencies, It sounds
> reasonable to link Lib2 and Lib3 submodules from App1. In your
> concept, can I construct a modules file to fetch the API files and
> their history without checking out the whole Lib1 and Lib2 source?
I think not. Then it wouldn't be a submodule anymore, but just some
random sources from an upstream project. Not that it's an uncommon
workflow or anything, but it's sort of akin to just importing the SHA1
implementation (a few source-files with no real interest in the history
of those source-files) from openssl into a different project rather than
actually using the entire openssl lib (which would be nice to have as a
submodule).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] git-explain
From: Jakub Narebski @ 2006-12-05 10:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vwt57j94c.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> [PATCH] git-explain
>
> This patch adds "git-explain" script that notices various clues
> other commands can leave the working tree and repository in and
> intended to guide the end user out of the confused mess.
I like it, although I think that it explains a bit too little
about aborted git-rebase / git-am, and for example doesn't touch
git-bisect at all. Both as an end-user script (BTW. the name could
be changed using aliases), and as a policy for git commands.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-05 10:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Torgil Svensson, sf-gmane, sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612041234390.3476@woody.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 4 Dec 2006, Torgil Svensson wrote:
>> Okay, missed that part. I wasn't familiar with contents of the CVS
>> modules files and misinterpreted your suggestion.
>>
>> MODULE [OPTIONS] [&OTHERMODULE...] [DIR] [FILES]
>>
>> So all this is UI only and the "normal" operations on the supermodule
>> will just ignore what's behind the commit-links?
>
> Right. That's how CVS modules work (although in the case of CVS modules,
> the "dir" thing is obviously there in the "modules" file, so it's not
> _purely_ UI in CVS - this would likely be different in a git
> implementation, because the "tree" object ends up telling not just the
> exact version, but the location too).
>
> So my suggestion basically boils down to:
>
> - "fetch" and "clone" etc will just look at the "modules" file, and
> recursively fetch/clone whatever the module files talks about. This is
> the "thin veneer to make it _look_ like git actually understands
> submodules" part. It woudln't really - they're very much tacked on.
>
> - the tree entries are what makes the "once you have all the submodule
> objects, this is how you can do 'diff' and 'checkout' on them, and this
> is what tells you the exact version that goes along with a particular
> supermodule version".
>
> In other words, the simple and stupid way to do this is to just consider
> these two things two totally independent issues, and have different
> mechanisms for telling different operations what to do.
>
> Is it "pretty"? No. The whole sub-module thing wouldn't be a tightly
> integrated low-level thing, it would very much be all about tracking
> multiple _separate_ git repositories, and just make them work well
> together. They'd very much still be separate, with just some simple
> infrastructure glue to make them look somewhat integrated.
>
> So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
> actually think that users _want_ hacky. Exactly because "deep integration"
> ends up having so many _bad_ features, so it's better to have a thin and
> simple layer that you can actually see past if you want to.
>
Indeed. With the "tight" integration option we'd also have to have the
mechanism to rewrite the tree-entries with the location where the
submodule is located in the working tree. This might be needed anyways,
but it sure as hell seems a lot easier to just tack that part on when
doing a checkout and actually creating all the files.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-05 10:33 UTC (permalink / raw)
To: Uwe Kleine-Koenig, Andreas Ericsson, Martin Waitz, Andy Parkins,
git
In-Reply-To: <20061205090125.GA2428@cepheus>
Uwe Kleine-Koenig wrote:
> Hello,
>
> Andreas Ericsson wrote:
>> The only problem I'm seeing atm is that the supermodule somehow has to
>> mark whatever commits it's using from the submodule inside the submodule
>> repo so that they effectively become un-prunable, otherwise the
>> supermodule may some day find itself with a history that it can't restore.
> One could circumvent that by creating a separate repo for the submodule
> at checkout time and pull the needed objects in the supermodule's odb
> when commiting the supermodule. This way prune in the submodule cannot
> do any harm, because in it's odb are no objects that are important for
> the supermodule.
>
Yes, but then you'd lose history connectivity (I'm assuming you'd only
pull in the tree and blob objects from the submodule, and prefix the
tree-entrys with whatever directory you're storing the submodul in).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH 1/5] git-svn: make test for SVK mirror path import
From: Jakub Narebski @ 2006-12-05 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <20061205051738.16552.8987.stgit@localhost>
Sam Vilain wrote:
^^^^^^^^^^
> From: <sam@vilain.net>
[...]
> diff --git a/t/t9107-git-svn-svk-mirrorpaths.sh
b/t/t9107-git-svn-svk-mirrorpaths.sh
> new file mode 100755
> index 0000000..130e786
> --- /dev/null
> +++ b/t/t9107-git-svn-svk-mirrorpaths.sh
[...]
> +# Copyright (c) 2006 Eric Wong
^^^^^^^^^
???
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] merge-recursive: configurable 'merge' program
From: Jakub Narebski @ 2006-12-05 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612050836570.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> On Tue 5 Dec 2006 Jakub Narebski wrote:
>
>> Sam Vilain wrote:
>>
>>> For those who like to spawn interactive merge tools on a merge failure
>>> or otherwise run some kind of script allow a "merge.tool" repo-config
>>> option that will take arguments as merge(1) does.
>>
>> How it goes together with merge-recursive rewrite using built-in merge tool
>> from xdiff xdl_merge?
>
> Not a big problem. If people like Sam's patch it is easy to integrate
> since it only means that if merge.tool is set to something non-empty
> xdl_merge is not called but the merge.tool is forked.
Good idea. By the way, is it replacement for RCS merge, i.e. is it
file-level merge tool, merge.onefile rather than merge.tool? What happens
if there are multiple merge [contents] conflicts: is merge.tool invoked
in parallel for each conflict, or is it waiting for earlier merge.tool
to finish (well, in which case we can always do set merge.tool to
"<program> &")? And is merge.tool invoked for recursive part of recursive
merge strategy? This merge startegy depended on resolving conflict
markers, i.e. had built-in knowledge of 'merge'/'diff3 -E' output.
Besides, it would be useful not only to spawn interactive merge tools,
but also to use mergers specific for file-type, for example 3DM or xmlcmp
tools for merging XML files.
--
Jakub Narebski
^ permalink raw reply
* Re: Moving a directory into another fails
From: Jakub Narebski @ 2006-12-05 9:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0612050831550.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Linus Torvalds wrote:
>
>> [core]
>> escapefilenames = true
>
> I think this goes too far. The problem _only_ showed up with a made-up
> test case for gitweb. Let's bite the apple when we _have_ to (which I
> doubt will happen, because for the most part, developers understand that
> spaces and umlauts have _no_ place in filenames, basically since UNIX was
> invented by stupid US Americans who did not know anything about nice
> filenames, let alone other languages than English and C).
No, the problem showed with stupid HFS+ which uses different encoding
for creating file, and different for readdir.
Perhaps we should remove gitweb/test directory, and move testing gitweb
to proper place, t/ directory.
By the way, would it be correct to use external tools (if they exist),
namely HTMLtidy in gitweb output test to-be-written?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] git-explain
From: Eric Wong @ 2006-12-05 9:21 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, J. Bruce Fields, Nicolas Pitre, git,
Linus Torvalds
In-Reply-To: <20061205072622.GA21839@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Dec 04, 2006 at 10:09:17PM -0800, Junio C Hamano wrote:
>
> > Should I take these responses to mean that you two are negative
> > about the approach of spending extra cycles to commands that can
> > leave the working tree in a "in the middle of doing something"
> > state to help having a unified command to explain what the
> > situation is and suggest the user possible exits, or are you
> > saying that it might be a good idea but "git explain" is a bad
> > name?
>
> It seems like the point of this command is to show some state
> information which would otherwise be hard to see. I think of 'git
> status' as the way to look at the repository state. Perhaps we should
> enhance the output of 'git status' to note things such as failed merges,
> whether we're bisecting, in the middle of applying a patch series, etc.
> There could be an optional verbosity switch to give "full explanations"
> including recommended ways to deal with the situation.
I wholeheartedly agree that 'git status' should show something like
this. I actually had some stuff that was a work-in-progress several
months ago that enhanced status with several things like this; but got
distracted and forgot about that repository. I'll try to dig it out
sometime tomorrow. I remember my work started from wanting to know
what 'git-rerere' would be recording.
--
^ permalink raw reply
* Re: [PATCH 1/3] Ask git for author and committer name
From: Catalin Marinas @ 2006-12-05 9:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061205091017.GB25002@diana.vm.bytemark.co.uk>
On 05/12/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-12-04 22:24:52 +0000, Catalin Marinas wrote:
> > I haven't forgot about this patch. I switched StGIT to the gitconfig
> > files and there won't be a need to invoke "git repo-config". I'll
> > try to modify your patch.
>
> Ah, nice. But will you still honor the git author and committer
> environment variables that way?
Yes. My understanding is that the environment variables would override
the config options. I would also keep the [stgit] user information for
backward compatibility (there are people who use StGIT exclusively and
don't want to dig into GIT configs).
--
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-05 9:13 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86odqjj70y.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>
> no blob information
Can you make Data::Dumper display $fb where it dies with that message?
Thanks.
--
^ permalink raw reply
* RE: [PATCH] git-explain
From: Raimund Bauer @ 2006-12-05 9:11 UTC (permalink / raw)
To: 'Junio C Hamano', 'J. Bruce Fields',
'Nicolas Pitre'
Cc: git, 'Linus Torvalds'
In-Reply-To: <7v1wnekh6a.fsf@assigned-by-dhcp.cox.net>
> An issue with this approach is that this can be the beginning
> of hardwiring the official "right way of doing things" in the
> set of tools. Pursuing this approach would enhance the set
> of state markers like "FAILED_MERGE" in the example, which means:
Wouldn't it be better to create some kind of action-log (that's
cleared at the end of the command if everything was all right)
instead of creating special markers for different commands?
That way there would be only 1 place to check for what happened ...
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH 1/3] Ask git for author and committer name
From: Karl Hasselström @ 2006-12-05 9:10 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0612041424v42313a2r22d8fc8d1b18cb55@mail.gmail.com>
On 2006-12-04 22:24:52 +0000, Catalin Marinas wrote:
> On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Consistently do the following to get hold of default user and
> > committer:
> >
> > 1. Use the value specified on the command line, if any.
> >
> > 1. Otherwise, use the value from stgitrc, if available.
> >
> > 2. Otherwise, ask git for the value. git will produce the value
> > from on of its config files, from environment variables, or
> > make it up. It might be asking the spirits of the dead for
> > all we care.
>
> I haven't forgot about this patch. I switched StGIT to the gitconfig
> files and there won't be a need to invoke "git repo-config". I'll
> try to modify your patch.
Ah, nice. But will you still honor the git author and committer
environment variables that way?
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Catalin Marinas @ 2006-12-05 9:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, Karl Hasselström, git
In-Reply-To: <Pine.LNX.4.63.0612050841160.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On 05/12/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 4 Dec 2006, Catalin Marinas wrote:
> > I'll first move the message back to stdout.
>
> In other parts of git, the progress message is only printed if output goes
> to a tty. Why not do the same?
Thanks for the hint. This seems to me like the easiest solution.
--
^ 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