Merging commits in git

Question

I have a git repository with hundreds of commits. When I clone it, I get a lot of output like this:

... got ac6d99d2762efe0fcf2b78656e336c25ca8428d5 got ef98d4e93c680384f8174b95e431627b29a56580 got 4d6e1231e0f6265458a8e6ab47a44bfcd357486b got 7e3d3a2fc10d0dfe00e87e8eed4a3fc1efa5eaed walk b43c1e0062b72d3ab416ad209e94e13a6c71815d ...

This corresponds to every single commit, which is annoying. Is there a way of "merging" the commits (don't need them anymore) besides the (obvious) import of HEAD into a new repository?

Edit: The clone cmd is done with the http method.

Answer 1

If you only have issues with git clone, you could try using the -q flag to tell it to be more quiet.

If you want to merge commits, use git rebase -i. In git parlance, merging one commit into another is known as "squashing". Keep in mind that this only affects the current branch. If the commits exist on other branches, they will still exist on other branches.

Answer 2

don't need them anymore

What do you mean by this? For better or for worse, the HEAD commit of any given repository points to its parent, which points to its parent, all the way back to the very first commit ever made.

• Is the output of git-clone cluttering up the screen? You can avoid this by using the -q flag to make it quieter. You could also upgrade — in version 1.7.1, I do not get the long list of commits unless I ask for extra verbosity (with -vv).

  The chatty output only happens in the unsophisticated HTTP protocol. Using the git or ssh protocols is more efficient, and GitHub supports all of them. Also, read about the new Smart HTTP Transport.

• Are you used to centralized VCS, where a working copy only has the latest version? The best equivalent is probably a shallow clone, created with git clone --depth=n, where n is how much history you want. It has some limitations which you should read about, but it lets you clone only the recent history and still make changes that can be pushed back.

  You don't save as much space as you might expect with a shallow clone, by the way — I picked a random project, and the 2.2MB of history shrank to 1.2MB when I only grabbed the latest commit. Git's pack is very space efficient.

• Do you really want to throw away all that history? An important lesson in git is that any modifications to history make your repository incompatible with its origin — if you rebase to squash them all, or else throw away all the history and start over, you will not be able to communicate with the origin repository.