6 ms·

I use git a lot, and I like the speed and decentralized nature. But I do think there's much to be improved. Named branches don't really exist in git: there's o

by y7 6y ago

I use git a lot, and I like the speed and decentralized nature. But I do think there's much to be improved. Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information. Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps). Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.

skeppy 6y ago
What about a “git init-lite” option? So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work. With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.
- sangnoir 6y ago
  The good news is that git is extensible enough to support this use-case. You would need to wrap git with a tool/script that watches for file changes
- still_grokking 6y ago
  Sine decades I wish this would be a std. OS or FS feature!
  - vtbassmatt 6y ago
    VMS did it: https://wiki.vmssoftware.com/File_version https://wiki.vmssoftware.com/File_version
    - dreamcompiler 6y ago
      Indeed. I still miss VMS because of its automatic versioning, with version numbers being an explicit field of the pathname.
  - chipotle_coyote 6y ago
    It's something that exists in macOS, but as far as I know applications have to explicitly choose to use it. Most applications that support it have a "File > Revert To > Browse All Versions..." command available. BBEdit -- as often the case -- has a more useful variant of it, which brings up a diff window with "Search > Find Differences > Compare Against Previous Version". (It actually lets you choose any recorded previous version.)
  - boring_twenties 6y ago
    Back in the stone age I worked at a place that used a VCS called ClearCase. It supported exactly this, you'd be able to append things like @revision or @branchname or @timestamp to file and directory names to access them. Unfortunately, it required (IIRC) three full time people to administer the server. As for the client (my workstation), it required a proprietary kernel module which would panic about once a week. I'm told our license cost $1m/year (2001 dollars).
- icebraining 6y ago
  This exists: it's the git-annex assistant! You just have to configure the "annex.largefiles", because by default git-annex doesn't actually commit the content of the files, since it's designed to handle large binary files. But if you set that option and run the Assistant, it'll auto-commit files when they change, and can even auto-sync them with other computers, cloud storage, Android devices, etc. https://git-annex.branchable.com/assistant/ https://git-annex.branchable.com/assistant/
nyanpasu64 6y ago
> But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. I thought that merge commits stored an ordered list of parents, and the first parent is generally the main branch, and second parent is a side branch.
- mikeyjk 6y ago
  It does! I'm not sure what that person is referring to. git log can even use ASCII art to depict the relationship. Most modern git web frontends depict the relationship. Sourcetree, gitkraken depict the parent relationships. I wonder if we're misinterpreting? But the parents are distinct from one another, the hierarchy is not lost on merge. Part of the reason I prefer merge commits rather than rebasing.
  - smichel17 6y ago
    Note: they don't have to be exclusive. You can rebase a branch so the history is linear, then merge --no-ff and create a merge commit for it. This gets you something like the best and worst of both worlds.
dreamcompiler 6y ago
> This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information. Completely agree. I think rebasing is misguided. The objective is to keep history clean and linear. The proper way to solve that problem is with smart log analysis for different customers, not fictionally rewriting the log itself.

by y7 6y ago

skeppy 6y ago

What about a “git init-lite” option? So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work. With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.

sangnoir 6y ago
The good news is that git is extensible enough to support this use-case. You would need to wrap git with a tool/script that watches for file changes
still_grokking 6y ago
Sine decades I wish this would be a std. OS or FS feature!
- vtbassmatt 6y ago
  VMS did it: https://wiki.vmssoftware.com/File_version https://wiki.vmssoftware.com/File_version
  - dreamcompiler 6y ago
    Indeed. I still miss VMS because of its automatic versioning, with version numbers being an explicit field of the pathname.
- chipotle_coyote 6y ago
  It's something that exists in macOS, but as far as I know applications have to explicitly choose to use it. Most applications that support it have a "File > Revert To > Browse All Versions..." command available. BBEdit -- as often the case -- has a more useful variant of it, which brings up a diff window with "Search > Find Differences > Compare Against Previous Version". (It actually lets you choose any recorded previous version.)
- boring_twenties 6y ago
  Back in the stone age I worked at a place that used a VCS called ClearCase. It supported exactly this, you'd be able to append things like @revision or @branchname or @timestamp to file and directory names to access them. Unfortunately, it required (IIRC) three full time people to administer the server. As for the client (my workstation), it required a proprietary kernel module which would panic about once a week. I'm told our license cost $1m/year (2001 dollars).
icebraining 6y ago
This exists: it's the git-annex assistant! You just have to configure the "annex.largefiles", because by default git-annex doesn't actually commit the content of the files, since it's designed to handle large binary files. But if you set that option and run the Assistant, it'll auto-commit files when they change, and can even auto-sync them with other computers, cloud storage, Android devices, etc. https://git-annex.branchable.com/assistant/ https://git-annex.branchable.com/assistant/

nyanpasu64 6y ago

> But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. I thought that merge commits stored an ordered list of parents, and the first parent is generally the main branch, and second parent is a side branch.

mikeyjk 6y ago
It does! I'm not sure what that person is referring to. git log can even use ASCII art to depict the relationship. Most modern git web frontends depict the relationship. Sourcetree, gitkraken depict the parent relationships. I wonder if we're misinterpreting? But the parents are distinct from one another, the hierarchy is not lost on merge. Part of the reason I prefer merge commits rather than rebasing.
- smichel17 6y ago
  Note: they don't have to be exclusive. You can rebase a branch so the history is linear, then merge --no-ff and create a merge commit for it. This gets you something like the best and worst of both worlds.

dreamcompiler 6y ago

> This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information. Completely agree. I think rebasing is misguided. The objective is to keep history clean and linear. The proper way to solve that problem is with smart log analysis for different customers, not fictionally rewriting the log itself.