3 ms·

> It's local history that one rewrites I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if

by feoren 3y ago

> It's local history that one rewrites I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if it takes 2+ weeks? You have 2 weeks of code replicated only locally on your laptop? Or what do you mean by local?

interroboink 3y ago
I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc). So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others. A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history. Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo. Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less. ---- EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
asveikau 3y ago
Local in the sense that every developer has a full history, and can edit their own history after the fact before pushing changes. Basically it's the equivalent of bringing patches up to date before upstreaming them. Upstream isn't going to apply a patch that no longer applies cleanly.
lordgroff 3y ago
There's an easy way around this, and that's to namespace in some way branches that are free to be overwritten, ie WIP work not yet merged into the canonical branches. Works just fine. If the project is too large for this, you can also fork off the repo itself and then merge in your changes to the main canonical version when you're ready.
skissane 3y ago
You can push your local work to a private remote branch. (By private, I don't mean that other people can't see it, I just mean some convention which means other developers will ignore it in normal circumstances.) If a person commits a lot, they can end with all kinds of little commits which are just fixing typos or syntax errors, exploring half-baked ideas, can't be bothered writing a commit message right now, etc. What's the point of keeping all that stuff long-term? Then, when it is ready to be reviewed, you rewrite that real history into something more logical - e.g. first commit creates an interface, second commit implements it, third makes other parts of the code call it, etc - and then submit that for review as a PR - that "fake" history is likely to be much more useful to others (and to one's own future self) than the real development history was
- bluGill 3y ago
  The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. However this is a defect of your version control system. back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.
  - skissane 3y ago
    > The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future
burntsushi 3y ago
Yes, local is the wrong word. Or rather, it's imprecise. A better word is unshared. But even that is imprecise, because you might consider pushing a set of commits to the Internet as sharing. Maybe an even better word is collaborate. I don't rewrite history of source code that I am collaborating with someone else on. For example, the history on master never gets re-written. But that feature branch I pushed to get review before being merged? Absolutely. I'll rewrite its history without a second thought before it gets merged. It doesn't matter what source control system you hand me. It could be your ideally perfect system. I would still rewrite history that I'm not collaborating with others on. I try treat source history (as much as is practical) as a sequence of logical changes to the code. I treat it like I treat the code. I try to optimize for making it intelligible and understandable to other humans (including myself). You can look at any of my projects on GitHub for examples.
cryptonector 3y ago
Local == not published (on the trunk or whatever you call the main branch). Local != not pushed to a remote. You can totally push to a per-developer remote, or to branches under a per-developer namespace.
IshKebab 3y ago
"Local" probably wasn't quite the word he meant. "Personal" is maybe a better word. In other words, only you are working on it. As soon as you share a branch with other people and they start adding commits - that's when you should start avoiding "rewriting history" (though if you coordinate well even then it's fine). And to answer your actual questions. Yes, you either: 1. Push it to a shared repo but with a name that makes clear it is a branch belonging to you (e.g. `<yourname>/branch`), or 2. Back it up with your standard laptop backup (the one you have set up that backs up non Git stuff too).
dspillett 3y ago
I'm not a fan of changing history at all, but: > to any shared repository while still working on a feature? What if it takes 2+ weeks? A lot of projects don't want our partially implemented changes, if only one person is working on them, just the first ready-for-others result and subsequent smaller fix updates. > Or what do you mean by local? This is key: remember that git is distributed, so backups of your really local repository should be as easy as pushing to a remote copy. If you aren't doing that (or even if you are) keeping an automatic off-machine backup of your working directories is a good idea in case of drive failure. If you are working on a feature with a team, perhaps a team-local shared repository is a valid answer.

by feoren 3y ago

interroboink 3y ago

I'm not the person you asked, but I think they meant: changes that are not shared with others. You can back up your own stuff as you please, but once you share it with someone else, it's best to treat that bit of repo history as immutable from that point onward (because they may have made their own copies, shared it with other people, etc). So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others. A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history. Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo. Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less. ---- EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

asveikau 3y ago

Local in the sense that every developer has a full history, and can edit their own history after the fact before pushing changes. Basically it's the equivalent of bringing patches up to date before upstreaming them. Upstream isn't going to apply a patch that no longer applies cleanly.

lordgroff 3y ago

There's an easy way around this, and that's to namespace in some way branches that are free to be overwritten, ie WIP work not yet merged into the canonical branches. Works just fine. If the project is too large for this, you can also fork off the repo itself and then merge in your changes to the main canonical version when you're ready.

skissane 3y ago

You can push your local work to a private remote branch. (By private, I don't mean that other people can't see it, I just mean some convention which means other developers will ignore it in normal circumstances.) If a person commits a lot, they can end with all kinds of little commits which are just fixing typos or syntax errors, exploring half-baked ideas, can't be bothered writing a commit message right now, etc. What's the point of keeping all that stuff long-term? Then, when it is ready to be reviewed, you rewrite that real history into something more logical - e.g. first commit creates an interface, second commit implements it, third makes other parts of the code call it, etc - and then submit that for review as a PR - that "fake" history is likely to be much more useful to others (and to one's own future self) than the real development history was

bluGill 3y ago
The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. However this is a defect of your version control system. back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.
- skissane 3y ago
  > The reason you are asving this is because git is so aweful at managing many tiny commits. So you work around it by squashing. I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future

burntsushi 3y ago

Yes, local is the wrong word. Or rather, it's imprecise. A better word is unshared. But even that is imprecise, because you might consider pushing a set of commits to the Internet as sharing. Maybe an even better word is collaborate. I don't rewrite history of source code that I am collaborating with someone else on. For example, the history on master never gets re-written. But that feature branch I pushed to get review before being merged? Absolutely. I'll rewrite its history without a second thought before it gets merged. It doesn't matter what source control system you hand me. It could be your ideally perfect system. I would still rewrite history that I'm not collaborating with others on. I try treat source history (as much as is practical) as a sequence of logical changes to the code. I treat it like I treat the code. I try to optimize for making it intelligible and understandable to other humans (including myself). You can look at any of my projects on GitHub for examples.

cryptonector 3y ago

Local == not published (on the trunk or whatever you call the main branch). Local != not pushed to a remote. You can totally push to a per-developer remote, or to branches under a per-developer namespace.

IshKebab 3y ago

"Local" probably wasn't quite the word he meant. "Personal" is maybe a better word. In other words, only you are working on it. As soon as you share a branch with other people and they start adding commits - that's when you should start avoiding "rewriting history" (though if you coordinate well even then it's fine). And to answer your actual questions. Yes, you either: 1. Push it to a shared repo but with a name that makes clear it is a branch belonging to you (e.g. `<yourname>/branch`), or 2. Back it up with your standard laptop backup (the one you have set up that backs up non Git stuff too).

dspillett 3y ago

I'm not a fan of changing history at all, but: > to any shared repository while still working on a feature? What if it takes 2+ weeks? A lot of projects don't want our partially implemented changes, if only one person is working on them, just the first ready-for-others result and subsequent smaller fix updates. > Or what do you mean by local? This is key: remember that git is distributed, so backups of your really local repository should be as easy as pushing to a remote copy. If you aren't doing that (or even if you are) keeping an automatic off-machine backup of your working directories is a good idea in case of drive failure. If you are working on a feature with a team, perhaps a team-local shared repository is a valid answer.