2007-09-11 11:19:34 +08:00
|
|
|
/*
|
|
|
|
|
* "git reset" builtin command
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2007 Carlos Rica
|
|
|
|
|
*
|
|
|
|
|
* Based on git-reset.sh, which is
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2005, 2006 Linus Torvalds and Junio C Hamano
|
|
|
|
|
*/
|
2022-11-19 21:07:38 +08:00
|
|
|
#define USE_THE_INDEX_VARIABLE
|
Fix sparse warnings
Fix warnings from 'make check'.
- These files don't include 'builtin.h' causing sparse to complain that
cmd_* isn't declared:
builtin/clone.c:364, builtin/fetch-pack.c:797,
builtin/fmt-merge-msg.c:34, builtin/hash-object.c:78,
builtin/merge-index.c:69, builtin/merge-recursive.c:22
builtin/merge-tree.c:341, builtin/mktag.c:156, builtin/notes.c:426
builtin/notes.c:822, builtin/pack-redundant.c:596,
builtin/pack-refs.c:10, builtin/patch-id.c:60, builtin/patch-id.c:149,
builtin/remote.c:1512, builtin/remote-ext.c:240,
builtin/remote-fd.c:53, builtin/reset.c:236, builtin/send-pack.c:384,
builtin/unpack-file.c:25, builtin/var.c:75
- These files have symbols which should be marked static since they're
only file scope:
submodule.c:12, diff.c:631, replace_object.c:92, submodule.c:13,
submodule.c:14, trace.c:78, transport.c:195, transport-helper.c:79,
unpack-trees.c:19, url.c:3, url.c:18, url.c:104, url.c:117, url.c:123,
url.c:129, url.c:136, thread-utils.c:21, thread-utils.c:48
- These files redeclare symbols to be different types:
builtin/index-pack.c:210, parse-options.c:564, parse-options.c:571,
usage.c:49, usage.c:58, usage.c:63, usage.c:72
- These files use a literal integer 0 when they really should use a NULL
pointer:
daemon.c:663, fast-import.c:2942, imap-send.c:1072, notes-merge.c:362
While we're in the area, clean up some unused #includes in builtin files
(mostly exec_cmd.h).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-22 15:51:05 +08:00
|
|
|
#include "builtin.h"
|
2023-04-11 11:00:39 +08:00
|
|
|
#include "advice.h"
|
2017-06-15 02:07:36 +08:00
|
|
|
#include "config.h"
|
2023-03-21 14:26:03 +08:00
|
|
|
#include "environment.h"
|
2023-03-21 14:25:54 +08:00
|
|
|
#include "gettext.h"
|
2023-05-16 14:34:00 +08:00
|
|
|
#include "hash.h"
|
2023-02-24 08:09:27 +08:00
|
|
|
#include "hex.h"
|
2014-10-01 18:28:42 +08:00
|
|
|
#include "lockfile.h"
|
2007-09-11 11:19:34 +08:00
|
|
|
#include "tag.h"
|
|
|
|
|
#include "object.h"
|
2017-12-12 16:55:35 +08:00
|
|
|
#include "pretty.h"
|
2007-09-11 11:19:34 +08:00
|
|
|
#include "run-command.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "diff.h"
|
|
|
|
|
#include "diffcore.h"
|
|
|
|
|
#include "tree.h"
|
2008-02-08 00:40:16 +08:00
|
|
|
#include "branch.h"
|
2023-04-11 15:41:49 +08:00
|
|
|
#include "object-name.h"
|
2008-03-05 06:11:34 +08:00
|
|
|
#include "parse-options.h"
|
2023-05-16 14:33:59 +08:00
|
|
|
#include "path.h"
|
2009-12-30 13:54:47 +08:00
|
|
|
#include "unpack-trees.h"
|
|
|
|
|
#include "cache-tree.h"
|
2023-03-21 14:26:05 +08:00
|
|
|
#include "setup.h"
|
2023-05-16 14:33:51 +08:00
|
|
|
#include "sparse-index.h"
|
2017-04-22 01:39:53 +08:00
|
|
|
#include "submodule.h"
|
|
|
|
|
#include "submodule-config.h"
|
2023-04-11 11:00:38 +08:00
|
|
|
#include "trace.h"
|
|
|
|
|
#include "trace2.h"
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
|
|
|
#include "dir.h"
|
2023-02-07 06:58:57 +08:00
|
|
|
#include "add-interactive.h"
|
2017-04-22 01:39:53 +08:00
|
|
|
|
2018-10-24 03:04:23 +08:00
|
|
|
#define REFRESH_INDEX_DELAY_WARNING_IN_MS (2 * 1000)
|
|
|
|
|
|
2008-03-05 06:11:34 +08:00
|
|
|
static const char * const git_reset_usage[] = {
|
2012-08-20 20:32:39 +08:00
|
|
|
N_("git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]"),
|
2019-11-20 00:48:52 +08:00
|
|
|
N_("git reset [-q] [<tree-ish>] [--] <pathspec>..."),
|
2019-11-20 00:48:53 +08:00
|
|
|
N_("git reset [-q] [--pathspec-from-file [--pathspec-file-nul]] [<tree-ish>]"),
|
2019-11-20 00:48:52 +08:00
|
|
|
N_("git reset --patch [<tree-ish>] [--] [<pathspec>...]"),
|
2008-03-05 06:11:34 +08:00
|
|
|
NULL
|
|
|
|
|
};
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2010-01-19 12:25:57 +08:00
|
|
|
enum reset_type { MIXED, SOFT, HARD, MERGE, KEEP, NONE };
|
|
|
|
|
static const char *reset_type_names[] = {
|
2011-02-23 07:42:07 +08:00
|
|
|
N_("mixed"), N_("soft"), N_("hard"), N_("merge"), N_("keep"), NULL
|
2010-01-19 12:25:57 +08:00
|
|
|
};
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
|
2007-09-11 11:19:34 +08:00
|
|
|
static inline int is_merge(void)
|
|
|
|
|
{
|
2018-05-18 06:51:51 +08:00
|
|
|
return !access(git_path_merge_head(the_repository), F_OK);
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
2020-03-17 02:05:07 +08:00
|
|
|
static int reset_index(const char *ref, const struct object_id *oid, int reset_type, int quiet)
|
2007-09-11 11:19:34 +08:00
|
|
|
{
|
2017-09-05 21:04:51 +08:00
|
|
|
int i, nr = 0;
|
2009-12-30 13:54:47 +08:00
|
|
|
struct tree_desc desc[2];
|
2011-12-07 01:43:39 +08:00
|
|
|
struct tree *tree;
|
2009-12-30 13:54:47 +08:00
|
|
|
struct unpack_trees_options opts;
|
2017-09-05 21:04:51 +08:00
|
|
|
int ret = -1;
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2009-12-30 13:54:47 +08:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
|
opts.head_idx = 1;
|
|
|
|
|
opts.src_index = &the_index;
|
|
|
|
|
opts.dst_index = &the_index;
|
|
|
|
|
opts.fn = oneway_merge;
|
|
|
|
|
opts.merge = 1;
|
2020-03-17 02:05:07 +08:00
|
|
|
init_checkout_metadata(&opts.meta, ref, oid, NULL);
|
2008-06-01 09:10:58 +08:00
|
|
|
if (!quiet)
|
2009-12-30 13:54:47 +08:00
|
|
|
opts.verbose_update = 1;
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
switch (reset_type) {
|
2010-01-19 12:25:57 +08:00
|
|
|
case KEEP:
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
case MERGE:
|
2009-12-30 13:54:47 +08:00
|
|
|
opts.update = 1;
|
2021-09-28 00:33:43 +08:00
|
|
|
opts.preserve_ignored = 0; /* FIXME: !overwrite_ignore */
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
break;
|
|
|
|
|
case HARD:
|
2009-12-30 13:54:47 +08:00
|
|
|
opts.update = 1;
|
2021-09-28 00:33:44 +08:00
|
|
|
opts.reset = UNPACK_RESET_OVERWRITE_UNTRACKED;
|
2022-11-11 03:06:03 +08:00
|
|
|
opts.skip_cache_tree_update = 1;
|
2021-09-28 00:33:44 +08:00
|
|
|
break;
|
|
|
|
|
case MIXED:
|
|
|
|
|
opts.reset = UNPACK_RESET_PROTECT_UNTRACKED;
|
2022-11-11 03:06:03 +08:00
|
|
|
opts.skip_cache_tree_update = 1;
|
2021-09-28 00:33:44 +08:00
|
|
|
/* but opts.update=0, so working tree not updated */
|
|
|
|
|
break;
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
default:
|
2021-09-28 00:33:44 +08:00
|
|
|
BUG("invalid reset_type passed to reset_index");
|
Add 'merge' mode to 'git reset'
We have always had a nice way to reset a working tree to another state
while carrying our changes around: "git read-tree -u -m". Yes, it fails if
the target tree is different in the paths that are dirty in the working
tree, but this is how we used to switch branches in "git checkout", and it
worked fine.
However, perhaps exactly _because_ we've supported this from very early
on, another low-level command, namely "git reset", never did.
But as time went on, 'git reset' remains as a very common command, while
'git read-tree' is now a very odd and low-level plumbing thing that nobody
sane should ever use, because it only makes sense together with other
operations like either switching branches or just rewriting HEAD.
Which means that we have effectively lost the ability to do something very
common: jump to another point in time without always dropping all our
dirty state.
So add this kind of mode to "git reset", and since it merges your changes
to what you are resetting to, just call it that: "git reset --merge".
I've wanted this for a long time, since I very commonly carry a dirty
tree while working on things. My main 'Makefile' file quite often has the
next version already modified, and sometimes I have local modifications
that I don't want to commit, but I still do pulls and patch applications,
and occasionally want to do "git reset" to undo them - while still keeping
my local modifications.
(Maybe we could eventually change it to something like "if we have a
working tree, default to --merge, otherwise default to --mixed").
NOTE! This new mode is certainly not perfect. There's a few things to look
out for:
- if the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action is
likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index. But that's not how
read-tree has ever worked, so..
- "git checkout -m" actually knows how to do a three-way merge, rather
than refuse to update the working tree. So we do know how to do that,
and arguably that would be even nicer behavior.
At the same time it's also arguably true that there is a chance of loss
of state (ie you cannot get back to the original tree if the three-way
merge ends up resolving cleanly to no diff at all), so the "refuse to
do it" is in some respects the safer - but less user-friendly - option.
In other words, I think 'git reset --merge' could become a bit more
friendly, but this is already a big improvement. It allows you to undo a
recent commit without having to throw your current work away.
Yes, yes, with a dirty tree you could always do
git stash
git reset --hard
git stash apply
instead, but isn't "git reset --merge" a nice way to handle one particular
simple case?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
Hmm? Maybe I'm the only one that does a lot of work with a dirty tree, and
sure, I can do other things like the "git stash" thing, or using "git
checkout" to actually create a new branch, and then playing games with
branch renaming etc to make it work like this one.
But I suspect others dislike how "git reset" works too. But see the
suggested improvements above.
builtin-reset.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
2008-12-02 01:30:31 +08:00
|
|
|
}
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2022-11-19 21:07:30 +08:00
|
|
|
repo_read_index_unmerged(the_repository);
|
2009-12-30 13:54:47 +08:00
|
|
|
|
2010-01-19 12:25:57 +08:00
|
|
|
if (reset_type == KEEP) {
|
2016-09-06 04:08:11 +08:00
|
|
|
struct object_id head_oid;
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid(the_repository, "HEAD", &head_oid))
|
2011-02-23 07:42:06 +08:00
|
|
|
return error(_("You do not have a valid HEAD."));
|
2019-06-27 17:28:48 +08:00
|
|
|
if (!fill_tree_descriptor(the_repository, desc + nr, &head_oid))
|
2011-02-23 07:42:06 +08:00
|
|
|
return error(_("Failed to find tree of HEAD."));
|
2010-01-19 12:25:57 +08:00
|
|
|
nr++;
|
|
|
|
|
opts.fn = twoway_merge;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-27 17:28:48 +08:00
|
|
|
if (!fill_tree_descriptor(the_repository, desc + nr, oid)) {
|
2017-09-05 21:04:51 +08:00
|
|
|
error(_("Failed to find tree of %s."), oid_to_hex(oid));
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2017-09-05 21:04:28 +08:00
|
|
|
nr++;
|
|
|
|
|
|
2009-12-30 13:54:47 +08:00
|
|
|
if (unpack_trees(nr, desc, &opts))
|
2017-09-05 21:04:51 +08:00
|
|
|
goto out;
|
2011-12-07 01:43:39 +08:00
|
|
|
|
|
|
|
|
if (reset_type == MIXED || reset_type == HARD) {
|
2017-05-07 06:10:37 +08:00
|
|
|
tree = parse_tree_indirect(oid);
|
2018-11-10 13:49:02 +08:00
|
|
|
prime_cache_tree(the_repository, the_repository->index, tree);
|
2011-12-07 01:43:39 +08:00
|
|
|
}
|
|
|
|
|
|
2017-09-05 21:04:51 +08:00
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
|
|
out:
|
|
|
|
|
for (i = 0; i < nr; i++)
|
|
|
|
|
free((void *)desc[i].buffer);
|
|
|
|
|
return ret;
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void print_new_head_line(struct commit *commit)
|
|
|
|
|
{
|
reset --hard: make use of the pretty machinery
reset --hard currently uses its own logic for printing the first line of
the commit message in its output. Instead of just using the first line,
use the pretty machinery to create the output.
In addition to the easier to follow code, this makes the output more
consistent with other commands that print the title of the commit, such
as 'git commit --oneline' or 'git checkout', which both use
'pp_commit_easy()' with the CMIT_FMT_ONELINE modifier.
It is a slight change of the output if the second line of the commit
message is not a blank line, i.e. if the commit message is
foo
bar
previously we would print "HEAD is now at 000000 foo", while after
this change we print "HEAD is now at 000000 foo bar", same as 'git log
--oneline' shows "000000 foo bar".
So this does make the output more consistent with other commands, and
'reset' is a porcelain command, so nobody should be parsing the output
in scripts.
The current behaviour dates back to 0e5a7faa3a ("Make "git reset" a
builtin.", 2007-09-11), so I assume (without digging into the old
codebase too much) that the logic was implemented because there was
no convenience function such as 'pp_commit_easy' that would do this
already.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-02 04:57:21 +08:00
|
|
|
struct strbuf buf = STRBUF_INIT;
|
2007-09-11 11:19:34 +08:00
|
|
|
|
reset --hard: make use of the pretty machinery
reset --hard currently uses its own logic for printing the first line of
the commit message in its output. Instead of just using the first line,
use the pretty machinery to create the output.
In addition to the easier to follow code, this makes the output more
consistent with other commands that print the title of the commit, such
as 'git commit --oneline' or 'git checkout', which both use
'pp_commit_easy()' with the CMIT_FMT_ONELINE modifier.
It is a slight change of the output if the second line of the commit
message is not a blank line, i.e. if the commit message is
foo
bar
previously we would print "HEAD is now at 000000 foo", while after
this change we print "HEAD is now at 000000 foo bar", same as 'git log
--oneline' shows "000000 foo bar".
So this does make the output more consistent with other commands, and
'reset' is a porcelain command, so nobody should be parsing the output
in scripts.
The current behaviour dates back to 0e5a7faa3a ("Make "git reset" a
builtin.", 2007-09-11), so I assume (without digging into the old
codebase too much) that the logic was implemented because there was
no convenience function such as 'pp_commit_easy' that would do this
already.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-02 04:57:21 +08:00
|
|
|
printf(_("HEAD is now at %s"),
|
2023-03-28 21:58:46 +08:00
|
|
|
repo_find_unique_abbrev(the_repository, &commit->object.oid, DEFAULT_ABBREV));
|
reset --hard: make use of the pretty machinery
reset --hard currently uses its own logic for printing the first line of
the commit message in its output. Instead of just using the first line,
use the pretty machinery to create the output.
In addition to the easier to follow code, this makes the output more
consistent with other commands that print the title of the commit, such
as 'git commit --oneline' or 'git checkout', which both use
'pp_commit_easy()' with the CMIT_FMT_ONELINE modifier.
It is a slight change of the output if the second line of the commit
message is not a blank line, i.e. if the commit message is
foo
bar
previously we would print "HEAD is now at 000000 foo", while after
this change we print "HEAD is now at 000000 foo bar", same as 'git log
--oneline' shows "000000 foo bar".
So this does make the output more consistent with other commands, and
'reset' is a porcelain command, so nobody should be parsing the output
in scripts.
The current behaviour dates back to 0e5a7faa3a ("Make "git reset" a
builtin.", 2007-09-11), so I assume (without digging into the old
codebase too much) that the logic was implemented because there was
no convenience function such as 'pp_commit_easy' that would do this
already.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-02 04:57:21 +08:00
|
|
|
|
|
|
|
|
pp_commit_easy(CMIT_FMT_ONELINE, commit, &buf);
|
|
|
|
|
if (buf.len > 0)
|
|
|
|
|
printf(" %s", buf.buf);
|
|
|
|
|
putchar('\n');
|
|
|
|
|
strbuf_release(&buf);
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void update_index_from_diff(struct diff_queue_struct *q,
|
2022-12-13 19:13:48 +08:00
|
|
|
struct diff_options *opt UNUSED,
|
|
|
|
|
void *data)
|
2007-09-11 11:19:34 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
2014-02-04 10:20:09 +08:00
|
|
|
int intent_to_add = *(int *)data;
|
2007-09-11 11:19:34 +08:00
|
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
|
|
|
int pos;
|
2007-09-11 11:19:34 +08:00
|
|
|
struct diff_filespec *one = q->queue[i]->one;
|
2021-10-08 05:15:31 +08:00
|
|
|
int is_in_reset_tree = one->mode && !is_null_oid(&one->oid);
|
2014-02-04 10:20:09 +08:00
|
|
|
struct cache_entry *ce;
|
|
|
|
|
|
2021-10-08 05:15:31 +08:00
|
|
|
if (!is_in_reset_tree && !intent_to_add) {
|
2022-11-19 21:07:33 +08:00
|
|
|
remove_file_from_index(&the_index, one->path);
|
2014-02-04 10:20:09 +08:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-03 03:49:31 +08:00
|
|
|
ce = make_cache_entry(&the_index, one->mode, &one->oid, one->path,
|
2014-02-04 10:20:09 +08:00
|
|
|
0, 0);
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If the file 1) corresponds to an existing index entry with
|
|
|
|
|
* skip-worktree set, or 2) does not exist in the index but is
|
|
|
|
|
* outside the sparse checkout definition, add a skip-worktree bit
|
2021-11-29 23:52:42 +08:00
|
|
|
* to the new index entry. Note that a sparse index will be expanded
|
|
|
|
|
* if this entry is outside the sparse cone - this is necessary
|
|
|
|
|
* to properly construct the reset sparse directory.
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
|
|
|
*/
|
2022-11-19 21:07:38 +08:00
|
|
|
pos = index_name_pos(&the_index, one->path, strlen(one->path));
|
2022-11-19 21:07:34 +08:00
|
|
|
if ((pos >= 0 && ce_skip_worktree(the_index.cache[pos])) ||
|
reset: preserve skip-worktree bit in mixed reset
Change `update_index_from_diff` to set `skip-worktree` when applicable for
new index entries. When `git reset --mixed <tree-ish>` is run, entries in
the index with differences between the pre-reset HEAD and reset <tree-ish>
are identified and handled with `update_index_from_diff`. For each file, a
new cache entry in inserted into the index, created from the <tree-ish> side
of the reset (without changing the working tree). However, the newly-created
entry must have `skip-worktree` explicitly set in either of the following
scenarios:
1. the file is in the current index and has `skip-worktree` set
2. the file is not in the current index but is outside of a defined sparse
checkout definition
Not setting the `skip-worktree` bit leads to likely-undesirable results for
a user. It causes `skip-worktree` settings to disappear on the
"diff"-containing files (but *only* the diff-containing files), leading to
those files now showing modifications in `git status`. For example, when
running `git reset --mixed` in a sparse checkout, some file entries outside
of sparse checkout could show up as deleted, despite the user never deleting
anything (and not wanting them on-disk anyway).
Additionally, add a test to `t7102` to ensure `skip-worktree` is preserved
in a basic `git reset --mixed` scenario and update a failure-documenting
test from 19a0acc (t1092: test interesting sparse-checkout scenarios,
2021-01-23) with new expected behavior.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-27 22:39:17 +08:00
|
|
|
(pos < 0 && !path_in_sparse_checkout(one->path, &the_index)))
|
|
|
|
|
ce->ce_flags |= CE_SKIP_WORKTREE;
|
|
|
|
|
|
2014-02-04 10:20:09 +08:00
|
|
|
if (!ce)
|
|
|
|
|
die(_("make_cache_entry failed for path '%s'"),
|
|
|
|
|
one->path);
|
2021-10-08 05:15:31 +08:00
|
|
|
if (!is_in_reset_tree) {
|
2014-02-04 10:20:09 +08:00
|
|
|
ce->ce_flags |= CE_INTENT_TO_ADD;
|
|
|
|
|
set_object_name_for_intent_to_add_entry(ce);
|
|
|
|
|
}
|
2022-11-19 21:07:33 +08:00
|
|
|
add_index_entry(&the_index, ce,
|
|
|
|
|
ADD_CACHE_OK_TO_ADD | ADD_CACHE_OK_TO_REPLACE);
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-14 16:35:58 +08:00
|
|
|
static int read_from_tree(const struct pathspec *pathspec,
|
2016-09-06 04:08:11 +08:00
|
|
|
struct object_id *tree_oid,
|
2014-02-04 10:20:09 +08:00
|
|
|
int intent_to_add)
|
2007-09-11 11:19:34 +08:00
|
|
|
{
|
|
|
|
|
struct diff_options opt;
|
|
|
|
|
|
|
|
|
|
memset(&opt, 0, sizeof(opt));
|
2013-07-14 16:35:58 +08:00
|
|
|
copy_pathspec(&opt.pathspec, pathspec);
|
2007-09-11 11:19:34 +08:00
|
|
|
opt.output_format = DIFF_FORMAT_CALLBACK;
|
|
|
|
|
opt.format_callback = update_index_from_diff;
|
2014-02-04 10:20:09 +08:00
|
|
|
opt.format_callback_data = &intent_to_add;
|
2017-11-01 02:19:11 +08:00
|
|
|
opt.flags.override_submodule_config = 1;
|
2021-11-29 23:52:42 +08:00
|
|
|
opt.flags.recursive = 1;
|
2018-09-21 23:57:19 +08:00
|
|
|
opt.repo = the_repository;
|
2021-11-29 23:52:42 +08:00
|
|
|
opt.change = diff_change;
|
|
|
|
|
opt.add_remove = diff_addremove;
|
|
|
|
|
|
2022-08-07 12:13:33 +08:00
|
|
|
if (pathspec->nr && pathspec_needs_expanded_index(&the_index, pathspec))
|
2021-11-29 23:52:42 +08:00
|
|
|
ensure_full_index(&the_index);
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2017-05-07 06:10:35 +08:00
|
|
|
if (do_diff_cache(tree_oid, &opt))
|
2007-09-11 11:19:34 +08:00
|
|
|
return 1;
|
|
|
|
|
diffcore_std(&opt);
|
|
|
|
|
diff_flush(&opt);
|
2007-11-03 21:12:17 +08:00
|
|
|
|
2013-01-15 13:47:44 +08:00
|
|
|
return 0;
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
reset: give better reflog messages
The reset command creates its reflog entry from argv.
However, it does so after having run parse_options, which
means the only thing left in argv is any non-option
arguments. Thus you would end up with confusing reflog
entries like:
$ git reset --hard HEAD^
$ git reset --soft HEAD@{1}
$ git log -2 -g --oneline
8e46cad HEAD@{0}: HEAD@{1}: updating HEAD
1eb9486 HEAD@{1}: HEAD^: updating HEAD
However, we must also consider that some scripts may set
GIT_REFLOG_ACTION before calling reset, and we need to show
their reflog action (with our text appended). For example:
rebase -i (squash): updating HEAD
On top of that, we also set the ORIG_HEAD reflog action
(even though it doesn't generally exist). In that case, the
reset argument is somewhat meaningless, as it has nothing to
do with what's in ORIG_HEAD.
This patch changes the reset reflog code to show:
$GIT_REFLOG_ACTION: updating {HEAD,ORIG_HEAD}
as before, but only if GIT_REFLOG_ACTION is set. Otherwise,
show:
reset: moving to $rev
for HEAD, and:
reset: updating ORIG_HEAD
for ORIG_HEAD (this is still somewhat superfluous, since we
are in the ORIG_HEAD reflog, obviously, but at least we now
mention which command was used to update it).
While we're at it, we can clean up the code a bit:
- Use strbufs to make the message.
- Use the "rev" parameter instead of showing all options.
This makes more sense, since it is the only thing
impacting the writing of the ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-23 00:12:23 +08:00
|
|
|
static void set_reflog_message(struct strbuf *sb, const char *action,
|
|
|
|
|
const char *rev)
|
2007-09-11 11:19:34 +08:00
|
|
|
{
|
|
|
|
|
const char *rla = getenv("GIT_REFLOG_ACTION");
|
reset: give better reflog messages
The reset command creates its reflog entry from argv.
However, it does so after having run parse_options, which
means the only thing left in argv is any non-option
arguments. Thus you would end up with confusing reflog
entries like:
$ git reset --hard HEAD^
$ git reset --soft HEAD@{1}
$ git log -2 -g --oneline
8e46cad HEAD@{0}: HEAD@{1}: updating HEAD
1eb9486 HEAD@{1}: HEAD^: updating HEAD
However, we must also consider that some scripts may set
GIT_REFLOG_ACTION before calling reset, and we need to show
their reflog action (with our text appended). For example:
rebase -i (squash): updating HEAD
On top of that, we also set the ORIG_HEAD reflog action
(even though it doesn't generally exist). In that case, the
reset argument is somewhat meaningless, as it has nothing to
do with what's in ORIG_HEAD.
This patch changes the reset reflog code to show:
$GIT_REFLOG_ACTION: updating {HEAD,ORIG_HEAD}
as before, but only if GIT_REFLOG_ACTION is set. Otherwise,
show:
reset: moving to $rev
for HEAD, and:
reset: updating ORIG_HEAD
for ORIG_HEAD (this is still somewhat superfluous, since we
are in the ORIG_HEAD reflog, obviously, but at least we now
mention which command was used to update it).
While we're at it, we can clean up the code a bit:
- Use strbufs to make the message.
- Use the "rev" parameter instead of showing all options.
This makes more sense, since it is the only thing
impacting the writing of the ref.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-23 00:12:23 +08:00
|
|
|
|
|
|
|
|
strbuf_reset(sb);
|
|
|
|
|
if (rla)
|
|
|
|
|
strbuf_addf(sb, "%s: %s", rla, action);
|
|
|
|
|
else if (rev)
|
|
|
|
|
strbuf_addf(sb, "reset: moving to %s", rev);
|
|
|
|
|
else
|
|
|
|
|
strbuf_addf(sb, "reset: %s", action);
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
2010-01-19 12:26:01 +08:00
|
|
|
static void die_if_unmerged_cache(int reset_type)
|
|
|
|
|
{
|
2022-11-19 21:07:30 +08:00
|
|
|
if (is_merge() || unmerged_index(&the_index))
|
2011-02-23 07:42:07 +08:00
|
|
|
die(_("Cannot do a %s reset in the middle of a merge."),
|
|
|
|
|
_(reset_type_names[reset_type]));
|
2010-01-19 12:26:01 +08:00
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-14 16:35:47 +08:00
|
|
|
static void parse_args(struct pathspec *pathspec,
|
|
|
|
|
const char **argv, const char *prefix,
|
|
|
|
|
int patch_mode,
|
|
|
|
|
const char **rev_ret)
|
2007-09-11 11:19:34 +08:00
|
|
|
{
|
|
|
|
|
const char *rev = "HEAD";
|
2016-09-06 04:08:11 +08:00
|
|
|
struct object_id unused;
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
/*
|
|
|
|
|
* Possible arguments are:
|
|
|
|
|
*
|
2013-01-15 13:47:49 +08:00
|
|
|
* git reset [-opts] [<rev>]
|
|
|
|
|
* git reset [-opts] <tree> [<paths>...]
|
|
|
|
|
* git reset [-opts] <tree> -- [<paths>...]
|
|
|
|
|
* git reset [-opts] -- [<paths>...]
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
* git reset [-opts] <paths>...
|
|
|
|
|
*
|
2013-01-15 13:47:38 +08:00
|
|
|
* At this point, argv points immediately after [-opts].
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
*/
|
|
|
|
|
|
2013-01-15 13:47:38 +08:00
|
|
|
if (argv[0]) {
|
|
|
|
|
if (!strcmp(argv[0], "--")) {
|
|
|
|
|
argv++; /* reset to HEAD, possibly with paths */
|
|
|
|
|
} else if (argv[1] && !strcmp(argv[1], "--")) {
|
|
|
|
|
rev = argv[0];
|
|
|
|
|
argv += 2;
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
}
|
|
|
|
|
/*
|
2013-01-15 13:47:38 +08:00
|
|
|
* Otherwise, argv[0] could be either <rev> or <paths> and
|
2013-01-15 13:47:49 +08:00
|
|
|
* has to be unambiguous. If there is a single argument, it
|
|
|
|
|
* can not be a tree
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
*/
|
2023-03-28 21:58:46 +08:00
|
|
|
else if ((!argv[1] && !repo_get_oid_committish(the_repository, argv[0], &unused)) ||
|
|
|
|
|
(argv[1] && !repo_get_oid_treeish(the_repository, argv[0], &unused))) {
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
/*
|
2013-01-15 13:47:49 +08:00
|
|
|
* Ok, argv[0] looks like a commit/tree; it should not
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
* be a filename.
|
|
|
|
|
*/
|
2013-01-15 13:47:38 +08:00
|
|
|
verify_non_filename(prefix, argv[0]);
|
|
|
|
|
rev = *argv++;
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
} else {
|
|
|
|
|
/* Otherwise we treat this as a filename */
|
2013-01-15 13:47:38 +08:00
|
|
|
verify_filename(prefix, argv[0], 1);
|
Allow "git-reset path" when unambiguous
Resetting a selected set of index entries is done with
"git reset -- paths" syntax, but we did not allow -- to be omitted
even when the command is unambiguous.
This updates the command to follow the general rule:
* When -- appears, revs come before it, and paths come after it;
* When there is no --, earlier ones are revs and the rest are paths, and
we need to guess. When lack of -- marker forces us to guess, we
protect from user errors and typoes by making sure what we treat as
revs do not appear as filenames in the work tree, and what we treat as
paths do appear as filenames in the work tree, and by erroring out if
that is not the case. We tell the user to disambiguate by using -- in
such a case.
which is employed elsewhere in the system.
When this rule is applied to "reset", because we can have only zero or one
rev to the command, the check can be slightly simpler than other programs.
We have to check only the first one or two tokens after the command name
and options, and when they are:
-- A:
no explicit rev given; "A" and whatever follows it are paths.
A --:
explicit rev "A" given and whatever follows the "--" are paths.
A B:
"A" could be rev or path and we need to guess. "B" could
be missing but if exists that (and everything that follows) would
be paths.
So we apply the guess only in the last case and only to "A" (not "B" and
what comes after it).
* As long as "A" is unambiguously a path, index entries for "A", "B" (and
everything that follows) are reset to the HEAD revision.
* If "A" is unambiguously a rev, on the other hand, the index entries for
"B" (and everything that follows) are reset to the "A" revision.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-26 09:16:36 +08:00
|
|
|
}
|
|
|
|
|
}
|
2013-01-15 13:47:37 +08:00
|
|
|
*rev_ret = rev;
|
2013-09-13 03:25:01 +08:00
|
|
|
|
2013-07-14 16:35:50 +08:00
|
|
|
parse_pathspec(pathspec, 0,
|
|
|
|
|
PATHSPEC_PREFER_FULL |
|
|
|
|
|
(patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0),
|
2013-07-14 16:35:47 +08:00
|
|
|
prefix, argv);
|
2013-01-15 13:47:37 +08:00
|
|
|
}
|
|
|
|
|
|
2016-09-06 04:08:11 +08:00
|
|
|
static int reset_refs(const char *rev, const struct object_id *oid)
|
2013-01-15 13:47:39 +08:00
|
|
|
{
|
|
|
|
|
int update_ref_status;
|
|
|
|
|
struct strbuf msg = STRBUF_INIT;
|
2016-09-06 04:08:11 +08:00
|
|
|
struct object_id *orig = NULL, oid_orig,
|
|
|
|
|
*old_orig = NULL, oid_old_orig;
|
2013-01-15 13:47:39 +08:00
|
|
|
|
2023-03-28 21:58:46 +08:00
|
|
|
if (!repo_get_oid(the_repository, "ORIG_HEAD", &oid_old_orig))
|
2016-09-06 04:08:11 +08:00
|
|
|
old_orig = &oid_old_orig;
|
2023-03-28 21:58:46 +08:00
|
|
|
if (!repo_get_oid(the_repository, "HEAD", &oid_orig)) {
|
2016-09-06 04:08:11 +08:00
|
|
|
orig = &oid_orig;
|
2013-01-15 13:47:39 +08:00
|
|
|
set_reflog_message(&msg, "updating ORIG_HEAD", NULL);
|
2017-10-16 06:06:51 +08:00
|
|
|
update_ref(msg.buf, "ORIG_HEAD", orig, old_orig, 0,
|
2014-04-07 21:47:56 +08:00
|
|
|
UPDATE_REFS_MSG_ON_ERR);
|
2013-01-15 13:47:39 +08:00
|
|
|
} else if (old_orig)
|
2017-10-16 06:06:50 +08:00
|
|
|
delete_ref(NULL, "ORIG_HEAD", old_orig, 0);
|
2013-01-15 13:47:39 +08:00
|
|
|
set_reflog_message(&msg, "updating HEAD", rev);
|
2017-10-16 06:06:51 +08:00
|
|
|
update_ref_status = update_ref(msg.buf, "HEAD", oid, orig, 0,
|
2014-04-07 21:47:56 +08:00
|
|
|
UPDATE_REFS_MSG_ON_ERR);
|
2013-01-15 13:47:39 +08:00
|
|
|
strbuf_release(&msg);
|
|
|
|
|
return update_ref_status;
|
|
|
|
|
}
|
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
static int git_reset_config(const char *var, const char *value,
|
|
|
|
|
const struct config_context *ctx, void *cb)
|
2017-06-01 08:30:47 +08:00
|
|
|
{
|
|
|
|
|
if (!strcmp(var, "submodule.recurse"))
|
|
|
|
|
return git_default_submodule_config(var, value, cb);
|
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-29 03:26:22 +08:00
|
|
|
return git_default_config(var, value, ctx, cb);
|
2017-06-01 08:30:47 +08:00
|
|
|
}
|
|
|
|
|
|
2013-01-15 13:47:37 +08:00
|
|
|
int cmd_reset(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
|
|
|
|
int reset_type = NONE, update_ref_status = 0, quiet = 0;
|
2022-03-25 01:33:10 +08:00
|
|
|
int no_refresh = 0;
|
2019-11-20 00:48:53 +08:00
|
|
|
int patch_mode = 0, pathspec_file_nul = 0, unborn;
|
parse-options: consistently allocate memory in fix_filename()
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in
front of the filename to make up for the fact that Git has chdir()'d to
the top of the repository. We can do this with prefix_filename(), but
there are a few special cases we handle ourselves.
Unfortunately the memory allocation is inconsistent here; if we do make
it to prefix_filename(), we'll allocate a string which the caller must
free to avoid a leak. But if we hit our special cases, we'll return the
string as-is, and a caller which tries to free it will crash. So there's
no way to win.
Let's consistently allocate, so that callers can do the right thing.
There are now three cases to care about in the function (and hence a
three-armed if/else):
1. we got a NULL input (and should leave it as NULL, though arguably
this is the sign of a bug; let's keep the status quo for now and we
can pick at that scab later)
2. we hit a special case that means we leave the name intact; we
should duplicate the string. This includes our special "-"
matching. Prior to this patch, it also included empty prefixes and
absolute filenames. But we can observe that prefix_filename()
already handles these, so we don't need to detect them.
3. everything else goes to prefix_filename()
I've dropped the "const" from the "char **file" parameter to indicate
that we're allocating, though in practice it's not really important.
This is all being shuffled through a void pointer via opt->value before
it hits code which ever looks at the string. And it's even a bit weird,
because we are really taking _in_ a const string and using the same
out-parameter for a non-const string. A better function signature would
be:
static char *fix_filename(const char *prefix, const char *file);
but that would mean the caller dereferences the double-pointer (and the
NULL check is currently handled inside this function). So I took the
path of least-change here.
Note that we have to fix several callers in this commit, too, or we'll
break the leak-checking tests. These are "new" leaks in the sense that
they are now triggered by the test suite, but these spots have always
been leaky when Git is run in a subdirectory of the repository. I fixed
all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There
may be others in scripts that have other leaks, but we can fix them
later along with those other leaks (and again, you _couldn't_ fix them
before this patch, so this is the necessary first step).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 18:31:22 +08:00
|
|
|
const char *rev;
|
|
|
|
|
char *pathspec_from_file = NULL;
|
2015-11-10 10:22:28 +08:00
|
|
|
struct object_id oid;
|
2013-07-14 16:35:47 +08:00
|
|
|
struct pathspec pathspec;
|
2014-02-04 10:20:09 +08:00
|
|
|
int intent_to_add = 0;
|
2013-01-15 13:47:37 +08:00
|
|
|
const struct option options[] = {
|
|
|
|
|
OPT__QUIET(&quiet, N_("be quiet, only report errors")),
|
2022-03-25 01:33:10 +08:00
|
|
|
OPT_BOOL(0, "no-refresh", &no_refresh,
|
reset: introduce --[no-]refresh option to --mixed
Add a new --[no-]refresh option that is intended to explicitly determine
whether a mixed reset should end in an index refresh.
Starting at 9ac8125d1a (reset: don't compute unstaged changes after reset
when --quiet, 2018-10-23), using the '--quiet' option results in skipping
the call to 'refresh_index(...)' at the end of a mixed reset with the goal
of improving performance. However, by coupling behavior that modifies the
index with the option that silences logs, there is no way for users to have
one without the other (i.e., silenced logs with a refreshed index) without
incurring the overhead of a separate call to 'git update-index --refresh'.
Furthermore, there is minimal user-facing documentation indicating that
--quiet skips the index refresh, potentially leading to unexpected issues
executing commands after 'git reset --quiet' that do not themselves refresh
the index (e.g., internals of 'git stash', 'git read-tree').
To mitigate these issues, '--[no-]refresh' and 'reset.refresh' are
introduced to provide a dedicated mechanism for refreshing the index. When
either is set, '--quiet' and 'reset.quiet' revert to controlling only
whether logs are silenced and do not affect index refresh.
Helped-by: Derrick Stolee <derrickstolee@github.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-15 09:49:39 +08:00
|
|
|
N_("skip refreshing the index after reset")),
|
2023-07-19 21:37:39 +08:00
|
|
|
OPT_SET_INT_F(0, "mixed", &reset_type,
|
|
|
|
|
N_("reset HEAD and index"),
|
|
|
|
|
MIXED, PARSE_OPT_NONEG),
|
|
|
|
|
OPT_SET_INT_F(0, "soft", &reset_type,
|
|
|
|
|
N_("reset only HEAD"),
|
|
|
|
|
SOFT, PARSE_OPT_NONEG),
|
|
|
|
|
OPT_SET_INT_F(0, "hard", &reset_type,
|
|
|
|
|
N_("reset HEAD, index and working tree"),
|
|
|
|
|
HARD, PARSE_OPT_NONEG),
|
|
|
|
|
OPT_SET_INT_F(0, "merge", &reset_type,
|
|
|
|
|
N_("reset HEAD, index and working tree"),
|
|
|
|
|
MERGE, PARSE_OPT_NONEG),
|
|
|
|
|
OPT_SET_INT_F(0, "keep", &reset_type,
|
|
|
|
|
N_("reset HEAD but keep local changes"),
|
|
|
|
|
KEEP, PARSE_OPT_NONEG),
|
Use OPT_CALLBACK and OPT_CALLBACK_F
In the codebase, there are many options which use OPTION_CALLBACK in a
plain ol' struct definition. However, we have the OPT_CALLBACK and
OPT_CALLBACK_F macros which are meant to abstract these plain struct
definitions away. These macros are useful as they semantically signal to
developers that these are just normal callback option with nothing fancy
happening.
Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
OPT_CALLBACK_F where applicable. The heavy lifting was done using the
following (disgusting) shell script:
#!/bin/sh
do_replacement () {
tr '\n' '\r' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' |
sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' |
tr '\r' '\n'
}
for f in $(git ls-files \*.c)
do
do_replacement <"$f" >"$f.tmp"
mv "$f.tmp" "$f"
done
The result was manually inspected and then reformatted to match the
style of the surrounding code. Finally, using
`git grep OPTION_CALLBACK \*.c`, leftover results which were not handled
by the script were manually transformed.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28 16:36:28 +08:00
|
|
|
OPT_CALLBACK_F(0, "recurse-submodules", NULL,
|
2023-07-19 21:37:39 +08:00
|
|
|
"reset", "control recursive updating of submodules",
|
|
|
|
|
PARSE_OPT_OPTARG,
|
|
|
|
|
option_parse_recurse_submodules_worktree_updater),
|
2013-08-03 19:51:19 +08:00
|
|
|
OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
|
2014-02-04 10:20:09 +08:00
|
|
|
OPT_BOOL('N', "intent-to-add", &intent_to_add,
|
|
|
|
|
N_("record only the fact that removed paths will be added later")),
|
2019-11-20 00:48:53 +08:00
|
|
|
OPT_PATHSPEC_FROM_FILE(&pathspec_from_file),
|
|
|
|
|
OPT_PATHSPEC_FILE_NUL(&pathspec_file_nul),
|
2013-01-15 13:47:37 +08:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
2017-06-01 08:30:47 +08:00
|
|
|
git_config(git_reset_config, NULL);
|
2013-01-15 13:47:37 +08:00
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, prefix, options, git_reset_usage,
|
|
|
|
|
PARSE_OPT_KEEP_DASHDASH);
|
2013-07-14 16:35:47 +08:00
|
|
|
parse_args(&pathspec, argv, prefix, patch_mode, &rev);
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2019-11-20 00:48:53 +08:00
|
|
|
if (pathspec_from_file) {
|
|
|
|
|
if (patch_mode)
|
2022-01-06 04:02:16 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--pathspec-from-file", "--patch");
|
2019-11-20 00:48:53 +08:00
|
|
|
|
|
|
|
|
if (pathspec.nr)
|
2022-01-06 04:02:24 +08:00
|
|
|
die(_("'%s' and pathspec arguments cannot be used together"), "--pathspec-from-file");
|
2019-11-20 00:48:53 +08:00
|
|
|
|
|
|
|
|
parse_pathspec_file(&pathspec, 0,
|
|
|
|
|
PATHSPEC_PREFER_FULL,
|
|
|
|
|
prefix, pathspec_from_file, pathspec_file_nul);
|
|
|
|
|
} else if (pathspec_file_nul) {
|
2022-01-06 04:02:19 +08:00
|
|
|
die(_("the option '%s' requires '%s'"), "--pathspec-file-nul", "--pathspec-from-file");
|
2019-11-20 00:48:53 +08:00
|
|
|
}
|
|
|
|
|
|
2023-03-28 21:58:46 +08:00
|
|
|
unborn = !strcmp(rev, "HEAD") && repo_get_oid(the_repository, "HEAD",
|
|
|
|
|
&oid);
|
2013-01-15 13:47:50 +08:00
|
|
|
if (unborn) {
|
|
|
|
|
/* reset on unborn branch: treat as reset to empty tree */
|
2018-05-02 08:26:02 +08:00
|
|
|
oidcpy(&oid, the_hash_algo->empty_tree);
|
2019-11-25 04:25:49 +08:00
|
|
|
} else if (!pathspec.nr && !patch_mode) {
|
2013-01-15 13:47:49 +08:00
|
|
|
struct commit *commit;
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid_committish(the_repository, rev, &oid))
|
2013-01-15 13:47:49 +08:00
|
|
|
die(_("Failed to resolve '%s' as a valid revision."), rev);
|
2018-06-29 09:21:58 +08:00
|
|
|
commit = lookup_commit_reference(the_repository, &oid);
|
2013-01-15 13:47:49 +08:00
|
|
|
if (!commit)
|
|
|
|
|
die(_("Could not parse object '%s'."), rev);
|
2015-11-10 10:22:28 +08:00
|
|
|
oidcpy(&oid, &commit->object.oid);
|
2013-01-15 13:47:49 +08:00
|
|
|
} else {
|
|
|
|
|
struct tree *tree;
|
2023-03-28 21:58:46 +08:00
|
|
|
if (repo_get_oid_treeish(the_repository, rev, &oid))
|
2013-01-15 13:47:49 +08:00
|
|
|
die(_("Failed to resolve '%s' as a valid tree."), rev);
|
2017-05-07 06:10:37 +08:00
|
|
|
tree = parse_tree_indirect(&oid);
|
2013-01-15 13:47:49 +08:00
|
|
|
if (!tree)
|
|
|
|
|
die(_("Could not parse object '%s'."), rev);
|
2015-11-10 10:22:28 +08:00
|
|
|
oidcpy(&oid, &tree->object.oid);
|
2013-01-15 13:47:49 +08:00
|
|
|
}
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2009-08-15 19:48:31 +08:00
|
|
|
if (patch_mode) {
|
|
|
|
|
if (reset_type != NONE)
|
2022-01-06 04:02:16 +08:00
|
|
|
die(_("options '%s' and '%s' cannot be used together"), "--patch", "--{hard,mixed,soft}");
|
2019-02-23 06:25:09 +08:00
|
|
|
trace2_cmd_mode("patch-interactive");
|
2023-02-23 06:55:45 +08:00
|
|
|
update_ref_status = !!run_add_p(the_repository, ADD_P_RESET, rev,
|
2023-02-07 06:58:57 +08:00
|
|
|
&pathspec);
|
2023-02-07 07:07:40 +08:00
|
|
|
goto cleanup;
|
2009-08-15 19:48:31 +08:00
|
|
|
}
|
|
|
|
|
|
2007-09-11 11:19:34 +08:00
|
|
|
/* git reset tree [--] paths... can be used to
|
|
|
|
|
* load chosen paths from the tree into the index without
|
|
|
|
|
* affecting the working tree nor HEAD. */
|
2013-07-14 16:35:47 +08:00
|
|
|
if (pathspec.nr) {
|
2007-09-11 11:19:34 +08:00
|
|
|
if (reset_type == MIXED)
|
2011-02-23 07:42:06 +08:00
|
|
|
warning(_("--mixed with paths is deprecated; use 'git reset -- <paths>' instead."));
|
2007-09-11 11:19:34 +08:00
|
|
|
else if (reset_type != NONE)
|
2011-02-23 07:42:07 +08:00
|
|
|
die(_("Cannot do %s reset with paths."),
|
|
|
|
|
_(reset_type_names[reset_type]));
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
if (reset_type == NONE)
|
|
|
|
|
reset_type = MIXED; /* by default */
|
|
|
|
|
|
2019-02-23 06:25:09 +08:00
|
|
|
if (pathspec.nr)
|
|
|
|
|
trace2_cmd_mode("path");
|
|
|
|
|
else
|
|
|
|
|
trace2_cmd_mode(reset_type_names[reset_type]);
|
|
|
|
|
|
2014-02-16 10:28:03 +08:00
|
|
|
if (reset_type != SOFT && (reset_type != MIXED || get_git_work_tree()))
|
2009-12-30 16:47:03 +08:00
|
|
|
setup_work_tree();
|
2007-12-31 15:13:52 +08:00
|
|
|
|
2009-12-30 13:54:44 +08:00
|
|
|
if (reset_type == MIXED && is_bare_repository())
|
2011-02-23 07:42:07 +08:00
|
|
|
die(_("%s reset is not allowed in a bare repository"),
|
|
|
|
|
_(reset_type_names[reset_type]));
|
2009-12-30 13:54:44 +08:00
|
|
|
|
2014-02-04 10:20:09 +08:00
|
|
|
if (intent_to_add && reset_type != MIXED)
|
2022-01-06 04:02:19 +08:00
|
|
|
die(_("the option '%s' requires '%s'"), "-N", "--mixed");
|
2014-02-04 10:20:09 +08:00
|
|
|
|
2021-11-29 23:52:40 +08:00
|
|
|
prepare_repo_settings(the_repository);
|
|
|
|
|
the_repository->settings.command_requires_full_index = 0;
|
|
|
|
|
|
2022-11-19 21:07:38 +08:00
|
|
|
if (repo_read_index(the_repository) < 0)
|
2021-11-29 23:52:40 +08:00
|
|
|
die(_("index file corrupt"));
|
|
|
|
|
|
2007-09-11 11:19:34 +08:00
|
|
|
/* Soft reset does not touch the index file nor the working tree
|
|
|
|
|
* at all, but requires them in a good order. Other resets reset
|
|
|
|
|
* the index file to the tree object we are switching to. */
|
2013-01-15 13:47:40 +08:00
|
|
|
if (reset_type == SOFT || reset_type == KEEP)
|
2010-01-19 12:26:01 +08:00
|
|
|
die_if_unmerged_cache(reset_type);
|
2013-01-15 13:47:40 +08:00
|
|
|
|
|
|
|
|
if (reset_type != SOFT) {
|
2017-09-05 20:15:21 +08:00
|
|
|
struct lock_file lock = LOCK_INIT;
|
2022-11-19 21:07:38 +08:00
|
|
|
repo_hold_locked_index(the_repository, &lock,
|
|
|
|
|
LOCK_DIE_ON_ERROR);
|
2013-01-15 13:47:51 +08:00
|
|
|
if (reset_type == MIXED) {
|
2013-08-31 05:56:45 +08:00
|
|
|
int flags = quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN;
|
2023-02-07 07:07:40 +08:00
|
|
|
if (read_from_tree(&pathspec, &oid, intent_to_add)) {
|
|
|
|
|
update_ref_status = 1;
|
|
|
|
|
goto cleanup;
|
|
|
|
|
}
|
2019-02-16 01:59:21 +08:00
|
|
|
the_index.updated_skipworktree = 1;
|
2022-03-25 01:33:10 +08:00
|
|
|
if (!no_refresh && get_git_work_tree()) {
|
2018-10-24 03:04:23 +08:00
|
|
|
uint64_t t_begin, t_delta_in_ms;
|
|
|
|
|
|
|
|
|
|
t_begin = getnanotime();
|
2014-02-16 10:28:03 +08:00
|
|
|
refresh_index(&the_index, flags, NULL, NULL,
|
|
|
|
|
_("Unstaged changes after reset:"));
|
2018-10-24 03:04:23 +08:00
|
|
|
t_delta_in_ms = (getnanotime() - t_begin) / 1000000;
|
2022-03-15 09:49:41 +08:00
|
|
|
if (!quiet && advice_enabled(ADVICE_RESET_NO_REFRESH_WARNING) && t_delta_in_ms > REFRESH_INDEX_DELAY_WARNING_IN_MS) {
|
2022-03-15 09:49:40 +08:00
|
|
|
advise(_("It took %.2f seconds to refresh the index after reset. You can use\n"
|
2022-03-24 02:18:00 +08:00
|
|
|
"'--no-refresh' to avoid this."), t_delta_in_ms / 1000.0);
|
2018-10-24 03:04:23 +08:00
|
|
|
}
|
|
|
|
|
}
|
2013-01-15 13:47:47 +08:00
|
|
|
} else {
|
2020-03-17 02:05:07 +08:00
|
|
|
struct object_id dummy;
|
|
|
|
|
char *ref = NULL;
|
|
|
|
|
int err;
|
|
|
|
|
|
2023-03-28 21:58:54 +08:00
|
|
|
repo_dwim_ref(the_repository, rev, strlen(rev),
|
|
|
|
|
&dummy, &ref, 0);
|
2020-03-17 02:05:07 +08:00
|
|
|
if (ref && !starts_with(ref, "refs/"))
|
2021-03-15 02:47:35 +08:00
|
|
|
FREE_AND_NULL(ref);
|
2020-03-17 02:05:07 +08:00
|
|
|
|
|
|
|
|
err = reset_index(ref, &oid, reset_type, quiet);
|
2013-01-15 13:47:47 +08:00
|
|
|
if (reset_type == KEEP && !err)
|
2020-03-17 02:05:07 +08:00
|
|
|
err = reset_index(ref, &oid, MIXED, quiet);
|
2013-01-15 13:47:47 +08:00
|
|
|
if (err)
|
|
|
|
|
die(_("Could not reset index file to revision '%s'."), rev);
|
2020-03-17 02:05:07 +08:00
|
|
|
free(ref);
|
2013-01-15 13:47:47 +08:00
|
|
|
}
|
reset [--mixed]: only write index file once
When doing a mixed reset without paths, the index is locked, read,
reset, and written back as part of the actual reset operation (in
reset_index()). Then, when showing the list of worktree modifications,
we lock the index again, refresh it, and write it.
Change this so we only write the index once, making "git reset" a
little faster. It does mean that the index lock will be held a little
longer, but the difference is small compared to the time spent
refreshing the index.
There is one minor functional difference: We used to say "Could not
write new index file." if the first write failed, and "Could not
refresh index" if the second write failed. Now, we will only use the
first message.
This speeds up "git reset" a little on the linux-2.6 repo (best of
five, warm cache):
Before After
real 0m0.239s 0m0.214s
user 0m0.160s 0m0.130s
sys 0m0.070s 0m0.080s
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-15 13:47:46 +08:00
|
|
|
|
2017-09-05 20:15:21 +08:00
|
|
|
if (write_locked_index(&the_index, &lock, COMMIT_LOCK))
|
2013-01-15 13:47:42 +08:00
|
|
|
die(_("Could not write new index file."));
|
2007-09-11 11:19:34 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-14 16:35:47 +08:00
|
|
|
if (!pathspec.nr && !unborn) {
|
2013-01-15 13:47:47 +08:00
|
|
|
/* Any resets without paths update HEAD to the head being
|
|
|
|
|
* switched to, saving the previous head in ORIG_HEAD before. */
|
2016-09-06 04:08:11 +08:00
|
|
|
update_ref_status = reset_refs(rev, &oid);
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2013-01-15 13:47:47 +08:00
|
|
|
if (reset_type == HARD && !update_ref_status && !quiet)
|
2018-06-29 09:21:58 +08:00
|
|
|
print_new_head_line(lookup_commit_reference(the_repository, &oid));
|
2013-01-15 13:47:47 +08:00
|
|
|
}
|
2013-07-14 16:35:47 +08:00
|
|
|
if (!pathspec.nr)
|
2019-03-29 18:38:59 +08:00
|
|
|
remove_branch_state(the_repository, 0);
|
2007-09-11 11:19:34 +08:00
|
|
|
|
2022-11-09 02:17:38 +08:00
|
|
|
discard_index(&the_index);
|
|
|
|
|
|
2023-02-07 07:07:40 +08:00
|
|
|
cleanup:
|
|
|
|
|
clear_pathspec(&pathspec);
|
parse-options: consistently allocate memory in fix_filename()
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in
front of the filename to make up for the fact that Git has chdir()'d to
the top of the repository. We can do this with prefix_filename(), but
there are a few special cases we handle ourselves.
Unfortunately the memory allocation is inconsistent here; if we do make
it to prefix_filename(), we'll allocate a string which the caller must
free to avoid a leak. But if we hit our special cases, we'll return the
string as-is, and a caller which tries to free it will crash. So there's
no way to win.
Let's consistently allocate, so that callers can do the right thing.
There are now three cases to care about in the function (and hence a
three-armed if/else):
1. we got a NULL input (and should leave it as NULL, though arguably
this is the sign of a bug; let's keep the status quo for now and we
can pick at that scab later)
2. we hit a special case that means we leave the name intact; we
should duplicate the string. This includes our special "-"
matching. Prior to this patch, it also included empty prefixes and
absolute filenames. But we can observe that prefix_filename()
already handles these, so we don't need to detect them.
3. everything else goes to prefix_filename()
I've dropped the "const" from the "char **file" parameter to indicate
that we're allocating, though in practice it's not really important.
This is all being shuffled through a void pointer via opt->value before
it hits code which ever looks at the string. And it's even a bit weird,
because we are really taking _in_ a const string and using the same
out-parameter for a non-const string. A better function signature would
be:
static char *fix_filename(const char *prefix, const char *file);
but that would mean the caller dereferences the double-pointer (and the
NULL check is currently handled inside this function). So I took the
path of least-change here.
Note that we have to fix several callers in this commit, too, or we'll
break the leak-checking tests. These are "new" leaks in the sense that
they are now triggered by the test suite, but these spots have always
been leaky when Git is run in a subdirectory of the repository. I fixed
all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There
may be others in scripts that have other leaks, but we can fix them
later along with those other leaks (and again, you _couldn't_ fix them
before this patch, so this is the necessary first step).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 18:31:22 +08:00
|
|
|
free(pathspec_from_file);
|
2007-09-11 11:19:34 +08:00
|
|
|
return update_ref_status;
|
|
|
|
|
}
|
