installer: refine git pull behavior text to prevent misconfiguration

[jzbakh]

Description

The previous phrasing of the git pull behavior defaults could lead to unintended configurations of the pull.rebase vs pull.ff parameters in the global .gitconfig. This PR refactors the text to introduce strict mechanical representations of the git state machine. The goal is to reduce ambiguity concerning commit graph resolution and align the UI text with current upstream defaults.

Technical Scope

• Textual and UI Layout Update: This modification strictly targets the strings passed to the CreatePage and CreateRadioButton functions for the GP_GitPullMerge, GP_GitPullRebase, and GP_GitPullFFOnly options.
• Added Label: A standard TLabel (LblInfo) was added at the bottom of the page to clarify how Git handles file conflicts.
• Logic Intact: No underlying Pascal Script conditional logic, registry parsing (ReplayChoice), or silent install vectors were altered. The internal component IDs remain untouched.

Visual Regression Testing

Before	After

Signed-off-by: Jason Zbakh jzbakh@gmail.com

[jzbakh]

Reopened: head repository restored after accidental deletion.

[dscho]

Hmm. I'm not sure that that wording is any clearer. Maybe a better idea would be to add a page on gitforwindows.org and then to add a footer to this installer page that links to that documentation? That way, there is a lot more space to work with.

[jzbakh]

Makes sense. I'll write a doc page for git-for-windows.github.io and ping you on a draft PR.
For this one:

• Let me know if I should keep any part, otherwise I'll close it.
• Or leave it open, and I'll repurpose it later as a minimal PR with just a footer note like "Need help choosing? See [link to docs]." once the docs page lands.

[dscho]

• Or leave it open, and I'll repurpose it later as a minimal PR with just a footer note like "Need help choosing? See [link to docs]." once the docs page lands.

I like this option a lot!

[jzbakh]

@dscho I'm currently working on the documentation page we discussed, and it got me thinking about the installer screen again.

I completely agree with your previous feedback: my first version with the diagrams and the note on conflicts was too dense and unclear.

However, I feel there are still a few issues with the current installer text:

1. The option titles might imply that choosing "Rebase" prohibits fast-forwarding.
2. The descriptions are very repetitive regarding the "fast-forward" concept. Option 1 explains it, and Option 2 (Rebase) tries to explain that it also fast-forwards when possible, but uses slightly confusing wording ("If there are no local commits to rebase, this is equivalent to a fast-forward").

Currently, the top of the screen displays two lines:

• "Choose the default behavior of git pull"
• "What should git pull do by default?" (which is quite repetitive).

This is exactly what initially prompted me to propose an improvement.

If we replace that second line with: "A pull always attempts a fast-forward first.", the context would become clearer, avoiding the need to explain fast-forwarding for each option.

We could then align the option titles with the internal variables (Merge, Rebase, FFOnly) and significantly simplify the descriptions:

• Merge: Create a merge commit to combine branches. This preserves the exact history of parallel work.
• Rebase: Rewrite your local commits on top of the remote branch, maintaining a single, linear timeline.
• Fast-forward only: Safely abort if a fast-forward is not possible.

I just wanted to see if you agree with this approach. If so, I can use these exact headings and descriptions while writing the documentation page. What do you think?

[dscho]

@jzbakh sure, that sounds reasonable to me!

[jzbakh]

@dscho I've updated the PR and organized the changes into two distinct commits to keep the history clean and logical:

1. installer: add documentation link to git pull behavior page: Adds the footer label that directs users to the external guide.
2. installer: improve wording of git pull behavior options: Implements the simplified titles (Merge, Rebase, Fast-forward only), concise descriptions, and updates the top context line ("Pulling always attempts a fast-forward first.").

In parallel, the corresponding documentation page is now drafted and ready for review here: git-for-windows/git-for-windows.github.io#92

Let me know if this implementation aligns with what you had in mind :

Visual regression testing

After Commit 1 (Documentation link added)	After Commit 2 (Wording improved - Final state)

[dscho]

Nice!

[dscho]

I am a big fan of the principle to separate concerns into separate commits. In this instance, the change to allow for no experimental options is separate from the change to describe the git pull options better.

However, I don't want this split to be a blocker for this PR, so I'll merge it as-is.

[dscho]

Sorry for missing -rc1 with this, but it'll be in -rc2!

[jzbakh]

@dscho Thanks for the merge and for getting this into -rc2!

Regarding the #ifdef lines: my mistake. My apologies for the extra noise !

[dscho]

Thanks for the merge and for getting this into -rc2!

Thank you for the contribution!

Regarding the #ifdef lines: my mistake. My apologies for the extra noise !

No worries, I could easily have fixed it if it had been important.