Thanks for the thoughts. I am not part of a team in this particular 
instance. And I am basically just learning git and perhaps how I, 
personally, want to use it for some of my own purposes. I tend to do a 
commit after each successful edit/compile/test cycle. Mainly so that I can 
change my mind easily. A sign of "ad hoc" design on my part, which I agree 
is not optimal or even very good/wise. The rebase seems like an interesting 
idea as well. The two books discourage it. But they are talking about 
rebasing a published repository which some one else may have cloned.

I tested the "git merge --squash" and it is just what I was looking for in 
my original scenario.

On Monday, December 3, 2012 6:54:15 PM UTC-6, John McKown wrote:
> I've been reading "Version Control using git" (already finish Pro Git). 
> One thing the author said was that git really encourages developers to 
> commit frequently. Mainly because they have an entire (at the time) copy of 
> the repository. So there's not a lot of overhead of sending files across 
> the Internet (or Intranet). This sounds good to me. Basically, what I like 
> to do is: "until satisified do; edit; compile; test; commit; done " I do 
> this for every program. Once a "change" is complete, i.e. all programs and 
> files modified, and tested, I then do a "git push" to the repository.
> But it occurs to me that this is a lot of commits for what is logically a 
> single change. Would it be "better" to implement a single "change" as a 
> single, well documented, commit? If so, then how to eliminate all those 
> commits? What I've read says to do something like create a new branch; do 
> all your development and commits in that branch; then do a "git checkout" 
> back to "master" and do a single "git merge" of the new branch. The way 
> that I read the doc, what happens is that your branch remains and the 
> "master" branch commit has two parents. One from "master" the other from 
> the "change" branch. What I was thinking would be better would be to 
> completely remove all vestiges of the "change" branch. I think this can be 
> done by abusing git as follows:
> git tag starting
> git branch changes
> until satisfied; do edit; compile; test; commit; done #use the changes 
> branch for all development
> git merge --no-commit changes
> git branch -d changes
> git reset --soft starting
> git tag -d starting
> git commit #put in a single commit with very detailed documentation
> git push #push the change up to the origin
> Does this seem reasonable? Or am I entirely out of the ball park?


Reply via email to