Rich Freeman on 25 Oct 2012 12:18:24 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] git-fu

On Thu, Oct 25, 2012 at 1:35 PM, Eric at <> wrote:
> Thanks. yes, I need to start doing all my work in branches as you suggest.
> I've read that before but have not yet developed that habit.

Just one note about reseting head back a few commits.  You won't
technically lose the work you just did, but you will find it rather
hard to find as git only has back-references and not forward ones.

If you write down the hash of your current head then you can always
get back to it.

You could also create a new branch based on your current head to mark
its place, and then move the master head back a few commits.

It all makes sense once you understand how git works.  Git has a
linked list of commits (which can have more than one parent in the
case of merges), and heads that point to commits.  Branches generally
correspond to heads (I think it is 1:1, but I could be missing some
obscure use of git I'm not aware of).

So, the master head is just a pointer to a particular commit.  From
that commit you can see all the commits before, and none of the ones
that follow (though in general commits don't follow heads anyway).

git rebase -i is another useful way to look at your past history and
manipulate it.  You can discard commits that way, or combine them.

Note that anytime you modify a commit in any way its hash changes, and
the old one is still floating in the repository somewhere, though
likely stranded without anything pointing at it.

git has a real beauty to it, though some things are surprisingly hard
to do compared to rcs/cvs.  With cvs it is very cheap to compare two
versions of a file, since it just stores the diffs per file.  With git
the only way to tell what the differences are between two commits is
to walk the entire tree doing comparisons (though this is greatly
aided by the fact that everything is hashed already).

I'll probably post a blog entry soon on my work with comparing a
converted git repository with its original csv version.  The git
portion uses hadoop to descend the tree in parallel across all commits
and end up with a per-file history.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --