Show what branch we cherry-pick'd from

[pgporada]

This produces a prompt as follows. This helps me in my day to day workflow to know what I cherry-pick'd from.

[phil@myserver ~/work/somerepository] on master△ [cherry-pick from SOME_BRANCH_NAME]

[rpdelaney]

What if the last commit message from another branch contains an asterisk?

[pgporada]

@rpdelaney good point, 1 moment

[rpdelaney]

The code seems fine. I know Todd will want tests though. :)

The remaining question is how we feel about introducing a dependency on awk. Awk is pretty ubiquitous, but not everyone has it installed.

[twolfson]

Thanks for the suggestion. I have mixed feelings about this feature as it adds extra content to our prompt when nobody has asked for it up to this point.

Additionally, it goes on tangents like:

Not exclusive to branches

Cherry-picks aren't exclusive to branches. For example, when I use them it's typically for a commit range (e.g. git cherry-pick abc123...def456) which is to pull a set of changes from 1 branch to another.

That being said, I'm going to guess there's only 1 cherry-pick going on at a time and git somehow queues them up

Similar progress actions

If we add support for cherry-pick, then we'll likely need to add support for all our other progress actions since they're in a similar vein (e.g. rebase from <ref>, merge from <ref>).

---

With respect to awk and git branch, there's probably a more efficient way to do that leveraging the CHERRY_PICK_HEAD but let's first determine if we want the feature/not. I think the course of action is to set up a mock prototype and see how it feels (e.g. hardcode it or toggle via if/else environment variables).

I don't have time to do this at the moment but I'll take a look at it by Sunday (probably sooner)

[twolfson]

Took a shot at the prototypes. They can be found here:

https://github.com/twolfson/sexy-bash-prompt/blob/3bd876b1f10606e4a18011aa6da2a14ecf3c1a45/.bash_prompt#L117-L163

Here's the before:

and here's the after:

I have mixed feelings still. It definitely adds value but also it starts entering a "2 line prompt" territory which I would like to avoid. I'm going to take time to think about it some more. Other opinions would be appreciated

[pgporada]

Possibly a flag could be added that enables turning this verbose mode on/off with it defaulting to off. The job I have is the first one where I've ever dealt with rebasing and cherry-picking so the more info the better, to me.

[rpdelaney]

It seems unlikely to me that anybody with severe terminal width constraints (say, 80-120 columns) would be using sexy-bash-prompt in the first place. It's already a verbose prompt. That said, there should be some practical limits on just how verbose the prompt should be. But where should we draw the line, exactly?

[twolfson]

@rpdelaney I'd say that while 80 characters might seem silly from a coding perspective, I think it's still within reason for a terminal itself.

In my own case, I use a small font size and half-monitor width terminal typically which allows up to 105 characters. If I didn't want to strain my eyes as much or were presenting, then I'd likely have a larger font size and be closer to 80 characters.

@pgporada An environment flag is totally within reason although for one-offs in the past (e.g. syntax changes), we've asked people to fork instead. An environment flag might be better here due to the amount of edge cases (e.g. commit vs branch, different git versions)

The downside for us would be adding more code to test/maintain with possibly not so many people using it

[twolfson]

After taking some time to think about it, I'm going to lean on the side of not adding this functionality for now. I don't think the value is frequent enough in the general case to risk going over line limits and adding extra code to test/maintain

That being said, we've seen a number of forks with one-offs so maybe we should start a list in the README or something /cc @rpdelaney