Re: More Beginning Git Questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



tactical <a5158017@xxxxxxxxx> 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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]