

git cascade and git forward-merge - cool-RR
https://github.com/cool-RR/git-cascade

======
languagehacker
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.

------
mnarayan01
Today was probably not the best day to submit this.

------
twic
This is nice.

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?

~~~
salgernon
>> If we find bugs during pre-release testing, we fix them on release, then
immediately merge release back on 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.

~~~
gcr
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.

~~~
salgernon
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...

------
maaaats
How would one normally achieve the effect of the git forward-merge in the
command line?

My IDE usually does that for me, so never really considered it an issue to
change branch with an unclean tree.

~~~
cool-RR
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.

------
stonewhite
The name 'git cascade' made think that it was about updating feature branches
when a mainline branch was committed to.

~~~
cool-RR
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.

