Replies: 8 comments 34 replies
-
|
...actually, it seems even |
Beta Was this translation helpful? Give feedback.
-
|
A few quick thoughts:
One possibility is that you are used to having a long chain of commits where they are arranged in the order you made the changes. So, the 13th commit might be a fixup to the second commit in the chain. This would require a lot of There are a few workflows that people tend to use. https://martinvonz.github.io/jj/latest/FAQ/ and https://martinvonz.github.io/jj/v0.10.0/github/ might (or might not) be helpful, they describe some of them. I generally create one branch per PR, after a I rely on |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate the links to the FAQ and the GitHub/GitLab documentation; thanks. |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth, the author of this blog post also prefers long commit chains: https://v5.chriskrycho.com/journal/jj-init/ |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for taking the time to write feedback!
It's actually mostly because we haven't seen much need for it, so we're keeping the data model simpler until we're convinced it's needed. If there's such a thing as a "current branch" in the model, then you need to figure out when to set and when to clear that. Git sets the current branch when you pass the branch name to
Maybe we should support something like Mercurial's topics extension, which lets you associate a single name with a commit. It lets you have the same topic name for multiple commits. Then you might do There's also issue #2338 for adding a
That
I don't think you should have to use |
Beta Was this translation helpful? Give feedback.
-
It's not clear to me from the topics documentation, but I think topics are a way to assign commits to arbitrary commit sets representing units of work. If I understand correctly, this concept doesn't exist as a first-class concept in Git or Breezy (or stock Mercurial or Monotone): sets of commits to be reviewed, etc., are implicitly calculated by computing the merge-base between two nodes in a commit graph and selecting one side. Possibly Pijul takes a more similar approach via some notion of patch sets. To me topics system seems marginally better from a conceptual perspective (setting aside the fact that most people are familiar with Git-style branches and would have to learn a new concept), except that representing Git branches as topics for interop could be confusing if commits are meant to belong to no more than one topic.
I think we can already achieve this workflow with jj workspaces and simply not using branches? This should be much better-supported in jj than in Git. But I think it would be warranted to add a way to operate on remote commits directly (say something like |
Beta Was this translation helpful? Give feedback.
-
Yes, in theory Pijul channels are patch sets that you can work with separately. But in practice, they are polluted with the dependencies, and the choice was made to make everything colocated since most people are familiar with that from Git.
I haven't looked at workspaces. Is it not colocated? |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @arxanas that topics sound pretty good for what I want, but also that it's not clear what the advantage of "topics" is versus just having branch-heads automatically advance like the active branch does in Git.
That is indeed the workflow I prefer, and it sounds pretty close to what I want. I've left a couple of comments in that issue thread.
It is not. https://martinvonz.github.io/jj/prerelease/working-copy/#workspaces |
Beta Was this translation helpful? Give feedback.
-
|
Here's an idea: what if the revset language included a symbol (or a function with a short name, though I'd prefer a symbol) to mean either "the last created or checked-out branch" or, if topics are introduced, "the branch(es) associated with the current topic"? That would mean that a lot of existing commands would more easily support working with branches, without needing users to type out branch names manually so often. Additionally, as a possible alternative (or addition) to #2338, and inspired by the discussion about a possible |
Beta Was this translation helpful? Give feedback.
-
|
I hope this isn't too off topic (pun not intended), but for me, I want |
Beta Was this translation helpful? Give feedback.
-
|
Scott Chacon's GitButler is "a Git client for simultaneous branches on top of your existing workflow". He talked about it in So You Think You Know Git - FOSDEM 2024. |
Beta Was this translation helpful? Give feedback.
-
|
Note that (as it was mentioned by Martin) you can use I used Darcs for a long time, so I'm actually somewhat fond of the approach. Actually, in one of my projects, I use this trick extensively to both help CI automation (run some tests under a version without switching to a different working copy, workspaces are perfect for that) and as a development strategy. Sometimes it's really useful on certain projects where you might have expensive/time-consuming compilation steps. You can spend more disk space to have multiple folders of different versions and run Also, in recent times most people who have wanted "Virtual Branches" the way GitButler does it have now adopted a workflow I came up with a few months ago — though I think it came to me fairly naturally — which is called "Simultaneous Edits" in @steveklabnik's tutorial (but I call it "Mega Merge".) The basic idea is you just create a merge commit on top of all the branches you want to check out simultaneously. Resolve any conflicts if needed, and then simply I haven't used GitButler, though I assume my way is more involved and more tedious. However I think these features arise from the basic fundamental building blocks that are already available, so you can sort of create it yourself. So maybe another question is, how do we achieve reusability out of the fundamental building blocks we have? I'm not really sure if we should think about presenting these features differently. Just wanted to put this out there. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I also wrote up another overview/walkthrough of the merge workflow: https://ofcr.se/jujutsu-merge-workflow |
Beta Was this translation helpful? Give feedback.
-
|
is there any discussion on making this workflow more straightforward? i find this a really compelling GitButler feature |
Beta Was this translation helpful? Give feedback.
-
|
@jabdinghoff What do you find not-straightforward about it? Do you have ideas about how it could be improved? |
Beta Was this translation helpful? Give feedback.
-
|
Just tossing this out here: as someone working on a project using
makes all of this a breeze. The branches never move, so I never need to change them, a Depending on upstream policy, you may not be able to do this, but it ends up being very nice. Since I like git's staging area, in practice I work on an empty |
Beta Was this translation helpful? Give feedback.
-
|
Indeed I have started using |
Beta Was this translation helpful? Give feedback.
-
|
I've been experimenting with modifying commits under PR, seeing what happens when other people have also checked out the PR bookmark and what happens when history is re-written. In the past, I've always felt that "Never re-write pushed history". But after trying this out, I can see that this really should be "Never re-write history on branches other people might base new work off of". If I edit a commit in a PR and just The consequences of this are that Stacked PRs are straight-up easy. If you have a chain of PRs up, and someone wants you to make a change to the very first link in the chain, no problem. Make your changes. If you get conflicts higher up in the chain of PRs, go fix the conflicts. When you push, ALL of your PRs are updated with sideways changes to the bookmarks. Damn! |
Beta Was this translation helpful? Give feedback.
-
|
At Meta the modify PR flow is used like you describe, but the previous version is a first class citizen in the UI, so reviewers see what changed from the last time they reviewed it. And it support flows like “accept with suggested changes” where the engineer makes subsequent changes, pushes the branch and then a post commit review is triggered to review the diff between “accepted changes” and the set of changes actually committed. |
Beta Was this translation helpful? Give feedback.
-
|
@ejc3 GitHub and GitLab both have similar features, but in my experience they can be a little flaky, and neither platform makes it all that obvious to see how to do that kind of comparison, let alone including a link to do so in the notification itself. It's too bad the mainstream publicly-available forges are not better suited for stacked PRs. |
Beta Was this translation helpful? Give feedback.
-
|
I use the stacked workflow with The only requirement is to add
Most of the work has a linear history and is done without branching. Sometimes, I have a couple of stacks, but usually, one. After customising templates, I also have these topics visible in the logs. Config[template-aliases]
topic = '''
description.lines().map(|line|
if(
line.lower().starts_with("topic:"),
line.substr(6, line.len()).remove_prefix(" ").remove_suffix(" "),
)
).join("")
'''
relative_topic = '''
description.lines().map(|line|
if(
line.lower().starts_with("relative:"),
concat(
"→ ",
line.substr(9, line.len()).remove_prefix(" ").remove_suffix(" "),
),
)
).join("")
'''
draft = '''
description.lines().map(|line|
if(
line.lower().starts_with("labels:") && line.lower().contains("draft"),
"DRAFT"
)
).join("")
'''
topic_label = 'separate(" ", label("draft", draft), label("topic", topic), label("relative", relative_topic))'
[colors]
draft = { fg = "bright red", bold = false, underline = false }
topic = "bright yellow"
relative = "bright black"
"username" = { fg = "bright black", bold = false }
"timestamp" = { fg = "bright black", bold = false }
|
Beta Was this translation helpful? Give feedback.
-
|
Splitting the "create branches and PRs" responsibility out to a separate tool makes a lot of sense to me! I hadn't heard of revup, so I will give that a try. |
Beta Was this translation helpful? Give feedback.
-
|
...ah, actually I can't use revup until it supports gitlab, at least for my current work. Unfortunate. |
Beta Was this translation helpful? Give feedback.
-
|
This thread gave me the most clues about how to just get on and use jj, somehow, anyhow. It has not been easy to find out what is the simplest way I can track my work in a remote git without breaking things. To work on top of a branch, e.g. main, the simplest flow I have found is: # after a jj git clone, or the previous jj git push, do:
# make changes
jj log # snapshots any changes made, causing jj to "stage" the changes - in jj it makes a detached head commit
jj commit -m "description of the changes made" # a conventional commit, but jj adds a fresh empty detached head commit on top
jj bookmark set --revision @- main # since we point to the fresh empty detached head commit on top, point the bookmark (branch name) to the prior not empty commit
jj git push -r @- # push the bookmark (git branch) that points to the prior not empty commit
# make more changes, and repeat |
Beta Was this translation helpful? Give feedback.
-
|
@BatmanAoD for what you described, "push after each commit", in my personal repos I do:
This does not look any more tedious than git to me, although I've been using jj exclusively for years now, maybe I forgot. And I get all the rebases/revsets/templates and other jj goodies. And like, I don't always push immediately, I might do some cleanups with Well, as I kept and keep saying, topics - as I see them in my head anyway, and if/when they can be exported as git branches - will fix the auto-advancing issue anyway. As, again, I've been saying that a lot too, bookmarks and tags are very similar - tags are named commit-ids (don't move at all unless you move them) and bookmarks are named change-ids (move with the changeid when rewriting commits, but don't otherwise, unless you move them). So bookmarks semantically should not "auto-advance", we are just using bookmarks as a stop-gap to be able to push to git remotes, because git requires branches for pushes - and we will be using topics as a hack like that too, until the distant bright future where native jj repos are a thing, but at least they solve the auto-advancing. |
Beta Was this translation helpful? Give feedback.
-
Well, it's three commands instead of two, and one of those is an alias you had to add. So, while admittedly a minor difference, it's strictly more onerous than git, especially since there isn't a built-in way to do it. And for what it's worth, I've previously used
I think that might just be the fundamental disconnect between myself and everyone happy with the "jj way." I do always push immediately, even if I later rebase or otherwise modify commits.
Maybe, but it depends what the final design ends up being, and I have no idea how long it will take for topics to be available. In the meantime, it doesn't affect what I'm able to do now with |
Beta Was this translation helpful? Give feedback.
-
|
Hm, actually I think you'd benefit greatly from a remote-backed commit store, since you push everything always immediately to have your work stored not only on your local machine I'm assuming. With a remote-backed commit store (with a local layer ofc) you'd never have to push at all - well unless interacting with git repos. I guess that'd be basically a jj-aware server then, something along those lines |
Beta Was this translation helpful? Give feedback.
-
|
Yep, if you look at the last paragraph of my original post, I actually mentioned possibly doing this! I'll consider it again. |
Beta Was this translation helpful? Give feedback.
-
|
Just to add other options to an interesting thread. I'm really enjoying the flexibility and the config system. I went through the publicly documented options, and among other things, I set the following aliases (more to come): [aliases]
dds = ["diff", "--tool", "difft-s"]
ddi = ["diff", "--tool", "difft-i"]
di = ["diff", "--tool", "idea"]
sm = ["b", "s", "main"]
smb = ["b", "s", "main", "-B"]
gp = ["git", "push"]
gf = ["git", "fetch"]
gpn = ["git", "push", "--allow-new"]I use code generation extensively, so I'm constantly (re)creating projects. My workflow has been as follows: jj git init --colocate
jj desc -m "initial commit"
jj sm # For "Set or Create the 'main' bookmark to Current Commit"
gh repo create --source . --public
jj gpn # For git push and allow new bookmarks
gh browseWith these aliases,
To add:
I'm sold. Now I'm just contemplating on how I might be able to contribute to the project. Docs, Rust is my primary language. I've got an other open source project I'm in the midst of getting ready for publicizing (very powerful code generator), but I'm inclined to find some time for this, too. |
Beta Was this translation helpful? Give feedback.
-
|
@necauqua Perfect, thank you. jj is fabulous and new to me. I hope my beginner feedback helps. From your comment I got 2 things:
Like many, I am grateful for jujutsu appearing. It feels like Déjà vu! I lived through the godsend of git, after years of waiting for something like bzr, GNU Arch, Monotone, DARCS, Hg etc to go mainstream. |
Beta Was this translation helpful? Give feedback.
-
|
Just to clarify, You can have this in your [aliases]
tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"]
Reiterating a bit to help you with 1. - one of the main concepts of jj is that barring unusual circumstances commands work on the tree of commits, @ being just one of them. Just working on commits and not having staging or index is both simple and very powerful - all commands can work on "remote" commits - I can have my @ being in one place, and then rebase some branch on top of some other branch and not have my work disrupted being one of many many examples of that. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for [aliases]
# tug - move the nearest bookmark to the nearest non-empty change at or before @
tug = ["bookmark", "move", "--from", "closest_bookmark(@)", "--to", "closest_nonempty(@)"]
# sync - move the nearest bookmark and current git branch to the nearest non-empty change at or before @
sync = ["util", "exec", "--", "bash", "-c", """
set -euo pipefail
jj tug
git switch `jj closestbookmark`
""", ""]
# closestbookmark - show the name of the nearest bookmark at or before @
closestbookmark = ["util", "exec", "--", "bash", "-c", """
jj log --no-graph -r 'closest_bookmark(@)' -T 'stringify(local_bookmarks.map(|b| b.name()).join("\n")).first_line()++"\n"'
""", ""]
[revset-aliases]
'closest_bookmark(to)' = 'heads(::to & bookmarks())'
'closest_nonempty(to)' = 'heads(::to ~ empty())' |
Beta Was this translation helpful? Give feedback.
-
|
Here's a nice way to use jj with a Git style current-branch?: Use Then, a bookmark pointing at And, as a bonus, reduces the likelihood that you accidentally commit the wrong files. I mean, Also, I'm pretty clueless about jj, still, I started wondering if such a The only "problem" is if there's two local-only bookmarks and you want to keep only one pointing at Is this an a bit interesting tiny change of mindset? That a new feature is constantly represented by the same & stable change-id, and a "tail" keeps growing behind this change-id. Rather than adding new change-ids on top of each other? |
Beta Was this translation helpful? Give feedback.
-
Regarding this suggestion, we have an experimental feature that you can enable which will make |
Beta Was this translation helpful? Give feedback.
-
|
@emesterhazy Thanks! Trying it out now. Nice that it apparently works also with |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've read the tutorial, and I understand that
jjdoesn't have a concept of a "working branch," but I'm wondering if I've missed something fundamental, because it seems like the basic git workflow of "make some changes, commit them, push them" is fairly high-friction.Since
jjdoesn't have a concept of a "working branch", it appears that I need to explicitly runjj branch set <name> -r @every time I want to add commits to a branch. Is that correct? Is there a reason for that, other than encouraging users to rewrite commits rather than add new commits?It may be that I just haven't adapted to the
jj"way" (I only installed it yesterday), but here are the things I miss about having a working branch:jj'snewcommand does this for individual commits, but that seems too granular for me; I don't always know the nature of a small change I'm about to make before I make it. I do, however, always have a high-level plan, generally captured as a feature name and/or issue-tracker number.jj git pushdoesn't work without either manually specifying a commit and a remote destination or first usingbranch set ... -r @.The second of these points is much more important to me than the first. Should I just get used to setting up
rsync, Dropbox, or similar for my data-synchronization, and stop using commit & push for this purpose? Isjj git push -c @something I should be doing more frequently?Beta Was this translation helpful? Give feedback.
All reactions