Re: More Beginning Git Questions

From: tactical <a5158017@nepwk.com>
Date: Sep 25, 2011, 02:16 UTC
Message-ID: <1wllqv48uqfjq.lt9yp4rbxugb.dlg@40tude.net>
In-Reply-To: <201109242259.p8OMxqIM026259@no.baka.org>

Seth Robertson wrote:

Show 21 quoted lines

> As I explained on IRC, you can use the following workflow to create a
> three way merge.
> 
> git stash
> git fetch
> git merge @{u} stash
> git mergetool
> git stash drop
> 
> You can then do whatever other work you want.  You can repeat this
> workflow as often as you want.  When you are done, then you can
> commit:
> 
> git commit -a -m "My important work"
> 
> This is of course easily scriptable so it becomes one command to you.
> And since you mentioned it, if the merge went poorly and you wanted to
> start over (only before you dropped the stash of course), you can:
> 
> git reset --hard HEAD
> git merge @{u} stash

Thanks. It's a shame, however, that Git makes the user jump through hoops to achieve such a simple thing.

> Of course, I would recommend you consider some of the more gitish
> workflows.

And that, I feel, is a problem with Git. In some cases, you can't do things how you want -- you have to do things how Git wants.

Another example of this is the lack of support for anonymous branching as part of a normal workflow in Git. Anonymous branching is very powerful and very simple. I use it all the time in Mercurial.

Show 5 quoted lines

> Commit early and often.  `git pull --rebase` as often as
> you want, and then use `git rebase -i @{u}^` to squash all of your
> in-progress commits together.  With appropriate in-progress commit
> message crafting, you can use the --autosquash functionality of
> git-rebase to make this process easier.

Thanks for the ideas, but they don't solve my particular problem. The reason I regularly pull with local changes is that I like to use clones for short-term branching (because it's powerful and flexible -- for example, when I create my "TryFeatureX" clone, I have two versions of my project on disk, and I can run them side by side).

In order to avoid pointless merges, I sometimes don't commit until I've pulled. Sure, I could commit and then rebase instead, but, in this situation, rebasing is effectively merging and committing in one step. With my workflow, however, after I merge, I can still make changes (and do other stuff like running unit tests) before finally committing.