![]() > numerous callers from rebase/sequencer to reset_head() > stash (though currently dead code reset always had a value of 0) > continue using reset_nuke_untracked, but so that other callers, ![]() > alternative available in the form of 'switch -discard-changes' > maybe it is OK for 'checkout -f' to nuke everything if there is a safe > same way but it appears from that other message that they do not so > thought that 'checkout -f' and 'switch -discard-changes' behaved the > I've no recollection of writing that email! When I was writing today I > - any reason for your change of opinion? > command that should remove untracked files in the way. > Junio weighed in and explicitly called out checkout -force as being a > I originally started down that path to see what it looked like, but > switching branches, I'd prefer it if it did not remove untracked files. > I often use checkout -force to clear unwanted changes when I'm > that ignored files will continue to be removed by these commands. > the commit message, though, is probably a good idea. > Your suggestion to point out the behavior relative to ignored files in > files, only for non-ignored untracked files. So, there's no change in behavior for ignored > commands so that they stop overwriting untracked files, unless those u, despite the fact that you explicitly called out (and I even quoted > refused to overwrite untracked and ignored files currently.ĭoh, I was thinking of read-tree -reset -u rather than read-tree -m > Are you sure, I thought 'read-tree -m -u' unlike 'read-tree -reset -u' > Those commands made no distinction between untracked and ignored files > but it would be good to spell out the change in the commit message. > so that they will overwrite ignored files - I'm in favor of that change > patch changes the behavior of 'git read-tree -m -u' (and other commands) ![]() > remove untracked files or not - that could always be added later. > it would be nice if read-tree callers could choose whether they want to > there didn't seem to be much interest from others. > but then moved on quite soon after I posted that series I think and > confident about modifying the unpack_trees() code. > Mainly lack of time/distracted by other things. Any reason you didn't pursue that old series further? > See for an alternative approach that used an enum instead of adding > which is simply an or-ing of the other two. > of these flags, introduce a third one for convenience: > and, since many code paths in unpack_trees need to be followed for both However, many of the other uses should not be deleting untracked > `git read-tree -reset`, but then started appearing in other places as > was okay to delete any untracked files in the way. > Traditionally, unpack_trees_options->reset was used to signal that it > On 00:15, Elijah Newren via GitGitGadget wrote: Subject: Re: Split unpack_trees 'reset' flag into two for untracked handlingĭate: Thu, 19:27:35 -0700 Re: Split unpack_trees 'reset' flag into two for untracked handling - Elijah Newren archive mirror help / color / mirror / Atom feed From: Elijah Newren
0 Comments
Leave a Reply. |