ok/jj
1
0
Fork 0
forked from mirrors/jj
Commit graph

8 commits

Author SHA1 Message Date
Yuya Nishihara
e0965c4533 git: on push, update jj's view of remote branches without using import_refs()
This means that the commits previously pinned by remote branches are no longer
abandoned. I think that's more correct since "push" is the operation to
propagate local view to remote, and uninteresting commits should have been
locally abandoned.
2023-10-17 15:06:03 +09:00
Yuya Nishihara
ce0821f06d docs: adjust tracking branches design to deal with "fetch/push && undo"
The original idea was to completely replace git_refs with remotes["git"] by
introducing "forgotten" state, but it turned out to break "fetch && undo"
scenario. There are other ways around, but they also have problems:

* Sets tombstone on forgotten/deleted remote refs, exports remote refs without
  comparing to the known refs.
  * `jj undo` would need to insert tombstone by diffing old/new views.
  * `jj branch forget` would need to preserve the @git branch whereas the other
    remote branches would be forgotten.
* Always overwrites remote refs on export.
  * `jj git export` without importing would discard remote refs.

So, I decided to not remove git_refs. Apparently, it also improves the undo
behavior. In the new model, `jj git fetch && jj undo && jj git fetch` works
even if git_refs isn't rolled back. So we can unify the default of
`jj undo --what`.
2023-09-28 18:00:25 +09:00
Philip Metzger
09a99e36dc docs/design: Clarify run.md a bit.
This is essentially a new version, which clarifies multiple statements about
`jj run`. Notably, it cleans up some mistakes which were overlooked or deemed
good enough in the Google Docs version.
2023-09-14 16:39:40 +02:00
Philip Metzger
5b729a90a9 docs/design: Move the run doc to github.
This ticks another box in #1869.

Co-Authored-By: arxanas <me@waleedkhan.name>
Co-Authored-By: hooper <hooper@google.com>
Co-Authored-By: martinvonz <martinvonz@google.com>
2023-09-14 16:39:40 +02:00
Yuya Nishihara
aae9aa4a7a doc: add plan for non-tracking branches support
#1136, #1666, #1734
2023-08-23 09:58:01 +09:00
Glen Choo
d165e931eb docs/design: propose submodule storage approach
This doc discusses the requirements of a submodule storage solution and
proposes a solution: storing submodules as full jj repos.
2023-04-24 14:29:47 -07:00
Glen Choo
562eebe213 WIP docs/design: describe submodule storage ideas and how to judge them
This doc describes what we need to consider in a submodule storage
solution, some possible solutions and what criteria we should use to
decide on a future direction.

This is still a WIP:

- The solutions are still underdescribed
- The actual evaluation of solutions is missing

Suggestions for the above are welcome :)
2023-04-24 14:29:47 -07:00
Glen Choo
707d82245f docs/technical: add aspirational Git submodules doc
This document is meant to be a record of how we think about Git
submodules (and not a _current_ implementation of submodules). We will
fill it out incrementally as we get a clearer idea of what we want
submodules to look like.

As an initial version, I started with (IMO) the least controversial
points:

- We want to support most workflows Git submodules users are accustomed
  to.

- A roadmap that allows us to incrementally roll out Git submodule
  functionality (instead of having to boil the ocean).
2023-04-03 12:58:17 -07:00