Chosen name "src" is quite unfortunate, as it will be a src of confusion.
Agreed, such a horrible name choice.
Simple Revision Control
131–140 of 179 posts
Re: Simple Revision Control
#132See also https://github.com/rupa/rvn (not to be taken seriously). (By the author of z, possibly the most time-saving unix tool ever created).
Re: Simple Revision Control
#133I 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 " to track changes of . 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…
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.
the .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.
Re: Simple Revision Control
#134Earlier quoted context omitted.
"a nice enough guy" Nope: http://esr.ibiblio.org/?p=26
See also his attempts to take credit for other people's work on ncurses: http://invisible-island.net/ncurses/ncurses-license.html . I don't think I would want to work with him on a project.
The part of that thread that I found interesting were RMS's replies. He seems very measured.
Re: Simple Revision Control
#135I 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…
There's a FAQ on this: 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.…
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.
Re: Simple Revision Control
#136I 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…
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…
So, "when I need something easier to use" would be your primary use case for this? Which would mean that for someone that knows git reasonably well already, they would have no use case for this software? After all, learning a wholly new tool is harder than using a tool you already know.
Re: Simple Revision Control
#137Sounds like someone misses DEC VMS's method of revision
I sort of do.
Re: Simple Revision Control
#138Earlier quoted context omitted.
It's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. Here's the thing that's funny to me: git is easy . Everyone (especially mercurial users) goes on about how horrible the UI is, but when I think of git, I think of how similar it is to RCS: easy, quick, and simple. With both, I can diff things and check in changes very quickly. I have a bunch of single files in…
I love git. I'm a git power user. I've used git as the datastore for a CRM I built. But I respectfully disagree. Git is not "easy." You've been conditioned. You and I know that it's very very hard to lose work or lose commits with Git. I'd say it's nearly impossible to do on accident. But in my first month with Git I rewrote several things because I messed up somehow and couldn't figure it out. I would hose my checko…
It's easy to mess up a somewhat complex repo in git, but for versioning really simple things like rsync scripts or dot-files, where you have one committer, one branch, and a linear commit log, git's pretty easy. git init, git commit -am, gitk to view history or diff, done.
Re: Simple Revision Control
#139Earlier quoted context omitted.
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…
I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.
> git add -u
This is a wasteful step; you can commit all your changes with "git commit -a" which adds the modified files to the index, and commits, in one step.
The index is a completely pointless idea in git that has no purpose; the next major version of git should factor it out. Git would really improve if it lost the index thing.
You're already using distributed version control where you can have a whole swath of commits which are not published to your upstream. That is all the staging area you need; you don't need a staging area before your staging area. There are just too many levels: working copy to index. Index to commit. Commit to upstream repo.
Git tries to hide the index from users, but that backfires when awareness of its semantics crops up in corner cases. For instance, quite stupidly, if you try to revert a file from a prior commit with "git reset ", it does it in the index rather than where you expect, namely the working copy (that being left untouched). This is a purposeless complication. Now you have a "git diff" which looks like the change is being added rather than subtracted (because that's actually the delta from the index to the unmodified working copy), and a "git diff --cached" which is exactly its opposite (because it's a delta from HEAD to the index).
There has to be a concept of modified state which extends to "this new file is scheduled for addition" or "this file is scheduled for deletion". That's all the "index" you need. Other than that, there should only be the working tree, and whatever is in HEAD.
Git has the tools that let you make multiple commits and squash them together into one, so the index is completely redundant from that point of view. Instead of
hack file
git add file
hack file
git add file # squash into previous index entry
hack file
git commit file # pretend the index doesn't even exist
hack file
git commit file
This is actually cleaner because you're not doing "squash as you go" into the staging area, but making actual commits where the changes are tracked and separated. Maybe you will end up not wanting to squash them into a single change!
I.e. since commits can be amended, cherry picked and squashed to your heart's content, there is no need for the software to support workflow involving a staging area where you prepare the perfect commit. It is superfluous.
The index smells like a left over from some early prototyped version of the software, before the full concept was hammered out, which was then difficult to remove (or it never occurred to anyone).
Re: Simple Revision Control
#140Earlier quoted context omitted.
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…
Git is one of those things where it pays off immensely to understand the underlying object model. Learn about commit objects, tree objects, and file blobs. Then learn about the staging area. There are some things layered on top of or next to this (such as stashing, pull and push), but understanding this small core is sufficient for everything else. I've worked on large problems and juggled many branches, and I've nev…
Once I read that git's core model is a DAC abs everything is just a label to nodes on the graph, I haven't had any issues using git. Before that, it was a bit of a mystery.