| Summary: | Support Hard-links for local project cloning | ||
|---|---|---|---|
| Product: | [Technology] JGit | Reporter: | Roland Schulz <roland> |
| Component: | JGit | Assignee: | Project Inbox <jgit.core-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | caniszczyk, matthias.sohn, remy.suen, thomas |
| Version: | 1.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Unix All | ||
| Whiteboard: | |||
|
Description
Roland Schulz
If it's the Common Public License then it should be possible from what I understand. Doesn't Java7 support this now via java.nio.file.Files.createLink(...) I would rather go that route. Yes. But I would think that you don't want to require Java7 for Juno. So until Java7 is required, JNA might be the best option. I rather use Java7 if available otherwise degrade gracefully. It's a bit of a pain to get third party libraries through the IP process at eclipse.org :) I'm with Chris on this one. Not because of licensing but because JGit is pure-java. Introduce JNA and you introduce platform dependencies with it and one of the major reasons for JGits existence is gone. I mean, going that route, why not create a JNI layer for the native Git client instead? Much less maintenance. |