John Keeping wrote:
> It looks to me like setup_git_directory() returns NULL if we're at the
> top of the working tree so we do need that check. I suspect that's so
> that "!prefix" does the right thing.
Ah, yes. My bad. I expected it to return "/" on the toplevel
directory actually.
--
To unsu
On Fri, Apr 19, 2013 at 04:45:38PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > I'm not actually sure this is better. I'm more afraid of the condition
> > for outputting files changing in the future than of passing
> > output_prefix around, so I'd much rather keep that condition in
John Keeping wrote:
> I'm not actually sure this is better. I'm more afraid of the condition
> for outputting files changing in the future than of passing
> output_prefix around, so I'd much rather keep that condition in one
> place.
>
> If you really feel strongly about it, I'd prefer to extract
On Fri, Apr 19, 2013 at 03:23:37PM +0530, Ramkumar Ramachandra wrote:
> John Keeping wrote:
> > Changes since v2:
> > - Rewrite commit message
> > - Add a new test for 'prefix ignored with HEAD:top'
> > - Use '<<-\EOF' where appropriate in t1513
>
> Thanks for the re-roll.
>
> In the
John Keeping wrote:
> Changes since v2:
> - Rewrite commit message
> - Add a new test for 'prefix ignored with HEAD:top'
> - Use '<<-\EOF' where appropriate in t1513
Thanks for the re-roll.
In the previous iteration, I wasn't sure this was the right approach
because I thought it would
This makes 'git rev-parse' behave as if it were invoked from the
specified subdirectory of a repository, with the difference that any
file paths which it prints are prefixed with the full path from the top
of the working tree.
This is useful for shell scripts where we may want to cd to the top of
6 matches
Mail list logo
