Seems easy enough, I read the article multiple times and I don't get why what they are describing is needed.
The difference is that git rebasing is a destructive operation, you lose track of the old version when you do it. (Yes, there's technically the reflog.. but it's much less friendly to browse, and there's no way to share it across a team.)
Maybe that's an okay tradeoff for something you use by yourself, but it gets completely untenable when you're multiple people maintaining it together, because constantly rebasing branches completely breaks Git's collaboration model.
You don't need to push the rebased branch to the same branch on your remote, if that's an issue (although I don't see how it is).
Maybe this is a case of "Dropbox is just rsync", but I feel like just learning git and using it is easier than learning a new tool.
I would agree if this "new tool" we're talking about wasn't just a simple wrapper over existing git commands. You can learn it in its entirety, including how it works (not just how to use it), in a matter of a half hour or less.
Between monthly syncs we push our own changes to our latest monthly branch (which also get manually sent upstream when we get a chance).
To me that sounds like not a great idea, but if you must do it, I could see some usefulness to this.
I agree that it's not ideal, but... there are always tradeoffs to manage.
[0]: https://github.com/stackabletech/docker-images/tree/e30798ac...
The likelihood of conflicts is minimal, and often if you see conflicts it’s a good indication your issue may have been resolved. Or if not, you can see if it’s still needed, or how to adjust it.
> fork the repo (at whatever tag makes sense), then periodically sync with the latest code for that version.
Yeah, this is the workflow that Lappverk is trying to enable.
The problem is that neither of Git's collaboration models works well for this problem. Rebasing breaks collaboration (and history for the patchset itself), and merging quickly loses track of individual patches. Lappverk is an attempt to provide a safer way to collaborate over the rebase workflow.
Same happens with patches that Debian applies on top of fixed versions of packages. They are stored in Debian's Salsa git.
Quilt is automation for the "bag of patches" model. I used it once when I needed to upgrade the internal bag of patches at $big_corp so as to apply them to a newer version of $public_app. It was predictably complex but somehow still manageable.
If you squint a bit then the [bag of patches] + [automated application in order] is a poor man's Git. If you keep this in a git repo then you're basically versioning repos (poor man's ones) in a repo. It almost sounds like the solution to author's problem :)
Ultimately the solution I ended up using was git rebase; it just works the nicest out of all of them:
* Your patches are always kept on top at the git log.
* It's absolutely trivial to drop an unnecessary patch, add a new one in the chain or to merge two patches that do the same thing. (Use git rebase -i for that.) Fixing typos in patches is trivial too.
* Your history isn't so important for a patch fork; the patches are what matters, so don't fret too much about commit hashes changing. I promise you, it'll be fine.
* Git will complain if you try to do a rebase that doesn't work out of the box, using similar tools as resolving merge conflicts. You can instantly do a git pull from another upstream that rebases with git pull --rebase upstream/master . This does assume you've added the upstream as a second origin to git under the name upstream and that they push the code you want to patch onto the master branch.
As for drawbacks, I only wound up with two:
* CI tools and git server UIs often aren't prepared to handle a heavily rebased master branch - it leads to lots of builds that are linked to dangling commit hashes. GitHub also for some reason insists on displaying the date of the last rebase, rather than the date of when the patch was committed. Not sure why.
* Pushing your fork means heavy use of force pushes, which feels instinctively wrong.
The drawback isn't large enough for me to mind it in practice.
Opted to use rebase for this sort of fork after reading a bit about non-merge related git flows and wondering what'd happen if I did a rebase-based workflow but just... never send any patches. Turns out it works really well.
> GitHub also for some reason insists on displaying the date of the last rebase, rather than the date of when the patch was committed. Not sure why.
Sounds like you’re running into the difference between author and committer, which Git models distinctly.
radare2 -qq -w -c "wx 01 @ 0xb407" /usr/bin/manResult: Our project activity resulted in a "your pull request has been updated" email spam about a pull request we had no control over.
reading the readme didn't make it clear to me how this app would make my life any easier (also considering the added complexity of a new tool).
i rarely, if ever, need to look at the history of this.
I'm going to try to make a frontend UI for it.
First, because I have a special setup. Second, I often want some small changes in the software.
I work for a decade as mainframe technical support mostly install fix. And because of these lately when I spent 3 months as a hobby to change the turbo bridge to take external bridge card. I injected code or hacking of the code like jes2 exit and without touching much the host program modify the host program behaviour.
This is very different from my colleagues who are application programmer who can totally change a cics module involving even changing db2 schema.
What is a modification meant in this title … I wonder.