Re: [git-users] Clarification Regarding Git Commit Granularity
On Thu, 6 Jun 2013 22:49:24 -0700 PJ Weisberg pjweisb...@gmail.com wrote: So, one thing I'm still a bit fuzzy on is the recommend granularity of commits, and I'm wondering if anyone can help me out. [...] If I understand correctly, you're making two logical changes, each of which touches several files. Then of course you'll want to make two commits. Put them in one commit and you're unnecessarily tying together unrelated things. Break them up into ten or twenty commits and you have a bunch of half-done changes that don't actually work and need to be combined with other commits before they actually make sense. By putting each change into a single commit you have a piece of working software after every revision, which makes it easier to bisect when diagnosing a bug, for example. But note that it's a normal Git practice to crunch a series of small commits which introduce partial changes (and comprise non-working states of a program) on a private feature branch, and then squash-merge [*] them into a single pretty commit on an integration branch which is to be published (i.e. pushed somewhere). You don't *have to* take this route but some people prefer to do things this way. One upside of this approach is relative ease of rolling back to any committed state while you're exploring possible ways to implement a feature by trial and error. [*] Read up on the --squash option of the `git merge` command. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Problem with git checkout --orphan
On Thu, 6 Jun 2013 14:51:50 -0400 wor...@alum.mit.edu (Dale R. Worley) wrote: [...] $ git --version git version 1.7.7.6 [...] $ # Try to create an orphaned branch. This fails. $ git checkout --orphan first-new-branch fatal: You are on a branch yet to be born Works for me with Git 1.8.1: C:\tmp\foogit init Initialized empty Git repository in C:/tmp/foo/.git/ C:\tmp\foogit checkout --orphan foo Switched to a new branch 'foo' C:\tmp\foogit checkout --orphan foo2 Switched to a new branch 'foo2' C:\tmp\foogit checkout --orphan foo3 Switched to a new branch 'foo3' C:\tmp\foogit --version git version 1.8.1.msysgit.1 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Problem with git checkout --orphan
From: Konstantin Khomoutov flatw...@users.sourceforge.net Works for me with Git 1.8.1: Good. I will check again when I upgrade to Git =1.8.1. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Re: Problem with git checkout --orphan
From: Thomas Ferris Nicolaisen tfn...@gmail.com Repos (or branches) without history are funny places where a lot of operations make less or more sense. The place to address this is the Git developer mailing list, but the use-case does sound a bit, well, pointless. It's true that it's not very important, but the oddity of the situation is that while the repo is created in the state an empty repository, the first commit will create the branch master, you cannot change the state to an empty repository, the first commit will create the branch xyz. Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Getting good compression
From: Martin Mųller Skarbiniks Pedersen traxpla...@gmail.com It sounds like you are using the mbox email format where everything is kept inside a single file. That is correct. Have you considered using the Maildir fomat instead ? No, because my mail reader uses mbox format (and it might require various changes to my infrastructure). Dale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Problem with git checkout --orphan
On Fri, 7 Jun 2013 11:30:38 -0400 wor...@alum.mit.edu (Dale R. Worley) wrote: From: Konstantin Khomoutov flatw...@users.sourceforge.net Works for me with Git 1.8.1: Good. I will check again when I upgrade to Git =1.8.1. Looks like that was fixed by commit abe1998 [1] (and further improved since -- just do `git log --grep unborn -F` on Git master). 1. https://github.com/git/git/commit/abe1998 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Best approach to combine frameworks in github?
I'm new to git, and having done a fair bit of reading up I've set up a github account ready to get started. I plan to combine elements of Inuit CSS ( https://github.com/csswizardry/inuit.css) with Bones ( https://github.com/eddiemachado/bones) to create my own starter framework for Wordpress projects. My question is should I fork each of these projects and clone them locally, then edit/combine and upload to a new repository? The help info regarding forking appears to imply that you would fork a repository when you were looking to contribute to the original repository rather than create a derivative work, or perhaps that is just the most common use case? The other option I can see is to just download the repository for each as a zip file, combine/edit and then upload them to a new repository. Is there a benefit to either route or perhaps another approach that I might be missing? Thanks. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
