9 ms·

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of

by rjbwork 10y ago

I freely admit to being an Hg fan, but that this stuff is accepted as common practice kinda blows my mind. What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development?

_pmf_ 10y ago
> What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development? What's wrong with organizing your source code in a single directory? Why do people insist on organizing them into subdirectories aud subsubdirectories instead of letting the main directory accurately reflect the size of the code base?
mikekchar 10y ago
It's just a way of looking at it. Let's say I'm in charge of a project. You send me a patch. I commit the patch. What I want in my history is that I committed your patch. I really don't care what you did in your history to create that patch. But it's equally valid to consider all your commits important in my history as well. It just depends on what you want. Personally, I never rebase, but I can understand why some people like that feature.
- k__ 10y ago
  That's what I find hard with contributing to OSS often. Many devs are happy with what you send them... as long if the history is right! And right seems totally random to me. Most are happy if you simply send them "one commit", but tell you to merge multiple commits before they accept it. Others say "lets split this or that" before they accept it. Then I have to go back and fiddle around with Git just to get my change landed...
chriswarbo 10y ago
There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of the YAGNI argument that its futile to think that you have a better idea of what future developers want to see, compared to those future developers themselves. My repo histories are riddled with stuff like "finished X", "stubbed out Y", "fix typo in X", but at least nothing has been hidden from future devs who might be digging around for their purposes, regardless of whatever elegant story I might come up with.
- angry-hacker 10y ago
  But what good does it have for future devs if the history is -- Added this thing -- Fixed typo -- Capitalized the letter Etc.
  - chriswarbo 10y ago
    One important reason is to avoid wasting time on gilding lilies. Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement. For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure out what special edge-cases X is trying to deal with that Y wasn't suitable for. Little do we realise that X was actually written before Y existed, but the commits got rearranged. That kind of archeology is difficult to predict in advance (mostly because, if we realised all of the issues with our code beforehand, we'd fix them immediately!). Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. In fact, they might have access to much smarter tools and IDEs than we do.
    - Dylan16807 10y ago
      >Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. The ability of devs to collapse a bunch of commits into a useful summary is near zero right now. You can only achieve it by rewriting history. Unless you think that feature is going to be commonplace very very soon, there is a compelling reason to lie.
      - chriswarbo 10y ago
        > The ability of devs to collapse a bunch of commits into a useful summary is near zero right now You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc. Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that future dev can, considering the fact that you don't know what they might want? The nice thing about git is that anyone can make a new branch from any point in the repo's history, merge, cherry pick, rebase, etc. to their heart's content, then garbage collect it once they've learned what they needed.
wongarsu 10y ago
Many people think that for later reference a history where each commit contains exactly one feature or bugfix is more useful than the usual development workflow of "start feature a, fix bug in related feature b, fix documentation of unrelated startup flag, implement feature c that turns out to be prerequisite to feature a, do more work on feature a, fix bug in c, [...], finish work on a". And in case you want to commit to an open source project you are basically forced to rewrite history for any non-trivial change because changes that make sense to develop at the same time often form independent PRs.
Dylan16807 10y ago
What does accurate history mean? Do you commit after every 20 seconds of typing? Why not? The people cleaning up history have the same motivation.
- newjersey 10y ago
  The last time we had this discussion the consensus bottom line was that you try to avoid rewriting history once you have pushed it to a place where others have access to it. Once you've published it, let it go. Do not mess with history. I think we can all agree on that. The disagreement is whether I should squish my commits before I push it and I put that in the same pile of questions as am I obligated to my significant other and society at large to shave my legs before going out in public.
  - StavrosK 10y ago
    You aren't obligated, you just might make people not like you very much.
yoavm 10y ago
I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush. Having 10 tiny commits like that are just failed attempts to fix a bug isn't practical. It makes reading and understanding your repository code _harder_. Git rebase helps me keep my log clean and understandable, thus making it something I can work with in the future.
- recursive 10y ago
  I'm using CI and CD. If I want to find out if I've fixed a bug, I just run the build locally before pushing.
  - rjbwork 10y ago
    Ideally, sure. But I've had to do this before due to the fact that a configuration value in the PaaS I was using was unmodifiable on remote, but modifiable locally, so I had to do a sort of binary search to narrow it down by observing the behavior of the server via changing my code's value a number of times. He makes a good point, but ultimately I have to agree with someone's point about "pointlessly gilding lillies".
  - swift 10y ago
    On some of the projects I've worked on, although I can easily run a subset of the tests as a sanity check, the full test suite takes hours to run and has to be run on several different platforms because there is a lot of platform-specific code. There's no way I or anyone else can have confidence in any substantial change until it's run through CI. This is a cycle that may repeat many, many times in some cases before some obscure, platform-specific bug can be tracked down. All of those intermediate attempts would quickly totally drown out the signal in the commit history. This is just one of many reasons why for larger projects, rewriting history is really the only practical option.
gwright 10y ago
Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers need the ability to iterate over their code to get it to a reasonable place before they want it enshrined in the blessed commit history that is shared with others or otherwise retained over time. The intermediary states, with false starts, poor implementations, hand crafted functions instead of standard functions, poorly named classes, and so on are all part of development but aren't particularly interesting to keep in the permanent history of a project. Git's ability to manipulate the existing commit tree (amend, reset, rebase, etc.) is extremely useful for this normal 'exploratory' development. Once a stable point has been reached though (often because the tree has been published or shared with others), these commands do become inappropriate and a different set of tools becomes relevant (revert, merge, etc.).
- gwright 10y ago
  One clarification: amend, reset, rebase and their ilk don't 'manipulate the commit tree' other than adding commits. The manipulation is with the branch names associated with the commits. I've always hated the common description of 'rebase' as 'rewriting history'. None of the existing commits are modified by rebase, new commits are added and the branch names are shuffled around.
  - rkangel 10y ago
    It doe rewrite history in the sense of which events followed which events. Imagine the following sequence of events: I make a commit on my local master Someone else makes a commit on their master They push I 'pull --rebase' That history now shows their commits before mine in the history, even though I made my commits first, directly on top of master.
    - gwright 10y ago
sethammons 10y ago
In my opinion, it is only valuable to present a pristine history to make sure that every "official" commit provides an application that can be ran. This allows git bisect to do amazing things. In other words, I will git merge --squash. When someone rewrites history after pushing, all they do is make everyone else have a bad day.
- rjbwork 10y ago
  If I'm pushing non-building commits on a feature branch in Hg, why should it matter? It documents the history of the development of that feature without interfering with default/master.
nolemurs 10y ago
You have to think about the purpose of the history. Git history serves a few purposes. First, it provides an overview of development so that someone can use `git log` to quickly figure out what's been done. Second, it provides context to code changes so that someone using `git blame` can figure out why some code looks the way it does. Finally, it provides a set of distinct points for clean manipulation of history via `git revert`, `git bisect` etc. From the point of those purposes, there's no real value in a history which accurately reflects the development process. The ideal commit has a few properties: it should address only one concern, it should contain all the immediate code changes addressing that concern, and it should not be overly long. Commits like that make navigating and manipulating the git history easy. There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.
- filoeleven 10y ago
  > There's nothing wrong with keeping an accurate picture of history. It's just not actually useful. Except for the relatively rare cases when it is incredibly useful. But that's why we have the reflog.
chubot 10y ago
How do you accurately reflect the history of development when it's nonlinear? I was an hg person too, but I came over to the git side when I needed to collaborate with people. git's killer feature is merges. And merges benefit from fine-grained commits that rewrite history.
m12k 10y ago
There can definitely be value in e.g. summarizing the final result and understanding after a number of 'failed' iterations. And that the many small commits can be considered "noise" if you only care about what happened at a high level. However, rewriting history with operations like squash or rebase IMO seems like a bad solution to a real problem - it really shows that we don't yet have the right abstractions or tools for doing this. If all the small commits are considered "noise" then it shows that we don't have good enough tooling for filtering and grouping when perusing our VC history. The information that people are currently putting into a squash commit is an aggregate or derivative of the original, and as such shouldn't replace it, it should supplement it. There are legitimate use cases where the details of those small commits are indeed valuable, even if the more high-level "just tell me the final result" use case is more common - you shouldn't have to be forced into making that tradeoff. I know some people are using merge commits or pull requests as a place to put this information - but maybe we need a an explicit mechanism for grouping together commits and summarizing them? I'm imagining something along the lines of code folding. Such a grouping might have other uses too (e.g. signal that there's a grouping of commits where the tests will fail, so skip to the last commit if bisecting)
- djsumdog 10y ago
  As I understand it (and what I now do when on a team) is use commits as atomic, fully flushed out parts. Commit 324rte may specifically "add support for PUT operations on widgets" or asde21 may "Refactor Business Rule Unit Tests into individual files".. and looking at the log, you can cherry-pick that one commit (and deal with potential merge issues) onto your branch. But if you're working at home on your own project and just want to sync between a few machines, what do you do? Commit, "Hashing on the Liststore kinda works, some bugs." Push. Go to your home machine, work some more, and finally squash all those kinda working commits into one commit ... potentially even need a "git push --force" (which you can safely do since you're the only developer?) I agree with you totally though. It shouldn't just be a branch. There should be a way to group x edits into one big commit. That's the atomic unit that has a specific feature, and all the mini-commits inside of it should be totally abstracted except for specific deep searching commands.
- nolemurs 10y ago
jakub_g 10y ago
You might want to have `git bisect` working, for instance. For bisect to be useful, each commit should leave the repo in a consistent, "green" state. If you commit something stupid by mistake, and add a commit later to fix it, then during the bisect you might get wrongly stopped at the stupid commit. Arguably it's more important to have clean commit history in open source projects. I used to be hard on this at work but I relaxed a bit lately. Generally the development in companies moves much faster than in open source libraries (in terms of # of commits per weeks), and generally in open source world it's expected to have clean, well tested, working solutions rather than hacks that can be fixed tomorrow if needed - and because of that, OS maintainers have higher standards for commits.
agentgt 10y ago
I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but on the opposite end I think Hg consistency is better for corp). One of my greatest challenges in using/understanding Git was(/is still) the reflog. I know the reflog isn't that complicated but there isn't anything really analogous in other SCM (of my limited knowledge of perforce, svn, hg, git). Also for some reason the presentation of the reflog UI wise is intimidating. Reflog is nice gem for git particularly since the builtin Mercurial rollback (I wish they would just remove that command) is fairly awful (use histedit or rebase instead). That being said Mercurials new changeset evolution experimental stuff looks really promising [1]. That being said if you are looking to undo in hg like this article talks about you have to look at the hg unbundle backupfile Unbundle is a pretty nasty command compared to the reflog commands but on the other it is just restoring from some backup file. I'm not too sure how you can transfer reflogs around. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution
- ngoldbaum 10y ago
  Rollback is deprecated, it doesn't show up in the docs. Because people use it in scripts it will never be removed due to mercurial's backward compatibility guarantees. Mercurial 3.9 ships with the journal extension, which is a bit like the git reflog: https://www.mercurial-scm.org/wiki/JournalExtension https://www.mercurial-scm.org/wiki/JournalExtension
  - agentgt 10y ago
    Vaguely remember seeing that extension. I did not know it ships with Hg now! Awesome! More reasons to stick with hg longer for my company :)
- krupan 10y ago
  I think bundles are easier to understand than the reflog. When you run a command that modifies commits, the original commits are stored off in a bundle file. When you unbundle that file, the commits show back up in your repository history. What could be simpler? The git reflog gives you a weird truncated log view of old commits that is very hard to parse (for a human at least). That being said, I've been using changeset evolution for over a year and it is awesome. Instead of creating a bundle your commits are just hidden. You can run any of your hg log commands with --hidden and it shows you those hidden commits. You can see exactly how your rebase removed (hid) some old commits and created new ones. It's very easy.
dspillett 10y ago
> What's so wrong with keeping an accurate picture of history I think part of the problem is the distinction between history and audit. What you are thinking of is a full audit: every change made by everyone to get to and from each state. History can sometimes be this, but sometimes you just want the solid states and the extra detail of each step between including failed steps that were back-tracked is more information than people want and can result in cognitive overload. Different people want different detail. Sometimes the same people want different detail for different tasks. One option might be for a feature to allow you to mark a commit as intermediate. Keep those with the flag around but don't display them or allow things like bisect to operate on it by default. Display them if an extra option is provided, allow action upon them similarly (not by default, you don't want a typo in a commit ID to result in a commit that exists but is not the one you are looking for to be accessed).
- rjbwork 10y ago
  I think that's what feature branches are for. You merge to master/default after you're done with your feature, and commit an accurate history to the branch.
  - dspillett 10y ago
    Probably, though that isn't something you can do after the fact where a "treat this as a partial result" flag on a commit could be.
krupan 10y ago
No version control system accurately reflects every bit of history that goes into creating and editing your code. You'd have to record every keystroke. The whole idea behind a vcs is to record helpful and relevant history. Is every little merge relevant and helpful history? Hard to say, maybe, but probably not.
paulddraper 10y ago
It's the same reason that history books aren't a bunch of primary sources stapled together. What more better than painstakingly accurate history is useful history. I don't care that Joe was distracted one day and had to make a fix-up commit. I care that he authored a certain change.
darekkay 10y ago
I'm also coming from Hg, and this picture [1] sums up the problem. The history tree in our company is way more messy - basically over 1/3 of all commits are just merges. [1] https://twitter.com/michaelhenke/status/585142133167751169 https://twitter.com/michaelhenke/status/585142133167751169

by rjbwork 10y ago

_pmf_ 10y ago

> What's so wrong with keeping an accurate picture of history that people do all kinds of manipulation to their history to keep from the VCS system from accurately reflecting history of development? What's wrong with organizing your source code in a single directory? Why do people insist on organizing them into subdirectories aud subsubdirectories instead of letting the main directory accurately reflect the size of the code base?

mikekchar 10y ago

It's just a way of looking at it. Let's say I'm in charge of a project. You send me a patch. I commit the patch. What I want in my history is that I committed your patch. I really don't care what you did in your history to create that patch. But it's equally valid to consider all your commits important in my history as well. It just depends on what you want. Personally, I never rebase, but I can understand why some people like that feature.

k__ 10y ago
That's what I find hard with contributing to OSS often. Many devs are happy with what you send them... as long if the history is right! And right seems totally random to me. Most are happy if you simply send them "one commit", but tell you to merge multiple commits before they accept it. Others say "lets split this or that" before they accept it. Then I have to go back and fiddle around with Git just to get my change landed...

chriswarbo 10y ago

There seems to be a split among git users between those who think history should show what actually happened (i.e. it's left alone), and those who think history should tell a story about the changes (i.e. once you've finished something, turn it into a coherent set of commits like "stub out X", "add tests for X", "make first X test pass", etc.). I agree with you, that history should be left alone; mostly I think of the YAGNI argument that its futile to think that you have a better idea of what future developers want to see, compared to those future developers themselves. My repo histories are riddled with stuff like "finished X", "stubbed out Y", "fix typo in X", but at least nothing has been hidden from future devs who might be digging around for their purposes, regardless of whatever elegant story I might come up with.

angry-hacker 10y ago
But what good does it have for future devs if the history is -- Added this thing -- Fixed typo -- Capitalized the letter Etc.
- chriswarbo 10y ago
  One important reason is to avoid wasting time on gilding lilies. Another reason is that the git information (e.g. from git blame) tells us when the code was written and in what order, rather than some post-hoc rearrangement. For example, we might notice that code X is doing some tricky work which elsewhere is done by a helper function Y. We look at the git info and see that X was added after Y, so we try to figure out what special edge-cases X is trying to deal with that Y wasn't suitable for. Little do we realise that X was actually written before Y existed, but the commits got rearranged. That kind of archeology is difficult to predict in advance (mostly because, if we realised all of the issues with our code beforehand, we'd fix them immediately!). Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. In fact, they might have access to much smarter tools and IDEs than we do.
  - Dylan16807 10y ago
    >Future devs are just as capable at traversing repos and collapsing diffs as you or I, so there's no need to lie to them. The ability of devs to collapse a bunch of commits into a useful summary is near zero right now. You can only achieve it by rewriting history. Unless you think that feature is going to be commonplace very very soon, there is a compelling reason to lie.
    - chriswarbo 10y ago
      > The ability of devs to collapse a bunch of commits into a useful summary is near zero right now You can get quite far with 'git diff START END'. Something more task-specific can probably be done with Emacs, Magit, Ediff mode, bash, elisp, etc. Even if you think collapsing commits by rewriting history is useful for making summaries, etc. what makes you think you can produce a more useful summary right now than that future dev can, considering the fact that you don't know what they might want? The nice thing about git is that anyone can make a new branch from any point in the repo's history, merge, cherry pick, rebase, etc. to their heart's content, then garbage collect it once they've learned what they needed.

wongarsu 10y ago

Many people think that for later reference a history where each commit contains exactly one feature or bugfix is more useful than the usual development workflow of "start feature a, fix bug in related feature b, fix documentation of unrelated startup flag, implement feature c that turns out to be prerequisite to feature a, do more work on feature a, fix bug in c, [...], finish work on a". And in case you want to commit to an open source project you are basically forced to rewrite history for any non-trivial change because changes that make sense to develop at the same time often form independent PRs.

Dylan16807 10y ago

What does accurate history mean? Do you commit after every 20 seconds of typing? Why not? The people cleaning up history have the same motivation.

newjersey 10y ago
The last time we had this discussion the consensus bottom line was that you try to avoid rewriting history once you have pushed it to a place where others have access to it. Once you've published it, let it go. Do not mess with history. I think we can all agree on that. The disagreement is whether I should squish my commits before I push it and I put that in the same pile of questions as am I obligated to my significant other and society at large to shave my legs before going out in public.
- StavrosK 10y ago
  You aren't obligated, you just might make people not like you very much.

yoavm 10y ago

I never had the urge to rewrite the history of my code until I started using CI & CD. Since then, it happened to me few times that I wanted to fix something small and ended up trying multiple times, pushing a new "maybe this time?!" commit over and over again. Obviously it's not best practice, but it something you do when there's a rush. Having 10 tiny commits like that are just failed attempts to fix a bug isn't practical. It makes reading and understanding your repository code _harder_. Git rebase helps me keep my log clean and understandable, thus making it something I can work with in the future.

recursive 10y ago
I'm using CI and CD. If I want to find out if I've fixed a bug, I just run the build locally before pushing.
- rjbwork 10y ago
  Ideally, sure. But I've had to do this before due to the fact that a configuration value in the PaaS I was using was unmodifiable on remote, but modifiable locally, so I had to do a sort of binary search to narrow it down by observing the behavior of the server via changing my code's value a number of times. He makes a good point, but ultimately I have to agree with someone's point about "pointlessly gilding lillies".
- swift 10y ago
  On some of the projects I've worked on, although I can easily run a subset of the tests as a sanity check, the full test suite takes hours to run and has to be run on several different platforms because there is a lot of platform-specific code. There's no way I or anyone else can have confidence in any substantial change until it's run through CI. This is a cycle that may repeat many, many times in some cases before some obscure, platform-specific bug can be tracked down. All of those intermediate attempts would quickly totally drown out the signal in the commit history. This is just one of many reasons why for larger projects, rewriting history is really the only practical option.

gwright 10y ago

Opinions differ on this matter because of different concepts of what 'history' is appropriate to maintain. At one extreme, you could keep track of all your keystrokes in the editor so that you could have a full history of your work including backspaces to correct typos. On the other extreme is the mythical programmer who crafts perfect commits in exactly the correct order on the first attempt. Most mortal programmers need the ability to iterate over their code to get it to a reasonable place before they want it enshrined in the blessed commit history that is shared with others or otherwise retained over time. The intermediary states, with false starts, poor implementations, hand crafted functions instead of standard functions, poorly named classes, and so on are all part of development but aren't particularly interesting to keep in the permanent history of a project. Git's ability to manipulate the existing commit tree (amend, reset, rebase, etc.) is extremely useful for this normal 'exploratory' development. Once a stable point has been reached though (often because the tree has been published or shared with others), these commands do become inappropriate and a different set of tools becomes relevant (revert, merge, etc.).

gwright 10y ago
One clarification: amend, reset, rebase and their ilk don't 'manipulate the commit tree' other than adding commits. The manipulation is with the branch names associated with the commits. I've always hated the common description of 'rebase' as 'rewriting history'. None of the existing commits are modified by rebase, new commits are added and the branch names are shuffled around.
- rkangel 10y ago
  It doe rewrite history in the sense of which events followed which events. Imagine the following sequence of events: I make a commit on my local master Someone else makes a commit on their master They push I 'pull --rebase' That history now shows their commits before mine in the history, even though I made my commits first, directly on top of master.
  - gwright 10y ago

sethammons 10y ago

In my opinion, it is only valuable to present a pristine history to make sure that every "official" commit provides an application that can be ran. This allows git bisect to do amazing things. In other words, I will git merge --squash. When someone rewrites history after pushing, all they do is make everyone else have a bad day.

rjbwork 10y ago
If I'm pushing non-building commits on a feature branch in Hg, why should it matter? It documents the history of the development of that feature without interfering with default/master.

nolemurs 10y ago

You have to think about the purpose of the history. Git history serves a few purposes. First, it provides an overview of development so that someone can use `git log` to quickly figure out what's been done. Second, it provides context to code changes so that someone using `git blame` can figure out why some code looks the way it does. Finally, it provides a set of distinct points for clean manipulation of history via `git revert`, `git bisect` etc. From the point of those purposes, there's no real value in a history which accurately reflects the development process. The ideal commit has a few properties: it should address only one concern, it should contain all the immediate code changes addressing that concern, and it should not be overly long. Commits like that make navigating and manipulating the git history easy. There's nothing wrong with keeping an accurate picture of history. It's just not actually useful.

filoeleven 10y ago
> There's nothing wrong with keeping an accurate picture of history. It's just not actually useful. Except for the relatively rare cases when it is incredibly useful. But that's why we have the reflog.

chubot 10y ago

How do you accurately reflect the history of development when it's nonlinear? I was an hg person too, but I came over to the git side when I needed to collaborate with people. git's killer feature is merges. And merges benefit from fine-grained commits that rewrite history.

m12k 10y ago

There can definitely be value in e.g. summarizing the final result and understanding after a number of 'failed' iterations. And that the many small commits can be considered "noise" if you only care about what happened at a high level. However, rewriting history with operations like squash or rebase IMO seems like a bad solution to a real problem - it really shows that we don't yet have the right abstractions or tools for doing this. If all the small commits are considered "noise" then it shows that we don't have good enough tooling for filtering and grouping when perusing our VC history. The information that people are currently putting into a squash commit is an aggregate or derivative of the original, and as such shouldn't replace it, it should supplement it. There are legitimate use cases where the details of those small commits are indeed valuable, even if the more high-level "just tell me the final result" use case is more common - you shouldn't have to be forced into making that tradeoff. I know some people are using merge commits or pull requests as a place to put this information - but maybe we need a an explicit mechanism for grouping together commits and summarizing them? I'm imagining something along the lines of code folding. Such a grouping might have other uses too (e.g. signal that there's a grouping of commits where the tests will fail, so skip to the last commit if bisecting)

djsumdog 10y ago
As I understand it (and what I now do when on a team) is use commits as atomic, fully flushed out parts. Commit 324rte may specifically "add support for PUT operations on widgets" or asde21 may "Refactor Business Rule Unit Tests into individual files".. and looking at the log, you can cherry-pick that one commit (and deal with potential merge issues) onto your branch. But if you're working at home on your own project and just want to sync between a few machines, what do you do? Commit, "Hashing on the Liststore kinda works, some bugs." Push. Go to your home machine, work some more, and finally squash all those kinda working commits into one commit ... potentially even need a "git push --force" (which you can safely do since you're the only developer?) I agree with you totally though. It shouldn't just be a branch. There should be a way to group x edits into one big commit. That's the atomic unit that has a specific feature, and all the mini-commits inside of it should be totally abstracted except for specific deep searching commands.
nolemurs 10y ago

jakub_g 10y ago

You might want to have `git bisect` working, for instance. For bisect to be useful, each commit should leave the repo in a consistent, "green" state. If you commit something stupid by mistake, and add a commit later to fix it, then during the bisect you might get wrongly stopped at the stupid commit. Arguably it's more important to have clean commit history in open source projects. I used to be hard on this at work but I relaxed a bit lately. Generally the development in companies moves much faster than in open source libraries (in terms of # of commits per weeks), and generally in open source world it's expected to have clean, well tested, working solutions rather than hacks that can be fixed tomorrow if needed - and because of that, OS maintainers have higher standards for commits.

agentgt 10y ago

I too admit that I'm a huge Hg fan (will not switch the company code to git) but I also admit history rewriting is a damn worthy feature. At the very minimum I think we can agree that safe rebasing is better than a plethora of merges that really serve no purpose other than to clutter history. The more distributed and diverse/disparate your team is the more I think history editing + cheap branching is worthwhile (but on the opposite end I think Hg consistency is better for corp). One of my greatest challenges in using/understanding Git was(/is still) the reflog. I know the reflog isn't that complicated but there isn't anything really analogous in other SCM (of my limited knowledge of perforce, svn, hg, git). Also for some reason the presentation of the reflog UI wise is intimidating. Reflog is nice gem for git particularly since the builtin Mercurial rollback (I wish they would just remove that command) is fairly awful (use histedit or rebase instead). That being said Mercurials new changeset evolution experimental stuff looks really promising [1]. That being said if you are looking to undo in hg like this article talks about you have to look at the hg unbundle backupfile Unbundle is a pretty nasty command compared to the reflog commands but on the other it is just restoring from some backup file. I'm not too sure how you can transfer reflogs around. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution

ngoldbaum 10y ago
Rollback is deprecated, it doesn't show up in the docs. Because people use it in scripts it will never be removed due to mercurial's backward compatibility guarantees. Mercurial 3.9 ships with the journal extension, which is a bit like the git reflog: https://www.mercurial-scm.org/wiki/JournalExtension https://www.mercurial-scm.org/wiki/JournalExtension
- agentgt 10y ago
  Vaguely remember seeing that extension. I did not know it ships with Hg now! Awesome! More reasons to stick with hg longer for my company :)
krupan 10y ago
I think bundles are easier to understand than the reflog. When you run a command that modifies commits, the original commits are stored off in a bundle file. When you unbundle that file, the commits show back up in your repository history. What could be simpler? The git reflog gives you a weird truncated log view of old commits that is very hard to parse (for a human at least). That being said, I've been using changeset evolution for over a year and it is awesome. Instead of creating a bundle your commits are just hidden. You can run any of your hg log commands with --hidden and it shows you those hidden commits. You can see exactly how your rebase removed (hid) some old commits and created new ones. It's very easy.

dspillett 10y ago

> What's so wrong with keeping an accurate picture of history I think part of the problem is the distinction between history and audit. What you are thinking of is a full audit: every change made by everyone to get to and from each state. History can sometimes be this, but sometimes you just want the solid states and the extra detail of each step between including failed steps that were back-tracked is more information than people want and can result in cognitive overload. Different people want different detail. Sometimes the same people want different detail for different tasks. One option might be for a feature to allow you to mark a commit as intermediate. Keep those with the flag around but don't display them or allow things like bisect to operate on it by default. Display them if an extra option is provided, allow action upon them similarly (not by default, you don't want a typo in a commit ID to result in a commit that exists but is not the one you are looking for to be accessed).

rjbwork 10y ago
I think that's what feature branches are for. You merge to master/default after you're done with your feature, and commit an accurate history to the branch.
- dspillett 10y ago
  Probably, though that isn't something you can do after the fact where a "treat this as a partial result" flag on a commit could be.

krupan 10y ago

No version control system accurately reflects every bit of history that goes into creating and editing your code. You'd have to record every keystroke. The whole idea behind a vcs is to record helpful and relevant history. Is every little merge relevant and helpful history? Hard to say, maybe, but probably not.

paulddraper 10y ago

It's the same reason that history books aren't a bunch of primary sources stapled together. What more better than painstakingly accurate history is useful history. I don't care that Joe was distracted one day and had to make a fix-up commit. I care that he authored a certain change.

darekkay 10y ago

I'm also coming from Hg, and this picture [1] sums up the problem. The history tree in our company is way more messy - basically over 1/3 of all commits are just merges. [1] https://twitter.com/michaelhenke/status/585142133167751169 https://twitter.com/michaelhenke/status/585142133167751169