Re: [Rails-devel] Git troubleshooting

[brett l. <bre...@gm...>]

On Thu, Jul 21, 2011 at 11:41 AM, Stefan Frey <ste...@we...> wrote:
> 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 ...).
>

Git is a *very* different tool, written to *very* different requirements.

SVN is "CVS done right", ignoring the fact that the CVS design is
fundamentally flawed and using a development methodology from the
1980s (the initial release of Gnu RCS was in 1982, and CVS is the
successor to RCS). Whereas Git is "Let's make a brand new VCS that can
handle the current linux-kernel development model."  Git is solving
today's problems where SVN is (re-)solving 20-30 year old problems.

I've had numerous problems over the years with corrupt SVN DBs; or
somebody using the wrong version of the SVN client and the stupid
server auto-upgrades the central SVN repo's DB, which makes all other
clients incompatible and causes much breakage. There are many design
decisions that SVN made that, IMO, are seriously flawed.

One of the things Git does right, IMO, is that it doesn't complicate
things with crap like using a DB. Everything in the .git directory is
a file. Your changes are stored as plain-text diffs. For performance,
Git gzips the files and repacks them, but they're all accessible for
viewing if you care to look.

I have a suspicion that this is the reason that I can muck with Git
outside of Eclipse and have EGit "just work". It doesn't have to
interface with a DB. It just looks at the state of the filesystem and
can see updates and just automatically refresh the view inside
Eclipse. As I've seen Linus post a few different times, "Git is a
stupid content tracker."  It's stupid, which makes it very smart. ;-)

> 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.
>

Agreed. The screenshots aren't super-helpful and a few are even outdated.

But, that's the way they chose to write their docs.

>>
>> 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?

Rebasing is changing the ordering of the commit history. It's an
incredibly important and powerful feature, but changing history is one
of those topics that's traditionally very scary to users. And, yes,
I've seen a number of "OMG! Rebasing ate my baby!" blog posts from
users who have misused or misunderstood the feature.

It's the one feature that trips people up the most because it's a
completely foreign concept if you're coming from CVS/SVN.

My point was, it's not the default behavior for good reason. However,
for the simple "git pull" operation, it tends to be the best option
(once you understand how it works) because it keeps the commit history
cleaner and separates the "update from upstream" and "merge your local
work" steps into two discrete actions. This separation makes it more
clear when the rebase of upstream changes causes a merge conflict and
when your local changes are causing the merge conflict.

This is one of those areas in which; unlike CVS/SVN, where you can get
away with not caring about the tool's internals; it is very helpful to
have some knowledge of _how_ Git works because it helps you do more
advanced things with the repository.

>
> 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.
>

Yep. We're going to need to learn platform-specific issues with the
new tool. My main machines are running Linux or Mac OS X. I've got an
old Windows machine I use occasionally, but not often.

> Hope it will soon all be sorted out.

Yes. Unfortunately, this is one of the down sides to EGit. For better
or worse, they decided to use a complete re-implementation of Git in
Java (JGit) instead of just hooking into the pre-existing tools and
libraries. It's not the choice I'd have made, but that's what they
went with. I'm certain it'll get better over time. Judging by the
mailing list, the project is under active development, so we should
see fixes relatively soon. The project has already come a long way in
the last year (when we opted for CVS->SVN instead of CVS->Git) and I'm
confident these issues will be sorted relatively soon.

> Stefan
>

---Brett.