0

I have a project structure thus:

\projects\
    .git\
    .gitignore
    folder1\
        \ignoredfolder
        \pushedfolder

From within \projects\ I have successfully pushed \projects\folder1\pushedfolder\ to the online repository. Then, I have deleted \projects\folder1\pushedfolder\ on my local machine. I would now like to recreate locally this folder and its contents from the online repository where it was previously pushed into.

Within Git Gui, on navigating to Branch -> Checkout, the following option is obtained

enter image description here

On clicking checkout, I notice that the just pushed files that were part of the locally deleted folder come back into the "Unstaged Changes" window of Git Gui. But beyond this, how can I actually get these files into the just deleted local folder?

Tryer
  • 3,580
  • 1
  • 26
  • 49
  • From what I understand you should look for the `git reset` corresponding feature in Git GUI – Gaël J Jul 31 '21 at 16:57
  • @GaëlJ What seems to work for me is, the checked out files are in the "unstaged changes" window of GitGui. Then, selecting these files and Reverting Changes went ahead and recreated these files by first recreating the directory and the files within them on the local machine. – Tryer Jul 31 '21 at 17:18
  • 1
    Some minor notes (I can't answer your question as I don't *use* `git-gui`): the `git-gui` tcl/tk script that comes with Git doesn't seem to be considered very good, even by those who like GUIs for Git. Meanwhile: never think of Git as pushing "files" or "folders", because it doesn't. What Git pushes—and saves—are *commits*. Each commit acts as a full snapshot of *every* file. Deleting a bunch of files and making a new commit means that you've made a snapshot that specifically lacks the deleted files (as compared to the previous snapshot, which has those files). – torek Aug 01 '21 at 03:44
  • 1
    Hence, to get files back from some *previous* commit, you must ... well, get at the previous commit. The documentation for `git-gui` says that it focuses "on commit generation and single file annotation and does not show project history" but a previous commit is part of project history. This seems to imply that git-gui is terrible at doing what you'd like to do. – torek Aug 01 '21 at 03:45
  • @torek Indeed, I am kind of struggling with Git Gui. Could you indicate via the command line how the question in the OP could be addressed? If it is too involved, I would be grateful for an outside link as well. The tutorials I have read online seem to not get to this issue or if they do, they tend to describe it in very complicated fashion atleast that's how it appears to my novice mind. – Tryer Aug 01 '21 at 06:03
  • 1
    From the command line, I'd recommend using the new (since Git 2.23) `git restore`. This is the "unsafe half" of `git checkout`. Let's say that you removed some file two commits ago, and have decided that it was a good file after all and you'd like it back now. The command-line command that will get it back is `git restore --source=HEAD~2 --staged --worktree -- `: this plucks the file out of the commit named by `HEAD~2` (you can use a raw hash ID instead if you like) and makes it both staged-for-commit and visible in your working tree. – torek Aug 01 '21 at 09:29
  • 1
    This `git restore` command is equivalent to `git checkout HEAD~2 -- ` (the `checkout` is clearly shorter, but is confusing because `git checkout` is *also* used to switch from one commit/branch to another commit/branch). In Git 2.23, `git checkout`'s two modes, "switch" and "extract file", were split into separate commands: `git switch` and `git restore`. – torek Aug 01 '21 at 09:31
  • 1
    Note that "switch to another commit/branch" invokes `git checkout`'s "safe" mode -- it checks to make sure that this won't lose unsaved work -- while "extract specific file" invokes `git checkout`'s unsafe mode: it will cheerfully overwrite unsaved work. Using two separate commands helps keep the safe and unsafe modes from getting mixed up. – torek Aug 01 '21 at 09:32

0 Answers0