| Message ID | 20190129051859.12830-2-koraktor@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3,1/3] Add tests for describe with --work-tree | expand |
On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote: > Subject: Re: [PATCH v3 2/3] Setup working tree in describe We usually write subjects as "area: do some thing" which is a little easier when scanning big lists of "git log --oneline". I think it's key, too, that we only do this for the --dirty case, not always. So maybe: describe: setup working tree for --dirty or something? > This ensures the given working tree is used for --dirty. There's been a lot of digging and discussion on the list about what happens if we don't do this. Could we summarize it here? Perhaps: We don't use NEED_WORK_TREE when running the git-describe builtin, since you should be able to describe a commit even in a bare repository. However, the --dirty flag does need a working tree. Since we don't call setup_work_tree(), it uses whatever directory we happen to be in. That's unlikely to match our index, meaning we'd say "dirty" even when the real working tree is clean. We can fix that by calling setup_work_tree() once we know that the user has asked for --dirty. > The implementation of --broken uses diff-index which calls > setup_work_tree() itself. If I hadn't just read the rest of the thread, I'd probably wonder why we are talking about --broken at all. Maybe: The --broken option similarly needs a working tree. But because the current implementation calls an external diff-index to do the work, we don't have to bother setting up the working tree in the git-describe process. > diff --git a/builtin/describe.c b/builtin/describe.c > index cc118448ee..b5b7abdc8f 100644 > --- a/builtin/describe.c > +++ b/builtin/describe.c > @@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix) > struct argv_array args = ARGV_ARRAY_INIT; > int fd, result; > > + setup_work_tree(); > read_cache(); > refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, > NULL, NULL, NULL); The patch itself looks good. :) -Peff
Jeff King <peff@peff.net> writes: > On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote: > >> Subject: Re: [PATCH v3 2/3] Setup working tree in describe > > We usually write subjects as "area: do some thing" which is a little > easier when scanning big lists of "git log --oneline". > > I think it's key, too, that we only do this for the --dirty case, not > always. So maybe: > > describe: setup working tree for --dirty > > or something? Thanks as always for being an excellent reviewer who not just reviews but also gives good suggestions. >> This ensures the given working tree is used for --dirty. > > There's been a lot of digging and discussion on the list about what > happens if we don't do this. Could we summarize it here? > > Perhaps: > > We don't use NEED_WORK_TREE when running the git-describe builtin, > since you should be able to describe a commit even in a bare > repository. However, the --dirty flag does need a working tree. Since > we don't call setup_work_tree(), it uses whatever directory we happen > to be in. That's unlikely to match our index, meaning we'd say "dirty" > even when the real working tree is clean. > > We can fix that by calling setup_work_tree() once we know that the > user has asked for --dirty. > >> The implementation of --broken uses diff-index which calls >> setup_work_tree() itself. > > If I hadn't just read the rest of the thread, I'd probably wonder why we > are talking about --broken at all. Maybe: > > The --broken option similarly needs a working tree. But because the > current implementation calls an external diff-index to do the work, > we don't have to bother setting up the working tree in the > git-describe process. > >> diff --git a/builtin/describe.c b/builtin/describe.c >> index cc118448ee..b5b7abdc8f 100644 >> --- a/builtin/describe.c >> +++ b/builtin/describe.c >> @@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix) >> struct argv_array args = ARGV_ARRAY_INIT; >> int fd, result; >> >> + setup_work_tree(); >> read_cache(); >> refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, >> NULL, NULL, NULL); > > The patch itself looks good. :) > > -Peff
On Tue, Jan 29, 2019 at 8:12 AM Jeff King <peff@peff.net> wrote: > On Tue, Jan 29, 2019 at 06:18:58AM +0100, Sebastian Staudt wrote: > > This ensures the given working tree is used for --dirty. > > There's been a lot of digging and discussion on the list about what > happens if we don't do this. Could we summarize it here? > > Perhaps: > > We don't use NEED_WORK_TREE when running the git-describe builtin, > since you should be able to describe a commit even in a bare > repository. However, the --dirty flag does need a working tree. Since > we don't call setup_work_tree(), it uses whatever directory we happen > to be in. That's unlikely to match our index, meaning we'd say "dirty" > even when the real working tree is clean. > > We can fix that by calling setup_work_tree() once we know that the > user has asked for --dirty. I have not particularly been following this thread, but this proposed commit message does an excellent job of summarizing and explaining the issue and making the fix obvious (so, now I don't have to go back and read the entire thread). > > The implementation of --broken uses diff-index which calls > > setup_work_tree() itself. > > If I hadn't just read the rest of the thread, I'd probably wonder why we > are talking about --broken at all. Maybe: > > The --broken option similarly needs a working tree. But because the > current implementation calls an external diff-index to do the work, > we don't have to bother setting up the working tree in the > git-describe process. This rewrite left me slightly in the dark since I had to infer that git-diff-index calls setup_work_tree() itself. Perhaps: ...an external diff-index to do the work, which itself calls setup_work_tree(), we don't have to bother... But that's minor.
On Tue, Jan 29, 2019 at 03:53:40PM -0500, Eric Sunshine wrote: > > > The implementation of --broken uses diff-index which calls > > > setup_work_tree() itself. > > > > If I hadn't just read the rest of the thread, I'd probably wonder why we > > are talking about --broken at all. Maybe: > > > > The --broken option similarly needs a working tree. But because the > > current implementation calls an external diff-index to do the work, > > we don't have to bother setting up the working tree in the > > git-describe process. > > This rewrite left me slightly in the dark since I had to infer that > git-diff-index calls setup_work_tree() itself. Perhaps: > > ...an external diff-index to do the work, which itself calls > setup_work_tree(), we don't have to bother... > > But that's minor. Yeah, my reasoning was that we handed off to diff-index, so if it doesn't work, then it has its own bug. ;) But I agree it is probably better to just be explicit. -Peff
Am Di., 29. Jan. 2019 um 23:35 Uhr schrieb Jeff King <peff@peff.net>: > > On Tue, Jan 29, 2019 at 03:53:40PM -0500, Eric Sunshine wrote: > > > > > The implementation of --broken uses diff-index which calls > > > > setup_work_tree() itself. > > > > > > If I hadn't just read the rest of the thread, I'd probably wonder why we > > > are talking about --broken at all. Maybe: > > > > > > The --broken option similarly needs a working tree. But because the > > > current implementation calls an external diff-index to do the work, > > > we don't have to bother setting up the working tree in the > > > git-describe process. > > > > This rewrite left me slightly in the dark since I had to infer that > > git-diff-index calls setup_work_tree() itself. Perhaps: > > > > ...an external diff-index to do the work, which itself calls > > setup_work_tree(), we don't have to bother... > > > > But that's minor. > > Yeah, my reasoning was that we handed off to diff-index, so if it > doesn't work, then it has its own bug. ;) But I agree it is probably > better to just be explicit. Thanks for that valuable feedback. Is there some trailer like "Co-authored-commit-message-by:"? ;) > > -Peff
On Wed, Jan 30, 2019 at 11:31:15AM +0100, Sebastian Staudt wrote: > > Yeah, my reasoning was that we handed off to diff-index, so if it > > doesn't work, then it has its own bug. ;) But I agree it is probably > > better to just be explicit. > > Thanks for that valuable feedback. > Is there some trailer like "Co-authored-commit-message-by:"? ;) We often say "Helped-by", but I am OK with or without that in this case. To me, making suggestions like this is all just part of review. :) -Peff
diff --git a/builtin/describe.c b/builtin/describe.c index cc118448ee..b5b7abdc8f 100644 --- a/builtin/describe.c +++ b/builtin/describe.c @@ -629,6 +629,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix) struct argv_array args = ARGV_ARRAY_INIT; int fd, result; + setup_work_tree(); read_cache(); refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED, NULL, NULL, NULL);
This ensures the given working tree is used for --dirty. The implementation of --broken uses diff-index which calls setup_work_tree() itself. Signed-off-by: Sebastian Staudt <koraktor@gmail.com> --- builtin/describe.c | 1 + 1 file changed, 1 insertion(+)