Gitless: a version control system

Post by dhimes » Sun, Oct 02, 2016, 4:18 PM UTC

rplst8 wrote: post #101

zajd wrote: post #67

Earlier quoted context omitted.

https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background

Atlassian has put some great "mind abstractions" on top of git to help people understand how to use it. It's definitely fashionable these days to hate on complicated tools. I wonder if the same is true in other professions. Simple tools are easy to use, yes. But anyone who as worked on a Bicycle or other equipment that requires specialized tools knows that the having the correct, often more complicated tool beats the…

Post by Pxtl » Sun, Oct 02, 2016, 4:22 PM UTC

douche wrote: post #118

dahart wrote: post #109

My criteria for whether an interface to git is truly easier is whether artists can use it. I've worked in games alongside artists, with everyone using Perforce. At some point we switched to Perforce for the art, and git for the programmers, with a big janky glue system in-between. Git couldn't really handle all the binary assets, and the artists couldn't really handle git, so it made sense. When we switched, it also…

As far as version-controlling art, I'd lean towards a system where checking a file out locks it from any other concurrent modifications. Unfortunately, trying to merge concurrent changes into an image file, for instance, is just about impossible. It's almost as bad trying to work with MS Office file types - I wish I could get people on my team to use something else that is more VCS friendly, like HTML or Markdown, bu…

Post by weberc2 » Sun, Oct 02, 2016, 4:27 PM UTC

k__ wrote: post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

Post by vesak » Sun, Oct 02, 2016, 4:30 PM UTC

Mithaldu wrote: post #53

okket wrote: post #2

See also discussion about the Gitless paper: "Purposes, Concepts, Misfits, and a Redesign of Git" https://news.ycombinator.com/item?id=12612333 (1 day ago, 106 comments)

And it hits the most important point of: Gitless tries to do away with the staging area, thus completely misunderstands Git.

Post by twic » Sun, Oct 02, 2016, 4:31 PM UTC

kazinator wrote: post #92

Git needs the parent pointer equivalent of NIL. Whenever I start a blank new repo nowadays, I do a git commit --allow-empty -m "NIL" See, many git operations require a parent reference! For instance if you want to interactively rebase the top commit, it's actually "git rebase -i HEAD^": rebase back to (but excluding) HEAD's parent. The equivalent "git rebase -i HEAD~1" means the same thing: that ~1 actually spans two…

  $ hg init
  $ echo silver >colour
  $ hg add colour
  $ hg commit --message 'First commit'
  $ hg checkout null
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ echo liquid >state
  $ hg add state
  $ hg commit --message 'Second commit'
  created new head
  $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n'
  1 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100
  0 = 6433a3e95c3d child of 000000000000: "First commit" @ 2016-10-02 17:29 +0100
  $ hg rebase --source 0 --dest 1
  rebasing 0:6433a3e95c3d "First commit"
  saved backup bundle to /path/to/repo/.hg/strip-backup/6433a3e95c3d-331b8224-backup.hg
  $ hg log --template '{rev} = {node|short} child of {p1node|short}: "{desc}" @ {date|isodate}\n'
  1 = b9951882336f child of 99f1472f8a69: "First commit" @ 2016-10-02 17:29 +0100
  0 = 99f1472f8a69 child of 000000000000: "Second commit" @ 2016-10-02 17:29 +0100