undefined | Better HN

0 pointsy75y ago0 comments

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.

0 comments

11 comments · 3 top-level

skeppy5y ago· 6 in thread

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.

icebraining5y 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/

still_grokking5y ago

Sine decades I wish this would be a std. OS or FS feature!

boring_twenties5y 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).

vtbassmatt5y ago

VMS did it: https://wiki.vmssoftware.com/File_version

1 more reply

chipotle_coyote5y 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.)

sangnoir5y 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

nyanpasu645y ago· 2 in thread

> 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.

mikeyjk5y 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.

smichel175y 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.

dreamcompiler5y 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.

j / k navigate · click thread line to collapse