On Fri, 19 Sep 2008, Junio C Hamano wrote:
Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
Regarding _the_ recommended workflow, I can think of a few possible
approaches:
a) Authoritative: either because we really believe it's the One True
Workflow, or just because we want to sound so.
b) Descriptive: describe it as the workflow "we" use (presumably this
includes linux.git which may be worth mentioning; I haven't touched
the kernel though).
c) Encyclopedic: describe and classify as many recipes (building
blocks) and workflows as possible in an attempt to build a
complete reference of sorts.
d) Blind eye: we're just the tool. Others can devise workflows.
I certainly aimed the patch at (a), since I wanted to be able to point
people at it (mostly on #git). The resources I learned Git with,
except for the videos, just show simple examples of pull/push usage,
which I found both unsatisfactory (e.g. I want to know _why_ it's a
good idea to make topic branches) and incomplete. This list is an
excellent place to learn, but I doubt that's an effort the average
user is willing to put in.
I think we should be honest and not try to do (a) nor (c). And as I
already said, as (b) your description looked fine, but it wasn't very
encouraging that not many people commented on it (nor said "Yeah, that's
what I was missing, thanks").
there is no workflow that is right for every situation, so only describing
one (A or B) is very limiting (even if you don't claim that it's the One
True way)
We've seen that D doesn't work well (people are confused and create
horribly bad workflows, decide that git is too confusing and too limited,
and tell everyone they know)
I think C is best. this doesn't mean that we need to imagine and create
every possible workflow, but including the workflows that we are sent (and
commenting on advantages/disadvantages of them) would be very helpful for
people just getting started with a project. Having a catagory of 'how not
to use git' with some of the worst examples would be very educational.
In almost all cases where people have spoken up and described their
workflow (and the pains involved with it) the git experts here have been
able to simplify things for the user (either by pointing out better ways
to do the same thing, or in some cases by tweaking git to better support
the different class of workflow)
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
