Daniel Jomphe's Library tagged mercurial →  View Popular

Note that we didn't use "commit -a" this time. This means that "git
commit --amend" will amend only the commit message and not any of the
actual files being tracked, (even if some of them had been modified
between the commits).

It's also possible to use "git commit -a --amend" to similarly fix up
mistakes noticed in code. That will replace the most recent commit
with a different commit based on any new changes to files.

If you have a situation where you want to pull a single time from some
repository, then you can simply give the path or URL of the repository
on the "git pull" command line. However, it's often the case that if
you want to pull changes from a repository once, you'll want to pull
changes from that same repository again in the future. This is where
the "git remote" notion is extremely useful---it allows you to
associate simple names, (and behaviors), with remote repository URLs

We've already seen one instance of "git remote" which is the creation
of the "origin" remote which happens automatically during "git
clone". Let's now create another. Let's assume you are going to be
working in the hello-remote repository and you'd like to pull changes
from the hello-pull repository, where your friend "fred" has been
making changes. Here's how to setup the new remote:

Now, generally the
purpose of pushing to a repository is to have some "collaboration
point" where potentially multiple people might be pushing or
pulling. Because there might be multiple people pushing into the
repository at any point, it wouldn't make sense to have a
working-directory associated with this repository.

For this, git has the notion of a "bare" repository, which is simply a
repository with no working directory. Let's create a new bare
repository and push some changes into it:

Writing a tool to do something that you want is often quite a simple matter of plugging together a few core commands.

It's simple enough that once a few basic concepts are there, you begin to feel comfortable knowing that the repository just can't wedge, changes can be discarded yet not lost unless you request them to be cleaned up, etc.

Disk might be cheap, but my /home is always full -
git has a separate step for compacting repositories, which
means that delta compression can be far more effective. If
you're a compression buff, think of it as having an arbitrarily
sized window, because when delta compressing git is able to match
strings anywhere else in the repository - not just the file
which is the notional ancestor of the new revision.

This space efficiency affects everything - the virtual memory
footprint in your buffercache while mining information from the
repository, how much data needs to be transferred during "push" and
"pull" operations, and so on. Compare that to Subversion, which
even when merging between branches is incapable of using the same
space for the changes hitting the target branch. The results speak
for themselves - I have observed an average of 10 to 1
space savings going from Subversion FSFS to git.

Ok, so you've already gone and made the
commits locally that you wanted to publish back to the Subversion
server. Perhaps you've even made a collection of changes, revising
each change to be clearly understandable, making a single small change
well such that the entire series of changes can be easily reviewed by
your fellow project contributors. It is now time to publish your
changes back to Subversion.

The command to use is git svn dcommit. The d stands for delta