git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Alex Davidson <descenterace@hotmail.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Apr 2014, #08; Fri, 25)
Date: Sat, 26 Apr 2014 01:04:10 -0500	[thread overview]
Message-ID: <535b4c5a3c91c_3d63109d2f00@nysa.notmuch> (raw)
In-Reply-To: <BLU0-SMTP3741FBD4980A29338AC8BA8D1450@phx.gbl>

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

  reply	other threads:[~2014-04-26  6:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 22:50 What's cooking in git.git (Apr 2014, #08; Fri, 25) Junio C Hamano
2014-04-25 23:19 ` Jeff King
2014-04-26  1:36   ` Felipe Contreras
2014-04-26  2:43     ` Alex Davidson
2014-04-26  6:04       ` Felipe Contreras [this message]
2014-04-26  9:39         ` Philip Oakley
2014-04-26 19:35           ` Felipe Contreras
2014-04-26  4:25     ` Jeff King
2014-04-28 17:48   ` Junio C Hamano
2014-04-28 18:01     ` Jeff King
2014-05-09 16:53   ` Michael Haggerty
2014-05-09 17:07     ` Felipe Contreras
2014-05-09 17:51     ` Philip Oakley
2014-05-12 21:05     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=535b4c5a3c91c_3d63109d2f00@nysa.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=descenterace@hotmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).