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