gitext-rs / git-stack

Stacked branch management for Git
Apache License 2.0
496 stars 19 forks source link

Improve other users branch takeover implicity #232

Closed uloco closed 2 years ago

uloco commented 2 years ago

Please complete the following tasks

Version

0.8.2

Use Case

When another team members branch is checked out locally a git stack command will show that it belongs to someone else, which is a nice thing! But: Checking the branch out and running git stack --pull also automatically rebases this branch against the nearest protected branch. This is great for taking over their work but I find it a bit too implicit. It did happen to me, without knowing and I was just confused if git stack would not respect other peoples branches in general.

See the discussion here: https://github.com/gitext-rs/git-stack/discussions/230#discussioncomment-2996493

Requirements

Never take over a branch without knowing you are doing so. I am usually very careful with my git commands but adapting this as a team is harder if things happen implicitly. We could set a config option how to handle this and check it in with .gitconfig, so it's easier to adapt to the teams workflow.

Possible Solutions

I would suggest a git stack --takeover or similar flag to explicitly take over someone elses branch if it is checked out. Maybe also a config option for to set a default way this is handled for people who want to keep the old behavior. Also I could not find any documentation about taking over other peoples branch in general. We should add some examples / docs here also.

What we could also do is the first time we do a git stack pull for a takeover, the user should be notified that they are taking over this branch, how to revert this and probably where to set some default behaviour.

epage commented 2 years ago

Never take over a branch without knowing you are doing so. I am usually very careful with my git commands but adapting this as a team is harder if things happen implicitly.

Having had more time to think about it, the big issue for me is that this is context dependent behavior which can be confusing, especially if a command isn't run inbetween to show that the branch isn't protected. In theory, the stack display at the end would hint at this and the user can use git branch-stash to restore the old behavior but thats a bit of a mess.

uloco commented 2 years ago

Having had more time to think about it, the big issue for me is that this is context dependent behavior which can be confusing

Not sure if you are talking about the current solution being confusing or the one I suggested...

epage commented 2 years ago

I'm referring to the current implementation. Depending on what is HEAD, commits are protected or not. That kind of context-specific behavior can be confusing.

epage commented 2 years ago

v0.8.3 is released with the new behavior. Note that I opened #235 to further refine this.