Especially in 3rd-party tools, where the shape of the repository/worktree is
unpredictable, it is a wise thing to have an option to pass pathspec
parameters via stdin rather than via the command line, as the latter has
size restrictions that the former does not have.
Johannes Schindelin (1):
res
The third column in command-list.txt determines what group a common
command is printed in 'git help'.
"git reset" is currently in the "work on the current change (see also:
git help everyday)" group. While it's true that "git reset" can
manipulate t
The third column in command-list.txt determines what group a common
command is printed in 'git help'.
"git reset" is currently in the "work on the current change (see also:
git help everyday)" group. While it's true that "git reset" can
manipulate t
Hi Adrian,
On Thu, 7 Mar 2019, Adrian Godong wrote:
> Windows 10, git version 2.21.0.windows.1
>
> git reset tries to delete folder when last file is removed but failed
> to do so if shell is in the deleted folder.
>
> Repro steps (powershell):
> mkdir test
> cd tes
Windows 10, git version 2.21.0.windows.1
git reset tries to delete folder when last file is removed but failed
to do so if shell is in the deleted folder.
Repro steps (powershell):
mkdir test
cd test
git init
mkdir dir
cd dir
add-content .\file ""
git add .
git commit -m "1
Hi,
trying to wrap git, I ran into this problem using git 2.17.1 on Ubuntu 18.04.1.
When fast-forwarding like this:
git reset --keep remotes/origin/master
sometimes git returns an error like:
error: Entry 'foo.txt' not uptodate. Cannot merge.
fatal: Could not reset ind
> > git rm a
> > touch a
> > git add --intent-to-add a
> > git status --short
> > git reset -- a
>
> "git reset" without "-- a" does remove intent-to-add status.
No I'm wrong. But it was because I didn't follow your exact steps
On Tue, Jan 8, 2019 at 2:28 PM Anthony Sottile wrote:
>
> ```
> git --version
> rm -rf t
> git init t
> cd t
> touch a
> git add a
> git commit -m "add a"
> git rm a
> touch a
> git add --intent-to-add a
> git status --short
> git reset -- a
On Mon, Jan 7, 2019 at 11:25 PM Anthony Sottile wrote:
> Even `git reset --intent-to-add -- a` or `git checkout -- a` don't
> seem to clear the `intent-to-add` state
>
> How do I reset the intent-to-add status in this case?
>
> Anthony
Pressed send too quickly, it ap
```
git --version
rm -rf t
git init t
cd t
touch a
git add a
git commit -m "add a"
git rm a
touch a
git add --intent-to-add a
git status --short
git reset -- a
git status --short
```
(the git version below is compiled from
ecbdaf0899161c067986e9d9d564586d4b045d62)
```
$ bash -x
Duy Nguyen writes:
> Without --mixed, you're using the first form
>
> git reset [-q] [] [--] ...
>
> which accepts pathspec. If it's not clear, of course patches are welcome.
Yup. The deprecation is about spelling with "--mixed" when invoking
the "
Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > > wrote:
> > > > >
> > > > >
> > > > > from "man git-reset":
> > > > >
> > > > > SYNOPSIS
> > > > > git reset [-q] [] [--] ...
> >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
> >
> > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> >
> > > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > > wrote:
> > > >
> > >
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > wrote:
> > >
> > >
> > > from "man git-reset":
> > >
> > >
On Sat, 8 Dec 2018, Duy Nguyen wrote:
> On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
> >
> >
> > from "man git-reset":
> >
> > SYNOPSIS
> > git reset [-q] [] [--] ...
> > git reset (--patch | -p) [] [--] [...]
> >
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
>
>
> from "man git-reset":
>
> SYNOPSIS
> git reset [-q] [] [--] ...
> git reset (--patch | -p) [] [--] [...]
> git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q]
> []
>
&g
from "man git-reset":
SYNOPSIS
git reset [-q] [] [--] ...
git reset (--patch | -p) [] [--] [...]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] []
oddly, the third form says nothing about possible "", even
though i'm pretty sure they'r
On Wed, 28 Nov 2018 at 13:02, Martin Ågren wrote:
>
> On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
> >
> > The git-reset documentation page section which is accessible via URL
> > https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
>
On Wed, 28 Nov 2018 at 12:42, Paweł Samoraj wrote:
>
> Hi!
> The git-reset documentation page section which is accessible via URL
> https://git-scm.com/docs/git-reset#_discussion is not looking good.
>
[snip]
>
> The web archive has got a snapshot from 2014-06-28 wh
Hi!
The git-reset documentation page section which is accessible via URL
https://git-scm.com/docs/git-reset#_discussion is not looking good.
ASCII tables should look like this:
working index HEAD target working index HEAD
git fetch https://github.com/benpeart/git reset-refresh-index-v4 &&
git checkout 8a2fef45d4
### Patches
Ben Peart (3):
reset: don't compute unstaged changes after reset when --quiet
reset: add new reset.quiet config setting
reset: warn when refresh_index() takes more than 2
From: Ben Peart
Reworded the documentation for git-reset per review feedback.
Base Ref:
Web-Diff: https://github.com/benpeart/git/commit/1228898917
Checkout: git fetch https://github.com/benpeart/git reset-refresh-index-v3 &&
git checkout 1228898917
### Interdiff (v2..v3):
diff
d
- by avoiding the scan of all files in the repo looking for additional
- unstaged changes. Defaults to false.
+reset.quiet::
+ When set to true, 'git reset' will default to the '--quiet' option.
include::sendemail-config.txt[]
diff --git a/Documentation/gi
every file.
If the user passes the --quiet switch, reset doesn�t display the remaining
unstaged changes but it still does all the work to find them, it just
doesn�t print them out so passing "--quiet" doesn�t help performance.
This patch series will:
1) change the behavior of "gi
Ok I have been bitten by this issue twice. :(
`git reset --hard` will reset modifications in the working directory
(of course). But if I remove a file, add a directory with the same
name, `git reset --hard` will erase that whole directory.
Specifically the following steps:
```
touch file
git add
On Thu, 2017-11-30 at 12:05 -0500, David Turner wrote:
> git submodule add https://my-git-repo blort
> git commit -m 'add a submodule'
> git reset HEAD^ blort
>
> The reset deletes the gitlink, but does not delete the entry in
> .gitmodules. On one hand, this is exa
git submodule add https://my-git-repo blort
git commit -m 'add a submodule'
git reset HEAD^ blort
The reset deletes the gitlink, but does not delete the entry in
.gitmodules. On one hand, this is exactly what the user asked for --
they wanted the path 'blort' to be chang
lse
> bare = false
> logallrefupdates = true
> symlinks = false
> ignorecase = true
> worktree = ../../../../target/upstream
> [remote "origin"]
> url = C:/Users/bion/Desktop/upstream
> fetch = +refs/heads/*:refs
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Now try to go back to the previous commit using git reset --hard:
git log --oneline
1f560be (HEAD -> master) Moved submodule parent directory.
a5977ce A
Efim Goncharuk writes:
> Starting from git v.2.13.0 onwards (v 2.12.2 works fine)
>
> git reset --hard with --work-tree and --git-dir options does not move HEAD to
> hash/tag specified. HEAD remains on same position.
>
> Example:
>
>> git --work-tree=lib/core --g
Hello,
Starting from git v.2.13.0 onwards (v 2.12.2 works fine)
git reset --hard with --work-tree and --git-dir options does not move HEAD to
hash/tag specified. HEAD remains on same position.
Example:
> git --work-tree=lib/core --git-dir=lib/core/.git/ reset --hard 0.1.0
Note:
on anot
s(+), 1 deletion(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 70f3753..727ba46 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -290,7 +290,8 @@ $ git reset --keep start<3>
to branch2 (i.e. "git checko
Signed-off-by: Štěpán Němec
---
Documentation/git-reset.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 8a21198..70f3753 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -115,7 +11
eful.
>
> But. One innocuous `git reset --hard` will just blow it away.
>
> How? reset_index() calls unpack_trees() which in turn tries to populate a
> new index and then discards the old one:
>
> https://github.com/git/git/blob/v2.12.2/unpack-trees.c#L1293
>
> That
Hi all,
I have a problem and would like to solicit advice how to fix it.
The untracked cache has made a real difference on rather large
repositories with tons of directories, and it is really, really useful.
But. One innocuous `git reset --hard` will just blow it away.
How? reset_index() calls
Dear list
Like it was suggested on git-users list I'm forwarding the original
message here.
I found out that "git reset --hard" produced different outcome
depending on current index content, i.e. when there is no entry for a
file in working tree it actually changed that fil
On Thu, Apr 20, 2017 at 12:41 PM, Brandon Williams wrote:
> On 04/18, Stefan Beller wrote:
>> v2:
>> * improved commit message to be proper English (Thanks, Philip!)
>> * clarified why the patch 2 is so short (i.e. it doesn't matter if the
>> submodule
>> is initialized in the preparation repo,
d6 (Merge branch
> 'sb/checkout-recurse-submodules', 2017-03-28), you would expect that
> teaching to recurse into submodules is easy for all the remaining
> working tree manipulations?
>
> It turns out it is. See the last patch how we teach git-reset to recurse
> into s
g
working tree manipulations?
It turns out it is. See the last patch how we teach git-reset to recurse
into submodules.
However when thinking more about what git-reset is expected to do,
I added tests and some fixes for them (patch 2+3).
patch 1 is a correctness thing, required for patch 3.
Thanks,
Stefan
Now that the BIG one has landed, e394fa01d6 (Merge branch
'sb/checkout-recurse-submodules', 2017-03-28), you would expect that
teaching to recurse into submodules is easy for all the remaining
working tree manipulations?
It turns out it is. See the last patch how we teach git-reset
On Tue, Mar 21, 2017 at 10:12:18PM +, Thomas Gummerer wrote:
> For "git stash -p --no-keep-index", the pathspec argument is currently
> not passed to "git reset". This means that changes that are staged but
> that are excluded from the pathspec still get unstag
I wonder if it has always been
> > unnecessary, but we never noticed because it's just a noop.
>
> I do think the "-u" is necessary. Say we have a repository with
> changes in 'foo' and 'bar', where the changes in bar are added to the
> index.
>
For "git stash -p --no-keep-index", the pathspec argument is currently
not passed to "git reset". This means that changes that are staged but
that are excluded from the pathspec still get unstaged by git stash -p.
Make sure that doesn't happen by passing the pathspec arg
On 03/20, Jeff King wrote:
> On Sun, Mar 19, 2017 at 08:23:51PM +, Thomas Gummerer wrote:
>
> > For "git stash -p --no-keep-index", the pathspec argument is currently
> > not passed to "git reset". This means that changed that are staged but
> > t
On Sun, Mar 19, 2017 at 08:23:51PM +, Thomas Gummerer wrote:
> For "git stash -p --no-keep-index", the pathspec argument is currently
> not passed to "git reset". This means that changed that are staged but
> that are excluded from the pathspec still get unsta
For "git stash -p --no-keep-index", the pathspec argument is currently
not passed to "git reset". This means that changed that are staged but
that are excluded from the pathspec still get unstaged by git stash -p.
Make sure that doesn't happen by passing the pathspec arg
ot;just before the commit".
Sure, but other workdir changes after the commit would have been blown
away; so why not this one?
> > > * lack of --recurse-submodules in git-reset? (and that not
> > > being default, see prior point)
> >
> > Or possibly this.
>
&
;
>> * git-status not reporting about uninitialized submodules?
>
> Here, I think git-status is correctly reporting the state of the repo.
>
>> * git reset --mixed not touching the submodule worktree
>
> Yes, possibly.
>
>> * lack of --recurse-submodules in git-reset
On Mon, 2017-03-13 at 10:51 -0700, Stefan Beller wrote:
> On Fri, Mar 10, 2017 at 1:06 PM, David Turner
> wrote:
> > Git reset --mixed ignores submodules which are not
> > initialized. I've
> > attached a demo script.
> >
> > On one hand, this matches
On Fri, Mar 10, 2017 at 1:06 PM, David Turner wrote:
> Git reset --mixed ignores submodules which are not initialized. I've
> attached a demo script.
>
> On one hand, this matches the documentation ("Resets the index but not
> the working tree"). But on the other h
Git reset --mixed ignores submodules which are not initialized. I've
attached a demo script.
On one hand, this matches the documentation ("Resets the index but not
the working tree"). But on the other hand, it kind of doesn't: "(i.e.,
the changed files are preserved
Don't mention git reset --hard in the documentation for git stash save.
It's an implementation detail that doesn't matter to the end user and
thus shouldn't be exposed to them. In addition it's not quite true for
git stash -p, and will not be true when a filename argumen
>
> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all]
> [-q|--quiet] []::
>
> - Save your local modifications to a new 'stash', and run `git reset
> - --hard` to revert them. The part is optional and gives
> + Save your loca
Don't mention git reset --hard in the documentation for git stash save.
It's an implementation detail that doesn't matter to the end user and
thus shouldn't be exposed to them. In addition it's not quite true for
git stash -p, and will not be true when a filename argumen
On 01/30, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Don't mention git reset --hard in the documentation for git stash save.
> > It's an implementation detail that doesn't matter to the end user and
> > thus shouldn't be exposed to them.
&
Thomas Gummerer writes:
> Don't mention git reset --hard in the documentation for git stash save.
> It's an implementation detail that doesn't matter to the end user and
> thus shouldn't be exposed to them.
Everybody understands what "reset --hard" does;
Don't mention git reset --hard in the documentation for git stash save.
It's an implementation detail that doesn't matter to the end user and
thus shouldn't be exposed to them. In addition it's not quite true for
git stash -p, and will not be true when a filename argumen
On Sat, Jan 28, 2017 at 07:30:28PM +, Thomas Gummerer wrote:
> Thanks all who chimed in here. My new description is definitely not
> right. The reason I wanted to change it is part because it's an
> implementation detail, and part because it's going to be not quite
> right when the filename
--- a/Documentation/git-stash.txt
> >> +++ b/Documentation/git-stash.txt
> >> @@ -47,8 +47,9 @@ OPTIONS
> >>
> >> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked]
> >> [-a|--all] [-q|--quiet] []::
> >>
> >> - Save
| 33 +++
3 files changed, 89 insertions(+), 1 deletion(-)
create mode 100755 t/t7107-reset-stdin.sh
base-commit: 4e59582ff70d299f5a88449891e78d15b4b3fabe
Published-As: https://github.com/dscho/git/releases/tag/reset-stdin-v3
Fetch-It-Via: git fetch https://github.com/dscho/git reset-
o/git/releases/tag/reset-stdin-v2
Fetch-It-Via: git fetch https://github.com/dscho/git reset-stdin-v2
Interdiff vs v1:
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 533ef69f91..abb71bb805 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@
Jakub Narębski writes:
>>> - Save your local modifications to a new 'stash', and run `git reset
>>> - --hard` to revert them. The part is optional and gives
>>> + Save your local modifications to a new 'stash', and revert the
>>>
it-stash.txt
>> @@ -47,8 +47,9 @@ OPTIONS
>>
>> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked]
>> [-a|--all] [-q|--quiet] []::
>>
>> -Save your local modifications to a new 'stash', and run `git reset
>> ---hard` to reve
t;> +++ b/Documentation/git-stash.txt
>> @@ -47,8 +47,9 @@ OPTIONS
>>
>> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked]
>> [-a|--all] [-q|--quiet] []::
>>
>> -Save your local modifications to a new 'stash', and run `git reset
&
>
> save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all]
> [-q|--quiet] []::
>
> - Save your local modifications to a new 'stash', and run `git reset
> - --hard` to revert them. The part is optional and gives
> + Save your local
W dniu 21.01.2017 o 21:08, Thomas Gummerer pisze:
> Don't mention git reset --hard in the documentation for git stash save.
> It's an implementation detail that doesn't matter to the end user and
> thus shouldn't be exposed to them.
>
> Signed-off-by: Thomas G
On 2017-01-21 20:08:02, Thomas Gummerer wrote:
> Don't mention git reset --hard in the documentation for git stash save.
> It's an implementation detail that doesn't matter to the end user and
> thus shouldn't be exposed to them.
> [...]
> + Save your local
Don't mention git reset --hard in the documentation for git stash save.
It's an implementation detail that doesn't matter to the end user and
thus shouldn't be exposed to them.
Signed-off-by: Thomas Gummerer
---
Documentation/git-stash.txt | 5 +++--
1 file changed, 3 insert
Use test_when_finished to run 'git reset --hard' after each test so
that the repository is left in a saner state for the next test.
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard
Tests now always run 'git reset --hard' at the end (even if they
fail), so it's no longer necessary to run 'git reset --hard' at the
beginning of a test.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/t/t76
@@ -289,23 +289,23 @@ test_expect_success 'mergetool takes partial path' '
'
test_expect_success 'mergetool delete/delete conflict' '
- test_when_finished "git reset --hard HEAD" &&
+ test_when_finished "git reset --
Tests now always run 'git reset --hard' at the end (even if they
fail), so it's no longer necessary to run 'git reset --hard' at the
beginning of a test.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/t/t76
@@ -289,23 +289,23 @@ test_expect_success 'mergetool takes partial path' '
'
test_expect_success 'mergetool delete/delete conflict' '
- test_when_finished "git reset --hard HEAD" &&
+ test_when_finished "git reset --
Use test_when_finished to run 'git reset --hard' after each test so
that the repository is left in a saner state for the next test.
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard
Use test_when_finished to run 'git reset --hard' after each test so
that the repository is left in a saner state for the next test.
This is a step toward making the tests more independent so that if one
test fails it doesn't cause subsequent tests to fail.
Signed-off-by: Richard
@@ -289,23 +289,23 @@ test_expect_success 'mergetool takes partial path' '
'
test_expect_success 'mergetool delete/delete conflict' '
- test_when_finished "git reset --hard HEAD" &&
+ test_when_finished "git reset --
Tests now always run 'git reset --hard' at the end (even if they
fail), so it's no longer necessary to run 'git reset --hard' at the
beginning of a test.
Signed-off-by: Richard Hansen
---
t/t7610-mergetool.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/t/t76
Duy Nguyen writes:
> rebase and cherry-pick/revert are not exactly in the same situation.
> When cherry-pick/revert in "continue/abort" mode, there's usually some
> conflicted files and it's easy to notice.
>
> But an interactive rebase could stop at some commit with clean
> worktree (the 'edit'
On Sat, Dec 10, 2016 at 2:24 AM, Stephan Beyer wrote:
> Hi Junio,
>
> On 12/09/2016 07:07 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>> Having the same operation with different names only increases git
>>> reputation of bad/inconsistent UI. Either forget is renamed to quit,
>>> or vice vers
On 12/09/2016 08:24 PM, Stephan Beyer wrote:
> t3510 also shows another use-case for --quit: the title says it all:
> "cherry-pick --quit" to "cherry-pick --abort"
I should've read what I actually pasted.
I wanted to paste: '--quit keeps HEAD and conflicted index intact'
Sorry for making no sense
Hi Junio,
On 12/09/2016 07:07 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>> Having the same operation with different names only increases git
>> reputation of bad/inconsistent UI. Either forget is renamed to quit,
>> or vice versa. I prefer forget, but the decision is yours and the
>> communi
Duy Nguyen writes:
> On Thu, Dec 8, 2016 at 3:04 AM, Junio C Hamano wrote:
>> Stephan Beyer writes:
>>
>>> [1] By the way: git cherry-pick --quit, git rebase --forget ...
>>> different wording for the same thing makes things unintuitive.
>>
>> It is not too late to STOP "--forget" from getting
On Thu, Dec 8, 2016 at 3:04 AM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>> [1] By the way: git cherry-pick --quit, git rebase --forget ...
>> different wording for the same thing makes things unintuitive.
>
> It is not too late to STOP "--forget" from getting added to "rebase"
> and give
Hi,
On Wed, Dec 7, 2016 at 7:36 PM, Stephan Beyer wrote:
> Hi,
>
> On 12/06/2016 07:58 PM, Junio C Hamano wrote:
>
>> (1) The third invocation of "cherry-pick" with "--abort" to get rid
>> of the state from the unfinished cherry-pick we did previously
>> is necessary, but the command d
On Thu, Dec 8, 2016 at 3:35 AM, Stephan Beyer wrote:
> Hi,
>
> On 12/07/2016 09:04 PM, Junio C Hamano wrote:
>> Stephan Beyer writes:
>>
>>> [1] By the way: git cherry-pick --quit, git rebase --forget ...
>>> different wording for the same thing makes things unintuitive.
>>
>> It is not too late
Hi,
On 12/07/2016 09:04 PM, Junio C Hamano wrote:
> Stephan Beyer writes:
>
>> [1] By the way: git cherry-pick --quit, git rebase --forget ...
>> different wording for the same thing makes things unintuitive.
>
> It is not too late to STOP "--forget" from getting added to "rebase"
> and give it
Stephan Beyer writes:
> [1] By the way: git cherry-pick --quit, git rebase --forget ...
> different wording for the same thing makes things unintuitive.
It is not too late to STOP "--forget" from getting added to "rebase"
and give it a better name.
Having said that, I have a feeling that these
an old fork point.
> ... the git-prompt gives "|CHERRY-PICKING" correctly.
>
> $ git reset --hard v2.10.2^0
> ... the git-prompt no longer says "|CHERRY-PICKING"
>
> $ edit && git commit -m "prelim work for backporting"
lict, decide to give up backporting to
> ... such an old fork point.
> ... the git-prompt gives "|CHERRY-PICKING" correctly.
>
> $ git reset --hard v2.10.2^0
> ... the git-prompt no longer says "|CHERRY-PICKING"
>
> $ edit && git c
licly available and stable, shows how bad it is.
$ git checkout v2.9.3^0
$ git cherry-pick 0582a34f52..a94bb68397
... see conflict, decide to give up backporting to
... such an old fork point.
... the git-prompt gives "|CHERRY-PICKING" correctly.
$ git reset -
in mind by anybody who wants to move this topic forward is that
a path that does not exist in the HEAD commit MUST be removed from
the index and the working tree upon "git reset --hard" when the path
resulted from a mergy operation. I.e. in this sequence:
$ git merge other-branch ;# o
knows it is recoverable and using fsck to
recover is not nice and easy for the user.
So having a bloblog for example in .git/logs/blobs/, like the reflogs
we already have, but for blobs, could help even if (first) it's just
about writing the filenames and sha1s related to the blobs we stop
ref
d the issue, this seems like
a smaller part of destroying local changes with a hard reset, and I'm
one of the lucky ones where it is recoverable.
Has anyone discussed having `git reset --hard` create objects for the
current state of anything it's about to destroy, specifically so they
On Sat, Dec 3, 2016 at 5:49 PM, Johannes Sixt wrote:
> Am 03.12.2016 um 06:04 schrieb Julian de Bhal:
>>
>> If you `git add new_file; git reset --hard`, new_file is gone forever.
>
> AFAIC, this is a feature ;-) I occasionally use it to remove a file when I
> already hav
On Sat, Dec 3, 2016 at 6:04 AM, Julian de Bhal wrote:
> If you `git add new_file; git reset --hard`, new_file is gone forever.
>
> This is totally what git says it will do on the box, but it caught me out.
Yeah, you are not the first one, and probably not the last
unfortunately, to be
Am 03.12.2016 um 06:04 schrieb Julian de Bhal:
If you `git add new_file; git reset --hard`, new_file is gone forever.
AFAIC, this is a feature ;-) I occasionally use it to remove a file when
I already have git-gui in front of me. Then it's often less convenient
to type the path in a
If you `git add new_file; git reset --hard`, new_file is gone forever.
This is totally what git says it will do on the box, but it caught me out.
It might seem a little less stupid if I explain what I was doing: I was
breaking apart a chunk of work into smaller changes:
git commit -a -m
Jeff King writes:
> Anyway, the existence of this discussion is probably a good argument in
> favor of Dscho's patch. I was mostly curious how close our plumbing
> tools could come.
Sure, in 100% agreement.
ree -r --ignore-missing $paths
> ) | git update-index --index-info
>
> which does not look too bad, even though this
>
> printf "%s\n" $paths | git reset --stdin
>
> does look shorter.
Of course neither of ours solutions works when "$paths" i
1 - 100 of 302 matches
Mail list logo
