331–340 of 366 posts
Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash. If you want more detail about the development of the PR…
Earlier quoted context omitted.
What about commit signatures? If you rebase, you lose the original signature, don't you?
If you let Github do the rebase, yes, you do. But you can do so manually yourself, taking the commit down to a single squashed commit, that you then sign. This is a tooling issue that needs to be solved client-side (i.e. where the signing key lives). It's an important one but actually really simple.
Earlier quoted context omitted.
> I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. Sure. The problem is not "distributed version control", some problems are: - I'm on a train with no internet, finished working on a thing and want to start working on another thing and don't want to mix them up. - I want to make a branch and don't want to wait for eons while everything gets…
All those things could be done on a centralized version control system as well. Just not on SVN.
Tbh I'm not sure why git is called "distributed", it's a local system with remote sync capabilities.
Earlier quoted context omitted.
> I fail to see the point of this I'm pretty sure the point is that this is a one-person project and the author can play around. He's not suggesting your team of 100 people to adopt this for the development of your commercial product.
Quite the opposite. The largest companies just about all use linear commit histories.
I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase a…
> The problem is not a history with a lot of branches in it, it is in not knowing how to use your tools to present a view on that history you are interested in and is easy for you to understand. To me this is like saying to a construction worker: “The problem is not that your hammer has sharp spikes coming out of the handle at every angle. The problem is that you don’t put on a chain mail glove when using it.” That’s…
I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase a…
It is amazing how much time projects seem to spend on rewriting history for the goal of displaying in in a pretty way. Leaving history intact and having better ways to display it seems far saner. Even after a merge, history in the branch maybe useful for bisect, etc.
Earlier quoted context omitted.
it's actually way easier to accidentally mess up a rebase, especially if rearranging commits. I can recommend git diff @{1} post rebase I alias it to d-
I'm not sure if you misread my comment, but my point was that it's far too easy to accidentally introduce bugs in merge commits that go unnoticed for a long time. I've never seen a rebase gone awry introduce production bugs, but I've known multiple gnarly bugs caused by errant merges. YMMV.
In a merge, you solve conflicts once. Whereas in a rebase, those conflicts will turn into incremental conflicts.
If the branch history is "tidy", with discrete, purposeful commits, this can be easier. Especially if incrementally rebasing.
The main difference is one rewrites history and the other does not. A rebase is by nature destructive and as such can introduce subtle changes in the process, especially if commits are reordered / modified in the process
Earlier quoted context omitted.
it's actually way easier to accidentally mess up a rebase, especially if rearranging commits. I can recommend git diff @{1} post rebase I alias it to d-
First time I've seen aliases using other chars other than a-z; care to share your dotfiles? It's a neat trick to explode your alias namespace, since you'll never see a tool published named `ls-` So you have reserved a huge "address block" for your personal aliases :)
https://github.com/CervEdin/gut/blob/config/.gitconfig
NB, that some are personal custom scripts, like git-branch-status, which I also publish in the same public repository.
It's very much opinionated and geared to my use but feel free to use it, submit feedback and/or PR
Earlier quoted context omitted.
All those things could be done on a centralized version control system as well. Just not on SVN.
Working offline could be done on a centralised VCS... it's just a bad idea? You'd need separate mechanisms to work offline vs online. Tbh I'm not sure why git is called "distributed", it's a local system with remote sync capabilities.
In practice of course almost nobody uses Git to push/pull from other people's personal machines (I think I've done it once ever). But it's pretty common to push and pull from multiple hosted repos (e.g. Github and an internal company Gitlab). I imagine doing that sort of thing with SVN would be a right pain.