Re: [PLUG] git-fu

[Frank Szczerba <frank@szczerba.net>]

On Oct 25, 2012, at 3:18 PM, Rich Freeman <r-plug@thefreemanclan.net> wrote:

> On Thu, Oct 25, 2012 at 1:35 PM, Eric at Lucii.org <eric@lucii.org> 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.

You can also use the reflog, which keeps track of every change to HEAD and to branch tips within a repository. Just run "git reflog" to see where HEAD has been (including all checkouts, rebases, pulls, etc). You can inspect a particular branch by naming it: "git reflog master" for example.

> 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.

This is another good reason to work in branches. Before merging a working fix in you can use "git rebase -i" to clean up the history, remove false starts, improve log messages, etc, ensuring that the mainline has a clean development history that only contains meaningful changes.

> 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.

Exactly. Note that these dangling objects are eventually cleaned up by garbage collection, but they stay around for at least a month or so.

> 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'm not sure what you mean here. Are you talking about the work git has to do behind the scenes? From a user perspective it's simple:

$ git diff refA..refB path1 path2 path3....

This is very fast, even on a large repo like the kernel sources.

> 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.

Sounds interesting, I'm looking forward to it.

> 
> Rich
> ___________________________________________________________________________
> Philadelphia Linux Users Group         --        http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

Frank
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug