4 ms·

I don't get how git (or any proper multi-file dvcs) falls behind facilitating the purpose ESR is shooting at. You can use "git log <file>" to track changes of <

I don't get how git (or any proper multi-file dvcs) falls behind facilitating the purpose ESR is shooting at. You can use "git log <file>" to track changes of <file>. It's like Gmail drafts. While it's delivered to you as an email stashing feature, I realized that it's the best cloud-based (offline-synced, omnipresent) note application. It can do that even if "note" is not in its name. We can be creative about using the tools at our disposal. Besides (back to the original problem), it can be handy sometimes that you have a tool that can operate over the whole range of managed files, even if they are logically unrelated.

crazygringo 12y ago
I don't know about this tool, but git does not make it easy to move files from one repository to another, for instance, and maintain that file's history. Heck, I'd like to be able to e-mail a single file to someone, and have the file keep its revision history. File-based revision histories, as opposed to repository-based, have a whole host of advantages that come from flexibility.
- dzsekijo 12y ago
  git also has good support for explicit cutting down the repo to a subset of its files, or merging back changes of a partial repo to the common one, see filter-branch and subtree commands.
jxf 12y ago
Here's a very obvious use-case: You have a single file with many historical changes. That file moves to a new directory that is not a subdirectory of its current directory. In git, the file vanishes from the repo and can't be tracked easily anymore. You lose all of its past history if you put it into a new repo. In SRC the history moves with the file.
- aidenn0 12y ago
  the .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.
  - jxf 12y ago
    I'm not saying that any of the stuff suggested can't be done with git. The point is that this is not the use case git was designed for, so it doesn't accommodate it easily -- you must write all the exceptions and special cases into your repository, which is cumbersome.
jordigh 12y ago
What if you'd like to track files at your filesystem root? /.git would be a tad complicated, since you'd need fairly complicated .gitignore rules, right? You wouldn't want "git status" or "git diff" to read your entire filesystem, including all mounted devices.
- dzsekijo 12y ago
  "git status" recurses only into those dirs where there is managed content. "git diff" restricts its operation to managed files. That said, if you are into managing particular files and not a file tree, most likely you'd consider all info about other files than the chosen ones to be noise, which can be expressed in .gitignore in a very succinct way: '*'.

crazygringo 12y ago

I don't know about this tool, but git does not make it easy to move files from one repository to another, for instance, and maintain that file's history. Heck, I'd like to be able to e-mail a single file to someone, and have the file keep its revision history. File-based revision histories, as opposed to repository-based, have a whole host of advantages that come from flexibility.

dzsekijo 12y ago
git also has good support for explicit cutting down the repo to a subset of its files, or merging back changes of a partial repo to the common one, see filter-branch and subtree commands.

jxf 12y ago

Here's a very obvious use-case: You have a single file with many historical changes. That file moves to a new directory that is not a subdirectory of its current directory. In git, the file vanishes from the repo and can't be tracked easily anymore. You lose all of its past history if you put it into a new repo. In SRC the history moves with the file.

aidenn0 12y ago
the .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.
- jxf 12y ago
  I'm not saying that any of the stuff suggested can't be done with git. The point is that this is not the use case git was designed for, so it doesn't accommodate it easily -- you must write all the exceptions and special cases into your repository, which is cumbersome.

jordigh 12y ago

What if you'd like to track files at your filesystem root? /.git would be a tad complicated, since you'd need fairly complicated .gitignore rules, right? You wouldn't want "git status" or "git diff" to read your entire filesystem, including all mounted devices.

dzsekijo 12y ago
"git status" recurses only into those dirs where there is managed content. "git diff" restricts its operation to managed files. That said, if you are into managing particular files and not a file tree, most likely you'd consider all info about other files than the chosen ones to be noise, which can be expressed in .gitignore in a very succinct way: '*'.