Prepopulate branch name in FormCreateBranch

[mstv]

Proposed changes

• prepopulate the branch name in FormCreateBranch with the first branch or tag at the current revision
  It can be replaced easily because the whole string is selected.

My use case:
I often create temporary copies of branches before rebasing, squashing or fetching force-pushed branches. I don't want to search the ref log.

Screenshots

Before

After

Test methodology

• manual

Test environment(s)

• Git Extensions 3.3.0
• Build d6096c4
• Git 2.24.1.windows.2
• Microsoft Windows NT 6.2.9200.0
• .NET Framework 4.8.4121.0
• DPI 96dpi (no scaling)

---

✒️ I contribute this code under The Developer Certificate of Origin.

[gerhardol]

Works fine

[RussKie]

Could you please provide rationale behind this FR?

[gerhardol]

When you want save a test/temp commit on what you are working on or you want to save a temp branch before a rebase (easier to find than using reflog or a tag).
I will use this several times a week.

[vbjay]

Instead just commit with wip in subject then when ready to cleanup just go an interactive rebase on the commits being cleaned up. You can squash or fixup or reword. You can also right-click a commit and tell it to create a fixup commit. Interactive rebase will autosquash.

[gerhardol]

Instead just commit with wip in subject

I use that as well as stash (should name them though). It all depends on what I am doing, how the changes are expected to be useful and if they can be merged or not.
At work, often xml files are changed that normally cannot be merged at all, often cannot be diffed either where WIP is impossible.

[mstv]

Could you please provide rationale behind this FR?

From issue description:

My use case:
I often create temporary copies of branches before rebasing, squashing or fetching force-pushed branches. I don't want to search the ref log.

[vbjay]

I usually create a local tag if I think I might have a hairy rebase. Then I just right click one commit in history and do an interactive rebase. I leave branches for seprate work. If it gets weird, I just abort and try again.

[mstv]

You still must give it a name. Extending the current branch (or tag) is a good default IMO.
I often enough abort. Though if there are merge conflicts, it is good to be able to compare everything afterwards. I often have plenty of merge conflicts when updating modules with project-specific configuration.

[mstv]

@msftbot merge in 1 day

[ghost]

Hello @mstv!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

• I won't merge this pull request until after the UTC date Tue, 07 Apr 2020 22:22:18 GMT, which is in 1 day

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".