Re: [PATCH 0/3] Support config-based names
Daniel Barkalow <barkalow@iabervon.org> writes:
Show 7 quoted lines
> On Mon, 11 Jun 2007, Junio C Hamano wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> What I'm worried about is whether we'll eventually want some sort of
> function and an object with the same name, and then have to have a syntax
> problem with legacy functions being confusing.
I would agree that I'd worry about that; we will eventually want some sort of function that is user customizable from command line, in the same sense as "@{any date specifier}" but possibly stronger. And at that point, even [] would get in the way of that scriptable part. I'd prefer to provide a set of well defined and usable "atoms" and let the people script with them.
Show 10 quoted lines
>> We need to see how useful this would be in practice; we would
>> not want to add new syntax without a set of convincing use
>> cases. At this point, it still feels as if it is a feature that
>> was implemented only because it could, not because there was a
>> real need.
>
> I'd be a lot more reliable at using git if git-commit reported "git log
> --pretty=oneline HEAD^{push}..HEAD" after each commit (if there is a
> HEAD^{push}). I'm forever committing things and forgetting to push them
> when I mean to.First, I think 'push' is a misnomer for that purpose, as your widely popular "pretend we immediately fetched back" topic made remote tracking branches, which were originally associated more strongly to 'fetch', associated equally well to 'push'. You are comparing what the remote counterpart of your current branch has (or supposed to have) with what you built. So I would have called it 'remote'.
Second, more importantly, that functionality to do log or diff would go to post commit hook script, and you shouldn't have to have such a built-in "function" and new syntax to implement that. I think more generally useful would be a change to "git remote" to teach what "git-parse-remote" historically has done, so that scripts can ask things like:
- what is the symbolic name of the remote associated with my
current branch (i.e. branch.$current.remote)?
- what is the url of the remote given its symbolic name
(i.e. remote.$remote.url and URL: in .git/remotes/$remote)?
- what branch at the remote would my current branch pushed to
(i.e. $current mapped through remote.$remote.push and Push: in
.git/remotes/$remote)?
- what remote tracking branch I am using to track that branch
(i.e. that remote branch mapped through remote.$remote.fetch
and Pull: in .git/remotes/$remote)?
- what remote branch do I usually merge into my current branch
(i.e. branch.$current.merge or the "first refspec listed"
fallback)?
and combinations of the above. I would even prefer the "combinations" to be performed by callers of "git remote", iow, in your hook script, not as myriad of "git remote" options.
> I didn't have a particular need for ^{merge}, but I accidentally wrote it
> first because I was confused as to what I wanted.The last question above is there for completeness. I think it would also be a good thing to give to the user.
In other words, I think the questions I listed above are "atoms" at more appropriate granularity to build flexible tools out of in order to fit people's different workflow, and I think it is way premature to embed only a selected-few combinations of them into syntax sha1_name.c understands.
Daniel Barkalow
