4 ms·

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and

> It combines features from Git (data model, speed), Mercurial (anonymous branching, simple CLI free from "the index", revsets, powerful history-rewriting), and Pijul/Darcs (first-class conflicts), with features not found in either of them (working-copy-as-a-commit, undo functionality, automatic rebase, safe replication via rsync, Dropbox, or distributed file system). You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. > The working copy is automatically committed Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away. I very much want the index / workspace distinction. > Automatic rebase > Comprehensive support for rewriting history This is very welcome. At the very least this confirms something important: the fallacious argument that "rebase rewrites history, so it's eeeevil" is finally dead.

yjftsjthsd-h 5y ago
If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?
- bonzini 5y ago
  The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.
  - masklinn 5y ago
    > You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.
    - bonzini 5y ago
      True but there's usually a "git diff --staged" in the middle to check what I am committing.
      - cryptonector 5y ago
        Exactly!
      - masklinn 5y ago
        You can do that with “git show HEAD” (and “git commit --amend -p”).
        cryptonector 5y ago
        `git diff --staged` is superior. For one, you get all the options to `git diff`. For another, it has no side effects, unlike `git commit --amend -p`.
        masklinn 5y ago
        > `git diff --staged` is superior. For one, you get all the options to `git diff`. Most of which you can get on git show at least if they're relevant to “what have I added”. And of course you can also use git diff on commits if you need something super specific. > For another, it has no side effects, unlike `git commit --amend -p`. … “git commit --amend -p” is the replacement for subsequent “git add -p”, as the GP was talking about a workfliw where they’d intersperse staging stuff and looking at what they’d staged.
  - martinvonz 5y ago
    > I am interested in how to do this with jj `jj split -r <commit>`, where `<commit>` may be the working copy commit (which is the default). See https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... for more examples.
    - detaro 5y ago
      so just for understanding: repeated `git add -p` followed by a `git commit` turns into repeated `jj split; jj squash`, since you create a commit each time?
      - martinvonz 5y ago
        That would work, yes, but there's also `jj squash -i` to move part of the child commit into the parent. There's also the more generic `jj move` command for moving part of any commit into any other commit (ancestor, descendant, sibling), so you `jj squash -i` is equivalent to `jj move -i --from @ --to @-` (where `@` is syntax for the working copy commit and `@-` is syntax for its parents).
  - erik_seaberg 5y ago
    I prefer "git stash -p" to exclude unfinished changes, because if I build up a partial commit in the index there’s no way to test it.
    - cryptonector 5y ago
      I do that later. I do `git rebase -i` and add `exec` lines to build each commit that must build.
  - cryptonector 5y ago
    `git add -e` is infinitely better.
  - andrewshadura 5y ago
    Try git-crecord.
- cryptonector 5y ago
  Yes, I do. I often do this (usually in detached HEAD mode!): : ; $EDITOR some-file ... : ; $build : ; git add -e # take a few chunks, maybe change them : ; git diff --staged; git status -uno : ; # lather, rinse, repeat : ; git commit -m '...' -ev : ; : ; git status -uno; git diff : ; git add -e # .. : ; # lather, rinse, repeat until happy : ; : ; git fetch origin : ; git rebase origin/master : ; # fix any conflicts : ; : ; # continue until all bug fix / feature : ; # activity for this issue is complete : ; : ; # review my changes: : ; git log --patch origin/master.. : ; : ; # if I have to clean my history a bit: : ; git rebase -i origin/master : ; # re-order commits, `edit` commits, `drop` : ; # commits as needed : ; $build : ; # fix remaining issues... : ; : ; # finally ready to push: : ; git push myclone HEAD:refs/heads/this-thing : ; : ; # open a PR Repeat as needed to deal with code review comments until done and integrated.
  - c-smile 5y ago
    Are you human? > detached HEAD mode Ah, I see, not anymore...
    - cryptonector 5y ago
      Lol, have an upvote!
martinvonz 5y ago
> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis...), there's an explanation there for how to achieve the same workflows. I get that it's different, but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched to Mercurial ~7 years ago. > This is very welcome. Thanks :)
- omegalulw 5y ago
  > With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.
  - em-bee 5y ago
    yeah, i feel this is going to bother me, or at least be difficult to get used to. i often have temporary files that i do not want to commit, nor do i want to add them to .gitignore (because i want to commit them later) but then, i'll have to spend some time using jj split. if it is powerful enough then maybe the end result is just that those files only live in the last commit. also, what happens on push? i'd never ever want the working copy to be pushed to the remote repo. i could not find anything in the documentation about that. (according to the answer here: https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554 the working copy is not supposed to be pushed)
  - joseph8th 5y ago
    Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.
dilap 5y ago
I like and use the index in git too, but I wouldn't be so quick to dismiss other models that might end up solving the same use cases in a different way... From the README, it looks like there's robust support for editing and splitting commits. So maybe in practice the flow is similar to using the index, with the added the added benefit that your work is backed via commits along the way, and the simplicity of not having the index as an extra concept. In general when exvaluating X from the perspective of Y, we will immediately see the thing's about Y we like that X lacks; it takes more time to see if perhaps in the fuller context of X those things are not necessary.
masklinn 5y ago
> Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away. You don’t need the index for that. In fact I’d say it gets in the way because the presence of the one means less pressure on improving the ability to edit commits: while it’s easy to add stuff to HEAD it’s much more painful to remove content from it. If that is solved, then the value of the index drops precipitously, because you can create a commit with a purpose and select its content instead of having to do it the other way around then forgetting what change you were trying to craft.
throw0101a 5y ago
> You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. Mercurial has an 'index' / staging area, but not exposed by default. You can access it with some extra CLI options, but there is an optional idea that may be 'better' and worth looking into: > If you need the index, you can gain its behavior (with many additional options) with mercurial queues [1] (MQ).[2] Simple addition of changes to the index can be imitated by just building up a commit with hg commit --amend (optionally with --secret, see phases [3]). * https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_staging_area https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi... [1] is "A Git User's Guide to Mercurial Queues" * https://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc... MQs (optionally) expand on the idea of only a single staging area: > This single "intermediate" area is where git stops. For many workflows it's enough, but if you want more power MQ has you covered. > MQ is called Mercurial Queues for a reason. You can have more than one patch in your queue, which means you can have multiple "intermediate" areas if you need them. If you only want to use one queue/index then that's fine too.
- cryptonector 5y ago
  I find Mercurial very difficult to use. I find Git much easier.
  - andrewshadura 5y ago
    It's just because you've been using Git for too long. Mercurial is much easier to use if you're not exposed to Git.
    - cryptonector 5y ago
      I used Mercurial before I used Git.
- alwillis 5y ago
  As a Mercurial user from almost the beginning, it’s not accurate to say Mercurial has a hidden index. That Steve Losh post is from 2010 and it was mainly highlighting a workflow that was popular at the time for a particular use case. It also highlighted how Mercurial’s plug-in architecture can be used to to support different workflows. Fast forward to the present and the use of MQ isn’t really a thing anymore, but is available for those who want it. Check out https://octobus.net/blog/2020-11-26-modern-mercurial.html https://octobus.net/blog/2020-11-26-modern-mercurial.html for modern Mercurial practices.
deleted 5y ago
[deleted]
indygreg2 5y ago
The index is a power user feature. Its forced presence in Git effectively constitutes a usability barrier for new users. After all, a VCS is effectively a glorified abstraction for "save a file." Any barrier imposed between changing a file and committing it can get in the way and confuse people. The Git index does this. Furthermore, the index is effectively a pseudo commit without a commit message. Any workflow using the index can be implemented in terms of actual commits itself. I think because Git doesn't have strong usability in general and especially around history rewriting, many Git users feel that the index or an index equivalent is somehow a required feature of a VCS because Git's shortcomings give that illusion. However, if you use a VCS with better history rewriting (such as Mercurial with evolve), you'll likely come around to my opinion that the index can be jettisoned without meaningful loss of functionality or productivity.
- cryptonector 5y ago
  I don't deny that the index is a power feature and that it's difficult to explain it to newbies. Perhaps there's room for new UIs. All I'm saying is I need this power. And it has to be easy to reach for it.

yjftsjthsd-h 5y ago

If you can rewrite the history that actually got committed, do you really need a temporary pre-commit staging area?

bonzini 5y ago
The index is mostly useful to me to split a commit in multiple ones. You do that with a sequence of "git add -p" and "git commit" commands. I am interested in how to do this with jj, because otherwise it looks like a very interesting tool.
- masklinn 5y ago
  > You do that with a sequence of "git add -p" and "git commit" commands. You can do that with git commit -p.
  - bonzini 5y ago
    True but there's usually a "git diff --staged" in the middle to check what I am committing.
    - cryptonector 5y ago
      Exactly!
    - masklinn 5y ago
      You can do that with “git show HEAD” (and “git commit --amend -p”).
      - cryptonector 5y ago
        `git diff --staged` is superior. For one, you get all the options to `git diff`. For another, it has no side effects, unlike `git commit --amend -p`.
        masklinn 5y ago
        > `git diff --staged` is superior. For one, you get all the options to `git diff`. Most of which you can get on git show at least if they're relevant to “what have I added”. And of course you can also use git diff on commits if you need something super specific. > For another, it has no side effects, unlike `git commit --amend -p`. … “git commit --amend -p” is the replacement for subsequent “git add -p”, as the GP was talking about a workfliw where they’d intersperse staging stuff and looking at what they’d staged.
- martinvonz 5y ago
  > I am interested in how to do this with jj `jj split -r <commit>`, where `<commit>` may be the working copy commit (which is the default). See https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis... for more examples.
  - detaro 5y ago
    so just for understanding: repeated `git add -p` followed by a `git commit` turns into repeated `jj split; jj squash`, since you create a commit each time?
    - martinvonz 5y ago
      That would work, yes, but there's also `jj squash -i` to move part of the child commit into the parent. There's also the more generic `jj move` command for moving part of any commit into any other commit (ancestor, descendant, sibling), so you `jj squash -i` is equivalent to `jj move -i --from @ --to @-` (where `@` is syntax for the working copy commit and `@-` is syntax for its parents).
- erik_seaberg 5y ago
  I prefer "git stash -p" to exclude unfinished changes, because if I build up a partial commit in the index there’s no way to test it.
  - cryptonector 5y ago
    I do that later. I do `git rebase -i` and add `exec` lines to build each commit that must build.
- cryptonector 5y ago
  `git add -e` is infinitely better.
- andrewshadura 5y ago
  Try git-crecord.
cryptonector 5y ago
Yes, I do. I often do this (usually in detached HEAD mode!): : ; $EDITOR some-file ... : ; $build : ; git add -e # take a few chunks, maybe change them : ; git diff --staged; git status -uno : ; # lather, rinse, repeat : ; git commit -m '...' -ev : ; : ; git status -uno; git diff : ; git add -e # .. : ; # lather, rinse, repeat until happy : ; : ; git fetch origin : ; git rebase origin/master : ; # fix any conflicts : ; : ; # continue until all bug fix / feature : ; # activity for this issue is complete : ; : ; # review my changes: : ; git log --patch origin/master.. : ; : ; # if I have to clean my history a bit: : ; git rebase -i origin/master : ; # re-order commits, `edit` commits, `drop` : ; # commits as needed : ; $build : ; # fix remaining issues... : ; : ; # finally ready to push: : ; git push myclone HEAD:refs/heads/this-thing : ; : ; # open a PR Repeat as needed to deal with code review comments until done and integrated.
- c-smile 5y ago
  Are you human? > detached HEAD mode Ah, I see, not anymore...
  - cryptonector 5y ago
    Lol, have an upvote!

martinvonz 5y ago

> You lost me at "free from the index". If you click the link that text points you to (i.e. https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md#the-index https://github.com/martinvonz/jj/blob/main/docs/git-comparis...), there's an explanation there for how to achieve the same workflows. I get that it's different, but I don't think it's worse. I consider myself a (former) git power user (I think I have ~90 patches in Git itself) and I've never missed the index since I switched to Mercurial ~7 years ago. > This is very welcome. Thanks :)

omegalulw 5y ago
> With Jujutsu, you'd instead use jj split to split the working copy commit into two commits. This is more confusing? Often times when debugging/writing a fix I would have extraneous code that I wouldn't want to commit. With an index I'm always sure if what I commit, but with this workflow you have to keep track of such stuff all the time and if you forget that stuff makes it in? Not to mention that another benefit of an index is being able to change commits and git replaying your working diff.
- em-bee 5y ago
  yeah, i feel this is going to bother me, or at least be difficult to get used to. i often have temporary files that i do not want to commit, nor do i want to add them to .gitignore (because i want to commit them later) but then, i'll have to spend some time using jj split. if it is powerful enough then maybe the end result is just that those files only live in the last commit. also, what happens on push? i'd never ever want the working copy to be pushed to the remote repo. i could not find anything in the documentation about that. (according to the answer here: https://news.ycombinator.com/item?id=30399554 https://news.ycombinator.com/item?id=30399554 the working copy is not supposed to be pushed)
- joseph8th 5y ago
  Yah... I have a long-standing habit of commenting `TODO` for some debugging or WIP code. Then, before I commit, I can just do `git diff | grep TODO` and see all the new TODOs I've added.

dilap 5y ago

I like and use the index in git too, but I wouldn't be so quick to dismiss other models that might end up solving the same use cases in a different way... From the README, it looks like there's robust support for editing and splitting commits. So maybe in practice the flow is similar to using the index, with the added the added benefit that your work is backed via commits along the way, and the simplicity of not having the index as an extra concept. In general when exvaluating X from the perspective of Y, we will immediately see the thing's about Y we like that X lacks; it takes more time to see if perhaps in the fuller context of X those things are not necessary.

masklinn 5y ago

> Right, so, the reason the index is powerful is that I get to do `git add -e`, `git commit`, and repeat until I'm done or ready to throw remaining changes away. You don’t need the index for that. In fact I’d say it gets in the way because the presence of the one means less pressure on improving the ability to edit commits: while it’s easy to add stuff to HEAD it’s much more painful to remove content from it. If that is solved, then the value of the index drops precipitously, because you can create a commit with a purpose and select its content instead of having to do it the other way around then forgetting what change you were trying to craft.

throw0101a 5y ago

> You lost me at "free from the index". The index is one of the most important parts of Git that makes my life easier. Opinionated DVCS UIs make my life harder -- all of them. Mercurial has an 'index' / staging area, but not exposed by default. You can access it with some extra CLI options, but there is an optional idea that may be 'better' and worth looking into: > If you need the index, you can gain its behavior (with many additional options) with mercurial queues [1] (MQ).[2] Simple addition of changes to the index can be imitated by just building up a commit with hg commit --amend (optionally with --secret, see phases [3]). * https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_staging_area https://www.mercurial-scm.org/wiki/GitConcepts#Git.27s_stagi... [1] is "A Git User's Guide to Mercurial Queues" * https://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc... MQs (optionally) expand on the idea of only a single staging area: > This single "intermediate" area is where git stops. For many workflows it's enough, but if you want more power MQ has you covered. > MQ is called Mercurial Queues for a reason. You can have more than one patch in your queue, which means you can have multiple "intermediate" areas if you need them. If you only want to use one queue/index then that's fine too.

cryptonector 5y ago
I find Mercurial very difficult to use. I find Git much easier.
- andrewshadura 5y ago
  It's just because you've been using Git for too long. Mercurial is much easier to use if you're not exposed to Git.
  - cryptonector 5y ago
    I used Mercurial before I used Git.
alwillis 5y ago
As a Mercurial user from almost the beginning, it’s not accurate to say Mercurial has a hidden index. That Steve Losh post is from 2010 and it was mainly highlighting a workflow that was popular at the time for a particular use case. It also highlighted how Mercurial’s plug-in architecture can be used to to support different workflows. Fast forward to the present and the use of MQ isn’t really a thing anymore, but is available for those who want it. Check out https://octobus.net/blog/2020-11-26-modern-mercurial.html https://octobus.net/blog/2020-11-26-modern-mercurial.html for modern Mercurial practices.

deleted 5y ago

[deleted]

indygreg2 5y ago

The index is a power user feature. Its forced presence in Git effectively constitutes a usability barrier for new users. After all, a VCS is effectively a glorified abstraction for "save a file." Any barrier imposed between changing a file and committing it can get in the way and confuse people. The Git index does this. Furthermore, the index is effectively a pseudo commit without a commit message. Any workflow using the index can be implemented in terms of actual commits itself. I think because Git doesn't have strong usability in general and especially around history rewriting, many Git users feel that the index or an index equivalent is somehow a required feature of a VCS because Git's shortcomings give that illusion. However, if you use a VCS with better history rewriting (such as Mercurial with evolve), you'll likely come around to my opinion that the index can be jettisoned without meaningful loss of functionality or productivity.

cryptonector 5y ago
I don't deny that the index is a power feature and that it's difficult to explain it to newbies. Perhaps there's room for new UIs. All I'm saying is I need this power. And it has to be easy to reach for it.