What is the diff between a --soft and a blank reset

What is the diff between a --soft and a blank reset

[A bughunter]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

What is the diff between a --soft and a blank which is --mixed reset? Does this from --soft: "leaves all your changed files "Changes to be committed", as  git status would put it.'" mean soft leaves the adds indexed but before the adds were commit and without commit whereas --mixed would erase the index having adds ready to commit? This is how I gather it however the manpage hint's at being written by a thirdparty and having conflicting and scattered jargon makes it to where the user cannot communicate in a meaningful way about using the software. The difference here is touching the index but what does that mean in pragma: what does a git repo index handle? Isn't there some better way to find answers rather than Google advertisements or IRC wrong answers.  See the snippet from the manpage below:

git reset [<mode>] [<commit>]
           This form resets the current branch head to <commit> and possibly
           updates the index (resetting it to the tree of <commit>) and the
           working tree depending on <mode>. Before the operation, ORIG_HEAD
           is set to the tip of the current branch. If <mode> is omitted,
           defaults to --mixed. The <mode> must be one of the following:

           --soft
               Does not touch the index file or the working tree at all (but
               resets the head to <commit>, just like all modes do). This
               leaves all your changed files "Changes to be committed", as
               git status would put it.

           --mixed
               Resets the index but not the working tree (i.e., the changed
               files are preserved but not marked for commit) and reports
               what has not been updated. This is the default action.

               If -N is specified, removed paths are marked as intent-to-add
               (see git-add(1)).



from A_bughunter@proton.me

Sent with Proton Mail secure email.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmc5T+sJkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu
8pkAAKvTAQCQIJGVcxvf7jSYvcPMUyeF15FriACM1QzPX2pyn++bxwEAxuK2
c5qmTxALcRE4OKHk8UkP2S0gHqnos75thGKMwAI=
=Ilx7
-----END PGP SIGNATURE-----

[-- Attachment #2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 653 bytes --]

[-- Attachment #3: publickey - A_bughunter@proton.me - 0x66540805.asc.sig --]
[-- Type: application/pgp-signature, Size: 118 bytes --]

Re: What is the diff between a --soft and a blank reset

[Chris Torek]

On Sat, Nov 16, 2024 at 6:08 PM A bughunter <A_bughunter@proton.me> wrote:
> The difference here is touching the index but what does that mean in pragma ...

Understanding "the index" is _crucial_ to using Git, yet it's not
often explained very well.

(Note: _emphasis_ means italics emphasis, while ALL CAPS means
bold emphasis, below.)

I think it helps to start with a simple fact about _every_ source
management system: such a system, by definition, _must_ have TWO
COPIES OF EVERY FILE available at all times.  This follows from
the fact that you can get back the version you started with -- and
to do that, the system must retain each original, unedited version
-- and yet you must also be able to edit files, which means the
system must retain the edited files as well.  So those are the two
_required_ copies: original, and edited.  If the two are the same,
it's at least theoretically possible to share them, but that's not
important here.  The actively-being-edited files are the _working
tree_, while the frozen-for-all-time original files are saved
(forever) in a Git commit, in the case of Git.

What's unusual about Git is that it keeps a THIRD copy of every
file.  As noted above, if any given pair of copies match, it's at
least theoretically possible to share them -- and Git sometimes
does -- but that's not important here.

What Git's index is all about is that it HOLDS THE THIRD COPY.
The reason this is crucial to know is that running:

    git commit

tells Git to make a *new* commit FROM THIS THIRD COPY.

There are tricks you can use to attempt to hide or ignore this
third copy, but using them is, in my opinion, a bad idea, because
eventually one of these tricks fails and you're exposed to the
fact that there _is_ a third copy.  You might as well just get
used to the idea.

Once you _are_ used to the idea, much of the rest of Git begins
to make sense:

 * `git add` mainly copies files _into_ the index, preparing them
   for a future commit.

 * `git commit` takes whatever is in the index _right then_ and
   uses that to make the new (permanently-frozen) copy of all
   those files.

Now, logically, `git reset` might be the one that undoes `git
add`.  And it _does_ do that.  The problem is that it does a
lot more as well.  It has, in fact, _three_ primary jobs:

 * It can move `HEAD`.  (Understanding precisly what `HEAD` means,
   in Git, is another crucial item, but this message won't cover
   that.)

 * It can copy some or all files from a commit into the index.

 * Last, it can _also_ copy those files from the commit, into the
   index, and then on into the working tree.

(Even more unfortunately, `git reset` has several auxiliary jobs
as well as these three primary ones.  I won't cover these.)

The three options -- `--soft`, `--mixed`, and `--hard` -- tell
`git reset` which of these three jobs to do:

  * With `--soft`, `git reset` _only_ adjusts `HEAD`.  The
    default adjustment is to leave it unchanged, so running
    `git reset --soft` with no additional arguments does
    nothing at all.  That is, it does only job #1, then
    stops.

 * With `--mixed`, `git reset` adjusts `HEAD` as before --
   it's usually wisest to not have it adjust anything for
   this case, in my opinion -- and then goes on to copy the
   files from the `HEAD` commit into the index.  That is, it
   does jobs #1 and #2, and then stops.

 * With `--hard`, `git reset` adjusts `HEAD`, copies the files
   from the adjusted `HEAD` to the index, and then copies the
   files from the index to the working tree.  That is, it does
   all three of jobs #1, #2, and #3.

And that's it: that's all you need to know.  Well, _almost_ all:
there are all kinds of finicky corner cases around files that are
in the working tree but _not_ in the index and/or commit.  There's
also one other problem, in a new, totally-empty repository in
which there are no commits yet.  But those edge cases need a lot
of explanation and should be left until later.

Chris

Re: What is the diff between a --soft and a blank reset

[A bughunter]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

My reply to Chris.

On Sunday, November 17th, 2024 at 02:57, Chris Torek <chris.torek@gmail.com> wrote:

> * With `--mixed`, `git reset` adjusts `HEAD` as before --
> it's usually wisest to not have it adjust anything for
> this case, in my opinion -- and then goes on to copy the
> files from the `HEAD` commit into the index. 

I didn't give any case: What are you talking about? It look's as though you are pasting a custom manpage for git-reset based on keyword matching. Essentially spamming the mailing list based on a keyword match. Yet another manpage being written by a thirdparty when having conflicting and scattered jargon makes it to where the user cannot communicate in a meaningful way about using the software. You vaguely show the difference (e.g. soft means job #1 and mixed means job #1 & #2) however not fully answering my pinpointed question "Does this from --soft: "leaves all your changed files "Changes to be committed", as  git status would put it.'" mean soft leaves the adds indexed but before the adds were commit and without commit whereas --mixed would erase the index having adds ready to commit?" conscerning what the difference means in pragma. We and you need to learn English or get off of mailing lists: stop spamming. I say we because you are not alone.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmc5r1gJkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu
8pkAAIesAQDkkFYk/snBkgshpusegy9iQB9bzbgPq0ErIwvIE0YYcAD+MGd5
Cb6hNTakaoa1GEM5/0kSLEqpuDWECaUefn8/ugU=
=K4lg
-----END PGP SIGNATURE-----

[-- Attachment #2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 653 bytes --]

[-- Attachment #3: publickey - A_bughunter@proton.me - 0x66540805.asc.sig --]
[-- Type: application/pgp-signature, Size: 119 bytes --]

Re: What is the diff between a --soft and a blank reset

[Kristoffer Haugsbakk]

On Sun, Nov 17, 2024, at 09:54, A bughunter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> My reply to Chris.
>
> On Sunday, November 17th, 2024 at 02:57, Chris Torek 
> <chris.torek@gmail.com> wrote:
>
>> * With `--mixed`, `git reset` adjusts `HEAD` as before --
>> it's usually wisest to not have it adjust anything for
>> this case, in my opinion -- and then goes on to copy the
>> files from the `HEAD` commit into the index. 
>
> I didn't give any case: What are you talking about? It look's as though 
> you are pasting a custom manpage for git-reset based on keyword 
> matching. Essentially spamming the mailing list based on a keyword 
> match. Yet another manpage being written by a thirdparty when having 
> conflicting and scattered jargon makes it to where the user cannot 
> communicate in a meaningful way about using the software. You vaguely 
> show the difference (e.g. soft means job #1 and mixed means job #1 & 
> #2) however not fully answering my pinpointed question "Does this from 
> --soft: "leaves all your changed files "Changes to be committed", as  
> git status would put it.'" mean soft leaves the adds indexed but before 
> the adds were commit and without commit whereas --mixed would erase the 
> index having adds ready to commit?" conscerning what the difference 
> means in pragma. We and you need to learn English or get off of mailing 
> lists: stop spamming. I say we because you are not alone.

Do you happen to use a translation program to write these emails? 

-- 
Kristoffer Haugsbakk

Re: What is the diff between a --soft and a blank reset

[Phillip Wood]

On 17/11/2024 08:54, A bughunter wrote:
> My reply to Chris.

Messages on this list are expected to be constructive and respectful to 
others. I strongly recommend that you read the code of conduct [1] and 
urge you to remember to be constructive and give others the benefit of 
the doubt when posting here in the future. If you are using an LLM or 
translation tool then I would suggest that you try a different one and 
get someone to check your message before sending it.

[1] https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md

> On Sunday, November 17th, 2024 at 02:57, Chris Torek <chris.torek@gmail.com> wrote:
> 
>> * With `--mixed`, `git reset` adjusts `HEAD` as before --
>> it's usually wisest to not have it adjust anything for
>> this case, in my opinion -- and then goes on to copy the
>> files from the `HEAD` commit into the index.
> 
> I didn't give any case: What are you talking about?

I think you have misunderstood what Chris was saying. My reading of this 
is that he is taking about the general case of a user running "git reset 
--mixed".

> It look's as though you are pasting a custom manpage for git-reset
 > based on keyword matching. Essentially spamming the mailing list
 > based on a keyword match.

Please remember that the person you are replying to is trying to help 
and has given up their time to do so. I think that rather than copy and 
pasting a manpage Chris has taken the time to write some bullet points 
to try and explain the different reset modes.

 > Yet another manpage being written by a thirdparty when having
 > conflicting and scattered jargon makes it to where the user cannot
 > communicate in a meaningful way about using the software.

Whether you like it or not understanding terms like "the index" and 
"HEAD" is necessary if you're going to be able to communicate clearly 
with others about git. I cannot see any non-standard terminology in 
Chris' reply.

 > You vaguely show the difference (e.g. soft means job #1 and mixed
 > means job #1 & #2) however not fully answering my pinpointed question
 > "Does this from --soft: "leaves all your changed files "Changes to be
 > committed", as git status would put it.'"

"git status" lists the files that differ between the worktree and the 
index as "Changes not staged for commit" and those that differ between 
the index and HEAD as "Changes to be committed". As "git reset --soft" 
changes HEAD but not the index then it may change the list of "Changes 
to be committed" because HEAD has changed, but the content of those 
files in the index is not changed. It will not change the list of 
"Changes not staged for commit" because the index is unchanged. As "git 
reset --mixed" changes both HEAD and the index then it may change both 
lists show by "git status".

 > mean soft leaves the adds indexed but
 > before the adds were commit and without commit whereas --mixed would
 > erase the index having adds ready to commit?" conscerning what the
 > difference means in pragma. We and you need to learn English or get>
 > off of mailing lists: stop spamming. I say we because you are not
 > alone.

Telling someone that they need to learn English or get off the mailing 
list is completely unacceptable.

Best Wishes

Phillip

Re: What is the diff between a --soft and a blank reset

[A bughunter]

[-- Attachment #1: Type: text/plain, Size: 7215 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

My reply to Phillip, Chris, and ML.

My pinpointed question "Does this from --soft: "leaves all your changed files "Changes to be committed", as  git status would put it.'" mean soft leaves the adds indexed but before the adds were commit and without commit whereas --mixed would erase the index having adds ready to commit?" conscerning what the difference means in pragma.

Phillip, I stated that my question is pinpointed. I will repaste the question above for the ML to focus on. I will admit that it is a complex sentence and complex problems may need to be described in complex ways.           I used the word ADD this is the word the software uses to add (or track) the file. When talking about git software the terms git has applied to the actions of it are authoritive. An ADD is not the change itself but the tracking. 
 The manpage terms the soft, mixed, and hard : modes. A mode of git-reset.
 Further the official Docs page uses this as a reference https://ndpsoftware.com/git-cheatsheet.html this visual should be accurate as it comes from the OFFICIAL source.





from A_bughunter@proton.me

Sent with Proton Mail secure email.

On Sunday, November 17th, 2024 at 15:21, Phillip Wood <phillip.wood123@gmail.com> wrote:

> On 17/11/2024 08:54, A bughunter wrote:
> 
> > My reply to Chris.
> 

Stopping spam is constructive. Usually with rule-books like that everybody else normatively violates higher points and then uses a lower point in the code to attack another or initiates a violation and then cites following defensive retorts (self-defence) to be violating while ignoring the agressive initiator. As such reading them is not worth my time:  only a tease of what would be nice if you guys followed the code of conduct. 
> Messages on this list are expected to be constructive and respectful to
> others. I strongly recommend that you read the code of conduct [1] and
> urge you to remember to be constructive and give others the benefit of
> the doubt when posting here in the future. If you are using an LLM or
> translation tool then I would suggest that you try a different one and
> get someone to check your message before sending it.
> 
> [1] https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
> 
> > On Sunday, November 17th, 2024 at 02:57, Chris Torek chris.torek@gmail.com wrote:
> > 
> > > * With `--mixed`, `git reset` adjusts `HEAD` as before --
> > > it's usually wisest to not have it adjust anything for
> > > this case, in my opinion -- and then goes on to copy the
> > > files from the `HEAD` commit into the index.
> > 
> > I didn't give any case: What are you talking about?
> 
> 
The docs call this mode. Ask yourself: Why would you call it something else? Doing so creates confusion. Also if everything you say is written with ambiguity sure anybody can apply their own meanings. A snippet from the manpage showing "modes" from man git-reset follows:

git reset [<mode>] [<commit>]
       This form resets the current branch head to <commit> and
       possibly updates the index (resetting it to the tree of
       <commit>) and the working tree depending on <mode>.
       Before the operation, ORIG_HEAD is set to the tip of the
       current branch. If <mode> is omitted, defaults to               --mixed. The <mode> must be one of the following:

> I think you have misunderstood what Chris was saying. My reading of this
> is that he is taking about the general case of a user running "git reset
> --mixed".
> 
> > It look's as though you are pasting a custom manpage for git-reset
> 
> > based on keyword matching. Essentially spamming the mailing list
> 
> > based on a keyword match.
> 

Spam is not help. Taking the time to rephrase entire manpages when given a pinpointed question is spam. Or rephrasing introductory tutorials of which I already have not answering the question. I obviously already have the manpages and it does not explain, it is not clear therefore rephrasing it with lax words does nothing to help but only add's confusion: having conflicting and scattered jargon makes it to where the user cannot communicate in a meaningful way about using the software.
> Please remember that the person you are replying to is trying to help
> and has given up their time to do so. I think that rather than copy and
> pasting a manpage Chris has taken the time to write some bullet points
> to try and explain the different reset modes.
> 
> > Yet another manpage being written by a thirdparty when having
> 
> > conflicting and scattered jargon makes it to where the user cannot
> 
> > communicate in a meaningful way about using the software.
> 

I agree the terms must be grasped. In order to do so you must write competent English. You would be able to take a visual yet have all of the information in correct English. To the good credit of Chris he appears to have made a small step towards describing this visual ( https://ndpsoftware.com/git-cheatsheet.html ) in English. However what Chris did good is not enough to answer my question. (Or break the curse of what Chris admit's to be poor instruction)
> Whether you like it or not understanding terms like "the index" and
> "HEAD" is necessary if you're going to be able to communicate clearly
> with others about git. I cannot see any non-standard terminology in
> Chris' reply.
> 
> > You vaguely show the difference (e.g. soft means job #1 and mixed
> 
> > means job #1 & #2) however not fully answering my pinpointed question
> 
> > "Does this from --soft: "leaves all your changed files "Changes to be
> 
> > committed", as git status would put it.'"
> 
> 
> "git status" lists the files that differ between the worktree and the
> index as "Changes not staged for commit" and those that differ between
> the index and HEAD as "Changes to be committed". As "git reset --soft"
> changes HEAD but not the index then it may change the list of "Changes
> to be committed" because HEAD has changed, but the content of those
> files in the index is not changed. It will not change the list of
> "Changes not staged for commit" because the index is unchanged. As "git
> reset --mixed" changes both HEAD and the index then it may change both
> lists show by "git status".
> 
> > mean soft leaves the adds indexed but
> 
> > before the adds were commit and without commit whereas --mixed would
> 
> > erase the index having adds ready to commit?" conscerning what the
> 
> > difference means in pragma. We and you need to learn English or get>
> 
> > off of mailing lists: stop spamming. I say we because you are not
> 
> > alone.
> 
> 

I disagree: speaking and writing English is a prerequisite for communicating on any ML.
> Telling someone that they need to learn English or get off the mailing
> list is completely unacceptable.
> 
> Best Wishes
> 
> Phillip
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmc6YPgJkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu
8pkAAJmIAP4wl4TnJFVLNlfOdBwd42oilKLueb9+AP4UaYxJl98pZwD8C6+2
GVtF9HFuKdJpn1/rOUPO5sQ93vdr6x6YJQcKswU=
=Mzyb
-----END PGP SIGNATURE-----

[-- Attachment #2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 653 bytes --]

[-- Attachment #3: publickey - A_bughunter@proton.me - 0x66540805.asc.sig --]
[-- Type: application/pgp-signature, Size: 119 bytes --]

Re: What is the diff between a --soft and a blank reset

[A bughunter]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hapse not... Kristoffer, Hapse not. 
> Do you happen to use a translation program to write these emails?
> 
> --
> Kristoffer Haugsbakk
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmc6bM0JkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu
8pkAAD0kAQCv7OoWzB10BoXhMGu/mnwI4uq6FUALZX5AHC1eazm/XgD+IO8T
sHHN0Og2R5fHrryn7g1tjyRgRU8BVXMlja2kwgU=
=00gR
-----END PGP SIGNATURE-----

[-- Attachment #2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 653 bytes --]

[-- Attachment #3: publickey - A_bughunter@proton.me - 0x66540805.asc.sig --]
[-- Type: application/pgp-signature, Size: 119 bytes --]

Re: What is the diff between a --soft and a blank reset

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> writes:

> Messages on this list are expected to be constructive and respectful
> to others. I strongly recommend that you read the code of conduct [1]
> and urge you to remember to be constructive and give others the
> benefit of the doubt when posting here in the future.
> ...
>
> [1] https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md
> ...
> Please remember that the person you are replying to is trying to help
> and has given up their time to do so. I think that rather than copy
> and pasting a manpage Chris has taken the time to write some bullet
> points to try and explain the different reset modes.
> ...
> Telling someone that they need to learn English or get off the mailing
> list is completely unacceptable.

Thanks, I have not much to add.

The code-of-conduct does make it acceptable to tell those who
deviate from acceptable behavior on the list to get off the list, by
the way.  I cannot yet say with 100% confidence if it is merely
misunderstanding due to language barrier, or somebody is trolling
others, deliberately, but perhaps we a few exchanges, we may know.

Re: What is the diff between a --soft and a blank reset

[A bughunter]

[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

BROAD OVERVIEW

bugreport[A], question[B] and use-case[C]. These are all related but separate threads for the purposes as labled. Please do not cross-post or cross-quote. Focus on productivity and solving these. You are welcomed to view and participate in all of these as I contribute more.

use-case[C] - git question (short) rephrase with use-case added.

ADD, ADD, ADD why cant they get that: ADD. ADD tracks files for commit. It's already been commit : push failed. Failed pushes piled up. I need them untracked. How do you undo an add ( many adds): simple question. Without deleting any files, to repush 1 by 1.

I suspect the answer is: "you can't - git provides no means to do so" - a defect, bug as we call it. The answer to this use-case question likely will confirm my bugreport and I get the feeling this is why they will not answer the question they do not want to accept my bugreport and have a bad spirit to argue. The excuses they give for this will be that it is not typical: This can normally be solved by repushing. However it is still a defect and in my use-case there is a slow or intermittent connection and no sha-backups yet because this is the initial creation of a repo. 

The above question is a use-case[C] seeking how to undo without deleting files. There shouldn't be any need to know a use-case in order to answer a technical question. I am open to discuss my use-case on this thread. The use-case if of this repo github.com/freedom-foundation/kjbible

My original bug report is that the user " may be cornered into delete files" bugreport[A] Summary as of 20241117 brian does not believe it's a bug and begins chattering to Peff about how to fix the bug "There are Git-level keepalives during the similar compression operation".

The full question[B] which is a child of the bugreport[A] is here. Summary as of 20241117 my question was mostly sidestepped and spammed whilst the thread devolved into a political drama about code_of_conduct. I am not open to discuss my use-case on this thread.


[A]: https://lore.kernel.org/git/20241115093214.GA1749331@coredump.intra.peff.net/#r

[B]: https://lore.kernel.org/git/xmqqr079xty7.fsf@gitster.g/T/#t

[C]: https://lore.kernel.org/all/4hiTc8Kx5yNhYuN8abv3QFJBuptM6VWZ9OKvkdZFlSI5y0zoK-lN_VHf-QCSEjllmSWvu9V-tbrvFOx17_P0Nq8UKxEcK3Rs2d02FjbYuUc=@proton.me/#r
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmc7uS4JkKkWZTlQrvKZFiEEZlQIBcAycZ2lO9z2qRZlOVCu
8pkAAKUDAQDf3cixv7dXR8M2wfPRVZBTenFZFOweS6hWNnv4RkLrQAEA1QZI
vpNUKP7SN+J1de9kuQ4zHHjDuksnTflDPeOQpQE=
=Yn2L
-----END PGP SIGNATURE-----

[-- Attachment #2: publickey - A_bughunter@proton.me - 0x66540805.asc --]
[-- Type: application/pgp-keys, Size: 653 bytes --]

[-- Attachment #3: publickey - A_bughunter@proton.me - 0x66540805.asc.sig --]
[-- Type: application/pgp-signature, Size: 119 bytes --]