Re: Two ideas for improving git's user interface

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Two ideas for improving git's user interface

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:18

Alan Chandler [off-list ref] 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.

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.

Re: Two ideas for improving git's user interface

From: Alan Chandler <hidden>
Date: 2016-06-15 22:42:18

On Saturday 04 February 2006 08:25, Junio C Hamano wrote:
Alan Chandler [off-list ref] writes:
quoted
Wow - light comes on.
That's good.
quoted
-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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help