Bugzilla – Full Text Bug Listing
| Summary: | Support symlinks | ||
|---|---|---|---|
| Product: | [Technology] JGit | Reporter: | Matthias Sohn <matthias.sohn> |
| Component: | JGit | Assignee: | Project Inbox <jgit.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | axel.richard, BoD, christian.halstrick, darkness.bsd, eclipse.org, eclipse.org, enzo.congiu, florian.winkler, gonzague.reydet, hrr, jacek.pospychala, jacobgodserv, jens.elmenthaler, josef.stadelmann, kk, klemens, loskutov, marc-philip.werner, mikael.barbero, mikael.springer, mknauer, mober.at+eclipse, neon, pascal.rapicault, piranna, robin.rosenberg, robin, simfox3, simon.alford, simon_kaegi, thomas, thomas, Tobias.Richter, vbhavdal |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 351976, 353771, 384910, 405326, 429304 | ||
|
Description
Matthias Sohn
In this case, we can missed compatibility with Java 5. Is it unimportant? (In reply to comment #0) > on Java 7 we could implement jgit support for symlinks on OSes supporting them In this case, we can missed compatibility with Java 5. Is it unimportant? We want to still support Java 5 and 6 so this needs to be installed via an optional feature until we drop Java 5 and 6 support. *** Bug 334137 has been marked as a duplicate of this bug. *** *** Bug 318598 has been marked as a duplicate of this bug. *** Hello, I just wanted to add, that this is really serious from my point of view. I'm just investigating on how to migrate a large symfony php project (ullright) from svn to git. eGit would play an important part, because the frontend development parts are performed by "not-so-technical" people like graphical artists and webdesigners. Git command line is not a real option for them. So sadly, this symlink bug is a real showstopper! (In reply to comment #3) > We want to still support Java 5 and 6 so this needs to be installed via an > optional feature until we drop Java 5 and 6 support. +1 (In reply to comment #7) > (In reply to comment #3) > > We want to still support Java 5 and 6 so this needs to be installed via an > > optional feature until we drop Java 5 and 6 support. > +1 I 100% agre with you because there a OS which has no such thing as symbolik links, given that matters. (In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #3) > > > We want to still support Java 5 and 6 so this needs to be installed via an > > > optional feature until we drop Java 5 and 6 support. > > +1 > > I 100% agre with you because there a OS which has no such thing as symbolik > links, given that matters. Feedback on https://git.eclipse.org/r/#/c/9379/ appreciated. -- robin (In reply to comment #3) > We want to still support Java 5 and 6 so this needs to be installed via an > optional feature until we drop Java 5 and 6 support. When the FS support in jgit is pluggable, it might be interesting to supply an implementation based on Eclipse EFS when Java 7 is not available. Support for reading symbolic links has been available in EFS since Eclipse 3.6 (originally contributed via bug 170317, as of today it is supported on Linux, Solaris, MacOSX, AIX natively as well as via java7 NIO through bug 375433). Docs start from here: http://help.eclipse.org/juno/topic/org.eclipse.platform.doc.isv/guide/resAdv_efs_api.htm While EFS cannot create symbolic links, just being able to read them should already help address most problems with symlinks in egit, such as constantly showing them as out-of-date. Using EFS should also address performance problems when walking the file tree, as indicated by http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg00722.html I assume that jgit should remain plain java and thus won't want any EFS dependency, but a plugged-in FS implementation for Eclipse would make a lot of sense IMO. Maybe somebody would be open contributing that with some initial pointers where to start; it shouldn't be too hard. The missing "create symlink" operation could be implemented by executing "ln -s" on the OS if desired. We've been doing that already in the core.resources tests for the EFS functionality. It would also be interesting to compare performance of Java 7 against EFS. (In reply to comment #11) > While EFS cannot create symbolic links, just being able to read them should > already help address most problems with symlinks in egit, such as constantly > showing them as out-of-date. If EFS cannot create symbolic links, how can I then clone a repository even check out a branch that contains them? Why would a solution that doesn't permit that be useful? Creating symlinks is not as performance critical as reading them. We have done
Runtime.getRuntime().exec("ln -s "+src+" "+tgt");
for this in the past.
(In reply to comment #13) > Creating symlinks is not as performance critical as reading them. We have > done > > Runtime.getRuntime().exec("ln -s "+src+" "+tgt"); > Right. That's what we do too in our solution. We also do "cp -a" to copy links. A personal reflection is that while there's a whole slew of solutions that can be used such as calling OS functions, comparing canonical/absolute paths, using JNA or JNI, I can't help thinking if it's worth it. Here's the KISS advocates solution: Use reflection to find the Java 1.7 functionality and then if it's not there, then throw an UnsupportedOperationException that explains to the user that in order to do the requested action, he'll need a more recent JVM. Everyone is happy with that except a few who really persist on doing symlinking (or hardlinking) with JGit on JVM's prior to 1.7. They cannot do that today and the proposed solution would not change that. Would it be such a bad thing to just pass on providing a solution for them? Why would a developer not want to run Java 7? I understand that you may want to target an older environment, but Eclipse lets you develop for Java 6 or older while using Java7. I know some people don't know this, but that's not reason enough. And btw, why the lack of interest in the Java 7 symiink support in Gerrit? I pulled the code from Gerrit and it appears to work fine. Seems I cannot make an impact on Gerrit to progress this change though. Some of our users are requesting this support. How can I help to make progress on this issue? What are the blocking issues? Thx in advance. Matthias, as you suggested in a private mail, I've checked out latest HEAD of jgit/egit, applied the patch on top, did a smoke test in Eclipse and reviewed code in Gerrit [1]. For a "jgit newbie" (but I have good Eclipse/Mercurial background) the patch looks just fine (there were only few minor/micro issues). What else is needed to move forward this contribution? I'm especially concerned because UI (egit) must be updated too, so this patch is just one of many road blocks on a "native" links support for the end user in Eclipse. <off-topic> Additionally it would be nice if somebody can give me some pointers how to update Egit label decorations to show right state for links. Right now with the patch applied, egit shows all links with "unknown/not tracked" decorations. I've quickly checked GitLightweightDecorator but it looks like I need to patch some underlined indexers to return proper flags in IndexDiffData. The questions now: * is there a bug for UI to support symlinks (show right descorations)? * should I create one, if there is no bug for it? * where in the code is the right place to start the patch? </off-topic> [1] https://git.eclipse.org/r/#/c/9379/25 (In reply to comment #19) You need https://git.eclipse.org/r/#/c/9381/ for decorations to work, at least to some degree. Obviously there is more to do, e.g. compare does not compare the symlinks, but rather the target content, which is probably not what you want. A problem there is where to draw the line, as some of the work is actually part of the Eclipse platform only, e.g. comparing two resources with each other. Another annoying thing is that dead links do not show up in (please don't report such issues against EGit). I do not think these issues prevent a release, however. You might also want to use Kepler M7 since it includes a dedicated symlink decoration, not related to EGit at all. It would be nice if someone with Windows could try the patches. It might work on Windows 7/2008, but not on earlier version (maybe Vista), but AFAIK Windows has it's set of quirks regarding symlinks. Whatever Windows-specific handling is in there, it's just guesses so far. (In reply to comment #20) > It would be nice if someone with Windows could try the patches. It might > work on Windows 7/2008, but not on earlier version (maybe Vista), but AFAIK > Windows has it's set of quirks regarding symlinks. Whatever Windows-specific > handling is in there, it's just guesses so far. In my understanding, commandline git on Windows (ie MSYSGIT) does not use the native NTFS symlinks but rather a workaround which stores the link target in a special file. I suppose that jgit should be compatible with the most widely used commandline git; so I don't think the OS version is relevant here, and even the java7 support is not relevant IMO. Here is some discussion of the topic: http://stackoverflow.com/questions/5917249/git-symlinks-in-windows http://code.google.com/p/msysgit/issues/detail?id=344 (In reply to comment #21) > (In reply to comment #20) > > It would be nice if someone with Windows could try the patches. It might > > work on Windows 7/2008, but not on earlier version (maybe Vista), but AFAIK > > Windows has it's set of quirks regarding symlinks. Whatever Windows-specific > > handling is in there, it's just guesses so far. > > In my understanding, commandline git on Windows (ie MSYSGIT) does not use > the native NTFS symlinks but rather a workaround which stores the link > target in a special file. I suppose that jgit should be compatible with the > most widely used commandline git; so I don't think the OS version is > relevant here, and even the java7 support is not relevant IMO. > > Here is some discussion of the topic: > http://stackoverflow.com/questions/5917249/git-symlinks-in-windows > http://code.google.com/p/msysgit/issues/detail?id=344 That's discussions on possible, not actual, solutions. MSysgit does not support symbolic links at all and the only reasonable solution is to use the Windows native symbolic links. If JGit does it, that may help driving the implementation in Git for Windows. Until then we'll stay incompatible. It will still be possible to use both EGit/JGit together with msysgit if you are careful. Cygwin support symlinks in the form of shortcuts. The drawback is that only cygwin programs and Windows Explorer understands that. JGit has a special FS subclass for cygwin, so it would be possible to be compatible there, but again, since e.g. Eclipse does not recognize shortcuts there is little use for that. I have voted this up, as I experienced some of the symlink related issues on Linux. FYI: I am not using eclispe on windows, but I did investigate the use of real symlinks for MSysgit on Windows 7 and newer. The main issue blocking the use of symlinks on Windows is that they can only be created by a process with administrator privileges. So that is why MSysgit has never implemented them. MSysgit instead just creates a file which contains the symlink destination. If a solution for windows is to be found, it will not be with real sysmlinks. Unless MS relax the requirement for administrator privileges to create one. The best "pseudo symlinks" I have seen on windows are in MobaXterm. They use a magic string "!<symlink>" in a file to indicate a symlink, followed by the destination (which is not a million miles away from what MSysgit does). To get that to work for Eclipse (Egit or whatever), it would have to check for the "magic" when doing a file open/compare/etc/etc and take the appropriate action. I assume this is not a practical solution as it would have to be implemented across the whole Eclipse universe. (In reply to comment #23) > I have voted this up, as I experienced some of the symlink related issues on > Linux. Unfortunately voting won't get this anywhere :( As Chris Halstrick pointed out somewhere, more tests are needed. The patches in Gerrit seems to work, but symlink support is intrusive enough that we need unit tests to sort-of prove that it does work for the strange cases and doesn't break anything and serve as regression tests for the unevitable bug fixing. Anyone can vote by creating tests and submitting them to gerrit. Don't squash the tests in at this time, just push them after the last patch for now. *That* will get things moving. The most important things to test is the dircache checkout and merge. If these can be covered convincingly, I think we're go for merge. As for Windows, I don't think fake symlinks are interesting *at all*. Only pure cygwin users have any use for that. It must be real symlinks or not at all (i.e. text files with target). Just wanted to add a note that it is "critically" important to the Orion team that if this feature is a way to disable symbolic link creation on checkout. Something like -- core.symlinks=false -- needs to be possible for us. (In reply to comment #25) > Just wanted to add a note that it is "critically" important to the Orion > team that if this feature is a way to disable symbolic link creation on > checkout. Something like -- core.symlinks=false -- needs to be possible for > us. Should be "...if this feature is added that there is a way to disable symbolic link creation..." The tentative patches in Gerrit support core.symlinks = false (In reply to comment #20) > (In reply to comment #19) > > You need https://git.eclipse.org/r/#/c/9381/ for decorations to work, at > least to some degree. Thanks. I've finally got time to play with it. Now we see that links itself are properly decorated, but all children of linked directories are decorated as "unknown" (with question marks). It is probably because DecoratableResourceAdapter checks FS.DETECTED.isSymLink(file)) which internally calls Files.isSymbolicLink(nioPath). Unfortunately Files.isSymbolicLink() returns false for all children of linked directories. Can you please give me a hint if this (DecoratableResourceAdapter) is the right place to address the decorator issue? Even some pointers how to solve it? (In reply to Robin Rosenberg from comment #24) > (In reply to comment #23) > As Chris Halstrick pointed out somewhere, more tests are needed. The patches > in Gerrit seems to work, but symlink support is intrusive enough that we > need unit tests to sort-of prove that it does work for the strange cases and > doesn't break anything and serve as regression tests for the unevitable bug > fixing. > > Anyone can vote by creating tests and submitting them to gerrit. Don't > squash the tests in at this time, just push them after the last patch for > now. *That* will get things moving. > > The most important things to test is the dircache checkout and merge. If > these can be covered convincingly, I think we're go for merge. this means the following tests org.eclipse.jgit.lib.DirCacheCheckoutTest org.eclipse.jgit.merge.SimpleMergeTest org.eclipse.jgit.merge.ResolveMergerTest org.eclipse.jgit.merge.RecursiveMergerTest should be enhanced to cover symlinks (In reply to Matthias Sohn from comment #29) > this means the following tests > > org.eclipse.jgit.lib.DirCacheCheckoutTest > > org.eclipse.jgit.merge.SimpleMergeTest > org.eclipse.jgit.merge.ResolveMergerTest > org.eclipse.jgit.merge.RecursiveMergerTest > > should be enhanced to cover symlinks Also WorkingTreeIterator (jgit) and ContainerTreeIterator (egit) should have their own tests. WorkingTreeIterator has some tests. There are some unicode tests to catch bugs in the difference between character length and byte length, but it turns out there are a number of unrelated issues there, so maybe it's better to fix unicode bugs later. *** Bug 351976 has been marked as a duplicate of this bug. *** I would like to help on this bug. From my understanding, it would need further tests to merge the reviews https://git.eclipse.org/r/#/c/9379 and following into the main repository. I listed 4 "locations" where more tests are expected: - dircache checkout, - merge, - WorkingTreeIterator (JGit) - ContainerTreeIterator (EGit) I saw that Robin R. has started to implement tests in this review https://git.eclipse.org/r/#/c/15395/. I am fairly new to the source code of EGit/JGit but I really want to step into. Would you provide me guidance about the other tests you are expecting. Thank you. I can provide some ideas for tests in the area of dircachecheckout which I am expecting: The basic use-case which I would like to cover with unit tests is "checking out a different branch" in a non-bare repository. Imagine you have checked out branch "master". Imagine the master branch contained files,folders(trees),symlinks and submodules (these are the 4 different types which we support, check the FileMode class). After the checkout you modified some files, created new files, replaced some of the folders by files, replaced some of the files by symlinks, deleted subfolders, ... . Part of your modification you staged to index, the other parts not. After staging you again modify some of the files you staged, replaced folders by symlinks, ... . And now you say "(j)git checkout 1.0". In branch "1.0" things look again completely different regarding whether under a certain path you see a file/folder/symlink/submodule. In the end you are facing 4 different states (HEAD: the branch you checked out, the workingtree, the index and MERGE: the branch you want to check out). For each path (e.g. 'src/foo') you may see a different file type in each state. The file 'src/foo' may be a file in HEAD, it may be a folder (containing src/foo/x.txt) in the working tree, it may be a symlink 'src/foo -> resource/a.jar' in the index and it may be missing (not existing) in the branch you check out. Git defines a complex logic what to do during a checkout (see [1]) and jgit has to follow these rules (I tried to explain in [2]). BUT: Up to know we handled only filetypes file,tree,submodule,missing. When we saw something in the filesystem which was not a folder ... then we knew it had to be a file. But from now on we have to distinguish between files and symlinks. Finally: what I would like to have more tests in the DirCacheCheckoutTest class which deal with symlinks. What happens if you only replaced a file by a symlink and checkout a different branch. What happens if you checkout a branch where 'src/foo' is a file but you have already staged a new version of a file 'src/foo' and the working tree contains a folder named 'src/foo'. Don't get confused by the class DirCacheCheckoutTestWithSymlinks - this covers a different case and should not contain the new test cases. [1] http://git-scm.com/docs/git-read-tree#_two_tree_merge [2] https://docs.google.com/spreadsheet/ccc?key=0Ask8nTwp7sXedElIQWg3bGlINENuNGtlN0lQYVZVSFE&usp=sharing&authkey=CJn1mC4 I try to reproduce the case you describe in the previous comment. I have a few questions about that. (In reply to Christian Halstrick from comment #33) > ... And now you say "(j)git checkout 1.0". In branch "1.0" > things look again completely different regarding whether under a certain > path you see a file/folder/symlink/submodule. The checkout of the branch 1.0 raises a CheckoutConflictException and doesn't apply. Is that what you expected from the test ? > In the end you are facing 4 different states (HEAD: the branch you checked > out, the workingtree, the index and MERGE: the branch you want to check > out). For each path (e.g. 'src/foo') you may see a different file type in > each state. The file 'src/foo' may be a file in HEAD, it may be a folder > (containing src/foo/x.txt) in the working tree, it may be a symlink 'src/foo > -> resource/a.jar' in the index and it may be missing (not existing) in the > branch you check out. With the diff command, I get a diff entry which allows me to get the file mode of 'src/foo' in the index (with getOldMode()) and in the branch 1.0 (with getNewMode()) But, how can I get the file mode for the HEAD and the working tree ? > Finally: what I would like to have more tests in the DirCacheCheckoutTest > class which deal with symlinks. I think I should write my test cases in the org.eclipse.jgit.java7.test plugin instead of DirCacheCheckoutTest in the org.eclipse.jgit.test plugin because the symlinks are only managed with Java7. What do you think ? > (In reply to Christian Halstrick from comment #33) > > ... And now you say "(j)git checkout 1.0". In branch "1.0" > > things look again completely different regarding whether under a certain > > path you see a file/folder/symlink/submodule. > > The checkout of the branch 1.0 raises a CheckoutConflictException and > doesn't apply. Is that what you expected from the test ? The rule is simple: jgit should do what native git does. If in your test case you create a situation where native git says "I cannot checkout" - then jgit should also throw a CheckoutConflictException. The situation which I describe is very likely to be like that. ... > With the diff command, I get a diff entry which allows me to get the file > mode of 'src/foo' in the index (with getOldMode()) and in the branch 1.0 > (with getNewMode()) > But, how can I get the file mode for the HEAD and the working tree ? I you want to test what the mode is for a certain path in e.g. the HEAD commit and the workingtree I would use a TreeWalk. Look for example in DiffCommand.call() and DiffFormatter.scan() to see how to setup a TreeWalk to walk a commit and the workingtree. The TreeWalk gives you the chance to see modes on all tree's you walk. ... > I think I should write my test cases in the org.eclipse.jgit.java7.test > plugin instead of DirCacheCheckoutTest in the org.eclipse.jgit.test plugin > because the symlinks are only managed with Java7. What do you think ? Right, tests which have to make use of filesystem symlinks should go into the java7.test plugin. There may be the chance to write also tests for bare repos where we don't need java7 but still deal with symlinks in HEAD,MERGE and index ... but I would also start in java7.test I execute this test : "What happens if you only replaced a file by a symlink and checkout a different branch" under windows and Linux. The test passes on Linux but fails on Windows with a CheckoutConflictException. The difference is in the method DirCacheEntry#isSmudged(): DirCacheEntry.isSmudged() line: 362 FileTreeIterator(WorkingTreeIterator).compareMetadata(DirCacheEntry) line: 759 FileTreeIterator(WorkingTreeIterator).isModified(DirCacheEntry, boolean) line: 811 DirCacheCheckout.processEntry(CanonicalTreeParser, CanonicalTreeParser, DirCacheBuildIterator, WorkingTreeIterator) line: 901 DirCacheCheckout.preScanTwoTrees() line: 250 DirCacheCheckout.doCheckout() line: 406 DirCacheCheckout.checkout() line: 393 CheckoutCommand.call() line: 240 It returns true on Windows and false on Linux. The method isSmudged() calls getLength() which returns 0 on Windows and 1 on Linux. The only difference that I seen between Windows and Linux is that the symlink created on Windows by FileUtils.createSymLink(File path, String target) has a size of 0 bytes while the symlink created on Linux by createSymLink has a size of 13 bytes on my machine. Do you think there is a lack in the method isSmudged() and it should manage symlinks ? The bug I raised in the following review https://git.eclipse.org/r/#/c/19059/ doesn't allow me to test the second case you describe here (In reply to Christian Halstrick from comment #33) > Finally: ... What happens if you checkout a > branch where 'src/foo' is a file but you have already staged a new version > of a file 'src/foo' and the working tree contains a folder named 'src/foo'. Have you other tests related with symlinks in mind that I can help on ? Besides these tests, is there something else that can block the merge of this review ? I pushed a review https://git.eclipse.org/r/#/c/19237/ that tests files modes with symlinks. Have you other tests related with symlinks in mind that I can help on ? Besides these tests, is there something else that can block the merge of this review ? I pushed a review https://git.eclipse.org/r/#/c/19237/ that tests files modes with symlinks. Have you other tests related with symlinks in mind that I can help on ? Besides these tests, is there something else that can block the merge of this review ? I pushed a review https://git.eclipse.org/r/#/c/20374/ This review is a SWTBot test which validates that the UI manage symlinks. For Windows users wishing to test symbolic links: You need a special privilege. See http://superuser.com/questions/124679/how-do-i-create-a-link-in-windows-7-home-premium-as-a-regular-user If you *are* an administrator use "run as administrator" to launch Eclipse else i.e. if you are not an administrator Ask an administrator to give you SeCreateSymbolicLinkPrivilege logout/login Launch Eclipse normally Giving SeCreateSymbolicLinkPrivilege to a user who is already Administrator has no effect, you need to elevate your privileges when launching Eclipse. I've only tested this on Windows 7. It might perhaps be possible to fix this for administrator by carefully reading http://msdn.microsoft.com/en-us/library/bb530410.aspx I implemented a part of missing file system operations for Win32, Cygwin and POSIX, in order to manage symlinks with Win32, and Cygwin. The review is here: https://git.eclipse.org/r/#/c/21135/ See https://wiki.eclipse.org/EGit/FS for more details on which methods have been implemented/tested or not. The review https://git.eclipse.org/r/#/c/21135/ is a proposal for a support of Symlinks on all POSIX systems (whatever their version of Java) and on Windows systems with cygwin (any java versions). Without this review only users of POSIX-Java7 and Windows-Java7 (with privileges) can take advantage of symlinks. To sum up comments on this review, performances will be deteriorated with the proposed implementation (but it can be balanced by deactivating by default these slow implementations with a global options, letting users to activate it if they do need symlinks in their non java 7 environment). Also, it has been stated that it is not the purpose of JGit to support technologies beyond their EOL (like Java 5 & 6). I mostly agree with these comments but still think some people may be interested in these implementations. So I would like to ask to people following this bug if they are interested in getting symlinks support for such kind of configurations (Cygwin, Java6, ...). If no one raises interest about my proposal, I will ditch it and abandon the review https://git.eclipse.org/r/#/c/21135/ . I think it would be very nice to keep this code but to disable it by default, and have an 'advanced' option somewhere to enable it. A warning can be showed, something like "warning, this may slow up file access", etc. *** Bug 426882 has been marked as a duplicate of this bug. *** For Win32: Interestingly it seems you actually can create a symbolic link without thinking of the target type and the target does not have to exist. The means we can create symlinks before we create the target, if we create the target. merged https://git.eclipse.org/r/#/c/9379/ as 078a9f60664fee1f7e85f0c3ab3fd067c0f674cc (In reply to Matthias Sohn from comment #47) > merged https://git.eclipse.org/r/#/c/9379/ as > 078a9f60664fee1f7e85f0c3ab3fd067c0f674cc Now the symlincs are merged for jgit (finally !!!), can we also review/merge two missing *egit* patches: https://git.eclipse.org/r/#/c/9380/ https://git.eclipse.org/r/#/c/9381/ Thanks. yes, but I first need to find a windows box as my 2nd laptop running windows needs to first be reimaged, I use to work on a mac Based on Christian's comments, I added further symlinks tests where the working tree is dirty (differs from index) and where we have staged but uncommitted changes. See https://git.eclipse.org/r/#/c/22160/ to have more details. Good catch, at least some of the tests are valid, i.e. fileModeTestFileThenSymlinkWithFolderInIndex, but it has nothing to do with symlinks. If I change the test to just modify the file instead of changing it to a symlink, the test still fails, though it shouldn't. I haven't checked the other cases.
@@ -1337,49 +1337,49 @@ public void fileModeTestFolderThenSymlinkWithMissingInWorkingTree()
/**
* Steps:
* <p>
* 1.Add file 'a'
* <p>
* 2.Commit
* <p>
* 3.Create branch '1'
* <p>
- * 4.Replace file 'a' by symlink 'a'
+ * 4.Modify file 'a'
* <p>
* 5.Commit
* <p>
- * 6.Delete symlink 'a' & replace by folder 'a' in the working tree & index
+ * 6.Delete file 'a' & replace by folder 'a' in the working tree & index
* <p>
* 6.Checkout branch '1'
* <p>
* The checkout command should raise an error. The conflicting path is 'a'.
- *
+ *
* @throws Exception
*/
@Test
- public void fileModeTestFileThenSymlinkWithFolderInIndex() throws Exception {
+ public void fileModeTestFileThenFileAgainWithFolderInIndex()
+ throws Exception {
Git git = new Git(db);
writeTrashFile("a", "Hello world a");
writeTrashFile("b", "Hello world b");
git.add().addFilepattern(".").call();
git.commit().setMessage("add files a & b").call();
Ref branch_1 = git.branchCreate().setName("branch_1").call();
git.rm().addFilepattern("a").call();
- File symlinkA = new File(db.getWorkTree(), "a");
- FileUtils.createSymLink(symlinkA, "b");
+ writeTrashFile("a", "b");
git.add().addFilepattern("a").call();
- git.commit().setMessage("add symlink a").call();
+ git.commit().setMessage("change file a").call();
FileEntry entry = new FileTreeIterator.FileEntry(new File(
db.getWorkTree(), "a"), db.getFS());
- assertEquals(FileMode.SYMLINK, entry.getMode());
+ assertEquals(FileMode.REGULAR_FILE, entry.getMode());
git.rm().addFilepattern("a").call();
FileUtils.mkdirs(new File(db.getWorkTree(), "a"));
writeTrashFile("a/c", "Hello world c");
git.add().addFilepattern(".").call();
entry = new FileTreeIterator.FileEntry(new File(db.getWorkTree(), "a"),
db.getFS());
assertEquals(FileMode.TREE, entry.getMode());
Alex' finding are moved to https://bugs.eclipse.org/bugs/show_bug.cgi?id=428819 since they do not relate to symbolic links Hi everyone, thanks for the discussion. I went through it completely, but I am a still a bit lost, what the current status of this is. I am facing issues on a git repository, which contains a symbolic link to another folder in the same git repository. Whenever I pull the code from the repo using eGit, eGit marks the symbolic link as deleted and puts it in the unstaged view. If I revert the deleted symbolic link back to HEAD revision, eGit changes the type of symbolic link (breaking the symbolic link nature). This is very annoying and I could not get around this so far. Is this part of the bug discussed here, is there a solution to it already, or do I have to open another report for it. Thanks and best regards, Florian Florian: This one might be part of it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=429303 (In reply to Robin Rosenberg from comment #54) > Florian: This one might be part of it: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=429303 or this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=405326 It seems that this bug about JGit support of symlinks can be closed. Every new comments since the merge of the reviews are about Egit and summarized in the umbrella bug 429304. What do you think? lets close this bug as it seems all JGit related problems have been fixed if you still find issues with symlinks in JGit file new bugs what version of JGit is this fixed in? I am using Luna SR2 (Eclipse 4.4.2) which comes with JGit and EGit 3.4.2.201412180340-r) and it clones symbolic links as files on my Linux (CentOS 6.6 64-bit) machine (In reply to Neon Ngo from comment #58) > what version of JGit is this fixed in? > I am using Luna SR2 (Eclipse 4.4.2) which comes with JGit and EGit > 3.4.2.201412180340-r) and it clones symbolic links as files on my Linux > (CentOS 6.6 64-bit) machine I think this was in 3.5 for JGit and 3.6 for EGit, but if you just update to the latest stable version (3.7.0) you will have link support in both. (In reply to Andrey Loskutov from comment #59) > (In reply to Neon Ngo from comment #58) Thanks, I added EGit's main update site (http://download.eclipse.org/egit/updates) to my Eclipse Luna and installed current EGit and JGit 3.7.0.201502260915-r and symbolic links are working properly now on my Linux machine. |