Re: [PATCH 3/8] Clean up work-tree handling

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 3/8] Clean up work-tree handling

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:24

Johannes Schindelin [off-list ref] writes:
quoted
This changes semantics, I think.

It used to be relative "up" path when no funny work-tree stuff
is used, but get_git_work_tree() now seems to return absolute,
hence this option as well.  If it introduces regression to
existing callers is up to what the caller does to the resulting
path, though.  If it only is used to prefix other things
(i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
be safe, but if the caller counted number of ../ in the return
value to see how deep it is, or if the caller expected to see
empty string in order to see if the process is at the toplevel,
this change would become a regression.
I am somewhat negative on keeping _that_ much backwards compatibility.  
Scripts which depend on show-cdup being a relative path _will_ be broken 
by work-tree.  Is it worth it to detect those errors late?
Well, one of the conditions to accept the worktree stuff was not
to break anybody who never ever uses worktree.  So if we can
keep the UP-ness of cdup, it would be much better.

Re: [PATCH 3/8] Clean up work-tree handling

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:24

Hi,

On Fri, 27 Jul 2007, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
This changes semantics, I think.

It used to be relative "up" path when no funny work-tree stuff
is used, but get_git_work_tree() now seems to return absolute,
hence this option as well.  If it introduces regression to
existing callers is up to what the caller does to the resulting
path, though.  If it only is used to prefix other things
(i.e. path="$(git rev-parse --show-cdup)$1"), the caller would
be safe, but if the caller counted number of ../ in the return
value to see how deep it is, or if the caller expected to see
empty string in order to see if the process is at the toplevel,
this change would become a regression.
I am somewhat negative on keeping _that_ much backwards compatibility.  
Scripts which depend on show-cdup being a relative path _will_ be broken 
by work-tree.  Is it worth it to detect those errors late?
Well, one of the conditions to accept the worktree stuff was not
to break anybody who never ever uses worktree.  So if we can
keep the UP-ness of cdup, it would be much better.
One could record if the work tree was changed from the default one, and 
do the old thing in that case.

But I really have to wonder what other use people concocted for 
"--show-cdup"?  Potentially some directory-counting?  But --show-prefix 
would be much better at that.

I'll try to flange something into the code to detect unchanged working 
tree, but that is rather ugly, so I'd prefer not to.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help