If the feature branches are defined in the cascade order, it'll do that.
This gives me the idea of implementing wildcards in the cascade order, so feature branches will automatically be in the cascade order. Pull requests welcome.
I think you'd have to check out the target branch (stashing any changes if you had them), do `git merge source_branch`, and then check out the original branch you were on, and pop stash if you saved one.
Alternatively if the merge is a simple fast-forward you can just do `git push . source:destination`, which is what `git forward-merge` does in that case too.
One project i work on has two branches, master and release. We develop on master, then branch release from master when we want to make a release. If we find bugs during pre-release testing, we fix them on release, then immediately merge release back on to master. Note that this ensures that master is always a descendent of release, which means it's always safe to re-branch release. We don't use named feature branches; we make commits straight to release (and master). Could we use git-cascade to automate the immediate merge from release back to master?
Yep. Except note that it won't merge from `release` to `master`, because the script doesn't know whether you guys pushed other commits to `release` that you don't want to have on `master`. So it'll push just the source commit to both `release` and `master`.
Meh. That seems sensible to me, I guess, if it's something that the developer will guarantee won't change anything (eg. a typo in a translated string). I think "automatically" generated commits like this should clearly be marked as such so if something does go wrong, it's possible to place the blame.
Back in days of yore, we decided to ship and updated the copyright string in the .text section of the product binary - from "Copyright 1989 SMI" to "Copyright 1991, Sun Microsystems", which subsequently changed the alignment of other sections and led to a 10% performance penalty (fixed by regenerating the order file.)
I've never thought there was such a thing as safe fix ever since...
Forward-merge sounds useful, but can't you just fetch from the remote and then merge the remote -- e.g. git merge origin/shared-branch ?
Cascade, on the other hand, sounds way too risky for me to want to use. The few seconds of time you're saving are an investment into not fucking up something huge.
In general, I'm not a fan of anything that's designed specifically to make it easier for you to skirt a version control/deployment workflow you've established. That just puts unnecessary effort into treating the symptoms of a bad workflow (or an unrealistic stakeholder) when you should be working to address the root cause instead.
12 comments
[ 2.5 ms ] story [ 37.8 ms ] threadThis gives me the idea of implementing wildcards in the cascade order, so feature branches will automatically be in the cascade order. Pull requests welcome.
My IDE usually does that for me, so never really considered it an issue to change branch with an unclean tree.
Alternatively if the merge is a simple fast-forward you can just do `git push . source:destination`, which is what `git forward-merge` does in that case too.
One project i work on has two branches, master and release. We develop on master, then branch release from master when we want to make a release. If we find bugs during pre-release testing, we fix them on release, then immediately merge release back on to master. Note that this ensures that master is always a descendent of release, which means it's always safe to re-branch release. We don't use named feature branches; we make commits straight to release (and master). Could we use git-cascade to automate the immediate merge from release back to master?
As a self diagnosed Aspie, I can't tell if this article or your comment are April 1st jokes. Which I guess is kind of the point of April 1st jokes.
I've never thought there was such a thing as safe fix ever since...
Cascade, on the other hand, sounds way too risky for me to want to use. The few seconds of time you're saving are an investment into not fucking up something huge.
In general, I'm not a fan of anything that's designed specifically to make it easier for you to skirt a version control/deployment workflow you've established. That just puts unnecessary effort into treating the symptoms of a bad workflow (or an unrealistic stakeholder) when you should be working to address the root cause instead.