On Thu, Jan 3, 2013 at 2:24 PM, Roy Stogner <royst...@ices.utexas.edu>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-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
