Re: Two ideas for improving git's user interface

On Saturday 04 February 2006 08:25, Junio C Hamano wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> writes:
> > Wow - light comes on.
>
> That's good.
>
> > -this tutorial the first time, I'd suggest to skip to "Publishing
> > -your work" section and come back here later.
> > +this tutorial the first time, I'd suggest to skip to "Resolving Merge
> > +Problems" section and come back here later.
>
> The changes before this look very good to me, but these two
> lines do not make any sense. If you are going to talk about
> "Resolving Merge Problems", you _need_ to know about index, so
> you cannot skip the material.

Maybe - since the light has just come on, I need to understand a lot more 
about this area before I can really comment.  The tutorial invited one to 
skip it before, so I was just doing so again.

Even today when I tried to read this section again my eyes glazed over.  The 
long sha outputs from git-ls-files screams off the page "don't bother this is 
detailed technical stuff" :-(




>
> I think having a section on manual merge resolution between the
> Index File section and Publishing section makes sense.  What
> kind of merges did you have trouble figuring out when you were
> still git novice?  That would be a good starting point.
>

I STILL come out in a cold sweat (actually that is a bit over the top:-) ) as 
soon as a merge fails for whatever reason.  The problem is that I am not 
doing development full time, nor in a team, so I probably hit one about once 
every 2 months.  This means that I don't remember what to do, and need to go 
and look it up.  But where - there is nothing in my main reference places 
(Everyday Git - or before that the tutorial). 

So I normally attempt to do what I think is sensible.  Manually searching for 
files that haven't merged. Edit the lines with the
 >>>>>>
====
<<< 
markers in them until I think the resultant file is what it should be and then 
try commit again (probably cg-commit rather than git commit).  But what 
happens next is then hit or miss - sometimes it just works - sometimes it 
doesn't and I am that place where there was a long thread a couple of months 
ago entitled something like "and what do I do now?"

I must admit it normally works OK - but I have come across situations a couple 
of weeks later where a file is in an unexpected state - seems to have been 
from the wrong branch, or missing a commit I thought I had made.
-- 
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html