On 1/14/15 12:29 AM, Daniel Murphy wrote:
The problem here is really that make sucks, right? And makefiles suck.
Maybe we should start seriously looking at replacing them with D scripts.
I agree that make sucks etc. but duplication sucks more (and would suck
regardless of what tool we use). Here we do have a simple method
(include files) that is suitable for addressing that. I'd assume we'd
use something similar with whichever tool we'd use.
Honestly I don't think automating rebase is a good idea, because it
discourages actually learning how to do it.
eg if all you're trying to do is get the current branch rebased on top
of upstream's master, you can do this:
git pull upstream master --rebase
Great. As an aside I just ran that and got:
error: unknown option `rebase'
usage: ...
Whether it's a command or a couple, that doesn't change the fact that I
need to run the same command four times, and in parallel if at all
possible. It's a perfect candidate for automation, and I haven't seen an
argument the makefile isn't a good place for that.
I'd also like to define "make rebase-dirty" based on this:
REBASE_DIRTY = MYBRANCH=`git rev-parse --abbrev-ref HEAD` &&\
git stash &&\
git co master &&\
git pull --ff-only upstream master &&\
git co $$MYBRANCH &&\
git rebase master &&\
git stash pop
which is useful because it lets me rebase on top of work in progress.
Again the prospect of duplicating this other macro across 3-4 projects
is fairly unattractive.
I've managed to get by fine with using shell scripts for stuff like this.
Do you need to upload the dlang.org website quickly and without error?
Overall I have difficulty understanding counterarguments.
Challenge: "We should eliminate some unpleasant duplication."
Response: "Make sucks. Make includes are unreliable for mythical
unexplained reasons. You don't know git. You should do scripts instead."
The response just doesn't follow. Care to clarify what you think we
should be doing here?
Andrei
