Github: Git context management

[wadethestealth]

Summary

This feature would allow users to select the current active project without interacting with the UI elements

Motivation

Specifically, it is a shortcut to speed up workflows and allow for better efficiency when switching projects is often required or desired.

Describe alternatives you've considered

Currently, there is no shortcut for switching projects.

Current Ideas In Running:

1️⃣ Bare minimum change idea (suggested by @wadethestealth):

Have a command that auto-focuses and expands the current select project list, and then use arrow keys for navigation as normal.

2️⃣ New dependency change idea (suggested by @aviatesk):

Have a command that opens an atom-select-list. This adds a new dependency, but it is still an atom package so its really nothing. On the plus this also allows for searching via type, which can become beneficial when working with lots of projects.

3️⃣ Facilitate old workflow idea (suggested by @smashwilson):

Have a command that uses the active center pane and switches to that context. This would facilitate the old workflow before #2308, but this time it is user determined rather than guessed. This could also be extremely efficient because there is no navigational component to this idea it just automatically know which project you are looking for.

4️⃣ "Active" dropdown item (suggested by @mattlyons0):

Add a dropdown item to the top of the list called Active (${projectName}), where ${projectName} changes to reflect the project that owns the active pane item. When chosen, context follows the active pane item. When other projects are chosen from the dropdown, they "stick".

5️⃣ Configuration option to follow active pane item (suggested by @mattlyons0):

Use a package configuration option to disable the project selection dropdown and instead follow the active pane item.

Additional context

Original discussion and light discussion that brought up this issue

[wadethestealth]

I personally think 3️⃣ is the best considering project history and previous workflows.

However I could see the case where you have 10 projects open or say we also duplicate entries for each remote that was also discussed here, which makes searching a clear benefit (ie. 2️⃣).

I even think you could implement both and be just fine.

[aviatesk]

I personally think 3️⃣ is the best considering project history and previous workflows.

yeah, I agree with that 3 might be the best for us, since it can kinda substitute the previous behaviour and we may be able to reuse the previous logic, I guess.

As for a searching functionality (which is great to have imho), actually we don't need the new dependency (like atom-select-list, which depends on etch, not react), but rather I guess we can use react-select's isSearchable option (and react-select is already in our deps).

[aviatesk]

I also want to ask you guys for allowing to switch to a repository via the option 3, even if it's outside of a current project.
I think as far as an user intentionally switched to a repository (even if it's not in a current project), it won't be confusing but just be useful.

[wadethestealth]

@aviatesk just based on the code that handles this, I think it will automatically do that with no trouble. However @smashwilson informed me it is an expensive operation. I will look over the old code and see if outside files were considered, because I think mirroring old functionality is better than adding new. I think if users plan on using the GitHub tab they should add the files project to their open projects, but I understand that you are trying to cover quick file edits.

[smashwilson]

Restoring some of the comments from the merged pull request:

@mordash:

Hi,

is there an option to disable this list ?
It really is not cool when working on several projects at the same time.

Best regards.

@wadethestealth:

@mordash currently no, but there is a pr not merged that adds a shortcut to switch to the git project of the current file you are in, it's this shortcut is supposed to both facilitate old behavior and make switching easier. We know it is cumbersome for multiproject workflows, but the change was necessary to remove confusion on how project selection worked.

@mattlyons0:

I do not believe any of the options listed in #2335 are sufficient to make the new behavior as good as the exiting behavior was.

If you are switching projects quickly finding the currently selected project from a dropdown can be difficult, especially with many projects open. Adding a shortcut to open the currently selected project is a nice step in the right direction but it is still an extra step from before.

I have added a setting to restore the old behavior of selecting the project based on the active panel in #2393 . I like this option because it gets around the confusing aspect since it is an opt-in experience and disables the dropdown but keeps it visible showing the current project name.

That said it is possible in addition to this solution adding a command to select the current project still has value for users who do not want to go all the way of enabling this new setting.

@wadethestealth:

@mattlyons0 I'm sorry you feel this way. The main reason for the change was because the old way was extremely user unfriendly, and instead of adding an option to maintain the old version and the new version, we opted out of keeping the old version in to reduce technical debt and code complexity as the old decision algorithm used guessing what the user wanted rather than explicit choice. This is not to deny your or, but rather to explain the context around the situation and some of the relevant to your case avenues of the many avenues discussed. Thank you for the feedback on this change as well.

@mattlyons0:

@wadethestealth The old behavior can be conditionally added with 19 lines of code in a single file as I have done so in this commit: 08aef18

I do not see that as a large amount of technical complexity to maintain a feature that is notably useful for users working in multiple repositories. This has only been released for 4 days (in Atom Stable 1.43) and already 7 users have found this several month old pull request indicating they would prefer the old behavior.

I don't think the old behavior is for everyone but it certainly has value for power users, of which I think Atom definitely has a lot of (given a major difference between Atom and VSCode is its flexibility). Putting this behind a configuration setting at the cost of merely 2 functions of additional technical complexity added seems like a valuable addition to me.

@wadethestealth:

@mattlyons0 it has only officially be released this long, but it has be in the nightly for a while. Also there will always be back lash to change in any degree. There are also a lot more atom users than 7 and of course people frustrated with the change are a lot more likely to seek out this pr and comment. That being said you provide fair points. I am not a maintainer of this repo and this change is a very old todo from a group of the previous maintainers. Ultimately the decision comes down to @smashwilson or an official atom team member.

@jarvelov:

Another user in favor of the old autoselect behavior here. I thought this was a bug introduced in 1.43. I don't see why we can't have both the git repo select and the old autoselect functionality. If this functionality can be implemented in the 19 lines of code @mattlyons0 I don't see how that code is complex and the feature is very valuable to me.

I, not being hyperbolic, always work with multiple repos and have to switch between them a lot and now to have to manually change the git repo adds another step for me that I previously didn't have to do.

I'm fine with it not being the default behavior but please add back the old functionality as a configuration setting.

[smashwilson]

Okay, now for my two cents. I've been out of the loop on this project for a little while - GitHub-the-company doesn't have work on this package prioritized in the near future, so this is now something I tinker with in my free time as opposed to my day job, and open-source time waxes and wanes.

The way that projects were switched automatically was a source of long-standing user confusion that we'd observed in a variety of contexts pretty much since the day this was released. The context tiles that @wadethestealth implemented are the first step toward an attempt to address this. If you get the chance, read over the feature request writeup in #1934 for the full scope of what we're thinking about, and to leave us feedback _before_ the rest of these changes hit Atom stable :wink:

For me, the primary goal of the context tile is to give you some kind of visual feedback about which project you're working in before you do any git operations. (I used to make new git branches in the wrong repositories _all the time._) Being able to switch between them explicitly, for me, was a useful side effect. So personally I don't feel strongly about _not_ following the active pane, and I'm rethinking my position here.

I wonder if it would be best to just always follow the active pane again? The context tiles provide visual feedback that git operations are happening in a different repo now, which is the main thing that was missing before. 🤔

[aviatesk]

I wonder if it would be best to just always follow the active pane again? The context tiles provide visual feedback that git operations are happening in a different repo now, which is the main thing that was missing before. 🤔

Fair enough. Allowing switching repositories in that way would just give us more flexibility for git operations.

FWIW, do we need to consider the performance issues with the previous behaviour that @wadethestealth stated in #2346 ?
I don't have any benchmark but still think we can _accept_ that since we've done so until now.

[smashwilson]

As a quick update, I haven't forgotten about this, I'm just having a really hard time weighing the relative usability of the different options in my head 😅@mattlyons0 has been making some good exploratory progress in #2393 (🙇) but I'm not sure we've found the sweet spot just yet. I'll edit the alternatives he's been pursuing into the description here for discussion.

There's a really thin line to walk here between "not surprising new users" and "behaving gracefully for users with many open projects."

Also, for a little bit of context, I am personally pretty biased against adding package settings when we can possibly avoid it because:

1. Package-specific settings in Atom have really poor discoverability. Most of the users who would benefit from the change in behavior will never find out that they could have it.
2. Virtually every new feature we have added, or change we have made, has prompted an immediate request to "make a new setting that turns it back to the way it was." You're always breaking _someone's_ workflow! (Also, I should consider writing this up in docs/ somewhere... hmm.)
3. Adding configuration settings for everything is often a design cop-out to avoid having a deep understanding of the ways that people use your software. Specifically: the fact that you (and some others) want one for this feature means that I had an insufficient understanding of the impacts to your workflow before we shipped this!
4. The existing configuration options are mostly related to diagnostics and performance monitoring so they're already pretty scattershot and not very useful. I'd like to clean those up before we make it worse.

So new package configuration options have a pretty high bar for me to sign off on.

[wadethestealth]

I think point 2 is always massively overlooked. Because of this nteract/hydrogen has a ton of random options. I remember when Snapchat updated UI and people said Snapchat was going to crumble, however it's still popular. I think changes just take time to get used to. I do think that multiproject workflows are massively cumbersome right now, and I think short cuts to switch projects like switch to active pane or switch to previous or switch to some bound directory is a great solution because it makes the user think yes I want to switch right now vs an active pane switch where if you change git projects to check source or something didn't necessarily mean you wanted to view the git. Also with the select now you can view the git with no open active panes and switch between them without ever opening a file. It is also my opinion that short cuts aren't cumbersome as they are a regular part of effective computer navigation. I am unsure of where my biases come from, but these are just some of my thoughts on the changes.

[mordash]

have you ever tried to work on 30 projects at the same time with this list?
if you try you will understand why we need to go back to the old configuration.
listen to your community a minimum...

[jarvelov]

My vote is for, in order of preference:

4

It makes the most sense to have it visible in the select and the stick part of this suggestion makes for the best UX.

5

Won't be as available to new users as 4 but at least users preferring the old behavior and new power users can enable it.

3

It makes for an even worse UX to just bring back the old behavior as this makes the select rather useless, unless there's some logic to make a selected project stick until.. some condition is met. Don't see how this won't be confusing.

---

What I liked about the old behavior:

When I switched to a file in another project the git context switched. I really liked this as my mental context was already in that context and I could quickly evaluate all things related to that context at a glance.

I think the list is a good addition and I want it to stay, however if anything I think it complements the old behavior as it gives another visual indication that the context was switched, as well as being a tool to allow you to switch just the git context.

Today I've been jumping around between 6 different projects, where 4 were open in my editor when I got to work and 2 were added during the day. Given that the select sorts the options in the order the projects were added it can be difficult to find the correct project if you don't remember the order you added them in. This can be fixed by sorting the options alphabetically but it's just extra mental overhead overall to even take it into account when I've already mentally switched context. This is just my personal preference but I wanted to share my view.

I like that you can view the git context separately even if I personally wouldn't do that very often without the context of the source file. However I don't think I want to view a source file without the git context.

The git context tells me what branch I am looking at, what previously happened in that project (git log) and what changes have been made to the project. This info makes it very easy to assess the current situation of the file in relation to the project. As of now I have to open the file and then select the git repo.

Another suggestion

This is kind of like suggestion 4 but another approach.

Variant 1

How about adding a button next to the select to lock the current git context? When locked the currently selected git repo won't change when a file in another repo is selected. Something like this:

Note, there was no unlock icon among the available icons, so just imagine the greyed out one is an unlocked button

Locked state

Unlocked state

Variant 2

In variant 1 when the icon is locked it would make sense for the select be disabled. However, given another icon we could keep the select enabled and have the switch be between M and A, manual and automatic.

Note, I'm just reusing icons already available, I think some additional thought needs to go into the design of this

Automatic state

Manual state

When in manual mode the selected git repo option from the select is what is used for the git context. If automatic is enabled the selected option in the selected is automatically updated, but the user can still select another option.

There are two ways this can play out from here:

• Switch to manual mode
• Keep the user's selected git repo until a pane from another repo is active and switch to that
  
  
  
  • This might be useful to "peek" into another git repo, maybe to just open up a modified file, but I can see this as being confusing.
  
  

Thoughts?

[wadethestealth]

I love variant 1! This way we can also add a tooltip with a slight explanation.

[smashwilson]

Yeah! I love the lock idea (especially variant 1).

• We can do this in addition to adding command-palette commands to navigate contexts, so there's still a mouseless way to navigate even if the lock is on. I believe the two play together nicely.
• Should we automatically engage the lock if you choose a project from the dropdown? Or would that be too much magic? I'm thinking that would be too much magic.

[jarvelov]

Yeah! I love the lock idea (especially variant 1).

Great! Can I help in any way to bring this feature into existence? I.e. would you accept a PR which implemented this?

* Should we automatically engage the lock if you choose a project from the dropdown? Or would that be too much magic? I'm thinking that would be too much magic.

Yeah I think that's too much magic as well.

[Aerijo]

Should we automatically engage the lock if you choose a project from the dropdown?

IMO, the lock should be independent of interacting with the dropdown. So:

• The user is always allowed to change using the dropdown. They are unlikely to accidentally change this, and so preventing them changing it while locked is just an arbitrary restriction.
• If the lock is engaged, then the active project is fixed to the current, and then what the user selects with the dropdown.
• If not engaged, the active project is the most recent of whatever-the-original-behaviour-was or the dropdown they selected.

This way the original behaviour is restored + it can be temporarily overridden without needing to open a file just for that (keep it unlocked), and the new behaviour is present (keep it locked).

[wadethestealth]

@Aerijo I was thinking the same thing, but you worded it much better than I could have

[smashwilson]

Great! Can I help in any way to bring this feature into existence? I.e. would you accept a PR which implemented this?

Yes, absolutely. I actually started tinkering with it a bit yesterday but we can race 😂At this point I'm not working with much of an advantage anyway... it's been a while since I've worked on this, and GitHubProject specifically is kind of a mess.

[wadethestealth]

For those of you racing (@smashwilson and @Aerijo) The previous active pane tracking is mostly located in the deleted section of #2308 in the lib/github-package.js file

Edit: Also you will need to add the lock to both the git-tab-view and github-tab-view.

[jarvelov]

Great! Can I help in any way to bring this feature into existence? I.e. would you accept a PR which implemented this?

Yes, absolutely. I actually started tinkering with it a bit yesterday but we can race 😂At this point I'm not working with much of an advantage anyway... it's been a while since I've worked on this, and GitHubProject specifically is kind of a mess.

Hehe, it won't be much of a race if you've already started and given that this is a new codebase for me I don't feel like I'll catch up to you even if I try! However, if you stop working on this for some reason then tag me and I'll give it a go!

[abumusamq]

do we have a way to disable this? very annoying, i manage multiple git projects and auto-selection was very handy

(from release notes)

Explicitly display and choose the active git working directory in the Git and GitHub tabs.

[smashwilson]

@abumusamq: You can (temporarily, I hope!) downgrade the GitHub package:

apm install [email protected]

Then add "github" to "Version Pinned Packages" in your core settings to disable the prompt to upgrade.

You can also read the rest of this thread - we're actively working on a way to restore "follow active pane context" in a way that _also_ visually shows the current context and allows you to change it explicitly.

[smashwilson]

The context lock button (with context-follows-active-pane-item behavior when unlocked) has been added in #2399 and published in atom/[email protected]. It'll be bundled with the next beta version of Atom and in nightly builds starting with tonight's (1.45.0-nightly5).

It won't be in Atom stable until the release after next... _buuut_, if you want to take it for a spin beforehand, you have a few options.

• Try running on the Atom nightly channel! It's quite usable - I use it day-to-day, even though I'm not "officially" working on the Atom team any more. This is also a great way to give us feedback about upcoming feature implementations _before_ they ship to every Atom user... and if something _does_ cause you grief, you can file an issue and drop back to beta or stable. The more people we have on our nightly and beta channels - representing a broader cross-section of workflows and backgrounds and habits - the less likely it is that a feature will make it out to stable with these kinds of hitches.

• If you really want to live on the bleeding edge of GitHub package work in particular, you can install just the GitHub package from the master branch:

  apm install atom/github
  

  This will update every time we merge anything here.

I'd really appreciate anyone who lives with the context-lock changes for a while and helps us validate them and shake out any other breakage, especially before it hits stable 🙇 I did my best and we have good test coverage, but no test suite survives first contact with real users :wink: