Basic collaboration functionality
- Langage dominant
- Go
- Étoiles
- 762
- Forks
- 72
- Merge moyen
- 18 h 24 min
- PR mergées (30 j)
- 28
Description
The team I'm working with are excited to start stacking, and adopting git-spice as their tool for this workflow.
One recurring question that arises in this context is that of collaborating on stacks.
To follow along, create a new repository, and clone it locally to two distinct folders[^1].
[^1]: ideally from different GitHub user accounts, but I didn't do that for this issue
In `instance 1` of the project, create a main branch:
```
echo "hello" > README.md
git add README.md
git commit -m "first commit"
git push -u origin main
```
Set up git-spice and a stack:
```
gs ri
gs bc branch1 -m "commit 1"
gs bc branch2 -m "commit 2"
gs ss -c --no-draft
INF Created #1: https://github.com/haakon-e/literate-octo-tribble/pull/1
INF Created #2: https://github.com/haakon-e/literate-octo-tribble/pull/2
```
In `instance 2`, do
```
gs ri
git fetch
git switch branch1
git switch branch2
```
now I have local copies of both branches. Next, I want to track the existing stack.
Unfortunately, there is no `gs stack track`[^2], but perhaps I could do `gs branch track` from `branch2`. This executes, but `branch2` now has `main` as its base, which is not what I want.
[^2]: One first-pass implementation of this, could be to check for remote CRs associated with the branch to know which intermediate downstack branches are to be tracked. For upstack branches, you could look for the `nav-comment`.
Instead, I do
```
git switch branch1
gs btr
git switch branch2
gs btr
```
Conveniently I don't have to manually specify `--base=branch1` when tracking `branch2`, nice!
Suppose that a change is pushed to `branch1` from `instance 1`:
```
gs bco branch1
echo "big changes" > a.txt
git add a.txt
gs cc -m "big changes to a.txt"
gs ss
# INF Updated #1: https://github.com/haakon-e/literate-octo-tribble/pull/1
# INF Updated #2: https://github.com/haakon-e/literate-octo-tribble/pull/2
```
Back in `instance 2`, doing
```
gs rs
# INF main: already up-to-date
```
sees no remote changes.
To reconcile the remote force push, I try with the git commands I already know
```
gs bco branch1
git reset --hard origin/branch1
```
If I check `gs ls`, I am now told that `branch2` `(needs restack)`, so:
```
gs sr
# INF branch2: restacked on branch1
```
One caveat of this, is that the git hash of branch `b` locally and remotely are now different:
```
git rev-parse --short branch2
# 43af3f3
git rev-parse --short origin/branch2
# 1b06d3e
```
Let's review our status. In `instance 1`, we have:
```
┏━□ branch2 (#2)
┏━┻■ branch1 (#1) ◀
main
```
over in `instance 2`, the PR hasn't been discovered yet:
```
┏━□ branch2
┏━┻■ branch1 ◀
main
```
If I do `gs ss` in `instance 2`, I get
```
INF branch1: Using upstream name 'branch1'
INF branch1: If this is incorrect, cancel this operation and run 'git branch --unset-upstream branch1'.
INF branch1: Found existing CR #1
INF branch1: Found existing navigation comment: https://github.com/haakon-e/literate-octo-tribble/pull/1#issuecomment-3090263898
INF CR #1 is up-to-date: https://github.com/haakon-e/literate-octo-tribble/pull/1
INF branch2: Using upstream name 'branch2'
INF branch2: If this is incorrect, cancel this operation and run 'git branch --unset-upstream branch2'.
INF branch2: Found existing CR #2
INF branch2: Found existing navigation comment: https://github.com/haakon-e/literate-octo-tribble/pull/2#issuecomment-3090263897
INF Updated #2: https://github.com/haakon-e/literate-octo-tribble/pull/2
```
However, over at `instance 1`, doing `gs rs` simply tells me `INF main: already up-to-date`.
If I do `gs ls`[^3], I am told:
[^3]: I use VSCode, which periodically fetches remote branches, you might have to do `git fetch --all` to see these changes
```
┏━■ branch2 (#2) (needs push) ◀
┏━┻□ branch1 (#1)
main
```
Okay, so apparently `branch2` needs a push. Let's do `gs ss`
```
INF CR #1 is up-to-date: https://github.com/haakon-e/literate-octo-tribble/pull/1
INF Updated #2: https://github.com/haakon-e/literate-octo-tribble/pull/2
```
If I do `git fetch --all` in `instance 2`:
```
From https://github.com/haakon-e/literate-octo-tribble
+ f3962e1...e9a3e06 branch2 -> origin/branch2 (forced update)
```
and `gs ls`
```
┏━■ branch2 (#2) (needs push) ◀
┏━┻□ branch1 (#1)
main
```
now I am prompted in `instance 2` to update `branch2` again, although that branch has no actual changes! But their commit ids are different (due to the force push)
Of course, I can do the same trick as above. On `instance 2`, do: `git reset --hard origin/branch2`.
However, if I make a change from `instance 2`, e.g.
```
echo "big changes to b.txt" > b.txt
git add b.txt
gs cc -m "big changes to b.txt"
gs bs
# INF Updated #2: https://github.com/haakon-e/literate-octo-tribble/pull/2
gs ll
┏━■ branch2 (https://github.com/haakon-e/literate-octo-tribble/pull/2) ◀
┃ 03a3e11 big changes to b.txt (1 minutes ago)
┃ e9a3e06 commit 2 (35 minutes ago)
┏━┻□ branch1 (https://github.com/haakon-e/literate-octo-tribble/pull/1)
┃ 42ad138 big changes to a.txt (29 minutes ago)
┃ aad240a commit 1 (35 minutes ago)
main
```
Over at `instance 1`,
```
git fetch --all
gs ll
┏━■ branch2 (https://github.com/haakon-e/literate-octo-tribble/pull/2) (needs push) ◀
┃ e9a3e06 commit 2 (35 minutes ago)
┏━┻□ branch1 (https://github.com/haakon-e/literate-octo-tribble/pull/1)
┃ 42ad138 big changes to a.txt (29 minutes ago)
┃ aad240a commit 1 (35 minutes ago)
main
gs rs
INF main: already up-to-date
```
the remote changes to `branch2` are not registered, and I am instead prompted to push local changes. And if I do that, `gs bs`, then I overwrite the most recent commit to that branch, effectively deleting the changes I made from `instance 2` to the file `b.txt`.
As far as I can tell, there is no way to reconcile this with `git-spice` commands.
In the case above, note that the hash `e9a3e06 commit 2` is shared across both instances, but `instance 2` has an additional commit that `instance 1` does not have. Because it is not a force push, I can do `git pull -ff` from `instance 1` to synchronize with the remote, and `gs ls` will no longer complain that `branch2` `(needs push)`.
----
As I am writing this scenario, I realize that supporting this workflow may necessitate large, complex changes to `git-spice`. The tool would have to "see beyond" differing commit hashes / states to determine whether the local state is in sync with the remote, or how to reconcile differences.
Beyond collaborating with multiple people on the same stack, the above example illustrates limitations to working on the same stack from multiple of your own devices. Perhaps you have a desktop at work, and a laptop for travel. Or perhaps you have one copy of a project on your local machine, and another copy on a remote server you `ssh` into. Being able to work on the same stack across multiple devices would be an amazing addition to `git-spice`. Happy to discuss details of this further.
Guide de contribution
Ouvrir le guide de contribution
Évaluation
Cette issue n'a pas encore été évaluée.