3 ms·

Not an option if the rest of code base is likely different from the original cloned from. For me, this very often has been the case i.e. small changes in like m

Not an option if the rest of code base is likely different from the original cloned from. For me, this very often has been the case i.e. small changes in like may be 20 files scattered all over the code base just to get my copy run in a specific way debugging an issue.

jakub_g 13y ago
What's wrong about `git revert <commit-sha>`? It should be just fine, supposing no one changed the mentioned files in the meantime.
- fayyazkl 13y ago
  Oh, i meant the other 20 files all around the code base have just been changed to get my local setup to work. There is no way (without sub branching) in git to have a lot of modified files, but only wanting to revert the ones actually being worked upon. Core concept was still shallow check out in case of svn
  - jakub_g 13y ago
    Still not sure what's the case exactly. You mean, kind of partially revert a commit, but only the files in the commit which are in a specific subfolder?
    - fayyazkl 13y ago
      Yeah Exactly. Probably i should have worded more appropriately. But given the fact that most of software developers have to maintain large existing code bases, tailor a specific subsection to achieve a goal and only need to commit just a folder in that sub section
  - X-Istence 13y ago
    git checkout -- <file> This will revert the file back to the the last checked out version. git checkout <sha-1> -- <file> Will revert a file to the state it was in, in that particular sha-1.
    - fayyazkl 13y ago
      Yeah this will definitely do that. Only that mentioning name per file is painful. In large source trees, you often exactly don't know which files have been modified. You just have been following through a debug path making changes where needed. Just having the ability to checkout a folder down the hierarchy is really handy. Git recently added "sparse checkouts" but still they only solve the problem partially

jakub_g 13y ago

What's wrong about `git revert <commit-sha>`? It should be just fine, supposing no one changed the mentioned files in the meantime.

fayyazkl 13y ago
Oh, i meant the other 20 files all around the code base have just been changed to get my local setup to work. There is no way (without sub branching) in git to have a lot of modified files, but only wanting to revert the ones actually being worked upon. Core concept was still shallow check out in case of svn
- jakub_g 13y ago
  Still not sure what's the case exactly. You mean, kind of partially revert a commit, but only the files in the commit which are in a specific subfolder?
  - fayyazkl 13y ago
    Yeah Exactly. Probably i should have worded more appropriately. But given the fact that most of software developers have to maintain large existing code bases, tailor a specific subsection to achieve a goal and only need to commit just a folder in that sub section
- X-Istence 13y ago
  git checkout -- <file> This will revert the file back to the the last checked out version. git checkout <sha-1> -- <file> Will revert a file to the state it was in, in that particular sha-1.
  - fayyazkl 13y ago
    Yeah this will definitely do that. Only that mentioning name per file is painful. In large source trees, you often exactly don't know which files have been modified. You just have been following through a debug path making changes where needed. Just having the ability to checkout a folder down the hierarchy is really handy. Git recently added "sparse checkouts" but still they only solve the problem partially