* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-12 11:37 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <E43846E3-4F42-4B3A-BA5F-1A21FE70C3FB@wincent.com>
Hi,
On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> El 11/10/2007, a las 22:53, David Kastrup escribi?:
>
> > Johannes Sixt <j.sixt@viscovery.net> writes:
> >
> > > Jonathan del Strother schrieb:
> > > > How are you going to test that git works on paths with spaces if the
> > > > test suite doesn't run there?
> > >
> > > By writing a specific test?
> >
> > This is going to be much less thorough. And it does no harm if the
> > test scripts demonstrate defensive programming.
>
> +1: especially in this case, where it really is "defensive" and not
> "paranoiac".
I am all for it, _iff_ the guilty parties (and by that, I mean _you_) do
it and keep maintaining it. See? Discussion closed already.
Ciao,
Dscho
^ permalink raw reply
* [PATCH amend] git-config: print error message if the config file cannot be read
From: Gerrit Pape @ 2007-10-12 11:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <470B8286.5060006@viscovery.net>
Instead of simply exiting with 255, print an error message including
the reason why a config file specified through --file cannot be opened
or read.
The problem was noticed by Joey Hess, reported through
http://bugs.debian.org/445208
---
On Tue, Oct 09, 2007 at 02:16:41PM +0100, Johannes Schindelin wrote:
> On Tue, 9 Oct 2007, Gerrit Pape wrote:
> > + if (git_config(show_all_config) == -1)
> I'd rather check for < 0, just for future proofing.
Okay.
On Tue, Oct 09, 2007 at 03:30:46PM +0200, Johannes Sixt wrote:
> Gerrit Pape schrieb:
> >+ if (show_all) {
> >+ if (git_config(show_all_config) == -1)
> >+ die("unable to read config file %s: %s",
> >+ getenv(CONFIG_ENVIRONMENT), strerror(errno));
> I don't think that this works well: If there are no config files at
> all, then we don't want to see an error - just as if the config file
> were empty.
>
> Also, I don't think that errno is reliable at this point.
>
> You probably want to see an error message *only* if you have supplied
> a file name with --file.
I changed the patch to die() only if --file was sepcified, and errno is
not 0.
Thanks, Gerrit.
builtin-config.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 4444d52..e5bf791 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -172,8 +172,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
type = T_INT;
else if (!strcmp(argv[1], "--bool"))
type = T_BOOL;
- else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l"))
- return git_config(show_all_config);
+ else if (!strcmp(argv[1], "--list") || !strcmp(argv[1], "-l")) {
+ if (git_config(show_all_config) < 0 && file && errno)
+ die("unable to read config file %s: %s", file,
+ strerror(errno));
+ return 0;
+ }
else if (!strcmp(argv[1], "--global")) {
char *home = getenv("HOME");
if (home) {
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH amend] git-config: print error message if the config file cannot be read
From: Johannes Sixt @ 2007-10-12 11:59 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20071012114057.30803.qmail@12f4c67b8560e2.315fe32.mid.smarden.org>
Gerrit Pape schrieb:
>> You probably want to see an error message *only* if you have supplied
>> a file name with --file.
>
> I changed the patch to die() only if --file was sepcified, and errno is
> not 0.
Thanks. I can live with that. ;)
-- Hannes
^ permalink raw reply
* Re: push fails with unexpected 'matches more than one'
From: Steffen Prohaska @ 2007-10-12 12:06 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <11921723791817-git-send-email-prohaska@zib.de>
On Oct 12, 2007, at 8:59 AM, Steffen Prohaska wrote:
> This adds a test case for unambigous local match but multiple remote
> matches. To me, it is unexpected that a ref that is perfectly defined
> on the local side fails with 'matches more than one'.
>
> The following rule could solve this:
> A ref shall first be unambigously resolved on the local side, and its
> full name should be used for matching on the remote side.
> For example 'frotz' resolves locally to 'heads/refs/frotz'.
> Therefore pretend the user had typed 'heads/refs/frotz'.
>
> But maybe there is some hidden secret about the current rules that
> I do not see.
Here is a related question:
I read carefully through the documentation of git-send-pack and
git-rev-parse. The current implementation of git-send-pack is in line
with the documented behaviour, as is the implementation of git-rev-
parse.
So formally everything is correct.
But it is completely against my expectation that git-push <remote>
<head>
can successfully resolve a <head> that git-rev-parse fails to parse. I
understand that refs are not revs ;). But nonetheless, I'd expect that a
local ref that cannot be parsed by git-rev-parse should also fail to be
pushed by git-send-pack. I didn't expect that git-send-pack would locate
<head> as someprefix/<head>.
Why is my expectation wrong?
Or is the current specification of git-send-pack's ref parsing wrong?
Steffen
^ permalink raw reply
* Re: [PATCH amend] git-config: handle --file option with relative pathname properly
From: Johannes Schindelin @ 2007-10-12 12:08 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <20071012113251.29941.qmail@7584201f340355.315fe32.mid.smarden.org>
Hi,
On Fri, 12 Oct 2007, Gerrit Pape wrote:
> - setup_git_directory_gently(&nongit);
> + const char *file = setup_git_directory_gently(&nongit);
One last nit (because I did not see it earlier): please call the variable
"prefix", not "file".
Other than that, I think your patch is obviously correct.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Wincent Colaiuta @ 2007-10-12 12:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710121235230.25221@racer.site>
El 12/10/2007, a las 13:37, Johannes Schindelin escribió:
> On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
>
>> El 11/10/2007, a las 22:53, David Kastrup escribió:
>>
>>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>>
>>>> Jonathan del Strother schrieb:
>>>>> How are you going to test that git works on paths with spaces
>>>>> if the
>>>>> test suite doesn't run there?
>>>>
>>>> By writing a specific test?
>>>
>>> This is going to be much less thorough. And it does no harm if the
>>> test scripts demonstrate defensive programming.
>>
>> +1: especially in this case, where it really is "defensive" and not
>> "paranoiac".
>
> I am all for it, _iff_ the guilty parties (and by that, I mean
> _you_) do
> it and keep maintaining it. See? Discussion closed already.
How am *I* the guilty party? I'm merely endorsing David's comment
that a modicum of defensive programming isn't a bad thing; an
eminently reasonable position which is somewhat difficult to argue
against.
Cheers,
Wincent
^ permalink raw reply
* Workflow: split repository?
From: Jan Wielemaker @ 2007-10-12 12:21 UTC (permalink / raw)
To: Git Mailing List
Hi,
I've got a big active project, until yesterday managed using CVS. As
with any distributed academic research project the repository has become
a nice mess where most files are in the wrong place and there are
several almost independent sub-projects living in directories.
The plan is/was to
* Convert everything to GIT (done, through cvs2svn)
* Everyone keeps hacking on their bits, while one is starting
to reorganise the structure by moving files and directories
and changing import headers, and other file references in
a GIT branch.
* Now we merge the continued work and the reorganisation to
end up with a nice clean hierarchy :-)
* Split the big project into multiple projects. One of the
reasons is that we want to make part of them public. Others
we cannot publish as they contain copyrighted data. I understand
we can reunite them using GIT sub modules.
Does this make sense?
While splitting we want to *loose* history information for some of the
projects. That is easy: simply create a new repository from the current
files. For some however we would like to *preserve* the history. This
means we would like to pick a hierarchy with its history. After quite
a bit of reading, I get the impression this cannot be done. Am I right?
Is the only way to create a GIT repositiory right away from a subset of
the CVS for which we want to preserve the history?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-12 12:51 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Sixt, Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <A7970E82-92E0-4267-AF79-D4ABDB21F0D0@wincent.com>
Hi,
On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> El 12/10/2007, a las 13:37, Johannes Schindelin escribi?:
>
> > On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
> >
> > > El 11/10/2007, a las 22:53, David Kastrup escribi?:
> > >
> > > > Johannes Sixt <j.sixt@viscovery.net> writes:
> > > >
> > > > > Jonathan del Strother schrieb:
> > > > > > How are you going to test that git works on paths with spaces if
> > > > > > the
> > > > > > test suite doesn't run there?
> > > > >
> > > > > By writing a specific test?
> > > >
> > > > This is going to be much less thorough. And it does no harm if the
> > > > test scripts demonstrate defensive programming.
> > >
> > > +1: especially in this case, where it really is "defensive" and not
> > > "paranoiac".
> >
> > I am all for it, _iff_ the guilty parties (and by that, I mean _you_) do
> > it and keep maintaining it. See? Discussion closed already.
>
> How am *I* the guilty party? I'm merely endorsing David's comment that a
> modicum of defensive programming isn't a bad thing; an eminently
> reasonable position which is somewhat difficult to argue against.
All I'm saying: let patches speak. Talk is cheap.
Ciao,
Dscho
^ permalink raw reply
* Re: RCS keyword expansion
From: Jan Hudec @ 2007-10-12 12:57 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710121144001.3682@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]
On Fri, Oct 12, 2007 at 11:50:51 +0100, Peter Karlsson wrote:
> > But don't you see? When switching branches, this totally breaks down.
>
> Why would it? If the file is the same on both branches, nothing would
> happen (it is still the same version), and if the file is different, it
> gets changed anyway, and a new keyword expansion would take place.
It does not -- the blob ID is the same. And you can indeed get $Id$ expanded
to that (see gitattributes(5)). However, that's the ONLY thing that is the
same. The date of last modification or ID of commit that last touched that
file might not.
Why? Because git tracks content, not history. The trees and blobs (files) are
identified by SHA1 hashes of their content. Only commit objects add the
notion of history. Thus if two commits contain file with the same text, it's
the same file. Even if the file is the same in those commit purely by
accident.
> > No, really, IMHO it is enough to show either the commit name or the
> > blob name of the file. After all, you are not interested in the date
> > that this file was last committed, but in the _contents_.
>
> Yes, but I want it on the lowest addressable unit size, i.e on the file
> level (I could possibly want to have the last commit for a set of files
> when I have something that get generated from several sources, but that
> is rare for a regular website, unless since javascripts and stylesheets
> etc. are delivered separately).
>
> Already today when you do "git log" on a file, you get the log filtered
> for only changes to that file. So the mechanisms seem already to be
> there, I just need to figure out how to apply them to what I want.
Yes. But you need the (current) commit for that. Now if a file foo is the
same on branches A and B, switching between them will not touch that file,
but git log foo may well give you completely different results. That's why
there's no date or commit that last touched a file.
> > So why not go for the contents? With CVS/SVN you only have the
> > chance to do that by date or version number. With git, we have a more
> > powerful way: we do it by a hash of the contents.
>
> Yes, but the hash if of "everything". I'm not interested in
> "everything" in this context, and I don't want to have a separate git
> repository for each file...
>
> > If it's not what you want, I suggest rethinking what you want ;-)
> > Otherwise it is scripting time for you. It's easy enough with git.
>
> That's what I'm trying to figure out. I assume it would be possible to
> do with some kind of hook that is run on checkout. But I can't figure
> out how to do that.
If you read the (already mentioned) gitattributes(5) manpage, you'll find
description of smudge and clean filters. They will be applied to each file
written out to the tree and read back respectively. But be sure to understand
why you can't -- for principial, not techical reasons -- have the date or
commit ID expanded correctly in all cases.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: David Kastrup @ 2007-10-12 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710121351200.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
>
>> El 12/10/2007, a las 13:37, Johannes Schindelin escribi?:
>>
>> > On Fri, 12 Oct 2007, Wincent Colaiuta wrote:
>> >
>> > > El 11/10/2007, a las 22:53, David Kastrup escribi?:
>> > >
>> > > > Johannes Sixt <j.sixt@viscovery.net> writes:
>> > > >
>> > > > > Jonathan del Strother schrieb:
>> > > > > > How are you going to test that git works on paths with spaces if
>> > > > > > the
>> > > > > > test suite doesn't run there?
>> > > > >
>> > > > > By writing a specific test?
>> > > >
>> > > > This is going to be much less thorough. And it does no harm if the
>> > > > test scripts demonstrate defensive programming.
>> > >
>> > > +1: especially in this case, where it really is "defensive" and not
>> > > "paranoiac".
>> >
>> > I am all for it, _iff_ the guilty parties (and by that, I mean _you_) do
>> > it and keep maintaining it. See? Discussion closed already.
>>
>> How am *I* the guilty party? I'm merely endorsing David's comment that a
>> modicum of defensive programming isn't a bad thing; an eminently
>> reasonable position which is somewhat difficult to argue against.
>
> All I'm saying: let patches speak. Talk is cheap.
The patches spoke. That is what the [PATCH] in the subject line was about.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] add simple install replacement
From: Jan Hudec @ 2007-10-12 14:06 UTC (permalink / raw)
To: Robert Schiele; +Cc: git, gitster
In-Reply-To: <20071011215237.GI20753@schiele.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2881 bytes --]
On Thu, Oct 11, 2007 at 23:52:37 +0200, Robert Schiele wrote:
> This patch adds a very simple install replacement script to git.
> This allows more easy installation on systems that don't have a
> compatible install.
Do you have a particular case where you need it?
> Signed-off-by: Robert Schiele <rschiele@gmail.com>
> ---
> gitinstall | 35 +++++++++++++++++++++++++++++++++++
> 1 files changed, 35 insertions(+), 0 deletions(-)
> create mode 100755 gitinstall
>
> diff --git a/gitinstall b/gitinstall
> new file mode 100755
> index 0000000..8b346d6
> --- /dev/null
> +++ b/gitinstall
> @@ -0,0 +1,35 @@
> +#!/bin/sh
> +
> +MKDIRMODE=0
> +MODE=755
> +while getopts 'dm:' FLAG; do
No such thing here:
zsh$ /bin/sh
$ which getopts
$
Yes, bash and zsh do have that, but my (and I suspect many git users')
/bin/sh is neither of those. Git scripts should use just POSIX shell
features for portability.
Which is particularly important when you are trying to replace a common
utility, because the systems that won't have it are likely to not have bash
either.
You may want to have a look at /usr/share/automake-1.9/install-sh (or
/usr/share/automake<something>/install-sh). It shows how to portably process
options in shell and since it's in fact covered by the MIT/X license (and FSF
changes are public domain), git could just use it if necessary.
> + case "$FLAG" in
> + d) MKDIRMODE=1;;
> + m) MODE="$OPTARG";;
> + *) exit 1;;
> + esac
> +done
> +if test "$OPTIND" != 1; then
> + shift `expr $OPTIND - 1`
> +fi
> +if test $MKDIRMODE = 1; then
> + mkdir -p "$@"
> + chmod "$MODE" "$@"
> +else
> + if test $# = 2 && ! test -d "$2"; then
> + rm -rf "$2"
Are you sure reall install would do this? The maual (install(1)) states
following usage variants:
install [OPTION]... [-T] SOURCE DEST
install [OPTION]... SOURCE... DIRECTORY
install [OPTION]... -t DIRECTORY SOURCE...
install [OPTION]... -d DIRECTORY...
Now however there is nothing saying that SOURCE... is at least two, so is
install git /usr/bin
a case of the first or second usage? I would say the second, but your code
would:
rm -rf /usr/bin
cp git /usr/bin
> + cp "$1" "$2"
> + chmod "$MODE" "$2"
> + else
> + FILES=
> + while test $# != 1; do
> + FILES="$FILES $1"
> + shift
> + done
> + for i in $FILES; do
touch "foo*bar" "a b c"
./gitinstall "b*c" "a b c" /tmp
... will copy a lot of files to /tmp (presuming we are in git source
directory, where tons of files are called builtin-<something>.c) and complain
that there is no 'a', no 'b' and no 'c'.
> + rm -rf "$1/"`basename "$i"`
> + cp "$i" "$1"
> + chmod "$MODE" "$1/"`basename "$i"`
> + done
> + fi
> +fi
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:14 UTC (permalink / raw)
To: Sam Vilain, Jonathan del Strother; +Cc: git
In-Reply-To: <470E9858.5050904@vilain.net>
On Thu, 11 Oct 2007 23:40:40 +0200, Sam Vilain <sam@vilain.net> wrote:
> Jonathan del Strother wrote:
>>> For example, I want to convert one subversion repository which
>>> contains the folders:
>>> trunk/projectA
>>> trunk/projectB
>>>
>>> into two git repositories:
>>> projectA.git
>>> projectB.git
>>
>> I have a slightly different layout to you -
>>
>> projectA/trunk
>> projectA/branches
>> projectA/tags
>> projectB/trunk
>> projectB/branches
>> projectB/tags
>> etc
>>
>> - but I've been creating separate git repos from that with (for
>> example) :
>>
>> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
>> git-svn fetch
>>
>>
>> Or will git-svn not work with your sort of layout?
>
> It does work. Use:
>
> git-svn init -t projectA/tags -b projectA/branches \
> -T trunk/projectA http://svn.host.com/
> git fetch
With my paths this translates into
$ git-svn init -b eivindlm/branches \
-t eivindlm/tags \
-T eivindlm/trunk/src/probesimulator \
file:///svn-repo/
, which prints the happy message:
Initialized empty Git repository in .git/
The next command is unfortunately not as happy:
$ git fetch
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Cannot get the repository state from origin
I suppose this is due to my silly svn-repo layout... However, after some
trial and error it seems like the following command gives me what I want
(I don't need tags or other branches than main):
$ git-svn clone file:///svn-repo/ --follow-parent \
-T eivindlm/trunk/src/probesimulator
It seems to realize that the probesimulator directory has moved around in
my tree, and gives me history for files that belongs in this directory
only (and not history for other directories). So the problem appears to be
solved for my part, unless you see a reason for why I should not do it in
this way.
> [...]
Thanks a lot for the help to everyone who replied!
Eivind
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:15 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0710110624x2b50cfafo9bfdc176ba9063ce@mail.gmail.com>
Thanks,
I found svndumpfilter in the svn book, and gave it a try. Unfortunately it
seems to be confused about files that have moved around in the repository,
I was at least not able to make it dump the entire history for a directory
that over time has changed name, and that contains files that have moved
in from other directories.
Eivind
On Thu, 11 Oct 2007 15:24:59 +0200, Patrick Doyle <wpdster@gmail.com>
wrote:
> If you look through the Subversion FAQ or the book (I forget where
> I've seen it -- but I know I've seen it), you can export/filter out a
> tree from a subversion repository and load it into a new repository.
> Then you can import from that new repository.
>
> This presumes you have direct access to the subversion repository and
> can run commands like svnadmin --dump.
>
> --wpd
>
>
> On 10/11/07, Eivind LM <eivliste@online.no> wrote:
>> Hi,
>> I would like to convert a subversion repository to Git. The subversion
>> repository used to track development of several projects (only slightly
>> related), and I would like to divide the repository into several smaller
>> git repositories.
>>
>> For example, I want to convert one subversion repository which contains
>> the folders:
>> trunk/projectA
>> trunk/projectB
>>
>> into two git repositories:
>> projectA.git
>> projectB.git
>>
>> As far as I have understood, the way to do this is to
>> 1) Convert the entire subversion repository to git with git-svn.
>> 2) Make two copies of the whole new git-repository (projectA.git and
>> projectB.git).
>> 3) Use git-rm to remove projectB from projectA.git, and projectA from
>> projectB.git.
>>
>> This works fine, but both git-repositories now carries the history for
>> both projects. If possible, I would like to "clean" the history in the
>> repositories, so that I don't see history information for projectA when
>> I
>> am browsing logs in projectB.git. Has anyone been in the same situation?
>> Do you have suggestions on how it can be solved?
>>
>> Any help will be greatly appreciated.
>>
>> Thanks,
>> Eivind
>> -
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Jonathan del Strother @ 2007-10-12 14:23 UTC (permalink / raw)
To: Eivind LM; +Cc: Git Mailing List
In-Reply-To: <op.tz28hnd2jwclfx@ichi>
On 12 Oct 2007, at 15:14, Eivind LM wrote:
> On Thu, 11 Oct 2007 23:40:40 +0200, Sam Vilain <sam@vilain.net> wrote:
>
>> Jonathan del Strother wrote:
>>>> For example, I want to convert one subversion repository which
>>>> contains the folders:
>>>> trunk/projectA
>>>> trunk/projectB
>>>>
>>>> into two git repositories:
>>>> projectA.git
>>>> projectB.git
>>>
>>> I have a slightly different layout to you -
>>>
>>> projectA/trunk
>>> projectA/branches
>>> projectA/tags
>>> projectB/trunk
>>> projectB/branches
>>> projectB/tags
>>> etc
>>>
>>> - but I've been creating separate git repos from that with (for
>>> example) :
>>>
>>> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
>>> git-svn fetch
>>>
>>>
>>> Or will git-svn not work with your sort of layout?
>>
>> It does work. Use:
>>
>> git-svn init -t projectA/tags -b projectA/branches \
>> -T trunk/projectA http://svn.host.com/
>> git fetch
>
> With my paths this translates into
>
> $ git-svn init -b eivindlm/branches \
> -t eivindlm/tags \
> -T eivindlm/trunk/src/probesimulator \
> file:///svn-repo/
> , which prints the happy message:
> Initialized empty Git repository in .git/
>
> The next command is unfortunately not as happy:
> $ git fetch
> fatal: 'origin': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from origin
I believe you actually wanted "git-svn fetch" here
^ permalink raw reply
* Re: Workflow: split repository?
From: Jan Hudec @ 2007-10-12 14:30 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List
In-Reply-To: <200710121421.39159.wielemak@science.uva.nl>
[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]
On Fri, Oct 12, 2007 at 14:21:39 +0200, Jan Wielemaker wrote:
> Hi,
>
> I've got a big active project, until yesterday managed using CVS. As
> with any distributed academic research project the repository has become
> a nice mess where most files are in the wrong place and there are
> several almost independent sub-projects living in directories.
>
> The plan is/was to
>
> * Convert everything to GIT (done, through cvs2svn)
> * Everyone keeps hacking on their bits, while one is starting
> to reorganise the structure by moving files and directories
> and changing import headers, and other file references in
> a GIT branch.
> * Now we merge the continued work and the reorganisation to
> end up with a nice clean hierarchy :-)
> * Split the big project into multiple projects. One of the
> reasons is that we want to make part of them public. Others
> we cannot publish as they contain copyrighted data. I understand
> we can reunite them using GIT sub modules.
>
> Does this make sense?
It might make more sense to convert bit by bit, to separate git repositories.
Would save you some git-filter-branch work.
> While splitting we want to *loose* history information for some of the
> projects. That is easy: simply create a new repository from the current
> files. For some however we would like to *preserve* the history. This
> means we would like to pick a hierarchy with its history. After quite
> a bit of reading, I get the impression this cannot be done. Am I right?
It can, but you have to be aware of the pitfalls. Git allows you to create
a new history, which is defined modification of the original history. There
is git-filter-branch command, that can create a repository with just
a subtree and such. But it's a new, independent, history. You can't merge
between the old and new one (but you can rebase the few commits someone made
while you were converting) and anyone who has the old history in his repo
will still have it.
> Is the only way to create a GIT repositiory right away from a subset of
> the CVS for which we want to preserve the history?
No, it's not. It will save you work if you can do as much splitting as
possible during the conversion, ie. convert the bits you know will be
separate separately (and combine them using submodules as appropriate).
But if you have bits that will take a lot of work to factor out, you can
convert to git, make the other code ready to use a submodule and than use
git-filter-branch to extract the right bits of history for the submodule.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Eivind LM @ 2007-10-12 14:47 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <1B9700E6-5DFB-443D-9465-30E0DCAD0619@steelskies.com>
On Fri, 12 Oct 2007 16:23:44 +0200, Jonathan del Strother
<maillist@steelskies.com> wrote:
[...]
>>
>> $ git-svn init -b eivindlm/branches \
>> -t eivindlm/tags \
>> -T eivindlm/trunk/src/probesimulator \
>> file:///svn-repo/
>> , which prints the happy message:
>> Initialized empty Git repository in .git/
>>
>> The next command is unfortunately not as happy:
>> $ git fetch
>> fatal: 'origin': unable to chdir or not a git archive
>> fatal: The remote end hung up unexpectedly
>> Cannot get the repository state from origin
>
>
> I believe you actually wanted "git-svn fetch" here
You are right, that solved the problem :)
So both methods work now, apparently giving the same result. Is there a
difference between the fetch- versus the clone-approach? I am doing this
as a once-and-for-all import, and would like to forget everything about
the subversion repository afterwards.
Thanks,
Eivind
^ permalink raw reply
* Re: Workflow: split repository?
From: Jan Wielemaker @ 2007-10-12 14:57 UTC (permalink / raw)
To: Jan Hudec; +Cc: Git Mailing List
In-Reply-To: <20071012143043.GD7865@efreet.light.src>
Hi Jan,
On Friday 12 October 2007 16:30, Jan Hudec wrote:
> On Fri, Oct 12, 2007 at 14:21:39 +0200, Jan Wielemaker wrote:
> > Does this make sense?
>
> It might make more sense to convert bit by bit, to separate git
> repositories. Would save you some git-filter-branch work.
> > Is the only way to create a GIT repositiory right away from a subset of
> > the CVS for which we want to preserve the history?
>
> No, it's not. It will save you work if you can do as much splitting as
> possible during the conversion, ie. convert the bits you know will be
> separate separately (and combine them using submodules as appropriate).
>
> But if you have bits that will take a lot of work to factor out, you can
> convert to git, make the other code ready to use a submodule and than use
> git-filter-branch to extract the right bits of history for the submodule.
Thanks! git-filter-branch looks a bit overwhelming, but I think I can
manage :-) I'll do the simple things in separate conversions.
Cheers --- Jan
^ permalink raw reply
* Re: [PATCH] add simple install replacement
From: Robert Schiele @ 2007-10-12 15:07 UTC (permalink / raw)
To: Jan Hudec; +Cc: git, gitster
In-Reply-To: <20071012140647.GC7865@efreet.light.src>
[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]
On Fri, Oct 12, 2007 at 04:06:47PM +0200, Jan Hudec wrote:
> On Thu, Oct 11, 2007 at 23:52:37 +0200, Robert Schiele wrote:
> > This patch adds a very simple install replacement script to git.
> > This allows more easy installation on systems that don't have a
> > compatible install.
>
> Do you have a particular case where you need it?
We have some machines here where no compatible install was installed. Sure I
could have built GNU coreutils on all of them but writing this script was just
more convenient for me.
> No such thing here:
> zsh$ /bin/sh
> $ which getopts
> $
>
> Yes, bash and zsh do have that, but my (and I suspect many git users')
> /bin/sh is neither of those. Git scripts should use just POSIX shell
> features for portability.
I just used it because the shells on my machines had it. My idea was that if
someone has a shell with less features we could still replace parts with even
more basic ways of doing things.
> You may want to have a look at /usr/share/automake-1.9/install-sh (or
> /usr/share/automake<something>/install-sh). It shows how to portably process
> options in shell and since it's in fact covered by the MIT/X license (and FSF
> changes are public domain), git could just use it if necessary.
Oh, forgot about that implementation. Since this version is definitely more
advanced I retract my patch and propose to use that one instead.
> Are you sure reall install would do this? The maual (install(1)) states
> following usage variants:
>
> install [OPTION]... [-T] SOURCE DEST
> install [OPTION]... SOURCE... DIRECTORY
> install [OPTION]... -t DIRECTORY SOURCE...
> install [OPTION]... -d DIRECTORY...
I did not intend to write a full replacement for install but cover only the
cases needed to install git.
> Now however there is nothing saying that SOURCE... is at least two, so is
>
> install git /usr/bin
>
> a case of the first or second usage? I would say the second, but your code
> would:
>
> rm -rf /usr/bin
> cp git /usr/bin
No, in your example /usr/bin is a directory and thus this is:
rm -rf /usr/bin/git
cp git /usr/bin
> touch "foo*bar" "a b c"
> ./gitinstall "b*c" "a b c" /tmp
>
> ... will copy a lot of files to /tmp (presuming we are in git source
> directory, where tons of files are called builtin-<something>.c) and complain
> that there is no 'a', no 'b' and no 'c'.
There are no files with special characters in git to be installed. Again this
was meant a _simple_ replacement for install on systems without a compatible
install just to install _git_, not to reinvent the wheel.
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RCS keyword expansion
From: Barry Fishman @ 2007-10-12 17:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0710120726470.11771@perkele.intern.softwolves.pp.se>
Peter Karlsson <peter@softwolves.pp.se> writes:
> Yes, but not embedded in the page in a format that is visible to the
> visitor. For CVS I use something like this:
>
> <p class="date">$Date$</p>
>
> to embed the last update time into the page.
>
I guess everyone moving from CVS/SVN to Git faces rethinking of
what the RCS markers really mean in the context of their project.
In my case the identifier was just a away of seeing when the file was
last changed, and who did it. I decided this fit better as an editor
function, rather than a checkin function.
I changed my editor (Emacs) to convert RCS Ids to timestamps when I
opened a file for reading. This would fix old files. When i wrote out
files I would update the timestamp before writing them (via emacs's
timestamp package). I didn't have to think about it as my RCS Id
stamped files slowly evolve into my editor stamped ones. I'm sure I
could do something similar in VIM, or with a script encapsulating
another editor.
This actually worked out better for me. Now the timestamps were updated
even when I hadn't yet checked in the file. Since I test things before
checking them in, I did not have my file changed after testing by the
checkin process.
I could find the the commit assocated with the file fairly quickly using
"git log" and finding the commit for the file just after its timestamp.
--
Barry Fishman
^ permalink raw reply
* Re: git branch performance problem?
From: Salikh Zakirov @ 2007-10-12 17:32 UTC (permalink / raw)
To: hanwen; +Cc: Linus Torvalds, Lars Hjemli, git
Han-Wen Nienhuys wrote:
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
There exist a script contrib/workdir/git-new-workdir,
which creates a new working copy that literally shares the same object store.
It will share both object store and branches, so some care must be taken:
branch which checkout out in one shared working directory must never be
updated
(committed or pulled into) from the other shared working directory.
Said that, I personally find this trick very useful for browsing code
from different branch and quick bug fixing.
^ permalink raw reply
* Re: git branch performance problem?
From: Salikh Zakirov @ 2007-10-12 17:19 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Lars Hjemli, git
In-Reply-To: <f329bf540710101926vedf8b19p52e3eeb193203d03@mail.gmail.com>
Han-Wen Nienhuys wrote:
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
There exist a script contrib/workdir/git-new-workdir,
which creates a new working copy that literally shares the same object store.
It will share both object store and branches, so some care must be taken:
branch which checkout out in one shared working directory must never be updated
(committed or pulled into) from the other shared working directory.
Said that, I personally find this trick very useful for browsing alternate
branch code and quick bug fixing.
^ permalink raw reply
* Re: RCS keyword expansion
From: Linus Torvalds @ 2007-10-12 17:44 UTC (permalink / raw)
To: Barry Fishman; +Cc: git
In-Reply-To: <m3y7e8jmbm.fsf@barry_fishman.acm.org>
On Fri, 12 Oct 2007, Barry Fishman wrote:
>
> I changed my editor (Emacs) to convert RCS Ids to timestamps when I
> opened a file for reading. This would fix old files. When i wrote out
> files I would update the timestamp before writing them (via emacs's
> timestamp package). I didn't have to think about it as my RCS Id
> stamped files slowly evolve into my editor stamped ones. I'm sure I
> could do something similar in VIM, or with a script encapsulating
> another editor.
I think it might also be potentially interesting to make this just be a
pre-commit hook - although your point that doing it in the editor is to
some degree even nicer, because it also means that it shows up in diffs
even *before* you commit.
But if you want to explore the pre-commit hook approach, what it would
basically boild down to is that at that point you have a list of all files
that have changed, and then you could run some script on them to change
them even further.
I'm sure you'd find some problems with the approach, and I think it
absolutely sucks for merging (ie trivially you'll have all the merge
problems people *always* have with RCS Id's, and now you need to teach the
auto-merger to hide them from you), but it's probably better than trying
to do it at some "core level" (which screws up things like switching
branches etc).
Linus
^ permalink raw reply
* Re: RCS keyword expansion
From: Florian Weimer @ 2007-10-12 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <m3y7e8jmbm.fsf@barry_fishman.acm.org>
* Barry Fishman:
> I changed my editor (Emacs) to convert RCS Ids to timestamps when I
> opened a file for reading. This would fix old files. When i wrote out
> files I would update the timestamp before writing them (via emacs's
> timestamp package). I didn't have to think about it as my RCS Id
> stamped files slowly evolve into my editor stamped ones. I'm sure I
> could do something similar in VIM, or with a script encapsulating
> another editor.
The downside is that this causes totally unncessary conflicts when
merging. Maybe a custom merge handler could deal with that, though.
^ permalink raw reply
* Re: RCS keyword expansion
From: Salikh Zakirov @ 2007-10-12 19:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0710120723480.11771@perkele.intern.softwolves.pp.se>
Peter Karlsson wrote:
> But that's not what I want. Then my build procedure would need to do a
> "git status", or whatever you use to get the last commit information
> about a file, on each file that is changed and is to be installed. It
> would be a lot easier if that was done already on checkout through some
> kind of hook.
For what it's worth, I've made a small exercise on git scripting
(which I'm total newbie in), and tried to use filter mechanism
(smudge/clean) for solving the problem Peter stated.
Fundamental problems of this approach were discussed in full
on the mailing list, however, as I understand Peter's situation,
they do not apply, as the web site workspace is 'checkout-only',
and no actual work (commits) are made there.
Thus, it will not cause any merge problems etc.
Anyway, smudge/clean does not give the immediate solution to the problem
because of smaller technical shortcomings:
* smudge filter is not passed a name of file being checked out,
so it is not possible to exactly find the commit identifier.
However, this is alleviated by the fact that 'smudge' is only being run
for the changed files, so the last commit *is* the needed one.
* smudge filter is not passed a commit identifier. This is a bit more serious,
as this information is nowhere to get from otherwise. I tried to use 'HEAD'
value, but apparently it is not yet updated at the moment 'smudge' is being
run, so the files end up with the date of the "previous" commit rather than
the commit being checked out. "Previous" means the commit that was checked
out before. The problem gets worse if different branch is checkout out,
as the files get the timestamp of a previous branch.
AFAIR, lack of information in smudge filter was intentional, to discourage
this particular use of smudge/clean mechanism. However, I think this can be
reconsidered given the Peter's use case: "checkout-only" workspace for immediate
publishing to webserver. Alternatively, anyone interested in this use case
could implement additional smudge arguments as a site-local patch.
And then, there are small annoyances, which seems to be inevitable:
* if you change 'clean' filter and check out earlier revision, it will be
reported as having modifications (due to changed 'clean' definition).
Below is what I ended up with:
.gitattributes:
* filter=date
.git/config:
[filter "date"]
smudge = .git/smudge
clean = .git/clean
.git/clean:
#!/usr/bin/perl -p
s#\$Date[^\$]*\$#\$Date\$#;
.git/smudge:
#!/usr/bin/perl
use POSIX qw(strftime);
$branch = `git-symbolic-ref HEAD`; chomp($branch);
$rev = `git-rev-list -n 1 $branch`; chomp($rev);
open REV, "git show --pretty=raw $rev|";
$time = time; # default to current time
while (<REV>) {
if (/^committer.* (\d+) [\-+]\d*$/) {
$time = $1;
}
}
close REV;
$date = strftime "%Y-%m-%d %H:%M:%S", localtime($time);
while (<>) {
s#\$Date[^\$]*\$#\$Date: $date\$#;
print;
}
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Sam Vilain @ 2007-10-12 20:27 UTC (permalink / raw)
To: Eivind LM; +Cc: Jonathan del Strother, git
In-Reply-To: <op.tz28hnd2jwclfx@ichi>
Eivind LM wrote:
>>
>> git-svn init -t projectA/tags -b projectA/branches \
>> -T trunk/projectA http://svn.host.com/
>> git fetch
>
> With my paths this translates into
>
> $ git-svn init -b eivindlm/branches \
> -t eivindlm/tags \
> -T eivindlm/trunk/src/probesimulator \
> file:///svn-repo/
> , which prints the happy message:
> Initialized empty Git repository in .git/
>
> The next command is unfortunately not as happy:
> $ git fetch
> fatal: 'origin': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
> Cannot get the repository state from origin
>
> I suppose this is due to my silly svn-repo layout... However, after
> some trial and error it seems like the following command gives me what
> I want (I don't need tags or other branches than main):
Whoops, my mistake. That should have been "git svn fetch".
Sam.
^ 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