Re: [Rails-devel] Git troubleshooting

[Stefan F. <ste...@we...>]

Brett,
thanks for your support. Some comments below.

I have used subversion for several years now (I switched to svn as soon as it 
worked somehow).

My experience with subversion was that if you do not follow the recommended 
workflow from the beginning you are in a mess (e.g. not setting up the repo 
with trunk/branch/tag, avoid berkleyDB ...).

On Thursday, July 21, 2011 07:59:43 pm brett lentz wrote:
> Ok... I've made a few small commits with EGit, and I think I'm getting
> the hang of the interface. It's a bit clumsy, but it seems to do
> everything I expect. The EGit user guide is a fairly lengthy document,
> but as Stefan noted earlier, it's got a lot of important details that
> will help you learn the interface:
> http://wiki.eclipse.org/EGit/User_Guide

The main issue I have with the document is that if you are potential user of 
git most likely you do not need snapshots of each dialog, but better 
explanations and FAQs.

It is like the assumption of Microsoft (in the beginning) that admins would 
prefer day-by-day work using a GUI.

> 
> I think everyone should probably take a step back. I have a feeling we
> tried to run before we learned to walk. ;-)
> 
> Set aside the work you've done, do a clean clone of the repo in a new
> location following the EGit User Guide. Then, find some small one-line
> change to make. Commit it, push it, as directed by the User Guide.
> Let's try to get everyone to commit and successfully push a few small
> changes before we try to bite off anything bigger. Once we've got a
> few pushes and pulls done, we can come back to the bigger pieces of
> work that are being done.

OK.

> 
> Next...
> 
> Also, in your git configs (usually a .gitconfig file in your home
> directory), it's very handy to default to always rebasing incoming
> changes. Merge commits are supposed to be meaningful, but the default
> behavior is to always merge incoming changes (and create a merge
> commit for them). The tradeoff here is that rebasing changes the
> commit history, which is potentially dangerous and less obvious than
> adding a bunch of extraneous merge commits every time you do a pull.

Now you lost me: First you suggest to always rebase incoming changings and 
then you claim that it is potentially dangerous. Why should I choose such an 
option? 

More seriously:
This is set in the branching dialog for each branch. Given the documentation 
egit should use the default from .gitconfig for new branches, the egit default 
is merging.

http://wiki.eclipse.org/EGit/User_Guide#Branching

The connection is then set for the tracking relationship (rebase or merge on 
pull) and it seems that this cannot be changed via UI (maybe by setting a 
property in the git explorer view).

see here
http://wiki.eclipse.org/EGit/User_Guide#Pulling_New_Changes_from_Upstream_Branch

And the link above has a critical reminder for Windows user:
There is an existing bug such that WIndows users should avoid "git pull" on 
the command line if using egit. 

Hope it will soon all be sorted out.
Stefan