git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: tactical <a5158017@nepwk.com>
Cc: git@vger.kernel.org
Subject: Re: More Beginning Git Questions
Date: Sun, 25 Sep 2011 06:22:29 -0700 (PDT)	[thread overview]
Message-ID: <m31uv4rc47.fsf@localhost.localdomain> (raw)
In-Reply-To: <1wllqv48uqfjq.lt9yp4rbxugb.dlg@40tude.net>

tactical <a5158017@nepwk.com> writes:
> 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.

A short time after "git stash" was added to Git there was proposal to
automatically use git stash to allow merging with "dirty tree",
i.e. with uncomitted changes.  This idea was abandoned, if I remember
it correctly because a.) there were too many corner-cases b.) it
wasn't necessary in most cases.
 
With merging into branch with uncomitted changes your fairly well
understood 3-way merge (sometimes virtual 3-way merge in the case of
multiple common ancestors) would turn into 4-way merge.  Even if you
can automate it somehow (I do wonder how Mercurial manages that),
there could be problem resolving conflicts, unless you happen to touch
different parts of file.

> > 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.

Please take into account the fact that when you were creating your
workflow to suit your situation you were "forced" to fit it to
Mercurial abilities and best practices.  No wonder that it does not
fit Git-ish workflows.

What you use uncomitted changes for, I would use is a separate branch,
and keep it rebasing (something like using 'mq' in Mercurial).
 
> 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.

What do you use anonymous branching for?

Note that with Git by default pushing "matching" branches, you can
create private local-only branches.  The have to have _some_ name
(even if it is 'foo/temp'), but I think that it makes them perhaps
more work to create, but easier to use (to switch branches)... and for
single anonymous branch you can always use "detached HEAD".
 
-- 
Jakub Narębski

  reply	other threads:[~2011-09-25 13:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23 14:41 More Beginning Git Questions Jon Forrest
2011-09-23 16:11 ` Matthieu Moy
2011-09-23 17:42 ` Jakub Narebski
2011-09-23 18:14   ` Jon Forrest
2011-09-23 18:44     ` Mihamina Rakotomandimby
2011-09-23 18:59     ` Jakub Narebski
2011-09-24 20:22     ` tactical
2011-09-24 20:53       ` Frans Klaver
2011-09-24 22:17         ` tactical
2011-09-24 22:59           ` Seth Robertson
2011-09-25  2:16             ` tactical
2011-09-25 13:22               ` Jakub Narebski [this message]
2011-09-25 20:23                 ` tactical
2011-09-25 20:58                   ` Jakub Narebski
2011-09-25 21:07                     ` tactical
2011-09-26  0:34                       ` Konstantin Khomoutov
2011-09-26  0:56                         ` tactical
2011-09-26  1:34                           ` Andrew Ardill
2011-09-26  1:42                             ` tactical
2011-09-26 18:03                           ` Jakub Narebski
2011-09-24 21:10       ` Jakub Narebski
2011-09-24 22:10         ` tactical
2011-09-25 13:24           ` Jakub Narebski
2011-09-23 18:47 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m31uv4rc47.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=a5158017@nepwk.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).