Re: git annoyances

From: Karl Hasselström <kha@treskal.com>
Date: Apr 11, 2008, 07:00 UTC
Message-ID: <20080411070016.GA25970@diana.vm.bytemark.co.uk>
In-Reply-To: <32541b130804100805o4ad1e9a6x38e9b1fcf17c5d1d@mail.gmail.com>

On 2008-04-10 11:05:07 -0400, Avery Pennarun wrote:

Show 13 quoted lines

> On Thu, Apr 10, 2008 at 4:41 AM, Karl Hasselström <kha@treskal.com> wrote:
>
> > The @rev is called a "peg revision", and is different from the
> > "operative revision" specified with the -r flag. The peg revision
> > is used in conjunction with a path to specify the file (or
> > directory) you want, and the operative revision is used to specify
> > which revision of that file you mean.
>
> Yes, but I believe you get the one from @rev if you don't specify
> -r.
>
> For example, I can ask for an "svn diff svn://blahblah@56
> svn://blahblah@59" and it'll feed it to me as expected.

Ah, I didn't know that. But the URL I threw at you agrees:

Show 5 quoted lines

> Note that even when you don't explicitly supply a peg revision or
> operative revision, they are still present. For your convenience,
> the default peg revision is BASE for working copy items and HEAD for
> repository URLs. And when no operative revision is provided, it
> defaults to being the same revision as the peg revision.

Clearly, I need to use Subversion more, and not fool around with git all the time. :-)

Show 10 quoted lines

> > (This complexity is needed because subversion has a concept of
> > file identity.)
>
> File renames make diffing and merging complicated no matter whether
> you track them or not.
>
> svn's tracking of file identity is additional, but doesn't increase
> the (UI) complexity in the common case. At least with svn, a newbie
> can even get real work done without even knowing about -r *or*
> @notation.

I don't quite agree with you here. Subversion stores extra state, and that state needs to be considered (in the general case) when predicting what Subversion will do. There are a large number of simple cases where the user doesn't have to care, as you say, but every so often there's a case that's not so simple, and in those cases I _really_ prefer git's data model to Subversion's.

> Compare that to arbitrary differences in behaviour between
> "git-fetch" vs "git-fetch a" vs "git-fetch a b", or the difference
> between HEAD^ and HEAD~1 and HEAD@1. git is very powerful, but also
> definitely more complex for beginners.

Oh, I'm not arguing on that point. I like git because it's beutiful on the _inside_.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle