Seth Robertson wrote:
> 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.
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html