Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • thg-hgtk thg-hgtk
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 520
    • Issues 520
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • mercurial
  • TortoiseHg
  • thg-hgtkthg-hgtk
  • Issues
  • #217

Closed
Open
Created May 12, 2009 by Bitbucket Importer@bitbucket_importerOwner

Usability issues may leed to wrong sync

Created originally on Bitbucket by Anonymous

In the synchronize dialog we have experienced that users did things they did not want to, which may be avoided by changing the dialog.

  1. The "Default pull"/"Update to tip"/"Do fetch" choice should be saved on a per repository basis if possible. Not general. Also it should not be hidden behind an arrow, but be clearly visible so the user can see what happens when you press "Pull".
  2. The force pull or push choice should be saved on a per repository basis if possible. Not general.

Motivation:

When you have a long lived project in a local repository you often don't want to commit it before its done (not even locally). But you want to pull and merge the newest changes to it. If you have another repro where you have done a fetch last time, this setting is saved and used if you press pull in your long lived project, hence you get a commit that you don't want. Very easy to do by accident. This is why it should be clear what the pull button will do, and it would be nice to have it saved on a per repro basis.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking