5 ms·

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're a

by uses 5y ago

Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly manage the equivalent of .gitignore? What am I misunderstanding about the benefits of how this works?

TillE 5y ago
There are already popular Git GUIs like GitHub Desktop which abstract away the staging area. It's also how basically every other VCS works. Yeah, you should have an appropriately comprehensive .gitignore file, that's good practice in any case.
markstos 5y ago
You are too brainwashed by git.:) The bigger picture is that the project is trying to provide a better interface on top of the existing git data store. As someone who used darcs for a major project before Git dominated DVCS, there are much better user interfaces than what Git offers, and attempts to improve upon Git is a diversity to encourage. Unlike picking your own text editor, a whole team has to agree about the choice of DVCS, making it harder to try new ones. The beauty of a solution with a Git-compatible data store is it allows some people on the team to experiment with it while still collaborating with people using Git.
krick 5y ago
Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on the screen at that point, I'm as likely to notice mistakes there as I am in somebody else's code, if not less. When I'm adding a change, on the contrary, it's something I wrote minutes to seconds ago, I know what's in that code, and by adding that I'm kind of making a statement that this wasn't some random bullshit I do with the code, but something I intend to keep (even if later I'll completely change that while interactively rebasing or something like that). On the other hand, I didn't complain that much back in the day when I was using SVN. But I feel like my current workflow that employs most unique features of git is actually much better. Basically, horribly inconsistent CLI is the only complaint I have about git.
- JuettnerDistrib 5y ago
  > I wouldn't want anything to be added by default This line of reasoning works really well for those who understand (and want to understand) how git works. I know plenty of people who don't care about their development tools (e.g. scientists), and for them the index is a chore in the way of more important problems.
gitgud 5y ago
Does that mean that there's no "staged changes" in Jujutsu? That's one of my favourite and ironically hated parts of git...
- martinvonz 5y ago
  Yes, no staging area. Does https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help address your concern?
shp0ngle 5y ago
Exactly. Reading the docs makes me feel something is a bit “wrong”. But I felt like this before when I switched from subversion to git (“why would I download all history, always???”) so, who knows.
ezst 5y ago
> Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. And maybe I'm too brainwashed by Mercurial, but to me the index is nothing but a single weird commit with only downsides (why do we need a UI to work with the index that's different from the one to interact with commits, although the capabilities should be the same? Why being limited to a single index and not several? Why the different versioning/shareability characteristics, etc). I largely prefer Mercurial's "public vs draft" strategy and the "commit what you have and we give you the tools to tidy up the series whenever you feel like it". In practice it means that you have as many "indexes" as your series is long, and with hg's mutable-history and amazing history-rewriting extensions like absorb, it's much more convenient, fast and safe to work with than the git inconsistent equivalents.
jeltz 5y ago
Agreed, the index is one of my favorite parts of git. I do _not_ want to add everything almost ever.
smazga 5y ago
The stage is git's killer feature to me. I'm very iterative, so I tend to change a lot of tangential things as I narrow down the best implementation of my code. Knowing that I'm free to change whatever I want and only commit the parts that I've determined are good is very liberating. My workflow is basically just change whatever I want to get to my goal. When I finally get the behavior I want, stage the changes and stash the rest. Once I've verified that everything works, commit the stage and drop the stash. I don't have to think about anything not directly related to my commit. Feels like with tools like jujutsu, pijul, mercurial...I'd have a lot of manual cleanup to do _before_ committing...and then what if I accidentally clean up something I didn't realize I needed? It's gone. Whereas, with git I can just pop the stash and stage whatever piece I missed.
- martinvonz 5y ago
  Does https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help explain?

by uses 5y ago

TillE 5y ago

There are already popular Git GUIs like GitHub Desktop which abstract away the staging area. It's also how basically every other VCS works. Yeah, you should have an appropriately comprehensive .gitignore file, that's good practice in any case.

markstos 5y ago

You are too brainwashed by git.:) The bigger picture is that the project is trying to provide a better interface on top of the existing git data store. As someone who used darcs for a major project before Git dominated DVCS, there are much better user interfaces than what Git offers, and attempts to improve upon Git is a diversity to encourage. Unlike picking your own text editor, a whole team has to agree about the choice of DVCS, making it harder to try new ones. The beauty of a solution with a Git-compatible data store is it allows some people on the team to experiment with it while still collaborating with people using Git.

krick 5y ago

Your phrasing makes me think if I'm just too brainwashed by git as well, but, yeah, I wouldn't want anything to be added by default at all. While working I do all kinds of stuff I'm not going to commit, like debug statements and rough sketches, maybe some temporary scripts. And even though I do usually glance over diffs in the end, I don't really read them: that is, even if I did, it's not really my thoughts I see on the screen at that point, I'm as likely to notice mistakes there as I am in somebody else's code, if not less. When I'm adding a change, on the contrary, it's something I wrote minutes to seconds ago, I know what's in that code, and by adding that I'm kind of making a statement that this wasn't some random bullshit I do with the code, but something I intend to keep (even if later I'll completely change that while interactively rebasing or something like that). On the other hand, I didn't complain that much back in the day when I was using SVN. But I feel like my current workflow that employs most unique features of git is actually much better. Basically, horribly inconsistent CLI is the only complaint I have about git.

JuettnerDistrib 5y ago
> I wouldn't want anything to be added by default This line of reasoning works really well for those who understand (and want to understand) how git works. I know plenty of people who don't care about their development tools (e.g. scientists), and for them the index is a chore in the way of more important problems.

gitgud 5y ago

Does that mean that there's no "staged changes" in Jujutsu? That's one of my favourite and ironically hated parts of git...

martinvonz 5y ago
Yes, no staging area. Does https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help address your concern?

shp0ngle 5y ago

Exactly. Reading the docs makes me feel something is a bit “wrong”. But I felt like this before when I switched from subversion to git (“why would I download all history, always???”) so, who knows.

ezst 5y ago

> Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. And maybe I'm too brainwashed by Mercurial, but to me the index is nothing but a single weird commit with only downsides (why do we need a UI to work with the index that's different from the one to interact with commits, although the capabilities should be the same? Why being limited to a single index and not several? Why the different versioning/shareability characteristics, etc). I largely prefer Mercurial's "public vs draft" strategy and the "commit what you have and we give you the tools to tidy up the series whenever you feel like it". In practice it means that you have as many "indexes" as your series is long, and with hg's mutable-history and amazing history-rewriting extensions like absorb, it's much more convenient, fast and safe to work with than the git inconsistent equivalents.

jeltz 5y ago

Agreed, the index is one of my favorite parts of git. I do _not_ want to add everything almost ever.

smazga 5y ago

The stage is git's killer feature to me. I'm very iterative, so I tend to change a lot of tangential things as I narrow down the best implementation of my code. Knowing that I'm free to change whatever I want and only commit the parts that I've determined are good is very liberating. My workflow is basically just change whatever I want to get to my goal. When I finally get the behavior I want, stage the changes and stash the rest. Once I've verified that everything works, commit the stage and drop the stash. I don't have to think about anything not directly related to my commit. Feels like with tools like jujutsu, pijul, mercurial...I'd have a lot of manual cleanup to do _before_ committing...and then what if I accidentally clean up something I didn't realize I needed? It's gone. Whereas, with git I can just pop the stash and stage whatever piece I missed.

martinvonz 5y ago
Does https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... help explain?