remove git svn from installer?
Steffen Prohaska
personally.
I see two options:
1) Remove git svn from the installer. git svn would still be
available to
those who compile from source and those could fix the problems
they find.
2) Someone steps forward and takes responsibility for git svn. He
should
test (and fix) git svn before I create a release. I plan to
continue
creating releases soon after Junio's releases, so it's obvious
what the
schedule is.
Opinions?
Steffen
Marius Storm-Olsen
I think that, if git-svn doesn't work when setting
core.autocrlf=false, then we should drop it from the installer until
it has been fixed. If it *does* work, then we could just add a simple
fix to git-svn and keep it.
Obviously, git-svn should be fixed at the core though, so that you can
continue to develop on Windows with core.autocrlf=true; which is
really the only natural choice. (No Dscho, don't bite! ;-D)
--
.marius
Johannes Schindelin
On Thu, 26 Jun 2008, Steffen Prohaska wrote:
> git svn in msysgit seems to be broken and I do not plan to fix it
> personally.
It is unfortunate, that I put so much time and efforrt into it, only to
have something that is not working.
However, I simply have no incentive to work on that beast, so I say:
scratch it.
I would not even have a problem removing it from 4msysgit, if only to
punish the people taking the fun out of msysgit for me.
As for the msys-1.0.dll problem: I could imagine that the dll has to be
run through the "rebase" tool. See 523934a1(Add 'rebase', a tool to avoid
memory range clashes in .dll files) on the "full" branch.
You _might_ want to add a recipe (AKA release.sh) to build msys-1.0.dll to
the "msys" branch. This would make it easier for others to help (okay,
that is a bad joke, or morbid humor on my part, or both).
Ciao,
Dscho
Steffen Prohaska
On Jun 26, 2008, at 1:03 PM, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Jun 2008, Steffen Prohaska wrote:
>
>> git svn in msysgit seems to be broken and I do not plan to fix it
>> personally.
>
> It is unfortunate, that I put so much time and efforrt into it, only
> to
> have something that is not working.
>
> However, I simply have no incentive to work on that beast, so I say:
> scratch it.
>
> I would not even have a problem removing it from 4msysgit, if only to
> punish the people taking the fun out of msysgit for me.
I think we should leave it there and ask people to build git from
source if they like to use git svn.
> As for the msys-1.0.dll problem: I could imagine that the dll has to
> be
> run through the "rebase" tool. See 523934a1(Add 'rebase', a tool to
> avoid
> memory range clashes in .dll files) on the "full" branch.
First I'll try the patch that Cesar Strauss send to the list, see
http://article.gmane.org/gmane.comp.version-control.msysgit/2457
> You _might_ want to add a recipe (AKA release.sh) to build
> msys-1.0.dll to
> the "msys" branch. This would make it easier for others to help
> (okay,
> that is a bad joke, or morbid humor on my part, or both).
I'll see what I can do.
Steffen
Mark
git svn in msysgit seems to be broken and I do not plan to fix it personally.
I see two options:
1) Remove git svn from the installer. git svn would still be available to
those who compile from source and those could fix the problems they find.
I am just a user so I don't know just how important my input is but I would rather see it left in even as is. I use it and msysGit it just starting to get a little wider audience as witnessed by this blog posting which shows a work in progress on getting msysGit to work with CodePlex - which uses MS Team Foundation Server as the back end. http://www.ayende.com/Blog/archive/2008/06/26/Git-to-CodePlex.aspx
Thanks
-mark
Edward Z. Yang
I did some check-ups on git-svn, and actually there is no bug. Consider
the following repos:
Filename SVN Property Actual eol style
----------------------------------------------------------------
explicit-crlf.txt svn:eol-style=CRLF CRLF
explicit-lf.txt svn:eol-style=LF LF
implicit-crlf.txt (no prop) CRLF
implicit-lf.txt (no prop) LF
native.txt svn:eol-style=native CRLF/LF (CRLF for me)
I fetched this repository using git svn and then inspected the contents
of the checked out files, as well as what git status said.
As previously reported, the CRLF files, explicit-crlf.txt and
implicit-crlf.txt had "changes" (even from a clean checkout). However,
what I found interesting was the LF file, as well as the native file
(SVN equivalent of core.autocrlf).
I think this is proper behavior, and is identical behavior to Unix
systems. A bug would have been if native had been converted to CRLF, but
the internal repository format of those files is LF, which prevents
problems with core.autocrlf.
What is happening with the CRLF files is that they are being transferred
from Subversion to Git as CRLF, and thus are represented inside the Git
repository as CRLF. There is no way to losslessly checkout these files
with core.autocrlf on (as we will see later, there is a workaround),
because when Git commits them, it removes the CRLF and replaces it with
LF. Thus the errors.
For text files, I would argue that this is the *correct* behavior. They
should not have CRLF inside the repository, instead, Git, on checkout,
should convert if the platform is Windows. For files that must always be
CRLF, such as *.bat files, gitattributes can be used to set autocrlf on
a file-by-file (or, more probably, a glob-by-glob) for these files.
However, anything else should be stored as LF.
In short, I think it's a problem with improper line-endings in the
Subversion repository, and Git's just cleaning things up. There is no bug.
That being said, I do believe there are obvious areas we can improve.
However, the most important right now is informing users about the way
git-svn handles SVN repositories with CRLF files in them, and why they
need to either:
1. Make a mass commit for CRLF -> LF
2. Turn off core.autocrlf
3. Set all files that have problems to crlf=true with gitattributes
One last note; git gui and gitk seem to be a little flaky when it comes
to CRLF; I frequently have git and these tools disagreeing about the
working copy state. Further investigation is necessary.
Cheers,
Edward
Johannes Schindelin
On Thu, 26 Jun 2008, Mark wrote:
> On Thu, Jun 26, 2008 at 2:16 AM, Steffen Prohaska <proh...@zib.de> wrote:
>
> > git svn in msysgit seems to be broken and I do not plan to fix it
> > personally.
> >
> > I see two options:
> >
> > 1) Remove git svn from the installer. git svn would still be
> > available to those who compile from source and those could fix the
> > problems they find.
>
> I am just a user so I don't know just how important my input is but I
> would rather see it left in even as is.
That is not good enough.
If more than half the users have problems, it is not distribution-worthy.
If there is nobody to fix it, it needs pulling.
'nuff said,
Dscho
P.S.: Steffen, feel free to beat me to pulling the plug.
Peter Harris
I would like to be able to take option 2, but my schedule won't let me
commit to any particular time-frame. So I guess I'm suggesting option
1 in the short term.
Peter Harris
(who was going to look at git-svn earlier in the week, but got
distracted by the whole "msys CVS is a year out of date" thing)
Cesar Strauss
[...]
> (who was going to look at git-svn earlier in the week, but got
> distracted by the whole "msys CVS is a year out of date" thing)
date in the future.
I took a look myself at git-svn, and this is what I found out:
The problem is in path translation. Or, rather, the lack of it.
For instance, try something like this:
$ touch /tmp/mf8vpEaKoj
$ git hash-object -w /tmp/mf8vpEaKoj
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
git doesn't know where /tmp really is (it is actually C:\Documents and
Settings\...\Temp). Fortunately, path translation kicks in, and all is
well.
Now, the current implementation of "hash_and_insert_object" in Git.pm
works with pipes, like this:
$ echo /tmp/mf8vpEaKoj | git hash-object -w --stdin-paths
fatal: Unable to hash /tmp/mf8vpEaKoj
The file name is passed by stdin, but MSYS only translates paths on
the command line. The path is passed on untranslated.
One workaround would be to create the temporary file in the current
directory, avoiding the need for path translation.
Other than that, git svn clone and git svn dcommit seem to work fine.
I will try to come up with a patch.
Regards,
Cesar
Johannes Schindelin
On Thu, 26 Jun 2008, Cesar Strauss wrote:
> Now, the current implementation of "hash_and_insert_object" in Git.pm
> works with pipes, like this:
>
> $ echo /tmp/mf8vpEaKoj | git hash-object -w --stdin-paths
> fatal: Unable to hash /tmp/mf8vpEaKoj
>
> The file name is passed by stdin, but MSYS only translates paths on
> the command line. The path is passed on untranslated.
>
> One workaround would be to create the temporary file in the current
> directory, avoiding the need for path translation.
The thing is: we purposefully used MSys Perl (actually, we built our own
version of it, to be able to include SVN modules), so that the path
translation would kick in also in Perl.
> Other than that, git svn clone and git svn dcommit seem to work fine.
> I will try to come up with a patch.
Maybe we will have to come up with a MinGW Perl including SVN modules,
which might be trickier than with MSys Perl. But then, it might be
easier, as SVN uses Apache's compatibility layer for things like fork().
This might also make git-svn faster, although I would not bet on that.
But by "we" I mean those people who are personally interested in git-svn
on msysGit, but haven't done a single thing for msysGit yet.
I certainly do not mean people like you, who have contributed so much by
giving us the best possible start, MSys/MinGW.
Thanks,
Dscho
Edward Z. Yang
> I did some check-ups on git-svn, and actually there is no bug. Consider
> the following repos:
Hello, does anyone have any comments on this message? Thanks.
Clifford Caoile
On Fri, Jun 27, 2008 at 5:13 AM, Edward Z. Yang
<edwar...@thewritingpot.com> wrote:
>
> Hello all,
>
> I did some check-ups on git-svn, and actually there is no bug.
Thanks for this study. You should forward it to the upstream mailing
list for further comments, because this issue is not just a
Windows-only concern.
> What is happening with the CRLF files is that they are being transferred
> from Subversion to Git as CRLF, and thus are represented inside the Git
> repository as CRLF.
> ...
> In short, I think it's a problem with improper line-endings in the
> Subversion repository, and Git's just cleaning things up. There is no bug.
I do not agree that there is no bug. According to your findings, the
problem is in git-svn.perl, when converting from a non-LF only svn to
a git repo. git-svn should take into account this wider semantics. It
should save in some way the non-LF status of the imported file(s)
while converting them to LF only for the git repo. Then when
reintegrating git-side changes back to the upstream svn repo like in
git svn dcommit, it should conditionally consider the saved non-LF
status. I have not considered the case where the user on the git-side
wants to change line endings explicitly.
For git-svn to automatically convert all text files to LF, like
implicit-crlf.txt, git-svn will need the text file auto-evaluator
functionality that is present in some other facet of git.
I think the more fundamental problem is that git tools are implicitly
implemented as LF-only, or without checking the CRLF case. As long as
this design decision (indecision?) is not fixed, this fundamental
problem will be pushed to the edges like git-svn (and as you mention,
git gui and gitk).
> As previously reported, the CRLF files, explicit-crlf.txt and
> implicit-crlf.txt had "changes" (even from a clean checkout).
This is wierd. Of course you are talking about "core.autocrlf = true".
Inside the git repo, these files are still CRLF but after a clean
checkout, the resulting git status is "modified"?!?! I did a
simplified test myself (see attachment ./crlf-test.sh) without git-svn
using git 1.5.5-GIT on Ubuntu and the results confirm it.
Ubuntu-git> ./crlf-test.sh
#### created a repo with a CRLF file, core.autocrlf = false
#### clone the repo with core.autocrlf false
#### clone the repo with core.autocrlf true
#### checked out files are the same via md5sum
5fb0817dd3d5802b05a7a2d7142b354e cloned/crlf.txt
5fb0817dd3d5802b05a7a2d7142b354e cloned-autocrlf/crlf.txt
#### However git status shows modified on core.autocrlf=true
# On branch master
nothing to commit (working directory clean)
----
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: crlf.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
#### compare git ls-tree master (original tree object)
100644 blob ea0584cfe09ad03141721109a52da3a13622cd1e crlf.txt
----
100644 blob ea0584cfe09ad03141721109a52da3a13622cd1e crlf.txt
#### compare git ls-files --stage (index and working tree)
100644 ea0584cfe09ad03141721109a52da3a13622cd1e 0 crlf.txt
----
100644 ea0584cfe09ad03141721109a52da3a13622cd1e 0 crlf.txt
#### compare git hash-object, shows different hash
ea0584cfe09ad03141721109a52da3a13622cd1e
----
20aeba2bad864cf6904f9caaea55f46f03ce6ac1
#### reverted to core.autocrlf=false
ea0584cfe09ad03141721109a52da3a13622cd1e
I don't understand what git-status is actually doing to determine the
"modified" status, but if it is checking the hash-object of each
tracked file, then it makes sense.
Also, I wonder if "created a repo with a CRLF file, core.autocrlf =
false" is contrived for regular Unix-based git usage. Do
multi-platform projects that use git actually prepare their repos with
CRLF measures such as gitattributes? What is the necessary
housekeeping for multi-platform projects when using git?
> However, the most important right now is informing users about the way
> git-svn handles SVN repositories with CRLF files in them, and why they need
> to either:
>
> 1. Make a mass commit for CRLF -> LF
> 2. Turn off core.autocrlf
> 3. Set all files that have problems to crlf=true with gitattributes
1. Haha, good luck trying to educate the svn user for this issue. ;-)
In other words, this is not feasible, given the myriad of ways git-svn
is being used.
2. Not the optimal solution but it's the easiest workaround to come to
mind, since git-svn.perl really isn't core.autocrlf-aware.
3. "all files that have problems" == text files with CRLF? Could we do
this automatically during the git svn clone or git svn fetch phase? Or
are you suggesting SVN users create a .gitattributes file on the svn
side just in case they use git svn?
Best regards,
Clifford Caoile
Steffen Prohaska
On Jun 30, 2008, at 1:48 PM, Clifford Caoile wrote:
> Also, I wonder if "created a repo with a CRLF file, core.autocrlf =
> false" is contrived for regular Unix-based git usage. Do
> multi-platform projects that use git actually prepare their repos with
> CRLF measures such as gitattributes? What is the necessary
> housekeeping for multi-platform projects when using git?
Git can do the housekeeping for you. You should set
- core.autocrlf=true on Windows
- and core.autocrlf=input on Unix.
This ensures that CRLF *never* enters the repository accidentally.
Unfortunately, Unix doesn't have core.autocrlf=input set by default,
thus repositories can be polluted when committing on Unix.
Steffen