Re: wip push- rebase first

[Aleksej Saushev <asau%inbox.ru@localhost>]

Greg Troxel <gdt%ir.bbn.com@localhost> writes:

> Hauke Fath <hf%spg.tu-darmstadt.de@localhost> writes:
>
>>> Is it really unreasonable to expect developers with commit privileges
>>> to familiarize themselves with the tool on their own?
>>
>> No, it isn't, but... 
>
> Well, it's a bit unreasonable given the space between understanding git
> itself and knowing what the norms are in a particular project that uses
> it.
>
>> I've seen proponents of a certain VCS that shall remain unnamed suggest 
>> several times that NetBSD needs to switch to said VCS asap, because 
>> prospective new developers are being turned away by having to 
>> familiarize with CVS <http://www.netbsd.org/developers/cvs-repos/>. 
>
> I think both of these can be true at once.  It really does seem like the
> people coming to programming and open source are no longer aware of CVS.
> While git is harder to learn, other than niche participation in the open
> source world now requires knowing it, so the point is that the new
> people have already slogged through it, regardless of netbsd/pkgsrc.
>
>> At that point, it is mildly amusing when those proponents deny the need 
>> to document workflows as they apply to WIP for said VCS - which, since 
>> it was originally designed for a vastly different development model, 
>> does not have one obvious way of being used.
>
> I agree; workflow does need documenting.  I tried to list what I think
> the norms are.  People who get used to git in an environment with strong
> norms about avoiding needless merge commits and 1st-parent history are
> likely not to realize that these are workflow definition issues, not
> "just using git".  But I see them as good practice in the sense of
> craftsmanship.
>
> Does:
>
>   create commits that are single, complete logical changes
>
>   don't create (or rebase out) unnecessary merge commits (such as the
>   ones created by git pull)
>
>   ensure that for any commit you push, the first-parent ancestry points
>   back to the commits that were already on the branch (without a merge
>   commit, this is trivially true)
>
> seem adequate?

No, it is inadequate. Humans should not do what machines can do themselves.

You assume above that people have learned using git the way you intend already,
but this is absolutely unreasonable assumption especially in a project like wip
or pkgsrc itself. Even if you ignore the utter crappiness of git itself, you
impose restrictions on git usage that are equivalent to making it behave like
Subversion.

Similarly, if you impose such unnatural conditions on your users, you ought
to write a tutorial. On git, yes. Especially, if you use terms that make
no sense in git context. In particular, can you tell me how am I to detect
"the commits that were already on the branch"? Which branch?


-- 
HE CE3OH...