Fwd: An interesting opinion on DVCS/git

Fwd: An interesting opinion on DVCS/git

[Stefan Beller]

bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity

Re: An interesting opinion on DVCS/git

[Shawn Pearce]

On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:
> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity

Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
centralized systems like Subversion. Choice is good.

However... I found some passages troubling for Git, e.g.:

---snip---
Git is so amazingly simple to use that APress, a single publisher,
needs to have three different books on how to use it. It’s so simple
that Atlassian and GitHub both felt a need to write their own online
tutorials to try to clarify the main Git tutorial on the actual Git
website. It’s so transparent that developers routinely tell me that
the easiest way to learn Git is to start with its file formats and
work up to the commands.
---snap---

We have heard this sort of feedback for years. But we have been unable
to adequately write our own documentation or clean up our man pages to
be useful to the average person who doesn't know why the --no-frobbing
option doesn't disable the --frobinator option to the
--frobbing-subcommand of git frob.  :(

http://git-man-page-generator.lokaltog.net/ shouldn't exist and
shouldn't be funny. Yet it does. :(

Re: An interesting opinion on DVCS/git

[Junio C Hamano]

Shawn Pearce <spearce@spearce.org> writes:

> We have heard this sort of feedback for years. But we have been unable
> to adequately write our own documentation or clean up our man pages to
> be useful to the average person who doesn't know why the --no-frobbing
> option doesn't disable the --frobinator option to the
> --frobbing-subcommand of git frob.  :(

IIU/RC, GSoC is not only about coding.  Perhaps doing a proper
technical editing of the manual pages could be a summer project, to
which GitHub or somebody more skilled than us developers can supply
mentorship?

RE: An interesting opinion on DVCS/git

[Randall S. Becker]

> On 03 Mar 2015, Shawn Pearce Wrote:
>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:
> > bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
> 
> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized
> systems like Subversion. Choice is good.
> 
> However... I found some passages troubling for Git, e.g.:
> 
> ---snip---
> Git is so amazingly simple to use that APress, a single publisher, needs to have
> three different books on how to use it. It’s so simple that Atlassian and GitHub
> both felt a need to write their own online tutorials to try to clarify the main Git
> tutorial on the actual Git website. It’s so transparent that developers routinely
> tell me that the easiest way to learn Git is to start with its file formats and work
> up to the commands.
> ---snap---
> 
> We have heard this sort of feedback for years. But we have been unable to
> adequately write our own documentation or clean up our man pages to be
> useful to the average person who doesn't know why the --no-frobbing option
> doesn't disable the --frobinator option to the --frobbing-subcommand of git
> frob.  :(

In real life, I do process automation, so I'm coming at this from a slightly different point of view. What appeals to me about git is the richness of processes that can be implemented with it. You may want to consider it a complex process enabler engine that happens to do DVCS. Having built one of these also, and being saddled with huge numbers of requirements, I can say from experience that complexity is a side effect of doing what you need to do. Like many complex products, git takes on a life of its own, and obviously chose completeness instead of simplicity as a goal. Personally, I am not complaining, but I hear the complaints too. The bigger complaints are when you cannot do your job because the engine is not rich enough (see anything derived from SCCS - yes saying that shows my hair colour), which forced my company *to* git. 

When looking at git, I personally feel that it is important to deploy simple-to-use scripts and instructions to implement the process you want to use - and I hate to leave a footprint saying this, but, people are fundamentally lazy about non-goal activities. Thinking about mundane tasks like committing and delivering is outside the typical work-instruction box, but if, as a repository manager, you need a rich engine, spend the couple of days and script it. I think the objections in the article are essentially sound, from one point of view, but omit the core domain-space of why git is around and necessary, as opposed to many other unnamed RCS-like systems that are *not* sufficient.

> http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be
> funny. Yet it does. :(

Mockery is the not the kindest form of flattery, but it sure is the sincerest. I've been the target of this too. Laugh, and suggest workflows. And, for the record, the only way you will remove atomicity/immutability of changes is out of my cold dead hands. :)

Cheers,
Randall

Re: An interesting opinion on DVCS/git

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2631 bytes --]

On Tue, 3 Mar 2015, Shawn Pearce wrote:

> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:
>> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
>
> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
> centralized systems like Subversion. Choice is good.
>
> However... I found some passages troubling for Git, e.g.:
>
> ---snip---
> Git is so amazingly simple to use that APress, a single publisher,
> needs to have three different books on how to use it. It’s so simple
> that Atlassian and GitHub both felt a need to write their own online
> tutorials to try to clarify the main Git tutorial on the actual Git
> website. It’s so transparent that developers routinely tell me that
> the easiest way to learn Git is to start with its file formats and
> work up to the commands.
> ---snap---
>
> We have heard this sort of feedback for years. But we have been unable
> to adequately write our own documentation or clean up our man pages to
> be useful to the average person who doesn't know why the --no-frobbing
> option doesn't disable the --frobinator option to the
> --frobbing-subcommand of git frob.  :(
>
> http://git-man-page-generator.lokaltog.net/ shouldn't exist and
> shouldn't be funny. Yet it does. :(

As for the different online tutorials, I'll point out that every university that 
supports it's students using Thunderbird has it's own version of a tutorial on 
how to use and configure Thunderbird. The question is if they are coverying 
their one use case of how to use git with their service, or if they are trying 
to duplicate the git documentation.


There are two reasons for having multiple books out for a piece of software

1. the software is horribly complicated to use, even for beginners

2. the software is extremely powerful, to to understand all the different 
advanced options, and when to use them, takes a lot of explination

In the case of git, there's a bit of both.

Part of the problem is that there are so many different ways to use it (all in 
common use) that there isn't one simple set of insructions that will be right in 
all the different use cases (thus the value of services that force users to 
operate in one specific model providing a tutorial in how to use it with their 
service)

At this point, Internet Lore says "git is hard to use", and if you approach any 
software with that attitude, you will find lots of things to point at to justify 
your opinion.

I'm not saying that there isn't room for improvement, I'm just saying that the 
evidence provided is not as one-sided as they make it sound.

David Lang

Re: An interesting opinion on DVCS/git

[Michael J Gruber]

David Lang venit, vidit, dixit 04.03.2015 01:53:
> On Tue, 3 Mar 2015, Shawn Pearce wrote:
> 
>> On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller <sbeller@google.com> wrote:
>>> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
>>
>> Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
>> centralized systems like Subversion. Choice is good.
>>
>> However... I found some passages troubling for Git, e.g.:
>>
>> ---snip---
>> Git is so amazingly simple to use that APress, a single publisher,
>> needs to have three different books on how to use it. It’s so simple
>> that Atlassian and GitHub both felt a need to write their own online
>> tutorials to try to clarify the main Git tutorial on the actual Git
>> website. It’s so transparent that developers routinely tell me that
>> the easiest way to learn Git is to start with its file formats and
>> work up to the commands.
>> ---snap---
>>
>> We have heard this sort of feedback for years. But we have been unable
>> to adequately write our own documentation or clean up our man pages to
>> be useful to the average person who doesn't know why the --no-frobbing
>> option doesn't disable the --frobinator option to the
>> --frobbing-subcommand of git frob.  :(
>>
>> http://git-man-page-generator.lokaltog.net/ shouldn't exist and
>> shouldn't be funny. Yet it does. :(
> 
> As for the different online tutorials, I'll point out that every university that 
> supports it's students using Thunderbird has it's own version of a tutorial on 
> how to use and configure Thunderbird. The question is if they are coverying 
> their one use case of how to use git with their service, or if they are trying 
> to duplicate the git documentation.
> 
> 
> There are two reasons for having multiple books out for a piece of software
> 
> 1. the software is horribly complicated to use, even for beginners
> 
> 2. the software is extremely powerful, to to understand all the different 
> advanced options, and when to use them, takes a lot of explination
> 
> In the case of git, there's a bit of both.
> 
> Part of the problem is that there are so many different ways to use it (all in 
> common use) that there isn't one simple set of insructions that will be right in 
> all the different use cases (thus the value of services that force users to 
> operate in one specific model providing a tutorial in how to use it with their 
> service)
> 
> At this point, Internet Lore says "git is hard to use", and if you approach any 
> software with that attitude, you will find lots of things to point at to justify 
> your opinion.
> 
> I'm not saying that there isn't room for improvement, I'm just saying that the 
> evidence provided is not as one-sided as they make it sound.
> 
> David Lang
> 

Yes, that article has a few really weak lines of arguments, such as the
tutorial count.

Also, that advice to "learn git from the file formats", which I hope
means something like "learn the structure, not recipes" is good advice
for learning any powerful toolset - rediculing it is not quite a proof
of intelligence.

And I don't think there's anything we have to regret about the basic
architecture of (the DAG/object structure of) git. (OK, the various
signature formats ;)

That being said, we all know how often we want to change the UI and
backwards compatibility keeps us from doing so. The UI could really
benefit from a fresh start, where, based on what we know now, we first
think about:

- How do we structure/denote subcommands within commands? E.g. to dash
or not to dash, default subcommand etc.

- How do we structure "read" commands vs. "write" commands? E.g. the
pairs "branch [-l]"/"branch <name>", "log"/"commit" etc.

- How do we name options consistently? E.g. -n=--dry-run everywhere

- How do we make working with the special git concepts more natural?
E.g. index, detached heads.

Michael

Re: An interesting opinion on DVCS/git

[Sitaram Chamarty]

On 03/04/2015 08:55 PM, Michael J Gruber wrote:

> Yes, that article has a few really weak lines of arguments, such as the
> tutorial count.

Here's his definition of the main draw of a DVCS:

    No, the only thing that a DVCS gets you, by definition, is that
    everyone gets a copy of the full offline history of the entire
    repository to do with as you please.

That completely misses the point.  What about committing while offline,
'git blame' months-old changes offline, or local branches that don't
have to make it to the server until they have cooked for a while, and so
on and on?

We're not all "facebooks" with multi-GB repos, and I certainly don't
care as much about disk space or bandwidth if losing those features is
the cost.

It gets worse:

    Let me tell you something. Of all the time I have ever used DVCSes,
    over the last twenty years if we count Smalltalk changesets and
    twelve or so if you don’t, I have wanted to have the full history
    while offline a grand total of maybe about six times.

I don't know how you can work on anything reasonably complex and
multi-developer without using some of those features six times in a
*week* (sometimes, six times in a *weekend*) let alone 12 years.

Re: An interesting opinion on DVCS/git

[Philip Oakley]

From: "Stefan Beller" <sbeller@google.com>
Sent: Monday, March 02, 2015 3:29 AM
> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
> --

The part that the author misses is not all the nice (or not so) stuff 
about having a copy of the full repository locally, for all the reasons 
he mentions, rather it is the *distribution of control*.

In most centralised repo systems there is also centralisation of 
control. The user does not have control. I may initiate a request for 
change, but it's authorisation is always somewhere else, to avoid my 
accidental pollution of the golden source.

The thing that a DVCS brings to the user is an ability to regain a 
little control of their own environment and to include version recording 
within it. The fact that it can be integrated seamlessly into the golden 
source makes it a great tool providing a win-win for all, especially 
when a Hub environment provides a separation between the golden source 
and the user's perambulations and peregrinations that they'd like on a 
safe server.

It is the distribution of Control, not the distribution of Code that 
makes DVCS such a winner (for users). The distribution of all the code 
is icing on the cake (though natural in a FOSS project).
--
Philip