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

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

 



Alex Davidson wrote:
> 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 reasons why @{publish} will be useful have been documented and explained
already multiple times.

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

That is not political. Political would be if I gathered support from other
developers and said "more of us prefer this". This is not what I'm doing.

My conclusion is based on logic and reason, which are the bedstone of science.
You can make sensible decisions based on that alone, and in fact that's how
most good decisions are made.

-- 
Felipe Contreras
--
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]