|
|
ha ha, nice try  .
Fortunately it doesn't look like I'm becoming bald anytime soon 
|
|
|
|
|
A set of clippers could soon fix that.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
Paris in the cellar
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Debbie vs Jason
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
|
The Elephant Man
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Mmmmhh, a movie with a mask ? The Mask ?
|
|
|
|
|
Hey now!
Software Zen: delete this;
|
|
|
|
|
Easy one today:
Artillery regiment crazy about Queen (7)
Slogans aren't solutions.
|
|
|
|
|
Battery.
Crazy - batty
about queen - ER.
Andy B
|
|
|
|
|
That's the one. Well done.
Slogans aren't solutions.
|
|
|
|
|
Why is Queen "ER"? just curioous. I thought it would be "Q".
"This new learning amazes me, Sir Bedivere. Explain to me again how sheep's bladders may be employed to prevent earthquakes"
|
|
|
|
|
Elizabeth Regina, it's on all the UK currency, postage stamps etc. but it might not be obvious to a non-uk person.
|
|
|
|
|
Actually it should be EIIR. No wonder I couldn't solve it. 
|
|
|
|
|
Slogans aren't solutions.
|
|
|
|
|
Sorry, yes, a tad parochial of me (we Brits tend to specialise in that).
It's a standard substitution in UK crosswords so I just used it without thinking. Sometimes I forgot that our queen is no longer the queen of the known Universe.
Slogans aren't solutions.
|
|
|
|
|
I have a problem with working with multiple branch (like we are doing now) not very good with Git branch/merging.
What happened is, I was working on the dev branch and did lots of fixes, including some serious bug / crash fixes.
Meanwhile there are some issue on the production / release branch, which have been independently fixed.
But some serious problem remains and I was asked to fix the prod branch.
It just so happen that many fix needed were already done on the dev branch, but they don't want to deploy the current dev branch until it has been tested/validated (despite the dev branch being only bug fixes at this stage), hence the release branch has been diverging on its own and now I am duplicating fix, fearing some slight change in how I rewrite the fixes might cause merge issue later....
How do you cope / handle such situation?
Are we doing something wrong?
|
|
|
|
|
I'd say that it was a bad idea to push changes directly onto the release branch if someone else was working on related code. That's going to cause merge conflicts. It happens but you should try to avoid it. You can use git merge --strategy-option theirs to resolve the conflicts when you merge prioritizing any changes on the release branch, or git merge --strategy-option ours to prioritize your (the dev) branch.
If some of your fixes rely on the same code that was changed in the release branch though you might have issues and should consult with the team about overwriting the release changes with yours (assuming your fixes are equivalent to the release fixes). My 2 cents.
EDIT: Also, is this an open-source project? I find it odd they would force only your code to be validated/checked while they're pushing changes directly to the release branch with no regards to other branches.
|
|
|
|
|
Nah it's for work.
I had a long list of bug and feature to work on.
Meanwhile the release / pilot product had issue (hey those were on Jira) and some independent fix were applied on that production build.
For the simple reason they wouldn't want to deploy (untested / unvalidated) feature / bug fixes I was working on.
So you have the silly version of that:
Code has bug X, fix it in dev branch. But product has bug X too! Fix it in release branch (separately) since we don't want new feature (i.e. whole of dev branch) in prod branch.
Makes only so far as I was also working on new and/or breaking feature (including database schema change)
The whole process seems largely clunky to me.. Not sure ow to fix it though...
|
|
|
|
|
For a case like this, we would fix X in the production branch and then merge back to dev.
If X fix is so large that it could put production stability at risk, then create a production.X branch to do the work. merge production.X -> production -> dev.
Once you create the next stable release candidate:
production.X (if necessary) -> production -> candidate -> dev
or for a new feature in candidate that is not in production
candidate -> dev
|
|
|
|
|
|
Don't try to do it from your desk. Talk to people.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Short answer:
Have you considered a commit by commit merge from dev to prod using git cherry-pick[^]?
Long answer:
As for the overall strategy, I'd say it is wrong! Whoever authorised changing the production branch should be taken out back and given a damned good explaination of how and when to change a branch!
Let's start at the very beginning...
master is the head revision of released code. No development should be checked in here, this is your latest and greatest release to the wild.
production should be master plus anything being deployed. Again no development! The only commits are part of building the artifacts for release. Once built and tested it is merged back to master as the last step of the release.
development is where all the changes being prepared for release go. And no, you can't check development into development. Each user should branch of development and merge back completed changes.
So far, so good. That is a pretty normal work flow, and makes sure that nothing gets into the relase branch that shouldn't be there. Now for your problem.
Feck! production is being updated for the next release and so shouldn't be touched; *snigger*.
Branch from the tag in master at the release. Create the new branch hotfix-x; where 'x' is the version as you may have moire than one hot fix. This is equivalent to production but is behind development and that's an important distinction. Normally changes are merged at the head from development to production, here we do it piecemeal. So let us begin...
We will start with a dev change. First find the commit hash in the development branch. From hotfix-x do a cherry pick merge - git cherry-pick <hash>; one change done and dusted.
Now we have the problem of the idiot having changed production. Slap the idiot then find the commit hash and guess what you do next? Cherry pick is your friend today.
I personally would recommend merging from development to hotfix-x as much as you can. If there is a change that can only be applied to the older code then better branch from hotfix-x to hotfix-name-the-change Make the changes, unit test and merge back to hotfix-x then merge again to development.
When everything is sorted out, kick the eejit and test from hotfix-x as you would from production If this is all on top of master then it should be merged back, see above, when it is released.
veni bibi saltavi
|
|
|
|
|
+5 from me. I was about to suggest 'cherry-pick', then I saw this post. Cherry pick will be the best option here to pull a commit and push to a different branch. One important part here: whoever is doing this merge, should take care of the changes properly; else it may screw-up.
Vote up or Mark as Answered, if this information helped you.
Kind Regards - Kunal Chowdhury, Windows Platform Development MVP
|
|
|
|
|
I will have to do some practice at home this holiday first, haha.
But thanks man for the long tip.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
