Hi Mike,
On Thu, 9 Feb 2017, Mike Rappazzo wrote:
> On Thu, Feb 9, 2017 at 5:54 PM, Junio C Hamano wrote:
> >
> > That leaves what the right single-step behaviour change should be. As
> > I recall Duy said something about --common-dir and other things Mike's
> > earlier change also covered, I'd
On Thu, Feb 09, 2017 at 01:50:31PM -0800, Junio C Hamano wrote:
> > There is just no way you can "fix" this otherwise. As an occasional shell
> > scripter, you may be tempted to use `$(git rev-parse --show-cdup)$(git
> > rev-parse --git-path filename)`, but of course that breaks in worktrees
> > a
On Thu, Feb 9, 2017 at 5:54 PM, Junio C Hamano wrote:
>
> That leaves what the right single-step behaviour change should be.
> As I recall Duy said something about --common-dir and other things
> Mike's earlier change also covered, I'd prefer to leave it to three
> of you to figure out what the fi
Johannes Schindelin writes:
>> I have no strong opinion for or against a "longer term" solution
>> that makes "rev-parse --git-path" behave differently from how it
>> behaves today, but I am not yet convinced that we can reach that
>> longer term goal without a transition period, as I suspect the
Hi Junio,
On Thu, 9 Feb 2017, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Relevant thread in the past [1] which fixes both --git-path and
> > --git-common-dir. I think the author dropped it somehow (or forgot
> > about it, I know I did). Sorry can't comment on that thread, or this
> > patc
Johannes Schindelin writes:
> On Wed, 8 Feb 2017, Junio C Hamano wrote:
>
>> How long has "rev-parse --git-path" been around? Had scripts in the
>> wild chance to learn to live with the "output is relative to the top of
>> the working tree" reality? I think the answers are "since 2.5" and
>> "y
Hi Junio,
On Wed, 8 Feb 2017, Junio C Hamano wrote:
> How long has "rev-parse --git-path" been around? Had scripts in the
> wild chance to learn to live with the "output is relative to the top of
> the working tree" reality? I think the answers are "since 2.5" and
> "yes".
Correct. And the thi
Duy Nguyen writes:
> Relevant thread in the past [1] which fixes both --git-path and
> --git-common-dir. I think the author dropped it somehow (or forgot
> about it, I know I did). Sorry can't comment on that thread, or this
> patch, yet.
>
> [1]
> http://public-inbox.org/git/1464261556-89722-1-
Hi Mike,
On Thu, 9 Feb 2017, Mike Rappazzo wrote:
> On Thu, Feb 9, 2017 at 4:48 AM, Duy Nguyen wrote:
>
> > Relevant thread in the past [1] which fixes both --git-path and
> > --git-common-dir. I think the author dropped it somehow (or forgot
> > about it, I know I did). Sorry can't comment on t
On Thu, Feb 9, 2017 at 4:48 AM, Duy Nguyen wrote:
> On Wed, Feb 8, 2017 at 7:17 PM, Johannes Schindelin
> wrote:
>> In addition to making git_path() aware of certain file names that need
>> to be handled differently e.g. when running in worktrees, the commit
>> 557bd833bb (git_path(): be aware of
On Wed, Feb 8, 2017 at 7:17 PM, Johannes Schindelin
wrote:
> In addition to making git_path() aware of certain file names that need
> to be handled differently e.g. when running in worktrees, the commit
> 557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
> 2014-11-30) also snuck in
Johannes Schindelin writes:
> The problem lies deeper, much deeper...
> ... but it bought us many, many problems.
I think you are making a mountain out of molehill here.
This looks like as an opposite problem of a bug that forgets to
prepend the prefix to relative pathnames given by the end us
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it,
13 matches
Mail list logo
