Re: Cleaning up git user-interface warts

Jumping into this a day late, but:

Carl Worth wrote:

I don't see any defining difference that justifies cogito's
existence ("hide the index" maybe? let's just hide it a tiny bit more
in git). And I would like to help work to get the remaining good
stuff that has been proven in cogito---to get it pushed down into git
itself.
  

Agreed totally on the second point. It would be great if git natively 
supported everything people use in Cogito.

I find myself using native git commands for the most part, except for 
one Cogito command: "cg-update". It is vastly more convenient than 
git-pull in large part because it automatically merges upstream changes 
with uncommitted working-copy changes. I suppose you could classify this 
as "hide the index" in some sense.

Maybe I should give an example of what I mean. Suppose I have two child 
repositories (owned by different developers, say):

cg-clone repo child1
cg-clone repo child2

Now I go into both of them and make different (hopefull non-conflicting) 
edits to the same file.

echo foo >> child1/testfile
perl -pi -e 's/tree/shrub/' child2/testfile

I push the change from child1 into the integration repo.

cd child1
git-commit -a
git-push

Now I want to incorporate the change into child2, where I'm still doing 
work. With Cogito, I go to child2 and run:

cg-update

and afterwards, the upstream changes are merged into testfile and "git 
diff" still shows my local edits. With Git native commands, updating 
child2 if I'm not ready to commit yet is more like:

git-diff --binary > /tmp/patch
git-reset --hard
git-pull
git-apply /tmp/patch

I might have gotten that slightly wrong, but I think I have the general 
idea right; in any event, it's not nearly as convenient! The alternative 
is to commit then pull, but then when I want to look at my local edits, 
I have to remember to diff my working copy against the correct revision, 
which gets increasingly annoying if I update more than once.

Like others on this list, I'm also trying to sell an existing user base 
(in this case, they're using Subversion) on Git. The lack of a built-in 
equivalent to "svn update" is actually a pretty big UI annoyance for 
people whose workflow doesn't require git's more sophisticated feature 
set at a given point in time. Even a sophisticated user doesn't need the 
full power of the tool 100% of the time, so this isn't just a novice vs. 
expert thing in my opinion.

Absent Cogito, would the lack of a simple "svn update" equivalent be a 
deal-killing "throw your hands up in disgust and give up" thing? Maybe 
not, but it's a daily "ugh, why am I having to type extra commands to do 
something that only took one command in svn?" thing. So it's nice to 
have Cogito to paper over that particular wart.

If there is a native git equivalent to cg-update including the 
working-copy automatic merges, I'll be delighted to stand corrected!