12

There is no exact svn export equivalent command for git? Really?

Beware: this is not a duplicate question. That is, I already know and have tested these commands:

  • git clone --depth 1 <- Still downloads the .git folder.
  • git checkout-init <- Doesn't work for a remote repo, it works with a working copy (so you need to clone first).
  • git archive <- This would be the perfect solution, because it has a --remote argument, but it only has 2 possible formats: tar or zip, so I would need to untar/unzip after downloading, and for that I need a pipe (|), but I'm on windows!! (not *n?x)
  • git clone --bare <- I still don't know what the heck this is, but it's not what I need.

Please enlighten me is there a real svn export replacement in git?

knocte
  • 16,941
  • 11
  • 79
  • 125
  • 1
    This is not a duplicate of the proposed question. Basically the OP is asking how to download only the latest manifest of files from a remote repository. `git archive` works from a local clone so that is back to square 1: how to download only the latest manifest. – Lasse V. Karlsen Jun 30 '11 at 18:07
  • 4
    `git clone --depth 1` is what you need, read the documentation that Bruno is linking to and his comment. – Lasse V. Karlsen Jun 30 '11 at 18:07
  • 4
    You will not get around "getting a .git folder", but you will get around downloading the entire changeset history with `--depth 1`. You still have to delete the `.git` folder afterwards. There is no getting around that. – Lasse V. Karlsen Jun 30 '11 at 18:10
  • 1
    If you've installed git on windows then presumably you have git bash and the associate tools that it installs such as tar. If this is the case you can use git archive and a pipe to tar. – CB Bailey Jul 02 '11 at 06:02

8 Answers8

13

From How do I do a quick clone without history revisions?:

git clone --depth 1 your_repo_url

Then, from the rmdir documentation:

rd /s /q .git
Nicolás Ozimica
  • 9,481
  • 5
  • 38
  • 51
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • 2
    Stop proposing --depth, it's already mentioned in the question! – knocte Jun 30 '11 at 17:41
  • 6
    Not sure you understand what `--depth` does: it does not download all the revisions: it rebuilds a "fake" history only pretending to add the new files each time. You're not downloading any more than you would with the archive. – Bruno Jun 30 '11 at 17:44
  • @knocte: did you just downvote this answer after editing the question from "straight-forward" to "exact"? – Bruno Nov 22 '11 at 22:43
  • 1
    Its not polite to downvote answers to your own question, imo. – alternative Sep 05 '12 at 21:05
  • 2
    stackoverflow is not about politeness, it's about correctness – knocte Mar 25 '14 at 10:37
  • 1
    @knocte, quite surprised to see you're still active on this question. Nevertheless my answer was correct. – Bruno Mar 25 '14 at 11:59
  • @knocte you have marked the wrong answer correct; or you should change your question to be specific to github only – That Realty Programmer Guy Nov 18 '18 at 18:48
  • what happens is that there's no correct answer because there's no exact equivalent to `svn export`, but at least github provides a workaround – knocte Nov 19 '18 at 03:47
11

The question "how can I do a svn-style 'export' with git?" is like asking "How can I change the tires on my basketball?". You can't, but that's not the basketball's fault. Yes it is rubber and full of air, but the similarity ends there.

You only need "export" with svn because it pollutes every single subdirectory with a .svn directory. Git doesn't do that, so you really don't need it. A clone IS an export, just with one directory at the root dir that all the repository business lives in.

The easiest thing is to clone the repo and then just delete the .git directory from the top level of the repo. Do that, and it's not a repo anymore, it's just a stand-alone directory of files.

Or, you know, ignore git all together and just use the files you cloned down. That works too.

Dan Ray
  • 21,623
  • 6
  • 63
  • 87
  • 2
    Irrelevant: removing the .git folder doesn't save the precious time and bandwidth that I could save by not downloading it in the first place. – knocte Jun 30 '11 at 17:36
  • 2
    Unless your repo contains a LOT of binaries in its history, the repo itself is only fractionally bigger than the checked out working directory will be. Also I can pretty much guarantee you've used up more time and bandwidth complaining about this than you would just using the tool the way it's built. – Dan Ray Jun 30 '11 at 17:38
  • 2
    DanRay stop assuming the purpose of the tool. If I'm going to use it to download thousands of git repositories, the bandwidth savings would make sense, right? – knocte Jun 30 '11 at 17:41
  • 2
    I get the feeling that no answer other than "here is how you can make git perform just like your preferred tool" is going to satisfy... git and svn are VERY DIFFERENT from design to implementation. – Dan Ray Jun 30 '11 at 17:41
  • @knocte - Are you really downloading thousands of git repositories? Why? – Dan Ray Jun 30 '11 at 17:42
  • 1
    DanRay: because I want to retrieve their content. – knocte Jun 30 '11 at 17:45
  • 1
    @knocte - Okay. Well, do it the way the tool they're in does it, or don't. I'm done with this conversation. – Dan Ray Jun 30 '11 at 17:46
  • 1
    The analogy is not helpful to me. both svn and git store files with revision history. Both svn checkout and git clone create directory structures that contain information about that history. svn export is a way to ask for only the content of a specific revision without any metadata. If the point is that git does not, then it is horribly broken. If the answer is do "git clone" and "rm -rf .git" then just say that -- don't argue that git is so different that the equivalent of "svn export" is not a meaningful action. – sienkiew Jul 19 '12 at 14:08
  • This analogy made me laugh :) – ecbrodie Aug 06 '12 at 01:30
  • 4
    That's one of the *stupidest* analogies I've read. For this specific task (downloading just files, not the history, for a specific revision) it makes all kinds of intuitive sense to expect a revision control system with atomic commits to have a command to accomplish it. The reason to use `svn export` is specifically to get a copy of a revision *without* history. So telling someone to clone, getting a copy *with* history, and then just ignore that history, is condescending at best. Also, SVN no longer pollutes every single directory with a .svn folder, as of version 1.7 released back in 2011. – Ben May 22 '15 at 15:39
9

Just get rid of the repository within the working copy.

git clone remote
rm -Rf .git

(On Windows, it's rd /s /q. Thanks for the hint by @Bruno.)

KingCrunch
  • 128,817
  • 21
  • 151
  • 173
  • 1
    Perhaps `rd /s /q` instead of `rm -Rf` on Windows. – Bruno Jun 30 '11 at 17:29
  • I had to look very closely at the question to find the "I'm on windows!!" ;) I don't know windows' commandline. I'll assume `/s` is he `-Rf` equivalent. – KingCrunch Jun 30 '11 at 17:31
  • KingCrunch: irrelevant. The purpose of this is precisely to avoid deleting the ".git" folder later, and to save bandwidth and time by not downloading it. – knocte Jun 30 '11 at 17:32
  • Not sure either, but it looks like `-R` is `/s` and `-f` is `/q`: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/rmdir.mspx?mfr=true – Bruno Jun 30 '11 at 17:33
  • `git` _always_ interacts with the local repository. Even `push`, or `pull` goes right into the local one. This means, there is no way to save anything until you have a local copy, and then it's to late ;) I don't know, what you are going to achieve at the end, but as long as the maintainer don't provide a downloadable package (e.g. created via `git archive`) you need the repository anyway. Some web interfaces (github and such) provides the ability to download packaged branches. Usually as long as you don't clone the linux kernel the bandwith and time is negligible. – KingCrunch Jun 30 '11 at 17:36
  • @knocte, try using the `--depth` parameter with `git clone`. – Bruno Jun 30 '11 at 17:36
  • KingCrunch, your efforts to explain me the philosophy of git still don't answer why the hell there is no "svn export" equivalent. Kthxbye – knocte Jun 30 '11 at 17:39
  • @knocte, with `--depth=1`, the .git folder is just a few files of config and the patches required for the latest revision, it doesn't download all the revisions. – Bruno Jun 30 '11 at 17:40
  • Bruno, I know that. But it's still metadata I don't want and it causes me the need to post-process. – knocte Jun 30 '11 at 17:42
  • @knocte: Because nobody needs it. I explained the technical part in the comment, @DanRay explainedthe idea behind that in his answer and the consequence in his comment. Git repositories uses deltas and is itself compressed. In many cases you _will_ download more, if you just receive the uncompressed content, instead of the packed repository. Believe me, sometimes I clone repositories via GPRS ;) – KingCrunch Jun 30 '11 at 17:42
  • 1
    This has nothing to do with "fanboys". You want `svn export`? Than must use `svn`, because DVCS works very different to centralized VCS. You cannot switch from SVN to git and work with it like it were SVN. Understand git and you will understand what happens here. Or leave it, but don't blame the messenger ;) – KingCrunch Jun 30 '11 at 17:49
  • @knocte: what do you mean by post-process? Do you really get a massive overhead? It wouldn't be much worse than uncompressing an archive. Most of the data will be compressed during the transfer anyway. – Bruno Jun 30 '11 at 17:49
  • @Bruno: Most of the stuff within an git repository is already compressed ;) With `--depth 1` is like downloading the compressed archive and get it unpacked by git. Seriously, I don't understand whats the big deal here... – KingCrunch Jun 30 '11 at 17:51
  • @KingCrunch, of course, I think that's quite sensible, but the OP doesn't seem to agree. – Bruno Jun 30 '11 at 17:53
  • KingCrunch, there is no DVCS conceptual reason for git not to provide this feature, I could create a patch and they would add, so stop spreading wrong conclusions. – knocte Jun 30 '11 at 17:53
  • 2
    @knocte, of course, that could be added directly, not necessarily a bad idea. However, `git` fundamentally follows the unix approach of having a small command for each little things you need to do, which you can then combine. Some like this approach, some don't. I don't think `git clone --depth` followed by an `rmdir` is the hardest combination of commands you can get. Even with a potentially limited command line environment (e.g. Windows's `cmd`), it's not that hard. Doing it in one command might be better, but I'm not sure it's worth arguing like this... – Bruno Jun 30 '11 at 17:58
3

At some hostings like GitHub you can make exact svn export.

Example:

svn export https://github.com/GNOME/banshee/branches/master

Even partial! (some subpart of the repository)

Example:

svn export https://github.com/liferay/liferay-portal/branches/6.1.x/tools

For your own repository you should create some GitHub repository and add it as a remote:

git remote add github https://github.com/<user>/<repo>.git

then

git push github <branch>

Now you able to do a partial checkout as above.

UPDATE: Looks like this feature is getting discontinued.

knocte
  • 16,941
  • 11
  • 79
  • 125
Vladimir Sosnin
  • 118
  • 3
  • 3
    @knocte, the problem is that this answer doesn't answer the question. The fact that `svn export` works on GitHub has nothing to do with doing what you want with Git, it has to do with the fact the GitHub also offers a Subversion service that is a [bridge to its Git repositories](https://github.com/blog/626-announcing-svn-support). It's still a Subversion server, though, not a Git one. – Bruno Mar 25 '14 at 12:06
  • I know, but it's the least worse answer at the moment; I'm planning to contribute an option for this anyway, in git upstream, after 2.0 gets released (already contributed my first patch, I'm making progress) – knocte Mar 25 '14 at 12:10
  • The fact remains that `git clone --depth 1 your_repo_url` followed by the deletion of the `.git` repository still does exactly what you want, using **Git** repositories. How would this answer be the "least worse" when it doesn't even use Git repositories? I'm not going to downvote this answer because the answerer is visibly trying to help and this is a reasonable workaround for GitHub, but this doesn't actually answer the question. – Bruno Mar 25 '14 at 12:13
  • 1
    that command would not be an **exact** equivalent to `svn export` simply because it requires a post-cleanup step (deleting the .git folder) and the original Subversion command doesn't – knocte Mar 27 '14 at 18:18
3

For your I still don't know what the heck this is: git clone --bare will clone the repository without a working copy. This is usually done on a central repository so as to minimise disk space usage.

Bruno / King Crunch have the best answer. Although you could use git bash / cygwin to allow you to pipe if you need a one-liner.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Raoul
  • 2,043
  • 1
  • 21
  • 29
2

This is a rather old questions, nevertheless I didn't find an "obvious solution" in my opinion. After some research of the git documentation I found:

git archive --format=tar --remote ... | tar xf -

This will receive the contents even from a remote repository and write a tar archive to stdout. The tar command then will extract the contents and create it in your current directory.

If you like to do that from a local repository (which was explicitly not the desired request in the question), then

git archive --format=tar ... | ( cd /your/path && tar xf - )

will do the trick for you. The first approach works on Windows command prompt as well, if you have tar installed. The latter most probably does not and may overwrite your directory.

toaster
  • 61
  • 7
0

Re your point, git archive <- This would be the perfect solution ...but it only has 2 possible formats: tar or zip, you can add new formats using documentation from the EXAMPLES section of the git-archive(1) man page:

   git config tar.tar.xz.command "xz -c"
       Configure a "tar.xz" format for making LZMA-compressed tarfiles.
       You can use it specifying --format=tar.xz, or by creating an output
       file like -o foo.tar.xz.

While being "on windows" is generally considered an impediment to many tasks, with a little extra work, you can almost catch up to the folks running other operating systems by using software like Cygwin or MKS Toolkit.

If after confirming that whatever command you need is available from within your shell, this sort of git config … command still doesn't work for you, then you should perhaps post additional details about your configuration in a question on SuperUser.com.

Community
  • 1
  • 1
ghoti
  • 45,319
  • 8
  • 65
  • 104
  • wow, I can't believe git-archive can be configured with custom formats, but cannot be tweaked to have no format at all!!! seriously, it's not that I don't know or don't want to install cygwin or other shell, it's that I'm running this operation in a buildagent in which I don't want to install anything (because I actually don't have control over it) – knocte Sep 05 '12 at 20:40
  • 1
    What would the output of "no format at all" look like? The purpose of "git archive" is to create an *archive*. That implicitly requires some kind of format. Add a freely available [`tar.exe`](http://gnuwin32.sourceforge.net/packages/gtar.htm) to your build server, then try setting `git config tar.deploy.command "tar -x -C /path/to/target -f -"` and extract on the fly. NONE of your tools are perfect. Sure, git's architecture fails to compensate for other failures in your build environment, but that's what you've got. Just do what you can with the tools available. – ghoti Sep 06 '12 at 00:47
  • Woot, an anonymous downvote. Care to mention how this answer is inaccurate or misleading? – ghoti Sep 12 '12 at 00:21
  • You can list the available formats for your installation using `git archive --list`. For my installation, I'm seeing tar, tez, tar.gz, and .zip. – jbruni Jan 19 '21 at 17:57
  • @jbruni .. Yes -- on my system, I see `.tgz` as well. It might not have been clear from the formatting I used back in 2012, but the bold bit in the first paragraph was actually quoting the question. Since the OP was clear that he had only 2 formats available, I was trying to provide a way to add more. – ghoti Jan 22 '21 at 09:35
-1

From https://stackoverflow.com/a/160719/43597

git checkout-index -a -f --prefix=/destination/path/
Community
  • 1
  • 1
Amr Mostafa
  • 23,147
  • 2
  • 29
  • 24
  • Useless answer, as this needs to be done from a repository that has already been cloned. What we want to avoid is to do two steps instead of one (svn export is one step, git clone + git checkout-index is two steps). – knocte Feb 14 '12 at 13:21