<blockquote>
  <p>Question is there a way to get a single revision from Git without it's history ?</p>
</blockquote>

<p>To get a repository, no there's no way, mainly because there's no 'revision'. Git store commits, which are changes from previous state.<br>
If you want your repository at a specific point in time you have to pull the commit at this time and all it's ancestors or you'll get only the changes made in the commit. </p>

<p>To avoid confusion: Shallow cloning is getting the needed history and then truncating it to free space, the tree is still made from history.</p>

<p>For the solutions, @7ochem answer does cover them.</p>

CC BY-SA 3.0
2017-03-07T09:16:28.473Z
2017-03-07T09:24:46.423Z
2017-03-07T09:24:46.423Z
Tensibai
<p>Don't deploy your git repo. Develop a real deployment methodology. Even if it's as simple as tarring up an archive (= building an artifact with just the necessary files in it to be deployed) of deployed scripts.</p>

<p>Even if you shallow-clone the tip of your source repository, you likely don't need unit tests, documentation, linting profiles, and other supporting ephemera in your deployed environment.</p>

<p><strong>Note</strong>: for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. Then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools).</p>

CC BY-SA 3.0
2017-03-07T19:30:08.827Z
it's okay to question (or even challenge!) an answer -- that's what makes Stack Exchange great :)

for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools)
RubyTuesdayDONO
CC BY-SA 3.0
2017-03-07T19:32:36.937Z
@Pierre.Vriens yes, you're missing what's is suggested as tarring an archive, I.e building an artifact with just the necessary files in it to be deployed. That said I agree that's not a quality answer and this point should be extended. We are in private beta and answers should née explicit
Tensibai
CC BY-SA 3.0
2017-03-07T19:34:13.077Z
Then I don't see what this brings more than the accepted answer, if it's to point toward fit archive... it's just redundant, you should edit to extend on this way iMHo
Tensibai
CC BY-SA 3.0
2017-03-07T19:38:15.653Z
Please check my edit of your answer (just integrated your interesting comment). Feel free to improve/rework of course, or just rollback if you don't like my edit at all. BTW: your comment (= note I added) made me think like "really, that simple? Again a sample of how we Get Things Done in zOS ... with z for *zero downtime* ...". I think it's time to start to question way more questions/answers via similar comments ... Don't challenge me too much ...
Pierre.Vriens
CC BY-SA 3.0
2017-03-07T19:40:23.140Z
i don't purport that this is a complete or model answer, but i didn't see anyone else addressing the elephant in the room: if you use git to "deploy" your project, you're "gonna have a bad time" ;)
RubyTuesdayDONO
CC BY-SA 3.0
2017-03-07T19:41:39.767Z
just saw your edit to put my comment in the answer, yes, thank you for that :)
RubyTuesdayDONO
CC BY-SA 3.0
2017-03-07T20:10:51.433Z
@RubyTuesdayDONO using git to deploy is perfectly fitting the goal in some situation, static angular js front ends are a good example of app absolutely ok to deploy with a git pull in my experience
Tensibai
CC BY-SA 3.0
2017-03-07T20:22:19.197Z
you don't mind if users see unit tests & other meta/planning docs? and you don't mind resolving merge failures when deploying? and you always want everything in the repo included in the delivered product, accepting unforeseen interactions w/ experimental features? yes, for simplistic/hobbyist cases, it's adequate to deploy your source repo -- but we shouldn't promote it as best practice. by the time you're trying to optimize away little things like storage overhead of the git object database (which is pretty good at deduplication), you might want to look at more explicit release methodologies.
RubyTuesdayDONO
CC BY-SA 3.0
2017-03-08T08:03:58.470Z
Actually there is a reason to why we son't use achieved artifacts. Our product is part of a bigger build system, where each build might use a different revision of the product. That means we need to keep (or generate on the fly) an archive for each Git revision. Git archive solves most of that,  with the exception of having unnecessary files.
Rsf
CC BY-SA 3.0
2017-03-10T10:13:21.553Z
@RubyTuesdayDONO I've been unclear sorry, we have 2 apps like this,  we deploy branches per environment, chef run every 30 mins on the machines and a simple merge into a branch allow a deploy within 30 mins. Preventing access to unit tests/non relevant files is done by the webserver configuration. I agree this is a simplistic case, and adding a level of overhead with a build/package/store wouldn't bring really much for those simple cases. That doesn't mean promoting it for everything, but I think it shouldn't be frowned upon on *all* cases neither.
Tensibai
CC BY-SA 3.0
2017-03-07T18:56:44.947Z
2017-03-07T19:44:46.243Z
2017-03-07T19:44:46.243Z
RubyTuesdayDONO
<h3>Shallow clone</h3>

<p>You can indeed get a shallow clone out of Git using:</p>

<pre><code>git clone --depth=1 &lt;url&gt;
</code></pre>

<p>This will still clone the repo and create a <code>.git</code> folder with the objects, only smaller in size (difference depending on your total file size vs. history size).</p>

<h3>Git archive</h3>

<p>You can also use <a href="https://git-scm.com/docs/git-archive" rel="noreferrer">git-archive</a> to extract an archive of the repo:</p>

<blockquote>
  <p>Creates an archive of the specified format containing the tree structure for the named tree, and writes it out to the standard output. If  is specified it is prepended to the filenames in the archive.</p>
</blockquote>

<p>In the <a href="https://git-scm.com/docs/git-archive#_examples" rel="noreferrer">examples</a> it shows for instance:</p>

<blockquote>
  <p><code>git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip &gt;git-1.4.0.tar.gz</code>  </p>
  
  <blockquote>
    <p>Create a compressed tarball for <a href="/questions/tagged/v1.4.0" class="post-tag" title="show questions tagged &#39;v1.4.0&#39;" rel="tag">v1.4.0</a> release.</p>
  </blockquote>
</blockquote>

<h3>Hosted Git, archive API</h3>

<p>If you are hosting your repo on GitHub, then you can use their <a href="https://developer.github.com/v3/repos/contents/#get-archive-link" rel="noreferrer">archive API</a>:</p>

<p><code>https://api.github.com/repos/&lt;username&gt;/&lt;repository&gt;/zipball/&lt;commit_hash&gt;</code></p>

<p>Bitbucket.org has a same functionality for this:</p>

<p><code>https://bitbucket.org/&lt;username&gt;/&lt;repository&gt;/get/&lt;branch_name|commit_hash|tag&gt;.zip</code></p>

CC BY-SA 3.0
2017-03-07T18:16:14.667Z
7ochem, maybe gzip command need to be gzip -c ....
Romeo Ninov
CC BY-SA 3.0
2017-03-07T08:35:32.477Z
2017-03-10T09:50:08.590Z
2017-03-10T09:50:08.590Z
7ochem
<p>Having the full Git revision history has a lot of benefits as part of the development process. </p>

<p>But our product is the source code, we are using scripted languages that don't need compilation or processing, and then the Git history becomes a burden on deployment- in our example we deploy a clean virtual environment following every change, having several deployments on a single machine.</p>

<p>There are some ways to reduce the amount of history, for example shallow clones whose efficiency depends on how deep the revision is in the branch, doing a fetch instead of clone but then you still get history from the revision and back, or getting the full repo once then pull when needed but this is wasteful in terms of disk space and tends to be less reliable.</p>

<p>Is there a way to get a single revision from Git without it's history ?</p>

CC BY-SA 3.0
2017-03-07T10:38:46.520Z
Related Q&A at SO http://stackoverflow.com/questions/26135216/why-isnt-there-a-git-clone-specific-commit-option
Evgeny Zislis
<git>
Getting a single revision from Git
Rsf
# Getting a single revision from Git

(Asked by: username_0 on 2017-03-07)

Having the full Git revision history has a lot of benefits as part of the development process.

But our product is the source code, we are using scripted languages that don't need compilation or processing, and then the Git history becomes a burden on deployment- in our example we deploy a clean virtual environment following every change, having several deployments on a single machine.

There are some ways to reduce the amount of history, for example shallow clones whose efficiency depends on how deep the revision is in the branch, doing a fetch instead of clone but then you still get history from the revision and back, or getting the full repo once then pull when needed but this is wasteful in terms of disk space and tends to be less reliable.

Is there a way to get a single revision from Git without it's history ?

**Tags:** git

> **Comments:**
> **username_1**: Related Q&A at SO http://stackoverflow.com/questions/26135216/why-isnt-there-a-git-clone-specific-commit-option  

---

## 3 answers

### Answer by username_5 on 2017-03-07. Score: 16 | Accepted answer

Shallow clone
You can indeed get a shallow clone out of Git using:
git clone --depth=1 

This will still clone the repo and create a .git folder with the objects, only smaller in size (difference depending on your total file size vs. history size).
Git archive
You can also use git-archive to extract an archive of the repo:

Creates an archive of the specified format containing the tree structure for the named tree, and writes it out to the standard output. If  is specified it is prepended to the filenames in the archive.

In the examples it shows for instance:

git archive --format=tar --prefix=git-1.4.0/ v1.4.0 | gzip >git-1.4.0.tar.gz 

Create a compressed tarball for v1.4.0 release.


Hosted Git, archive API
If you are hosting your repo on GitHub, then you can use their archive API:
https://api.github.com/repos///zipball/
Bitbucket.org has a same functionality for this:
https://bitbucket.org///get/.zip

> **Comments:**
> **username_6**: username_5, maybe gzip command need to be gzip -c ....  

---

### Answer by username_3 on 2017-03-07. Score: 11

Don't deploy your git repo. Develop a real deployment methodology. Even if it's as simple as tarring up an archive (= building an artifact with just the necessary files in it to be deployed) of deployed scripts.

Even if you shallow-clone the tip of your source repository, you likely don't need unit tests, documentation, linting profiles, and other supporting ephemera in your deployed environment.

**Note**: for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. Then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools).

> **Comments:**
> **username_3**: it's okay to question (or even challenge!) an answer -- that's what makes Stack Exchange great :)  for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools)  
> **username_2**: @username_4 yes, you're missing what's is suggested as tarring an archive, I.e building an artifact with just the necessary files in it to be deployed. That said I agree that's not a quality answer and this point should be extended. We are in private beta and answers should née explicit  
> **username_2**: Then I don't see what this brings more than the accepted answer, if it's to point toward fit archive... it's just redundant, you should edit to extend on this way iMHo  
> **username_4**: Please check my edit of your answer (just integrated your interesting comment). Feel free to improve/rework of course, or just rollback if you don't like my edit at all. BTW: your comment (= note I added) made me think like "really, that simple? Again a sample of how we Get Things Done in zOS ... with z for *zero downtime* ...". I think it's time to start to question way more questions/answers via similar comments ... Don't challenge me too much ...  
> **username_3**: i don't purport that this is a complete or model answer, but i didn't see anyone else addressing the elephant in the room: if you use git to "deploy" your project, you're "gonna have a bad time" ;)  
> **username_3**: just saw your edit to put my comment in the answer, yes, thank you for that :)  
> **username_2**: @username_3 using git to deploy is perfectly fitting the goal in some situation, static angular js front ends are a good example of app absolutely ok to deploy with a git pull in my experience  
> **username_3**: you don't mind if users see unit tests & other meta/planning docs? and you don't mind resolving merge failures when deploying? and you always want everything in the repo included in the delivered product, accepting unforeseen interactions w/ experimental features? yes, for simplistic/hobbyist cases, it's adequate to deploy your source repo -- but we shouldn't promote it as best practice. by the time you're trying to optimize away little things like storage overhead of the git object database (which is pretty good at deduplication), you might want to look at more explicit release methodologies.  
> **username_0**: Actually there is a reason to why we son't use achieved artifacts. Our product is part of a bigger build system, where each build might use a different revision of the product. That means we need to keep (or generate on the fly) an archive for each Git revision. Git archive solves most of that,  with the exception of having unnecessary files.  
> **username_2**: @username_3 I've been unclear sorry, we have 2 apps like this,  we deploy branches per environment, chef run every 30 mins on the machines and a simple merge into a branch allow a deploy within 30 mins. Preventing access to unit tests/non relevant files is done by the webserver configuration. I agree this is a simplistic case, and adding a level of overhead with a build/package/store wouldn't bring really much for those simple cases. That doesn't mean promoting it for everything, but I think it shouldn't be frowned upon on *all* cases neither.  

---

### Answer by username_2 on 2017-03-07. Score: 6

> Question is there a way to get a single revision from Git without it's history ?

To get a repository, no there's no way, mainly because there's no 'revision'. Git store commits, which are changes from previous state.  
If you want your repository at a specific point in time you have to pull the commit at this time and all it's ancestors or you'll get only the changes made in the commit.

To avoid confusion: Shallow cloning is getting the needed history and then truncating it to free space, the tree is still made from history.

For the solutions, @username_5 answer does cover them.


---

