I'm glad the squash merge is what you were looking for. It's true that you
should avoid rebasing public history, but if you're not working on a team,
you can rebase to your heart's content without worrying about messing
anybody up. With your workflow, it sounds like interactive rebasing might
be very helpful. It lets you condense all those small commits into a
meaningful history.

On Dec 4, 2012 8:29 AM, "John McKown" <john.archie.mck...@gmail.com> wrote:

> 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