Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2014-04-25 at 20:36 -0500, Felipe Contreras wrote:
> Jeff King wrote:
> > If you are waiting on me, I do not have much else to say on this topic.
> > @{publish} as specified by Felipe is not useful to me, and I would
> > continue to pursue @{push} separately as "the remote-tracking branch of
> > where you would push to". I think there is room for both concepts.
> > 
> > As for the patches themselves, I have not reviewed them carefully, and
> > would prefer not to. As I mentioned before, though, I would prefer the
> > short "@{p}" not be taken for @{publish} until it has proven itself.
> 
> Presumably you want to save it for @{push}. While I'm not against to having
> just @{publish} for now, I'm farily certain most people would be using
> @{publish} and not @{push}, as that's what `git branch -v` would show, and it
> would be closely similar to @{upstream}. Therefore it would make sense to use
> @{p} for @{publish}

TL;DR: Presumably you want to grab it for @{publish} without evidence to
support a decision either way. 


The thing with shortened forms and abbreviations is that they assume a
mode of thought. Human communication assumes a lot of shared context,
hence the disconnect between code (explicit) and intent (often dependent
on context of conversation). Abbreviation is a form of compression using
context as an implied key.

Users who do not share your context will not find your abbreviation
intuitive. If a consensus context cannot be identified, abbreviation may
be interpreted as an attempt to impose a context. In other words, 'of
the many valid workflows enabled by git we obviously prefer this one
because we have provided more shortcuts for it'.

Attempts to impose context are not unreasonably perceived as political.

Saying that you are 'fairly certain' that most people would be using A
over B 'and therefore' we should support A smacks of political
manoeuvring rather than scientific experimentation.

The scientific approach is to provide both long options and record how
they are used, rather than gravitating towards an abbreviation of a
preferred option which may receive limited use.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]