10 ms·

I am not entirely sure I understand why one wouldn't use git for this role. If you don't need a remote git repository, you don't need to use one, and git will b

I am not entirely sure I understand why one wouldn't use git for this role. If you don't need a remote git repository, you don't need to use one, and git will be available everywhere. Certainly many production machines will tend to have it for deployment of applications across multiple machines. What are some use cases that don't work with git (which is probably already available on the system)? And why wouldn't git be an effective tool for that particular role? I'm certainly not as experienced as ESR (though, I'm coming up on 20 years of administering Linux and UNIX servers), and perhaps I'm missing some subtle nuance here. I'm not wanting to come off as "screw this, this is stupid". I'm just genuinely not understanding why I should learn a new tool (or re-learn an old tool that's be "reloaded") when git does all of this and more...and I already know it and have it installed broadly across my systems.

hapless 12y ago
You are almost certainly more experienced than ESR. He held his last technology position in the early 1990s.
- mwfogleman 12y ago
  Then again, ESR has assumed a role in the free software community as a VCS expert, as evidenced by his reposurgeon project and uses.
  - GFK_of_xmaspast 12y ago
    Providing an excellent example of what your schoolteacher said about "assuming".
  - jordigh 12y ago
    And his recent months of work on migrating Emacs from bzr to git.
    - deng 12y ago
      During which it became abundantly clear that he is surely no git expert (which does not diminish the work he did).
jgrahamc 12y ago
There's a FAQ on this: http://esr.ibiblio.org/?p=6518 http://esr.ibiblio.org/?p=6518 "Why SRC instead of $VCS? Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."
- SwellJoe 12y ago
  OK, but I don't see how git having those capabilities makes it inappropriate for cases where you don't need them. I guess I can appreciate the single-file revision control thing, since that is something git doesn't do well. But, I am usually OK with a whole directory being under revision control. All the other stuff is irrelevant, I'm pretty sure. Don't want branches and tags (I guess that's what "multi-fork" is referring to)? Don't use'em. Don't want multi-user? Doesn't matter, git doesn't lock files, and the user never needs to think about users if they are the only contributor to the repository.
vertex-four 12y ago
The point is managing single files, not directories. Want to version control your ~/.bashrc, for example? Or a single document? You can do that without having to move the file into its own directory in some hackish way.
- shabble 12y ago
  GNU Stow[1] referencing a git repo in ~/.dotfiles is what I use for that. You might consider it hackish, but at least there are plenty of tools out there for managing it :) [1] https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
- Karunamon 12y ago
  How is this different from just `init`ing the repo in your home directory and only adding files you care about?
  - desdiv 12y ago
    What happens if you accidentally git clean -dfx?
    - Karunamon 12y ago
      Roughly the same thing that happens if you run rm -rf ~. Any tool that manipulates files can be coaxed into shooting you in the foot. Any usage of -f on a git command means you're probably doing something that you shouldn't be unless you absolutely know better.
- mitchty 12y ago
  You can always just set GIT_REPO_DIR to a bare/remote git repo and not have to move crap around if you don't want to. git is a bit more flexible than how its normally used.
kazinator 12y ago
I am not entirely sure I understand why one wouldn't use git for this role. Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git. For many users, using Git means cutting and pasting command line recipes scoured from desperate web searches, and crossing their fingers. This does not go away when you use Git just for personal use with a repo that has no upstream. ESR probably wants something that is simple to use for simple use cases.
- debacle 12y ago
  > computer science degree and years of experience to even begin to understand Git, for one thing. Unless you're programming, in which case you should be able to understand git well enough, there are plenty of tools which completely abstract away the CLI interface (GitHub's is great).
- click170 12y ago
  > Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth is perpetuated by a small group of people who are very vocal about "git is hard". If git commit and git checkout are too complicated, I don't know what else to say except that every VCS has those concepts, perhaps you're just used to those systems instead.
  - k-mcgrady 12y ago
    I think git hard a small but steep learning curve. Lots of developers aren't used to using the command line anymore so git can seem 'scary'. Personally I gave up on git a couple of times before finally learning it but as a developer working by myself I also couldn't understand the need for version control (at the time) so giving up wasn't a big deal. I think once you give it a couple of hours of your time you can understand enough to use it in most situations. Plus the GUI tools (SourceTree for example) are quite good.

hapless 12y ago

You are almost certainly more experienced than ESR. He held his last technology position in the early 1990s.

mwfogleman 12y ago
Then again, ESR has assumed a role in the free software community as a VCS expert, as evidenced by his reposurgeon project and uses.
- GFK_of_xmaspast 12y ago
  Providing an excellent example of what your schoolteacher said about "assuming".
- jordigh 12y ago
  And his recent months of work on migrating Emacs from bzr to git.
  - deng 12y ago
    During which it became abundantly clear that he is surely no git expert (which does not diminish the work he did).

jgrahamc 12y ago

There's a FAQ on this: http://esr.ibiblio.org/?p=6518 http://esr.ibiblio.org/?p=6518 "Why SRC instead of $VCS? Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."

SwellJoe 12y ago
OK, but I don't see how git having those capabilities makes it inappropriate for cases where you don't need them. I guess I can appreciate the single-file revision control thing, since that is something git doesn't do well. But, I am usually OK with a whole directory being under revision control. All the other stuff is irrelevant, I'm pretty sure. Don't want branches and tags (I guess that's what "multi-fork" is referring to)? Don't use'em. Don't want multi-user? Doesn't matter, git doesn't lock files, and the user never needs to think about users if they are the only contributor to the repository.

vertex-four 12y ago

The point is managing single files, not directories. Want to version control your ~/.bashrc, for example? Or a single document? You can do that without having to move the file into its own directory in some hackish way.

shabble 12y ago
GNU Stow[1] referencing a git repo in ~/.dotfiles is what I use for that. You might consider it hackish, but at least there are plenty of tools out there for managing it :) [1] https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/
Karunamon 12y ago
How is this different from just `init`ing the repo in your home directory and only adding files you care about?
- desdiv 12y ago
  What happens if you accidentally git clean -dfx?
  - Karunamon 12y ago
    Roughly the same thing that happens if you run rm -rf ~. Any tool that manipulates files can be coaxed into shooting you in the foot. Any usage of -f on a git command means you're probably doing something that you shouldn't be unless you absolutely know better.
mitchty 12y ago
You can always just set GIT_REPO_DIR to a bare/remote git repo and not have to move crap around if you don't want to. git is a bit more flexible than how its normally used.

kazinator 12y ago

I am not entirely sure I understand why one wouldn't use git for this role. Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git. For many users, using Git means cutting and pasting command line recipes scoured from desperate web searches, and crossing their fingers. This does not go away when you use Git just for personal use with a repo that has no upstream. ESR probably wants something that is simple to use for simple use cases.

debacle 12y ago
> computer science degree and years of experience to even begin to understand Git, for one thing. Unless you're programming, in which case you should be able to understand git well enough, there are plenty of tools which completely abstract away the CLI interface (GitHub's is great).
click170 12y ago
> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth is perpetuated by a small group of people who are very vocal about "git is hard". If git commit and git checkout are too complicated, I don't know what else to say except that every VCS has those concepts, perhaps you're just used to those systems instead.
- k-mcgrady 12y ago
  I think git hard a small but steep learning curve. Lots of developers aren't used to using the command line anymore so git can seem 'scary'. Personally I gave up on git a couple of times before finally learning it but as a developer working by myself I also couldn't understand the need for version control (at the time) so giving up wasn't a big deal. I think once you give it a couple of hours of your time you can understand enough to use it in most situations. Plus the GUI tools (SourceTree for example) are quite good.