|
|
|
|
/*
|
|
|
|
|
* "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
|
|
|
|
|
*/
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
#include "tag.h"
|
|
|
|
|
#include "object.h"
|
|
|
|
|
#include "commit.h"
|
|
|
|
|
#include "run-command.h"
|
|
|
|
|
#include "refs.h"
|
|
|
|
|
#include "diff.h"
|
|
|
|
|
#include "diffcore.h"
|
|
|
|
|
#include "tree.h"
|
|
|
|
|
#include "branch.h"
|
|
|
|
|
#include "parse-options.h"
|
|
|
|
|
#include "unpack-trees.h"
|
|
|
|
|
#include "cache-tree.h"
|
|
|
|
|
|
|
|
|
|
static const char * const git_reset_usage[] = {
|
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(-)
16 years ago
|
|
|
"git reset [--mixed | --soft | --hard | --merge] [-q] [<commit>]",
|
|
|
|
|
"git reset [--mixed] <commit> [--] <paths>...",
|
|
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
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(-)
16 years ago
|
|
|
enum reset_type { MIXED, SOFT, HARD, MERGE, NONE };
|
|
|
|
|
static const char *reset_type_names[] = { "mixed", "soft", "hard", "merge", NULL };
|
|
|
|
|
|
|
|
|
|
static char *args_to_str(const char **argv)
|
|
|
|
|
{
|
|
|
|
|
char *buf = NULL;
|
|
|
|
|
unsigned long len, space = 0, nr = 0;
|
|
|
|
|
|
|
|
|
|
for (; *argv; argv++) {
|
|
|
|
|
len = strlen(*argv);
|
|
|
|
|
ALLOC_GROW(buf, nr + 1 + len, space);
|
|
|
|
|
if (nr)
|
|
|
|
|
buf[nr++] = ' ';
|
|
|
|
|
memcpy(buf + nr, *argv, len);
|
|
|
|
|
nr += len;
|
|
|
|
|
}
|
|
|
|
|
ALLOC_GROW(buf, nr + 1, space);
|
|
|
|
|
buf[nr] = '\0';
|
|
|
|
|
|
|
|
|
|
return buf;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int is_merge(void)
|
|
|
|
|
{
|
|
|
|
|
return !access(git_path("MERGE_HEAD"), F_OK);
|
|
|
|
|
}
|
|
|
|
|
|
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(-)
16 years ago
|
|
|
static int reset_index_file(const unsigned char *sha1, int reset_type, int quiet)
|
|
|
|
|
{
|
|
|
|
|
int nr = 1;
|
|
|
|
|
int newfd;
|
|
|
|
|
struct tree_desc desc[2];
|
|
|
|
|
struct unpack_trees_options opts;
|
|
|
|
|
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
if (!quiet)
|
|
|
|
|
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(-)
16 years ago
|
|
|
switch (reset_type) {
|
|
|
|
|
case MERGE:
|
|
|
|
|
opts.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(-)
16 years ago
|
|
|
break;
|
|
|
|
|
case HARD:
|
|
|
|
|
opts.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(-)
16 years ago
|
|
|
/* fallthrough */
|
|
|
|
|
default:
|
|
|
|
|
opts.reset = 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(-)
16 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
newfd = hold_locked_index(lock, 1);
|
|
|
|
|
|
|
|
|
|
read_cache_unmerged();
|
|
|
|
|
|
|
|
|
|
if (!fill_tree_descriptor(desc + nr - 1, sha1))
|
|
|
|
|
return error("Failed to find tree of %s.", sha1_to_hex(sha1));
|
|
|
|
|
if (unpack_trees(nr, desc, &opts))
|
|
|
|
|
return -1;
|
|
|
|
|
if (write_cache(newfd, active_cache, active_nr) ||
|
|
|
|
|
commit_locked_index(lock))
|
|
|
|
|
return error("Could not write new index file.");
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void print_new_head_line(struct commit *commit)
|
|
|
|
|
{
|
|
|
|
|
const char *hex, *body;
|
|
|
|
|
|
|
|
|
|
hex = find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV);
|
|
|
|
|
printf("HEAD is now at %s", hex);
|
|
|
|
|
body = strstr(commit->buffer, "\n\n");
|
|
|
|
|
if (body) {
|
|
|
|
|
const char *eol;
|
|
|
|
|
size_t len;
|
|
|
|
|
body += 2;
|
|
|
|
|
eol = strchr(body, '\n');
|
|
|
|
|
len = eol ? eol - body : strlen(body);
|
|
|
|
|
printf(" %.*s\n", (int) len, body);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
printf("\n");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int update_index_refresh(int fd, struct lock_file *index_lock, int flags)
|
|
|
|
|
{
|
|
|
|
|
int result;
|
|
|
|
|
|
|
|
|
|
if (!index_lock) {
|
|
|
|
|
index_lock = xcalloc(1, sizeof(struct lock_file));
|
|
|
|
|
fd = hold_locked_index(index_lock, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (read_cache() < 0)
|
|
|
|
|
return error("Could not read index");
|
|
|
|
|
|
|
|
|
|
result = refresh_index(&the_index, (flags), NULL, NULL,
|
|
|
|
|
"Unstaged changes after reset:") ? 1 : 0;
|
|
|
|
|
if (write_cache(fd, active_cache, active_nr) ||
|
|
|
|
|
commit_locked_index(index_lock))
|
|
|
|
|
return error ("Could not refresh index");
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void update_index_from_diff(struct diff_queue_struct *q,
|
|
|
|
|
struct diff_options *opt, void *data)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int *discard_flag = data;
|
|
|
|
|
|
|
|
|
|
/* do_diff_cache() mangled the index */
|
|
|
|
|
discard_cache();
|
|
|
|
|
*discard_flag = 1;
|
|
|
|
|
read_cache();
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
|
|
|
struct diff_filespec *one = q->queue[i]->one;
|
|
|
|
|
if (one->mode) {
|
|
|
|
|
struct cache_entry *ce;
|
|
|
|
|
ce = make_cache_entry(one->mode, one->sha1, one->path,
|
|
|
|
|
0, 0);
|
|
|
|
|
if (!ce)
|
|
|
|
|
die("make_cache_entry failed for path '%s'",
|
|
|
|
|
one->path);
|
|
|
|
|
add_cache_entry(ce, ADD_CACHE_OK_TO_ADD |
|
|
|
|
|
ADD_CACHE_OK_TO_REPLACE);
|
|
|
|
|
} else
|
|
|
|
|
remove_file_from_cache(one->path);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int interactive_reset(const char *revision, const char **argv,
|
|
|
|
|
const char *prefix)
|
|
|
|
|
{
|
|
|
|
|
const char **pathspec = NULL;
|
|
|
|
|
|
|
|
|
|
if (*argv)
|
|
|
|
|
pathspec = get_pathspec(prefix, argv);
|
|
|
|
|
|
|
|
|
|
return run_add_interactive(revision, "--patch=reset", pathspec);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int read_from_tree(const char *prefix, const char **argv,
|
|
|
|
|
unsigned char *tree_sha1, int refresh_flags)
|
|
|
|
|
{
|
|
|
|
|
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
|
|
|
|
|
int index_fd, index_was_discarded = 0;
|
|
|
|
|
struct diff_options opt;
|
|
|
|
|
|
|
|
|
|
memset(&opt, 0, sizeof(opt));
|
|
|
|
|
diff_tree_setup_paths(get_pathspec(prefix, (const char **)argv), &opt);
|
|
|
|
|
opt.output_format = DIFF_FORMAT_CALLBACK;
|
|
|
|
|
opt.format_callback = update_index_from_diff;
|
|
|
|
|
opt.format_callback_data = &index_was_discarded;
|
|
|
|
|
|
|
|
|
|
index_fd = hold_locked_index(lock, 1);
|
|
|
|
|
index_was_discarded = 0;
|
|
|
|
|
read_cache();
|
|
|
|
|
if (do_diff_cache(tree_sha1, &opt))
|
|
|
|
|
return 1;
|
|
|
|
|
diffcore_std(&opt);
|
|
|
|
|
diff_flush(&opt);
|
|
|
|
|
diff_tree_release_paths(&opt);
|
|
|
|
|
|
|
|
|
|
if (!index_was_discarded)
|
|
|
|
|
/* The index is still clobbered from do_diff_cache() */
|
|
|
|
|
discard_cache();
|
|
|
|
|
return update_index_refresh(index_fd, lock, refresh_flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void prepend_reflog_action(const char *action, char *buf, size_t size)
|
|
|
|
|
{
|
|
|
|
|
const char *sep = ": ";
|
|
|
|
|
const char *rla = getenv("GIT_REFLOG_ACTION");
|
|
|
|
|
if (!rla)
|
|
|
|
|
rla = sep = "";
|
|
|
|
|
if (snprintf(buf, size, "%s%s%s", rla, sep, action) >= size)
|
|
|
|
|
warning("Reflog action message too long: %.*s...", 50, buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int cmd_reset(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
|
|
|
|
int i = 0, reset_type = NONE, update_ref_status = 0, quiet = 0;
|
|
|
|
|
int patch_mode = 0;
|
|
|
|
|
const char *rev = "HEAD";
|
|
|
|
|
unsigned char sha1[20], *orig = NULL, sha1_orig[20],
|
|
|
|
|
*old_orig = NULL, sha1_old_orig[20];
|
|
|
|
|
struct commit *commit;
|
|
|
|
|
char *reflog_action, msg[1024];
|
|
|
|
|
const struct option options[] = {
|
|
|
|
|
OPT__QUIET(&quiet),
|
|
|
|
|
OPT_SET_INT(0, "mixed", &reset_type,
|
|
|
|
|
"reset HEAD and index", MIXED),
|
|
|
|
|
OPT_SET_INT(0, "soft", &reset_type, "reset only HEAD", SOFT),
|
|
|
|
|
OPT_SET_INT(0, "hard", &reset_type,
|
|
|
|
|
"reset HEAD, index and working tree", HARD),
|
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(-)
16 years ago
|
|
|
OPT_SET_INT(0, "merge", &reset_type,
|
|
|
|
|
"reset HEAD, index and working tree", MERGE),
|
|
|
|
|
OPT_BOOLEAN('p', "patch", &patch_mode, "select hunks interactively"),
|
|
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, prefix, options, git_reset_usage,
|
|
|
|
|
PARSE_OPT_KEEP_DASHDASH);
|
|
|
|
|
reflog_action = args_to_str(argv);
|
|
|
|
|
setenv("GIT_REFLOG_ACTION", reflog_action, 0);
|
|
|
|
|
|
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>
17 years ago
|
|
|
/*
|
|
|
|
|
* Possible arguments are:
|
|
|
|
|
*
|
|
|
|
|
* git reset [-opts] <rev> <paths>...
|
|
|
|
|
* git reset [-opts] <rev> -- <paths>...
|
|
|
|
|
* git reset [-opts] -- <paths>...
|
|
|
|
|
* git reset [-opts] <paths>...
|
|
|
|
|
*
|
|
|
|
|
* At this point, argv[i] points immediately after [-opts].
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (i < argc) {
|
|
|
|
|
if (!strcmp(argv[i], "--")) {
|
|
|
|
|
i++; /* reset to HEAD, possibly with paths */
|
|
|
|
|
} else if (i + 1 < argc && !strcmp(argv[i+1], "--")) {
|
|
|
|
|
rev = argv[i];
|
|
|
|
|
i += 2;
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Otherwise, argv[i] could be either <rev> or <paths> and
|
|
|
|
|
* has to be unambiguous.
|
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>
17 years ago
|
|
|
*/
|
|
|
|
|
else if (!get_sha1(argv[i], sha1)) {
|
|
|
|
|
/*
|
|
|
|
|
* Ok, argv[i] looks like a rev; it should not
|
|
|
|
|
* be a filename.
|
|
|
|
|
*/
|
|
|
|
|
verify_non_filename(prefix, argv[i]);
|
|
|
|
|
rev = argv[i++];
|
|
|
|
|
} else {
|
|
|
|
|
/* Otherwise we treat this as a filename */
|
|
|
|
|
verify_filename(prefix, argv[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (get_sha1(rev, sha1))
|
|
|
|
|
die("Failed to resolve '%s' as a valid ref.", rev);
|
|
|
|
|
|
|
|
|
|
commit = lookup_commit_reference(sha1);
|
|
|
|
|
if (!commit)
|
|
|
|
|
die("Could not parse object '%s'.", rev);
|
|
|
|
|
hashcpy(sha1, commit->object.sha1);
|
|
|
|
|
|
|
|
|
|
if (patch_mode) {
|
|
|
|
|
if (reset_type != NONE)
|
|
|
|
|
die("--patch is incompatible with --{hard,mixed,soft}");
|
|
|
|
|
return interactive_reset(rev, argv + i, prefix);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* git reset tree [--] paths... can be used to
|
|
|
|
|
* load chosen paths from the tree into the index without
|
|
|
|
|
* affecting the working tree nor HEAD. */
|
|
|
|
|
if (i < argc) {
|
|
|
|
|
if (reset_type == MIXED)
|
|
|
|
|
warning("--mixed option is deprecated with paths.");
|
|
|
|
|
else if (reset_type != NONE)
|
|
|
|
|
die("Cannot do %s reset with paths.",
|
|
|
|
|
reset_type_names[reset_type]);
|
|
|
|
|
return read_from_tree(prefix, argv + i, sha1,
|
|
|
|
|
quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
|
|
|
|
|
}
|
|
|
|
|
if (reset_type == NONE)
|
|
|
|
|
reset_type = MIXED; /* by default */
|
|
|
|
|
|
|
|
|
|
if (reset_type == HARD || reset_type == MERGE)
|
|
|
|
|
setup_work_tree();
|
|
|
|
|
|
|
|
|
|
if (reset_type == MIXED && is_bare_repository())
|
|
|
|
|
die("%s reset is not allowed in a bare repository",
|
|
|
|
|
reset_type_names[reset_type]);
|
|
|
|
|
|
|
|
|
|
/* 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. */
|
|
|
|
|
if (reset_type == SOFT) {
|
|
|
|
|
if (is_merge() || read_cache() < 0 || unmerged_cache())
|
|
|
|
|
die("Cannot do a soft reset in the middle of a merge.");
|
|
|
|
|
}
|
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(-)
16 years ago
|
|
|
else if (reset_index_file(sha1, reset_type, quiet))
|
|
|
|
|
die("Could not reset index file to revision '%s'.", rev);
|
|
|
|
|
|
|
|
|
|
/* Any resets update HEAD to the head being switched to,
|
|
|
|
|
* saving the previous head in ORIG_HEAD before. */
|
|
|
|
|
if (!get_sha1("ORIG_HEAD", sha1_old_orig))
|
|
|
|
|
old_orig = sha1_old_orig;
|
|
|
|
|
if (!get_sha1("HEAD", sha1_orig)) {
|
|
|
|
|
orig = sha1_orig;
|
|
|
|
|
prepend_reflog_action("updating ORIG_HEAD", msg, sizeof(msg));
|
|
|
|
|
update_ref(msg, "ORIG_HEAD", orig, old_orig, 0, MSG_ON_ERR);
|
|
|
|
|
}
|
|
|
|
|
else if (old_orig)
|
|
|
|
|
delete_ref("ORIG_HEAD", old_orig, 0);
|
|
|
|
|
prepend_reflog_action("updating HEAD", msg, sizeof(msg));
|
|
|
|
|
update_ref_status = update_ref(msg, "HEAD", sha1, orig, 0, MSG_ON_ERR);
|
|
|
|
|
|
|
|
|
|
switch (reset_type) {
|
|
|
|
|
case HARD:
|
|
|
|
|
if (!update_ref_status && !quiet)
|
|
|
|
|
print_new_head_line(commit);
|
|
|
|
|
break;
|
|
|
|
|
case SOFT: /* Nothing else to do. */
|
|
|
|
|
break;
|
|
|
|
|
case MIXED: /* Report what has not been updated. */
|
|
|
|
|
update_index_refresh(0, NULL,
|
|
|
|
|
quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
remove_branch_state();
|
|
|
|
|
|
|
|
|
|
free(reflog_action);
|
|
|
|
|
|
|
|
|
|
return update_ref_status;
|
|
|
|
|
}
|
