On Thu, Jan 3, 2013 at 2:24 PM, Roy Stogner <[email protected]>wrote:
> I didn't know that; thanks. I agree completely. I'm still not even > entirely certain whether it's a good idea to use an interactive rebase > to squash the occasional "commit N" and "commit N+1 fixing the bug > just introduced by commit N" together in a private branch. > Yeah - this is a personal decision. Here's what I generally do: 1. Create a branch for a new task (always!) 2. Commit incrementally as I work on the task and get to "save" points (ie, it compiles, it works in serial, it works in parallel, etc.) 3. "git rebase -i" and squash what others don't want to see. 4. git fetch upstream 5. git rebase upstream/master 6. git push upstream HEAD:master What I mean by #3 is that I decide if others would care to see each incremental checkin (ie, would someone ever want to rollback to one of my incremental checkins?). Usually I decide most people don't want to see all my tiny commits... and I squash them all into one "feature commit" that encapsulates a fully working patch. Sometimes I might leave the trail of my commit messages in that squashed commit as a reminder of all the things that I did (in case there is a bug and I need to remember what happened) other times I just write essentially "Implementing feature X" ;-) But yeah - I, personally, usually squash to individual features. Derek ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
