docs: make co-located repos more prominent, explain them better #2183
Conversation
ilyagr
force-pushed
the
colocated
branch
9 times, most recently
from
391bd3a
to
f20cf18
Compare
|
@yuja, I'm curious if you have any thoughts, especially in case I missed something important or said something misleading. |
|
I changed some paragraphs and fixed some typos. |
ilyagr
force-pushed
the
colocated
branch
5 times, most recently
from
2496543
to
9bb9f81
Compare
|
I think this is pretty much done, but I did a couple of moderately severe edits. I'll give people a bit of time to look them over. I'd like this PR to go into 0.9.0, if possible. @martinvonz, if I haven't merged it and it's slowing you down, please feel free to merge it yourself. |
This will be used for context in the next commit Includes a mention of martinvonz#2193.
|
Which commands will not put you into a detached HEAD state?
I don't actually know.
I'm pretty sure this covers read-only commands if the working copy hasn't
changed. I occasionally wonder whether it covers all command that don't
change the relevant parent of the working copy, and if not, whether it
should. That seems to be the largest class of command that could preserve
the current branch.
So, a word like "often", "usually", "generally" seemed appropriate.
…On Tue, Sep 5, 2023, 7:12 AM Philip Metzger ***@***.***> wrote:
***@***.**** approved this pull request.
LG
------------------------------
In docs/git-compatibility.md
<#2183 (comment)>:
> +for this (see below for more) is that `jj` commands will often put the git repo
+in a "detached HEAD" state, since in `jj` there is not concept of a "currently
last minor Nit: Which commands will not put you into a detached HEAD
state? I'd rephrase that to "One reason for this (...) is that jj
commands will put the git repo in a "detached HEAD" state, since in jj`
there is not a concept of a "currently tracked branch".
—
Reply to this email directly, view it on GitHub
<#2183 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7OTJ34J3WJRJOWORW3IH3XY4XL7ANCNFSM6AAAAAA4DO7GZA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I think the only case we don't detach it is when we just snapshot the working copy. For example, if you do |
|
it's less clear if e.g. jj new @- (which also keeps the parent commit unchanged) should keep the branch attached.
Why not? This only applies if we are already on a branch at the parent
commit, and only affects git integration. Git is not really aware of the
working copy commit, only of the contents.
…On Tue, Sep 5, 2023, 8:58 AM Martin von Zweigbergk ***@***.***> wrote:
I'm pretty sure this covers read-only commands if the working copy hasn't
changed.
I think the only case we don't detach it is when we just snapshot the
working copy. For example, if you do jj describe -m foo, we're going to
detach it. Maybe it's better to keep it attached in that case, but it's
less clear if e.g. jj new @- (which also keeps the parent commit
unchanged) should keep the branch attached.
—
Reply to this email directly, view it on GitHub
<#2183 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7OTJ3WVXFQBEW5HQPKVCDXY5D2FANCNFSM6AAAAAA4DO7GZA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
It just feels like |
|
For my workflow, if I care about the branch at Things are different if, say, I might open a separate issue for this. (Update: done, #2210) |
At this point, they are stable enough that I think we should advertise them and encourage their use. This also explains some caveats.
At this point, they are stable enough that I think we should
advertise them and encourage their use. This also explains
some caveats.
Checklist
If applicable:
CHANGELOG.md