* What is the diff between a --soft and a blank reset
@ 2024-11-17 2:07 A bughunter
2024-11-17 2:57 ` Chris Torek
0 siblings, 1 reply; 9+ messages in thread
From: A bughunter @ 2024-11-17 2:07 UTC (permalink / raw)
To: git@vger•kernel.org
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: What is the diff between a --soft and a blank reset 2024-11-17 2:07 What is the diff between a --soft and a blank reset A bughunter @ 2024-11-17 2:57 ` Chris Torek 2024-11-17 8:54 ` A bughunter 0 siblings, 1 reply; 9+ messages in thread From: Chris Torek @ 2024-11-17 2:57 UTC (permalink / raw) To: A bughunter; +Cc: git@vger•kernel.org 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 2:57 ` Chris Torek @ 2024-11-17 8:54 ` A bughunter 2024-11-17 12:59 ` Kristoffer Haugsbakk 2024-11-17 15:21 ` Phillip Wood 0 siblings, 2 replies; 9+ messages in thread From: A bughunter @ 2024-11-17 8:54 UTC (permalink / raw) To: Chris Torek; +Cc: git@vger•kernel.org [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 8:54 ` A bughunter @ 2024-11-17 12:59 ` Kristoffer Haugsbakk 2024-11-17 22:23 ` A bughunter 2024-11-17 15:21 ` Phillip Wood 1 sibling, 1 reply; 9+ messages in thread From: Kristoffer Haugsbakk @ 2024-11-17 12:59 UTC (permalink / raw) To: A bughunter, Chris Torek; +Cc: git@vger•kernel.org 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 12:59 ` Kristoffer Haugsbakk @ 2024-11-17 22:23 ` A bughunter 0 siblings, 0 replies; 9+ messages in thread From: A bughunter @ 2024-11-17 22:23 UTC (permalink / raw) To: Kristoffer Haugsbakk; +Cc: git@vger•kernel.org [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 8:54 ` A bughunter 2024-11-17 12:59 ` Kristoffer Haugsbakk @ 2024-11-17 15:21 ` Phillip Wood 2024-11-17 21:32 ` A bughunter 2024-11-18 0:32 ` Junio C Hamano 1 sibling, 2 replies; 9+ messages in thread From: Phillip Wood @ 2024-11-17 15:21 UTC (permalink / raw) To: A bughunter, Chris Torek; +Cc: git@vger•kernel.org 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 15:21 ` Phillip Wood @ 2024-11-17 21:32 ` A bughunter 2024-11-18 0:32 ` Junio C Hamano 1 sibling, 0 replies; 9+ messages in thread From: A bughunter @ 2024-11-17 21:32 UTC (permalink / raw) To: phillip.wood; +Cc: git@vger•kernel.org, Chris Torek [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-17 15:21 ` Phillip Wood 2024-11-17 21:32 ` A bughunter @ 2024-11-18 0:32 ` Junio C Hamano 2024-11-18 22:01 ` A bughunter 1 sibling, 1 reply; 9+ messages in thread From: Junio C Hamano @ 2024-11-18 0:32 UTC (permalink / raw) To: Phillip Wood; +Cc: A bughunter, Chris Torek, git@vger•kernel.org 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: What is the diff between a --soft and a blank reset 2024-11-18 0:32 ` Junio C Hamano @ 2024-11-18 22:01 ` A bughunter 0 siblings, 0 replies; 9+ messages in thread From: A bughunter @ 2024-11-18 22:01 UTC (permalink / raw) To: Junio C Hamano; +Cc: git@vger•kernel.org [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2024-11-18 22:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-17 2:07 What is the diff between a --soft and a blank reset A bughunter 2024-11-17 2:57 ` Chris Torek 2024-11-17 8:54 ` A bughunter 2024-11-17 12:59 ` Kristoffer Haugsbakk 2024-11-17 22:23 ` A bughunter 2024-11-17 15:21 ` Phillip Wood 2024-11-17 21:32 ` A bughunter 2024-11-18 0:32 ` Junio C Hamano 2024-11-18 22:01 ` A bughunter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox