* Re: cvs2svn conversion directly to git ready for experimentation
From: Marko Macek @ 2007-08-02 19:22 UTC (permalink / raw)
To: Michael Haggerty, git, users, prohaska
In-Reply-To: <46B2132D.7090304@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Michael Haggerty wrote:
> This can definitely be caused by unlabeled branches. It can also be
> caused by branches rooted in a vendor branch. In many cases, such
> branches can actually be grafted onto trunk, but cvs2svn does not (yet)
> attempt this.
It would be nice to be able to exclude the vendor branch if only
the initial commit was made on it (or maybe handle it better, by
remapping the commits to the main branch when they match).
I have tested this on my repository and currently gitk draws
large 'railroad switching stations' because many tags have the
vendor branch as a parent (and in some cases also the parent branch,
in addition to the parent commit).
Mark
[-- Attachment #2: railroad.png --]
[-- Type: image/png, Size: 3828 bytes --]
[-- Attachment #3: Type: text/plain, Size: 193 bytes --]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cvs2svn.tigris.org
For additional commands, e-mail: users-help@cvs2svn.tigris.org
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Steffen Prohaska @ 2007-08-02 19:13 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Michael Haggerty, git, users
In-Reply-To: <46B215E2.8010307@fs.ei.tum.de>
Simon,
On Aug 2, 2007, at 7:35 PM, Simon 'corecode' Schubert wrote:
> Steffen Prohaska wrote:
>> fromcvs's togit surrendered during the import.
>> fromcvs's tohg accepted more of the history, but finally
>> surrendered as well.
>
> Which repo is it you are converting? Is this available somewhere?
Unfortunately not, the content is a proprietary software package.
> I'd appreciate any reports concerning "surrenders" of fromcvs.
> Additionally, it seems strange that tohg should have worked
> "better" than togit, as these are basically just different backends.
Some time passed since I did the tests. I had no time to do a
detailed investigation then. I'll have more time now and will
prepare a bug report, which is not easy because I can't sent you
the cvs repo, sorry. Any hints what would be most helpful for you?
I remember that togit reported a broken pipe. My feeling was
that git-fastimport aborted, which may be reason why tohg
worked better. I didn't try to understand more details. I never
read ruby code before and it was already a challenge for me to
get everything up and running (rcs, rbtree).
Steffen
^ permalink raw reply
* Re: minor makefile issues
From: David Kastrup @ 2007-08-02 19:00 UTC (permalink / raw)
To: Joe Eykholt; +Cc: git
In-Reply-To: <46B21CB9.9050303@nuovasystems.com>
Joe Eykholt <joe@nuovasystems.com> writes:
> Hi All,
>
> Due to my unusual environment, I ran into two issues when installing
> git 1.5.2.4 from source.
> Although these are unusual, they might not be unique and the fixes are easy:
>
> 1. The make install failed because of line 49 in templates/Makefile:
> (cd blt && $(TAR) cf - .) | \
> (cd '$(DESTDIR_SQ)$(template_dir_SQ)' && $(TAR) xf -)
> because I have CDPATH set, the 'cd blt' actually outputs the new
> directory on stdout
> which confuses the second tar. Changing this to 'cd ./blt' fixes
> it. Perhaps this could
> be considered a bash bug.
No, it is a user bug. You don't want a script to _ever_ walk around
on its own volition, so you must _not_ export CDPATH. Instead, set it
in .bashrc without exporting it. That way, it will be available with
every interactive shell, and not interfering with scripts.
> 2. My home directory containing my build tree is NFS-mounted, and
> root doesn't have any
> permission to write it. So, when doing 'make prefix=/usr/local
> install-doc' as root, I got these errors:
>
> # make prefix=/usr/local install-doc
> make -C Documentation install
> make[1]: Entering directory
> /net/da01/home/jre/build/git-1.5.2.4/Documentation'
> rm -f doc.dep+ doc.dep
> rm: cannot remove `doc.dep': Permission denied
> make[1]: *** [doc.dep] Error 1
> make[1]: Leaving directory
> /net/da01/home/jre/build/git-1.5.2.4/Documentation'
> make: *** [install-doc] Error 2
>
> I'm not sure what the best fix is for the second problem. rm -f
> ignores non-existent files but not permission errors.
> I guess you could do 'rm -f doc.dep || true'.
First do "make doc" for your normal user, then make doc-install as
root.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Jakub Narebski @ 2007-08-02 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Linus Torvalds, Git Mailing List
In-Reply-To: <200708020018.18610.jnareb@gmail.com>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > Perhaps if the destination is local,
> >
> > - if -s is given, just set up alternates, do nothing else;
> > - by default, do "always copy never hardlink";
> > - with -l, do "hardlink if possible";
> >
> > Hmmmm...
>
> That I think it is the best solution, together with support for
> file:///path/to/repo.git scheme which would turn on old repacking
> behavior. I'm all for it.
By the way, with "-l" you have hardlinks only till repack ("git gc"),
isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Jakub Narebski @ 2007-08-02 10:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzri1pfi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Personally, this late in the game, I would be more interested in
> resolving the File::Find() stuff, which has been a real issue in
> the field, than the compressed transfer one.
I posted my tentative Ack, haven't I?
I guess that your solution is good, and doesn't have any drawbacks,
besides perhaps a tiny little bit of lost performance. So I think
that you should just commit this...
As to the new stuff: I think I postpone large changes, like blob
size in tree view, or links to no merges and first parent
log/shortlog/history view, or list form of two pipelines we have in
gitweb, or HTML cleanup, etc. after the v1.5.3 release.
--
Jakub Narebski
Poland
^ permalink raw reply
* minor makefile issues
From: Joe Eykholt @ 2007-08-02 18:04 UTC (permalink / raw)
To: git
Hi All,
Due to my unusual environment, I ran into two issues when installing git
1.5.2.4 from source.
Although these are unusual, they might not be unique and the fixes are easy:
1. The make install failed because of line 49 in templates/Makefile:
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_dir_SQ)' && $(TAR) xf -)
because I have CDPATH set, the 'cd blt' actually outputs the new
directory on stdout
which confuses the second tar. Changing this to 'cd ./blt' fixes
it. Perhaps this could
be considered a bash bug.
2. My home directory containing my build tree is NFS-mounted, and
root doesn't have any
permission to write it. So, when doing 'make prefix=/usr/local
install-doc' as root, I got these errors:
# make prefix=/usr/local install-doc
make -C Documentation install
make[1]: Entering directory
`/net/da01/home/jre/build/git-1.5.2.4/Documentation'
rm -f doc.dep+ doc.dep
rm: cannot remove `doc.dep': Permission denied
make[1]: *** [doc.dep] Error 1
make[1]: Leaving directory
`/net/da01/home/jre/build/git-1.5.2.4/Documentation'
make: *** [install-doc] Error 2
I'm not sure what the best fix is for the second problem. rm -f ignores
non-existent files but not permission errors.
I guess you could do 'rm -f doc.dep || true'.
No response necessary. Just thought you might like to know about
these. Otherwise, git seems nice!
Thanks,
Joe Eykholt
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-02 18:18 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11858118802945-git-send-email-prohaska@zib.de>
On Mon, Jul 30, 2007 at 06:11:20PM +0200, Steffen Prohaska wrote:
> git gui is especially useful because it allows to select diff hunks.
> Now it is at least mentioned in the user-manual.
Hm, OK. I think the user manual's only departures from the commandline
right now are a few mentions of gitk (which don't actually explain how
to use it; I assume that's self-explanatory).
But this seems interesting enough to be worth a mention, thanks.
> +Another approach for creating commits is git gui:
> +
> +-------------------------------------------------
> +$ git gui citool
> +-------------------------------------------------
> +
> +starts the commit tool (Note, "`git gui`" starts the full gui, which
> +provides more options).
> +
> +Beyond the basic operation of staging and unstaging complete files,
> +git gui can also selectively stage diff hunks. You can do so by
> +selecting a modified or staged file and right-click on the diff view
> +in the lower part of the gui. A pop-up will appear that lets you
> +select a specific hunk and stage or unstage it for the next commit.
> +This is particular useful for slicing large, ugly commits into smaller
> +pieces, for example when cherry-picking (see
> +<<reordering-patch-series>>).
I wonder whether we could get away with just the brief list of features
("lets you view changes in the index and the working file, lets you
individually select diff hunks for inclusion in the index"), and leave
the how-to stuff to online guit-gui help, if it's necessary?
Also, I like the verb "stage" as a way to explain the part of the index
file in creating commits, but I've been consistently using the word
"index" throughout the user manual, and I think that's consistent with
the rest of the documentation--so don't avoid it here.
--b.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Sam Ravnborg @ 2007-08-02 18:13 UTC (permalink / raw)
To: Bradford Smith; +Cc: David Kastrup, git
In-Reply-To: <f158199e0708020748o5cac4505ic76bfb39f25ab1f8@mail.gmail.com>
>
> Obviously, you aren't too concerned about 1 (the cost to you), because
> you're willing to do that work. However, if I were Junio, I wouldn't
> be willing to "spend" costs 2 and 3 on a patch that didn't either fix
> a problem or provide a new feature.
For any decent codebase there is a need to keep the code clean.
Being part of the linux-kernel community we see clean-up patches
each day and a lot are applied.
Even spelling errors in comments are sometimes applied.
Do not underestimate the value of a clean codebase.
Sam
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Ramsay Jones @ 2007-08-02 18:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Are you suggesting to make -l the default for local, in other
> words? I personally do not make local clone often enough that I
> am not disturbed having to type extra " -l" on the command line.
>
> But giving a way to force "copy not hardlink" while still
> avoiding "the same as the networked case by doing pack transfer"
> overhead may be a good thing to do.
>
> Perhaps if the destination is local,
>
> - if -s is given, just set up alternates, do nothing else;
> - by default, do "always copy never hardlink";
> - with -l, do "hardlink if possible";
>
> Hmmmm...
>
About six weeks ago, I finally got around to installing Linux (ubuntu 7.04)
on my laptop. Naturally, I cloned my sparse and git repositories over from
the Windows XP partition. Unfortunately, that left me with a sparse repo that
I could not modify; during the clone cpio copied the object directory, with
perhaps a little too much fidelity, which resulted in a .git/objects tree
with 555 permissions (both files and directories). [It also set the file
timestamps with utime(), BTW]. A quick chmod fixed it up without problem,
but still ...
When I cloned the git repo, however, I forgot the -l parameter and git-clone
effectively did a "git-fetch-pack --all -k $repo", leaving me with a
working, and fully repacked, repository. Nice.
So, I was about to suggest that when invoked with -l, if the object database
cannot be linked, due to EXDEV for example, it should fall back to the
"fetch-pack" behaviour. Since I don't have access to a large repo, I can't
compare the filesystem-copy time versus the fetch-pack time for a "realistic"
repo, but I suppose the copy would always be faster. Oh Well.
Just a data point.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Add a --user option to git-config
From: Ramsay Jones @ 2007-08-02 17:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <Pine.LNX.4.64.0708011913070.14781@racer.site>
Johannes Schindelin wrote:
>> Yep, which is why I made it a synonym; git-gui uses the --global option, for
>> example, and I'm confident that other (user) scripts use it too. The "future"
>> I had in mind was something like 1 year down the road, but it could be longer
>> (or forever) if necessary.
>
> Please read my reply as "I vote against ever removing the --global
> option".
>
OK.
Ramsay Jones
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: J. Bruce Fields @ 2007-08-02 17:58 UTC (permalink / raw)
To: Johannes Schindelin, Steven Grimm, Jean-François Veillette
In-Reply-To: <vpqtzrivt2n.fsf@bauges.imag.fr>
On Thu, Aug 02, 2007 at 05:45:20PM +0200, Matthieu Moy wrote:
> Depending on the kind of things I'm doing, I usually run status
> regularly, because it's short to read, and it shows me both staged and
> unstaged changes. git-status tells me if I did something obviously
> totally wrong (changing a file on which I was not working, deleting
> something important ...), and after that, git-diff gives me a
> finer-grained vision of what I did.
Yeah, ditto for me. When I return to a project after having been away a
few minutes, the first things I do are
git branch # remind me which topic I was working on
git status # remind me if I was in the middle of something.
So I end up running it a lot. I only do a git-diff if I need some
details.
--b.
^ permalink raw reply
* Re: Git clone error
From: Linus Torvalds @ 2007-08-02 17:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Denis Bueno, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708021806510.14781@racer.site>
On Thu, 2 Aug 2007, Johannes Schindelin wrote:
>
> Ah no. Linus diagnosed that this blob is your condor-uninstall script in
> your initial commit.
Well, I'm not sure the commit was the initial one, but it was the one that
*introduced* that file. It *may* be the initial one, of course (and quite
likely is, for an import), but..
Linus
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Simon 'corecode' Schubert @ 2007-08-02 17:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Michael Haggerty, git, users
In-Reply-To: <65F1862F-4DF2-4A52-9FD5-20802AEACDAB@zib.de>
Steffen Prohaska wrote:
> fromcvs's togit surrendered during the import.
> fromcvs's tohg accepted more of the history, but finally
> surrendered as well.
Which repo is it you are converting? Is this available somewhere?
I'd appreciate any reports concerning "surrenders" of fromcvs. Additionally, it seems strange that tohg should have worked "better" than togit, as these are basically just different backends.
cheers
simon
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 17:23 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, users
In-Reply-To: <65F1862F-4DF2-4A52-9FD5-20802AEACDAB@zib.de>
Steffen Prohaska wrote:
> On Aug 1, 2007, at 2:09 AM, Michael Haggerty wrote:
>> I am looking forward to your feedback. Even better would be if somebody
>> wants to join forces on this project. I would be happy to supply the
>> cvs2svn knowledge if you can bring the git experience.
>
> I tried it with revision trunk@3930 of cvs2svn. The results are as follows.
Thanks for the feedback!
> cvs2svn created a lot of branches that are not present in CVS,
> with names identical to CVS tags. Apparently these branches are
> used to create a commit matching a certain CVS tag.
That is correct. This is something that I plan to work on, at least for
tags that can be created from a single source commit.
> The branching structure looks, ... hmm ..., interesting. cvs2svn
> manufactured commits to get the branching points right.
> Apparently our CVS has some weired commits like 'unlabeled-1.1.1'
> and two other named tags (maybe vendor branches?) that cause
> these manufactured commits. In gitk I see long lines running
> parallel to the cvs trunk all down to these weired CVS tags. They
> are not very useful, altough they might be correct. Note,
> parsecvs imports our repository without such basically useless
> links. However, I can't verify if parsecvs gets something wrong.
Branches with names like "unlabeled-1.1.1" come from CVS branches for
which the revisions are still contained in the RCS files but for which
the branch name has been deleted. These wreak havoc on cvs2svn's
attempt to find simple branch sources and cause a proliferation of
basically useless branches. The main problem is that cvs2svn does not
attempt to figure out that "unlabeled-1.2.4" in one file might be the
same as "unlabeled-1.2.6" in another etc.
An "unlabeled-1.1.1", in particular, means that the branch whose name
was deleted was a vendor branch. The deletion of a vendor branch name
can cause even more mayhem.
In most cases it makes sense to exclude the unlabeled branches. After
all, somebody tried to delete them, so they can't be that important,
right? Use --exclude='unlabeled-.*', or add a line like this to your
options file:
ctx.symbol_strategy.add_rule(ExcludeRegexpStrategyRule(r'unlabeled-.*'))
. This can of course cause problems if other branches or tags were
created that branched off of the unlabeled branch. In such cases the
dependent branches/tags might have to be excluded too.
> Other branches are created over a couple of commits mixing in
> several branches (maybe again our weired commits already
> mentioned). See branching1.png, branching2.png, branching3.png.
> [ I have to apologize, our cvs repository contains proprietary
> information, so I can't publish it's history freely. ]
This can definitely be caused by unlabeled branches. It can also be
caused by branches rooted in a vendor branch. In many cases, such
branches can actually be grafted onto trunk, but cvs2svn does not (yet)
attempt this.
> cvs2svn is the first tool besided parsecvs that worked for me,
> that is imported the whole repository, passed the basic test of
> matching checkouts from cvs and git, and got the one suspicious
> commit right that I'm using for verifying the branching points.
>
> [ I have no time to go into the details of all these tests.
> Therefore only a very short summary:
> All tools needed basic cleanup of a few corrupted ,v files and
> ,v files that were duplicated in Attic.
> git-cvsimport fails to create branches at the right commit.
> fromcvs's togit surrendered during the import.
> fromcvs's tohg accepted more of the history, but finally
> surrendered as well.
> parsecvs works for me (crashes on corrupted ,v files).
> cvs2svn followed by git-svnimport create wrong state at the
> tips of branches.
> cvs2svn direct git import works for me (reports corrupted ,v files).
> ]
Thanks very much for this interesting summary.
> Right now, I'd prefer the import by parsecvs because of the
> simpler history. However, I don't know if I loose history
> information by doing so. I'd start by a run of cvs2svn to validate
> the overall structure of the CVS repository. Dealing with corruption
> in the CVS repository seems to be superior in cvs2svn. It reports
> errors when parsecvs just crashes.
If excluding the unlabeled branches does not fix things for you, I
suggest checking out the first revision on such a branch, and comparing
the results from CVS, from parsecvs, and from cvs2svn. It *should* be
that the version of the file from the vendor branch is included in the
working copy. cvs2svn should handle this correctly. I am curious
whether parsecvs does.
Michael
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 17:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708021804090.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Thu, Aug 02, 2007 at 06:05:00PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Aug 2007, Robert Schiele wrote:
>
> > On Thu, Aug 02, 2007 at 04:20:44PM +0200, David Kastrup wrote:
> > > Sigh. It's in Posix.
> >
> > It is in latest POSIX but latest POSIX is not in Solaris.
>
> It has been a really long standing tradition in git development to not
> care about POSIX if it disagrees with reality. A good tradition.
Sure. I mean if Solaris was really a system nobody uses nowadays there would
be no reason to care about it but it actually still is one of the mayor
platforms availlable and thus not supporting it would be quite stupid.
It would actually draw away my interest (and most likely the one of many
others) from git since I need a system that works on _all_ systems we support.
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: multiple checked out branches
From: Guilhem Bonnefille @ 2007-08-02 17:16 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20070802000217.GA20018@raptus.dandreoli.com>
On 8/2/07, Domenico Andreoli <cavokz@gmail.com> wrote:
> On Wed, Aug 01, 2007 at 11:19:25PM +0100, Julian Phillips wrote:
> The actual problem is that switching form a branch to another makes
> my autotools fuck and I have to rebuild stuff all the time. My box is
> still a faint-hearted single core...
I encounter same problem. Actually, I did full rebuild every time
(which is counter-productive). But, reading at your mail, I have an
other idea: what about the "remote" compilation offered by autotools?
Normally, autotools are design in such way that you can share the same
source for different configuration. To do this, simply create one
"build" directory per branch, go to this directory and do:
../configure && make
I'm unable to try it now, so I express now all my "confuses" if it was
a bad idea.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: Git clone error
From: Johannes Schindelin @ 2007-08-02 17:08 UTC (permalink / raw)
To: Denis Bueno; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <C2D74FA8.2C06%denbuen@sandia.gov>
Hi,
On Thu, 2 Aug 2007, Denis Bueno wrote:
> On 08/01/2007 15:12, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> wrote:
> >> How difficult would it be to create a new git repo which is exactly the same
> >> minus the initial condor-uninstall.sh commit? That is, just to pretend the
> >> initial import of condor-uninstall.sh never existed, and use the second
> >> commit of the old repo the first commit of the new, and preserve the rest of
> >> the history of the entire repo?
> >
> > That would be even easier. Just graft "nothingness" as parent of the
> > second commit:
> >
> > $ git rev-parse <second-commit> >> .git/info/grafts
>
> I must be misunderstanding:
>
> scripts[] > git fsck --full
> error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or
> missing
> missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429
>
> # b2... should fill in your <second-commit>?
Ah no. Linus diagnosed that this blob is your condor-uninstall script in
your initial commit. You should be able to get at it by calling "git log
--root" and taking the last commit. Just to make sure, "git show
<first-commit>:bla/condor-uninstall.sh" should fail miserably, mentioning
a corrupt blob.
The second commit I was referring to is the second last commit in the "git
log --root" output.
Hth,
Dscho
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Johannes Schindelin @ 2007-08-02 17:05 UTC (permalink / raw)
To: Robert Schiele; +Cc: git
In-Reply-To: <20070802161902.GP29424@schiele.dyndns.org>
Hi,
On Thu, 2 Aug 2007, Robert Schiele wrote:
> On Thu, Aug 02, 2007 at 04:20:44PM +0200, David Kastrup wrote:
> > Sigh. It's in Posix.
>
> It is in latest POSIX but latest POSIX is not in Solaris.
It has been a really long standing tradition in git development to not
care about POSIX if it disagrees with reality. A good tradition.
Ciao,
Dscho
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 16:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f8r09t$qdg$1@sea.gmane.org>
Jakub Narebski wrote:
> Michael Haggerty wrote:
> Have you contacted Jon Smirl about his unpublished work on cvs2git,
> cvs2svn based CVS to Git converter?
Yes, I am familiar with Jon Smirl's work, and as soon as he let us know
what he was working on, we tried to help. Unfortunately the cooperation
was not very fruitful.
- While Jon was (unknown to us) working on his git output patch, I was
working on a big cvs2svn rewrite to make cvs2svn more robust and easier
to hack. By the time he contacted us, his patch did not apply to the
cvs2svn code. The refactoring that obsoleted the patch, in fact, was
largely to remedy the very same architectural problems that were
hampering his work.
- In my opinion, Jon misdiagnosed the reason for the "fragmented branch
creation" problem that he claimed was preventing a clean conversion to
git, and he felt that we were not interested in fixing the problem. In
fact, I was working on fixing another problem that I believe was the
*real* reason for the fragmented branch creation. This fix is
implemented in cvs2svn version 2.0.
> Footnotes:
> ----------
> [*] If I remember correctly authors of cvs2svn were talking about separating
> the code dealing with disentangling CVS repository structure from the part
> translating it into Subversion repository (with its quirks), and the part
> generating Subversion repository.
Yes, this is now done, which was why it was only a couple of days of
programming for me to add a git output option.
Michael
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 16:19 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl72j9vn.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Thu, Aug 02, 2007 at 04:20:44PM +0200, David Kastrup wrote:
> Sigh. It's in Posix.
It is in latest POSIX but latest POSIX is not in Solaris.
> I've seen a lot of "modern" constructs in the Shell scripts of git
> (not least of all the eval hackery that is currently used instead of
> this), so do you actually have positive knowledge that the existing
> git stuff runs fine on such systems, and this wouldn't?
I can't say for sure for every corner case but for the most important stuff
the answer is "yes". If you have specific doubts about some construct you may
ask me for that. Then I would check.
> I don't have access to Solaris systems, so I have to take your word on
> it, but I find it somewhat surprising that they would not follow Posix
> here.
Nowadays you can download it for free if you like to test with it.
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
* [PATCH] the ar tool is called gar on some systems
From: Robert Schiele @ 2007-08-02 16:15 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Some systems that have only installed the GNU toolchain (prefixed with "g")
do not provide "ar" but only "gar". Make configure find this tool as well.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
This is another trivial configure patch. If you don't want to include it in
the upcomming release it is fine for me to delay it. If you expect me to
resubmit after the release, drop me a note.
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 84fd7f1..ed7cc89 100644
--- a/configure.ac
+++ b/configure.ac
@@ -104,7 +104,7 @@ AC_MSG_NOTICE([CHECKS for programs])
#
AC_PROG_CC([cc gcc])
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
-AC_CHECK_TOOL(AR, ar, :)
+AC_CHECK_TOOLS(AR, [gar ar], :)
AC_CHECK_PROGS(TAR, [gtar tar])
# TCLTK_PATH will be set to some value if we want Tcl/Tk
# or will be empty otherwise.
--
1.5.2.3
^ permalink raw reply related
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 15:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steven Grimm, Jean-François Veillette, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021614420.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, I'll answer just this one, instead of pointing you to the thread
> that I've been pointing to twice now
The link was probably not the right one since I saw only two [PATCH]
message, but yes, I remember a thread pointing out why git-status had
to update the index. I'm not arguing against that, I'm happy with the
current git-status behavior, but I find the git-diff one inconsistant
with git-status, and still don't understand any reason why a normal
user would want a difference.
> When is the time to say "git status"?
>
> It is just before committing. I.e when you really think that you're done
> editing, and want to have the end picture. "git status" only gives you
> names, and therefore it _has_ to update the index if it got out of sync,
> to show meaningful results.
>
> When is the time to say "git diff"?
>
> Much more often. In the middle of your work. And there it would be
> _disruptive_ if it updated the index all the time, especially if you have
> a quite large working tree.
That's your point of view, but I do not share it. Depending on the
kind of things I'm doing, I usually run status regularly, because it's
short to read, and it shows me both staged and unstaged changes.
git-status tells me if I did something obviously totally wrong
(changing a file on which I was not working, deleting something
important ...), and after that, git-diff gives me a finer-grained
vision of what I did.
Does this really sound so much irreasonable to you?
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Handle the errors from chdir in set_work_tree
From: Johannes Schindelin @ 2007-08-02 15:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <81b0412b0708020827p174515b7tc05fefde77f7d7c4@mail.gmail.com>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
> These I haven't seen yet. Wouldn't like such a surprise though.
> Also unstatic rel, it seems to be declared static accidentally.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix set_work_tree on cygwin
From: Johannes Schindelin @ 2007-08-02 15:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <81b0412b0708020825q4b64c47r3fa1d67858271b1e@mail.gmail.com>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
>@@ -209,7 +209,8 @@ const char *set_work_tree(const char *dir)
> len = strlen(dir);
> if (len > postfix_len && !strcmp(dir + len - postfix_len,
> "/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
>- strncpy(dir_buffer, dir, len - postfix_len);
>+ strncpy(dir_buffer, dir, len - postfix_len);
>+ dir_buffer[len - postfix_len] = '\0';
>
> /* are we inside the default work tree? */
> rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
Darn, darn, darn. strncpy does _not_ NUL terminate. I keep forgetting
that.
Better use strlcpy()?
Ciao,
Dscho
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 15:34 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git, users
In-Reply-To: <8b65902a0708010438s24d16109k601b52c04cf9c066@mail.gmail.com>
[I am CCing this response to the mailing lists.]
Guilhem Bonnefille wrote:
> On 8/1/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> I am the maintainer of cvs2svn[1], which is a program for one-time
>> conversions from CVS to Subversion. cvs2svn is very robust against the
>> many peculiarities of CVS and can convert just about every CVS
>> repository we have ever seen.
>
> What are the differences with cvsps ( http://www.cobite.com/cvsps/ )?
I'm not extremely familiar with cvsps, and I don't really want to get
into a "my-tool-is-better-than-your-tool" kind of argument. Instead I
will mention that the goals of the two projects are somewhat different:
cvs2svn is meant for one-time conversions from CVS, and therefore aims
for maximum conversion accuracy, robustness even in the presence of some
kinds of CVS repository corruption, intelligent translation of CVS
idioms to the idioms of a modern SCM, and scalability to large
repositories (by using on-disk databases instead of RAM for intermediate
data). Conversion speed is not a primary goal of cvs2svn, and
incremental conversions are not supported at all. cvs2svn requires
filesystem access to the CVS repository (it parses the RCS files directly).
cvsps is not a conversion tool at all, though it is used by other
conversion tools to generate the changesets. It appears (I hope I am
not misinterpreting things) to emphasize speed and incremental
operation, for example attempting to make changesets consistent from one
run to the next, even if the CVS repository has been changed prudently
between runs. cvsps does not appear to attempt to create atomic branch
and tag creation commits or handle CVS's special vendorbranch behavior.
cvsps operates via the CVS protocol; you don't need filesystem access
to the CVS repository.
I can also point you to a list of cvs2svn features, which includes a
list of some of the CVS quirks that it knows how to handle:
http://cvs2svn.tigris.org/cvs2svn.html#features
cvs2svn includes a large suite of perverse CVS repositories that we use
for testing. Many of them are derived from real-life CVS repositories
that people have had problems with. It would be very interesting to see
how other conversion tools handle these repositories, but I don't expect
to have time to do so in the near future.
Michael
^ 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