4 years ago I was placed on probation for not having the special format in source control check in comments. When I asked, the 'special format' was
clearly documented on page 18, sub-section 4, sub-paragraph 2, "All check in comments will include the solution name, separated by a colon,
and why the code was changed." My check-in comment was only missing the colon. Indecently, over 80% of the other comments consisted of 'adsf',
'bug fix', and several 'BOOM!'s. So I mistakenly said out loud 'This check-in policy appears only to exist to allow management to cherry pick
developers they do not like, find something wrong, and put them on probation.' That comment got on a 30-day ‘corrective action plan’ for openly disagreeing with a
company policy. Today, all those managers were either fired or quit and now I set policy. Dear Mr. ex-Bosses, I won.

The superpower to perform version control on reality. (Git)

Imagine this universe (the current branch), which is made up of a series of events (commits).

Having this ability to allows us to:

- undo events (git reset/git revert)
- reorder events (git rebase)
- transfer to another universe (git checkout)
- derive a new universe from current universe (git checkout -b)
- delete a universe (git branch -D)
- apply an event from another universe (git cherry-pick)

and my favorite:
- merge universes and their events (git merge)

we have to resolve conflicting events, of course.

What else? ;)

Senior Dev at work told me to cherry pick commits from another branch....later found out that it is an actual git command ! 😅

git cherry-pick <commmit>

My dad said I can't be a farmer.
The I did this:
`git cherry-pick b6b27bccc3c6abbf2551a8c4a3e59dd36fc1af18`

We'll he was right coz this is the closest I'm gonna get.
Oh!, wait; I can have a server farm.

Always make smaller commits! Easy to roll back, easy to cherry-pick, easy to debug when identifying when something went wrong.

!rant.
Here's some useful git tricks. Use with care and remember to be careful to only rewrite history when noones looking.

- git rebase: powerful history rewriting. Combine commits, delete commits, reorder commits, etc.

- git reflog: unfuck yourself. Move back to where you were even if where you were was destroyed by rebasing or deleting. Git never deletes commits that you've seen within at least the last 50 HEAD changes, and not at all until a GC happens, so you can save yourself quite often.

- git cherry-pick: steal a commit into another branch. Useful for pulling things out of larger changesets.

- git worktree: checkout a different branch into a different folder using the same git repository.

- git fetch: get latest commits and origin HEADs without impacting local braches.

- git push --force-with-lease: force push without overwriting other's changes

The more i use git.. more the fun it is.. Just found out the usage of rebase and cherry-pick.. I have read about the implications of these commands in a shared repo.. But it is fun to use it in a solo repo..

When I asked to Experienced Senior about cherry pick command in git.

I got 30 Minutes big lecture about Parent-Child Node.

But Cherry Pick, He did not pick for explain. 😡

Source tree opened

Finds new option 'cherry pick'

Wtf is this

Clicks on it

Wooow, there goes my master branch again

When you git cherry-pick for the first time, screw up, rebase-drop, repeat, screw up again, and end up just pasting the correct versions of the files and commiting on top of the branch.

Dirty, but it works.

let me preface with the fact that I'm now known at my new job for being the resident cli hipster. I can't lay any claims to knowing if it's "better" but I like it, I don't care if you do or don't, it just works for me and my flow

so at my job, we generally squash all our commits into one commit and delete the source branch upon merging; i accidentally committed all my work to an old, already merged branch, so my boss tells me it would be more of a PITA with the weird references we would encounter by merging the branch again, rather than just cherry pick the commits into a new branch, which i'm like "eh, fine.".

HIM: "You want to share your screen so we can resolve this?"
ME: "k"
HIM: "Oh, you won't be able to do this in a terminal, you are going to have to load up a GUI of some sort"
ME: "lawlz, no you don't"
HIM: "i highly doubt you will be able to accomplish that, but if you wanna make an ass of yourself, i'll humor you"
ME: "yeah, watch this"

> git log > log.txt
> git checkout <new branch>
> git cherry-pick <copy-paste-full-commit-hash-here>
> git push

ME: "done"
HIM: "what? there's no way you did it that easily, where are all your other commits???"
ME: "i usually try to amend my commits since we squash them anyhow. it really helps in situations like this"
HIM: "well, you go girl"

roll that up in your fancy degree and smoke it, why don't ya?

Just explained 3 senior devs what cherry-pick is.
Dunno if I should quit or get them fired.
Thoughts?

There's like one guy in the office who actually knows anything about the software we sell. It's a mess of bolted together chunks of code from different client projects (that the clients have paid for and continue to pay a license fee for) we just cherry pick the best bits and repackage it for the next release.

Some things never change

> Have to deploy only one feature to production
> Create branch from latest tag, cherry pick the correct changes
> Mess up merge
> Almost deploy resulting broken code to production
> Realize at last moment
> Let out a loud sigh, start over

Every damn time.

<sanityCheck> //asking for a friend

Some clever b*****ds wrecked a section of our production mysql db. To fix it I need to rollback the affected records 2 weeks - around 50/300 tables are affected, the other data must remain intact.

Currently my plan is to take a 2 week old dump and cherry pick the data I need from it, then combine it with a dump of the db in it's current state, drop the db and recreate it.

I know this approach will work - but it's risky, a pain in the ass and dealing with 300mb text files is tedious so since I only need to start in around 8 hours I figured It wouldn't hurt to post my approach and see if anyone thinks my plan is borderline retarded.

If you have any advice .etc that will make my life easier I would greatly appreciate it.

So in your opinion...

- is there a better/safer way?
- do you know of any db dump merge tools?
- have a recommended (linux) text editor for large text files?
- have you made any personal mistakes/fuck ups in the past you think I should avoid?
- am I just being a moron and overthinking this?
- if I am being a moron - In your humble opinion has the time come for me to give up all hope and pursue my dream of becoming a professional couch surfer?

</sanityCheck>

Note: Alternatively, if your just pissed that my rant is asking for a solution instead of simply trashing the people that created my situation and your secretly wishing it was on SO where it belongs so you can moderate/edit/downvote/mark the shit out it, feel welcome to troll me in the comments (getting dev advice just doesn't feel reliable without a troll - you matter to me). Afterwards If your panties are still in a bunch I'll post it on SO and dm a link to you to personally moderate - my days already fucked and I wouldn't want to ruin yours too.

Sitting in a bar with a senior colleague (Me - Student part timer, Him - 15+ Years of experience).
We started talking about our projects and he mentioned that after this, he'd get to spend his evening fixing a git merge, which went wrong because one of his teammates used cherry pick and thus messed up the history a bit (oversimplified).
So he tells me he'd be spending hours to get an overview of his colleagues codes (multiple devs and only team leader knows who does what exactly).
So I suggested he revert these cherry picked commits and so could maybe solve the problem in less time.
He thought about it... Told me HE didn't think of that and thanked me for my help.

Long story short: Today was a good day :3

Git Cherry-Pick is the discovery of the century 😳

Today's the day I realized my branch was better off if I just restarted from master and cherry-pick the commits I liked from the old one. This is what I get for the branch hanging around so long.

Lesson of the day: Merge early, and merge often.

FFS,
Team have a release candidate of code ready for a deployment but because a dev added functionality them deem should only be released in two weeks we have to cherry pick this chunk of code out,

yes other code now depends on this and is affecting lots,

FML wanker customer/QA team,
be happy that you are getting functionality early.

Git cherry-pick 35 commits, another dev commit to the wrong branch, and these commits will be released first

is it necessary to have cherry picking a part of git branching/release process?

we have 3 branches : develop, release and master.

currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.

so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :

1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.

2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x

3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release

4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.

so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.

for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.

what do you folks suggest?

It's too early to be asking these questions today:

Are your DB schema changes checked into source control?

What branch are they checked into?

Why are the schema changes checked into one branch, but deployed to a completely different database?

Is my CI pipeline deploying incorrectly? Oh, you manually deployed changes.

Are your DB changes in source control an accurate reflection of what you actually put in the staging database?

Why not?

Can I just cherry-pick update my schema with your changes from the staging database?

Why is there a typo in your field name?

Oh. Why is there a typo in the customer data set? Don't they know how to spell that word?

Why is the fucking staging database schema missing three critical tables?

Is the coffee ready? I need coffee.

Why is the coffee not ready yet?

What's going on in DevRant this morning?

What project am I working on now anyway?

Did my schema update finish yet?

Yup, it finished. Crap. Where the hell do I keep those backup files?

What's the command line to restore the file again?

Why doesn't our CLI tool support automated database restores?

I can fix that. What branch name should I check the CLI tool into?

What project was I working on this morning again?

(!rant || git)

Non-techy friend (n): you know what cherry pick is?
Me: cherries?
N: you dont know that?
Me: well, i love cherries...
N: i am disappointed of you.
Me: what the f...ing hell is that?
N: you know the git thingy you are always doing...
Me: i have never heard of that...
N: well use it every time before and after you commit.
Me : (not believing, but kinda believing) ok.
A few days later...
Me: nnooooooooooooo.!
Messed up 3 hrs of work

-------------------
What really is cherry pick guys?

You should produce
shirts that are boldly written ”Git Cherry-Pick Saves!”.
It has redeem me from messed up conflicts. conflited files = 89.
How the fuck am I going to review 89 files, when deadline is just two days from now.

git cherry-pick -n <commit>

The "-n" is alias for "--no-commit" and it applies the content of the target commit into your working directory without making any commit. Usefull if you want to cherry-pick many commits, tweak them and make a new one or simply want to grab some functionality into your index.

What's yours well-appreciated but not-that-well-known git functionality?

Cherry picked my first commit today, am proud.

Luckily I'd done all the work for a develop MR in 1 commit and could just cherry pick the 1 commit into master.

Not sure how I'll go with a commit range lol

I have a git feature branch with my commits but also have merged the changes from the main branch to resolve merge conflicts before PR.

But now need to create a special release with just my changes.

So I think have to cherry pick all my commits on my branch some the last Release. How can I do that?

Develop (others) + Feature => Develop

Want to create new branch

Last Release + Feature (but only my commits since last Release)

Just installed Visual Studio Code on my fresh machine and finally got the chance again to cherry pick extensions and themes :D

What Extensions and Themes have you installed and which do you frequently use?(doesn't matter for which programming language)