Replies: 5 comments 16 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.
-
|
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 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.
-
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