Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitless: experimental version control system

people.csail.mit.edu

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Gitless: experimental version control system

#31

Post by biehl »

austinz wrote: post #18
jammycakes wrote: post #15

Earlier quoted context omitted.

Depends on the GUI tool. Some of them do over-simplify things, for example, by omitting the DAG view. This is misleading because it tries to make the source history appear linear when it isn't. GitHub for Windows and Visual Studio's source history both make this mistake, for instance. Have you tried SourceTree? That's the one I tend to recommend these days. Alternatively, if you're prepared to splash out a bit, Smart…

I use a combination of SourceTree and the command line for my workflow, and can heartily recommend it. Some operations are just more intuitive to me when using the GUI such as: - staging portions of many files scattered across a directory tree - quickly glancing over diffs for a given commit - understanding the commit graph and the relationship between local and remote branches Each developer's experience may vary, b…

Exactly! And the cli is much better for the little workflows around rebase and cherry-pick.

Re: Gitless: experimental version control system

#32

Post by damian2000 »

jammycakes wrote: post #6

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

Agreed, I've been using Git Extensions GUI in Windows recently and its made a big difference. I find being able to select from the recently used repos list great to be able to quickly move around projects.

Re: Gitless: experimental version control system

#33

Post by Mathiasdm »

I wish Git would have used a different name than 'branch'. It's completely at odds with branches in any other version control system and only adds confusion for people switching to/from Git. Mercurial uses the term 'bookmarks' for Git-style branches, I feel that would have been a much better choice.

Re: Gitless: experimental version control system

#34

Post by Mathiasdm »

pain wrote: post #13

I have waited for a form-fit time to ask if we can experiment with Git using Mercurial syntax as well. While I have a feeling many would change Distributed Version Control System if there was immediately human translatable command knowledge between formats. Begs a question of if many software libraries with their typed dictionaries could counter a built-in thesaurus for alternative tool chains, and end a war between…

I believe this was a step in that direction: https://bitbucket.org/durin42/hgit

Re: Gitless: experimental version control system

#35

Post by qznc »

jammycakes wrote: post #6

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

http://pcottle.github.io/learnGitBranching/

This should be an interactive tutorial with visualization. It is currently broken for me (Chrome-Linux). There is screenshot on Github:

https://github.com/pcottle/learnGitBranching

Re: Gitless: experimental version control system

#36

Post by zeendo »

jammycakes wrote: post #6

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

In the last 5.5 years I've been using git I haven't met one person who used a GUI when learning it. I've taught several people how to use git and seen many others learn on their own....all no-GUIs. This experience spanned a variety of development teams in different companies (I was a consultant the entire time).

I'm not claiming a GUI hampers learning Git but just to offer some experience of it not being necessary.

With that said, this is very cool - https://pcottle.github.io/learnGitBranching/

Or well, it was when it worked. This seems similar, in spirit, but not as good as learnGitBranch was... - https://onlywei.github.io/explain-git-with-d3/

Re: Gitless: experimental version control system

#37

Post by jsprogrammer »

nulltype wrote: post #12
jsprogrammer wrote: post #8

Earlier quoted context omitted.

I wonder if there are any benchmarks or case-studies on very large git repos? Ideally you'd want to track (commit) every change to files and allow the user to place tags at certain places in the graph (similar to how commits are currently used) to represent aggregated logical changes. It would also be nice to have a visualization of the graph that could easily be 'seeked' through like a video. Putting this on top of…

Nice! Yeah that's along the lines I was thinking. There have been attempts at visualizations, like I remember clearcase had one that was probably pretty advanced 30 years ago. I think it's very doable without any serious R&D, and you could build it on top of git/maybe github. The real question to me is: is it worth the effort, and would anyone actually pay for it. People pay for tower and kaleidoscope so I assume it'…

Conceptually it is very simple. Integrating it with existing tools is where the real work is. Ideally, I think you'd want it integrated with your text editor and it should be useful not only for code, but more general composition (I'm thinking scientific literature) as well.

Of course, getting this to work in real-time with your collaborators is probably the holy grail and has been implemented to some extent over the years in quite a few products.

Re: Gitless: experimental version control system

#38

Post by erikb »

jammycakes wrote: post #6

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

I certainly used gitk a lot when starting out. But the other gui tools never convinced me. Gui tools have the problem that they often only map part of the process of using the shell tool. The best approach for learning for me was the git book. It's hard and long, but it explains everything and git really solves some hard problems, so in the end I felt it was worth it.

Re: Gitless: experimental version control system

#40

Post by erikb »

After reading the comments I found a few ideas that were not represented, so I write them here:

1. Git thinks around a commit, Gitless thinks around a file. Comparing two tools on a different basis might result in a flawed comparison. The reason that git uses for considering commits over single files is as far as I know, that you as a developer consider consistent states of your project. Before and after a change a project should be able to build, for instance. Often these changes can not happen in a single file and still be consistent. Therefore a project state is considered a unit, not a set of files that are changed on their own.

2. The staging area. Gitless thinks the staging area is a problem so it seems to be removed (might be a wrong interpretation by me). The staging area is quite important though. Sometimes I have made many changes, but I don't want all of them in one commit. In another scenario I did many changes that after squashing plus a few edits here and there might be better represented by a much smaller amount of commits. In both cases I need a space that is not the repository space of completed commits nor the workspace to represent a commit in its creation. The staging area might not be the best way to do it (I don't know a better one, though), but completely removing it without an alternative does not solve the problem.

Post reply on HN