10 ms·

Allow me to disagree with your disagreement. Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and o

Allow me to disagree with your disagreement. Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and one can easily get themselves into trouble. This is why there are Git guides and tutorials and UIs and they are all ultimately unsatisfying when you're a beginner. However the use case discussed in this article is NOT a beginner use case. It is an advanced case and the fact that Git is an advanced tool that supports it (both natively with git-filter-branch, as the author found out, and ad-hoc-ly as was their original plan is a testament to the power of the system. Tell me how you would better achieve the requirements that were the premise for this article in a different VCS?

jasoncchild 10y ago
I agree with your disagreement. Furthermore, I'm curious how this edge case could have been mitigated using an alternative tool? most of my VCS experience is with git, and a very little SVN.
- agentgt 10y ago
  As an experienced Hg user I will say what the author did would be about the same pain level in Hg (maybe even less if you use some extensions). Regardless it is probably less painful with whatever tool you are most familiar with. I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc). Of course it his hard for me to tell with out seeing his exact repository (files).
  - AstralStorm 10y ago
    In SVN, this case would completely explode into manually applying a big patch.
  - Someone 10y ago
    "The easiest strategy in a case like this is usually to (go) back in time [...] That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them." "a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it. That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138 http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.
    - saghm 10y ago
      > If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. Maybe I'm just too young to have a good perspective on this (due to only becoming a developer after git was fairly well established), but I thought that version control itself is supposed to be your backup
      - y4mi 10y ago
        it is for as long as your repository is undamaged. its rare, but sometimes a repository can get damaged beyond repair. keeping it inside of a cloud storage directory like google drive, dropbox or similar makes it prone for fatal errors. in such a scenario a backup of the full repository is required. in gits case, remote sources can fill the 'backup' role pretty easily, as everything gets pushed to a remote server. this is obviously not enough safety if you're a bigger enterprise, they'll need additional safety guards/backups, but its sufficient for most people.
      - Someone 10y ago
        A backup by necessity is a copy; with centralized version control as svn is, you don't have a copy of the repository, so you have to make one some way. (Decentralized version control is only slightly different; if you lose the 'main' repository and don't have an exact clone (aka a backup), you may be able to glue together something from other repositories that is close to or equal to what you had, but there is no way to know for sure)
- ams6110 10y ago
  The edge case could be mitigated by having a pre-defined development workflow and not seat-of-the-pants cowboy commits of "backend" and "frontend" changes that were in reality interwoven. Or even a basic code review where someone hopefully would say "WTF are you doing!?"
  - SOLAR_FIELDS 10y ago
    Agree - this should have been a single push and dev should have squashed commits together where it makes sense to. I get in the dev stage you might be all over the place but a well-designed codebase with separation of concerns should have allowed the dev to group like commits into single areas and brought it down to something more manageable like 20 commits instead of 400.
ksk 10y ago
What is advanced about a partial checkin?
- Ajedi32 10y ago
  Nothing. The author stated though that the merge had to be done: > without losing the commit history and messages Otherwise a "partial checkin" (which was exactly what "co-worker X" did) would have worked fine.
  - ksk 10y ago
    Ah okay, my bad.. I was mis-reading the article. I get it now. The topic branch commit history where the co-worker built up the branch would be lost if you just tacked on the leaf node to the master branch..
ap22213 10y ago
DVCS is fundamentally a simple concept. And, every use case should be possible with a series of elemental operations. Any 'advanced' use cases can and should just be 'macros'.
- kobeya 10y ago
  Not sure why you are being down-voted. What you describe is the philosophy of e.g. monotone, which works quite well.
- jack9 10y ago
  > DVCS is fundamentally a simple concept It is, if you're going to simplify it so far as to avoid the problemspace by nomenclature. It's just transforming nonlinear events into a linear sequence! I guess multithreading is also a fundamentally simple concept, in that vein.
  - ap22213 10y ago
    I don't mean to minimize the effort that went into Git. But, have you ever looked at the source code? It's like someone dropped the kitchen sink into the global namespace. The whole code base is full of premature optimizations. And, there's a lot of low-level infrastructure code coupled in with the core logic. I know abstraction is out of fashion these days, but it may have helped a little in organizing things. Abstraction, when used properly, can almost always make complicated things more simple. Basically, if a regular person had created Git, and not a demigod, would it even have become what it is?
    - Hello71 10y ago
      we would have hg. as a user, I'll take premature optimizations over slow as balls any day.
      - ap22213 10y ago
        The problem with premature optimization is that most of it has little effect on overall performance. Software performance almost always follows a Pareto distribution. But, wtf do I know, I'm just some regular person.
pg_is_a_butt 10y ago
i'm pretty sure a beginner is at some point going to add 16 new files and edit a few other files. you're all idiots.

jasoncchild 10y ago

I agree with your disagreement. Furthermore, I'm curious how this edge case could have been mitigated using an alternative tool? most of my VCS experience is with git, and a very little SVN.

agentgt 10y ago
As an experienced Hg user I will say what the author did would be about the same pain level in Hg (maybe even less if you use some extensions). Regardless it is probably less painful with whatever tool you are most familiar with. I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc). Of course it his hard for me to tell with out seeing his exact repository (files).
- AstralStorm 10y ago
  In SVN, this case would completely explode into manually applying a big patch.
- Someone 10y ago
  "The easiest strategy in a case like this is usually to (go) back in time [...] That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them." "a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it. That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138 http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.
  - saghm 10y ago
    > If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep. Maybe I'm just too young to have a good perspective on this (due to only becoming a developer after git was fairly well established), but I thought that version control itself is supposed to be your backup
    - y4mi 10y ago
      it is for as long as your repository is undamaged. its rare, but sometimes a repository can get damaged beyond repair. keeping it inside of a cloud storage directory like google drive, dropbox or similar makes it prone for fatal errors. in such a scenario a backup of the full repository is required. in gits case, remote sources can fill the 'backup' role pretty easily, as everything gets pushed to a remote server. this is obviously not enough safety if you're a bigger enterprise, they'll need additional safety guards/backups, but its sufficient for most people.
    - Someone 10y ago
      A backup by necessity is a copy; with centralized version control as svn is, you don't have a copy of the repository, so you have to make one some way. (Decentralized version control is only slightly different; if you lose the 'main' repository and don't have an exact clone (aka a backup), you may be able to glue together something from other repositories that is close to or equal to what you had, but there is no way to know for sure)
ams6110 10y ago
The edge case could be mitigated by having a pre-defined development workflow and not seat-of-the-pants cowboy commits of "backend" and "frontend" changes that were in reality interwoven. Or even a basic code review where someone hopefully would say "WTF are you doing!?"
- SOLAR_FIELDS 10y ago
  Agree - this should have been a single push and dev should have squashed commits together where it makes sense to. I get in the dev stage you might be all over the place but a well-designed codebase with separation of concerns should have allowed the dev to group like commits into single areas and brought it down to something more manageable like 20 commits instead of 400.

ksk 10y ago

What is advanced about a partial checkin?

Ajedi32 10y ago
Nothing. The author stated though that the merge had to be done: > without losing the commit history and messages Otherwise a "partial checkin" (which was exactly what "co-worker X" did) would have worked fine.
- ksk 10y ago
  Ah okay, my bad.. I was mis-reading the article. I get it now. The topic branch commit history where the co-worker built up the branch would be lost if you just tacked on the leaf node to the master branch..

ap22213 10y ago

DVCS is fundamentally a simple concept. And, every use case should be possible with a series of elemental operations. Any 'advanced' use cases can and should just be 'macros'.

kobeya 10y ago
Not sure why you are being down-voted. What you describe is the philosophy of e.g. monotone, which works quite well.
jack9 10y ago
> DVCS is fundamentally a simple concept It is, if you're going to simplify it so far as to avoid the problemspace by nomenclature. It's just transforming nonlinear events into a linear sequence! I guess multithreading is also a fundamentally simple concept, in that vein.
- ap22213 10y ago
  I don't mean to minimize the effort that went into Git. But, have you ever looked at the source code? It's like someone dropped the kitchen sink into the global namespace. The whole code base is full of premature optimizations. And, there's a lot of low-level infrastructure code coupled in with the core logic. I know abstraction is out of fashion these days, but it may have helped a little in organizing things. Abstraction, when used properly, can almost always make complicated things more simple. Basically, if a regular person had created Git, and not a demigod, would it even have become what it is?
  - Hello71 10y ago
    we would have hg. as a user, I'll take premature optimizations over slow as balls any day.
    - ap22213 10y ago
      The problem with premature optimization is that most of it has little effect on overall performance. Software performance almost always follows a Pareto distribution. But, wtf do I know, I'm just some regular person.

pg_is_a_butt 10y ago

i'm pretty sure a beginner is at some point going to add 16 new files and edit a few other files. you're all idiots.