When did Git become terrible? Let's track down the specific commit...
-
@zecc said in When did Git become terrible? Let's track down the specific commit...:
Mercurial does it.
Mercurial does not do it. It pretends. As long as it is set to synch the repos frequently, it can get away with it most of the time, but there's always a chance that you'll get inconsistencies in the numbering when you've got a divergence, and the possibility of divergences is an inevitable part of being a DVCS (and any DVCS should cope with the fact). The fix is to use a numbering scheme that doesn't depend on sequences, but which is rather an identifier based on a hash of the content of the commit; that works very well but is non-sequential by design. (Yes, you could claim that the sequential numbers are just local things… but people don't do that in reality. They want to be able to say things like “Bug #172209 was fixed by Commit #234589” and that's dangerously meaningless when those IDs are purely local.)
If you want full sequential numbering, use SVN. That has the central authority for a repo, and so can say exactly what a version ID means when it is sequential.
-
@dkf I guess you could set something up with a combination of a date-based sequence and a commit hash or GUID? That has the advantage of at least including when the commit was created, approximately, but is dangerous because it leads to invalid assumptions.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
Mercurial does not do it.
Sorry, I quoted too much. I meant this specifically:
but you could do local numbering.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
You can't do global sequential numbering (as that'd require a non-distributed shared entity to act as an authority for issuing said numbers), but you could do local numbering. As long as you're OK with the number you have for a commit occasionally changing under your feet.
That's one nice thing about
hg
, is that it does use numbering, too, which as you say, works only for a particular repo.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
Yes, you could claim that the sequential numbers are just local things… but people don't do that in reality.
Uh...yes they do.
-
@jaloopa said in When did Git become terrible? Let's track down the specific commit...:
autopilot
Ooooh! Like this one?
-
@greybeard said in When did Git become terrible? Let's track down the specific commit...:
When I were a lad, I had to control source with RCS. Uphill, both ways.
My first source control were Hollerith card boxes. I cried when I tripped on the way to the data center and ended up having to "defrag" my three boxes of cards. I think I sounded like one of those millennials at the time of the election:
FIX THIS SHIT RIGHT NOW!!! – 00:14
— peachysweetener
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
is an inevitable part of being a DVCS
Which is why I get so agitated when people want a DVCS to act like a CVCS (or vice versa). Even worse when a VCS choice is made which conflicts with the overall environment.
Here is a hint: If all of the work comes from a single budget, then at the root, you are centralized!
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Which is why I get so agitated when people want a DVCS to act like a CVCS (or vice versa). Even worse when a VCS choice is made which conflicts with the overall environment.
Here is a hint: If all of the work comes from a single budget, then at the root, you are centralized!There's a difference between administrative centralisation and technical centralisation. Anyone who's ever done significant amounts of coding on long-haul flights ( :() will know why it is useful to not require technical centralisation.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
There's a difference between administrative centralisation and technical centralisation. Anyone who's ever done significant amounts of coding on long-haul flights ( :() will know why it is useful to not require technical centralisation.
I used to do it. I still fly frequently (6 hrs, so pretty close to "long-hual") and work on the plane (totally disconnected). But I almost never work on a production codebase doing "real coding". Being disconnected from all of the other ALM aspects as well as the inability to integrate frequently (and with single focus) is not effective [base on my experience and those of others I deal with regularly].
Instead all of the items that can be effectively done in isolation are my primary focus, so that when I "rejoin the hive" I know exactly what to do (and how to do it). In the end, I will be much further ahead.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Which is why I get so agitated when people want a DVCS to act like a CVCS (or vice versa). Even worse when a VCS choice is made which conflicts with the overall environment.
Here is a hint: If all of the work comes from a single budget, then at the root, you are centralized!I agree with you, but also:
Like if I need feature X, which requires a central server, why can't Git do that also? Like why are "distributed" and "centralized" considered polar opposites? I don't get it.
It's the human beings saying "distributed is different!". There's nothing inherent in the software's design that prevents adding server-side stashes. It knows how to make stashes. It knows how to send stuff to a server.
"But that would make the software more complex!" Oh poor baby, I forgot open source software development was for baby infants who cry constantly and never do any hard work ever. "Waaaah, waaaaaaah."
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
Anyone who's ever done significant amounts of coding on long-haul flights ( ) will know why it is useful to not require technical centralisation.
I've never really understood this assertion. If I've done a Get Latest on the solution I'm working on, I can make changes fine with no connection. I might need to manually remove the read only attribute from files and endure a couple of "can't find the TFS server" warnings, but apart from that the workflow is identical
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Being disconnected from all of the other ALM aspects as well as the inability to integrate frequently (and with single focus) is not effective [base on my experience and those of others I deal with regularly].
Yes, the pace of commits you described earlier is insane.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Like if I need feature X, which requires a central server, why can't Git do that also?
Lots of things can be done (as can be observed by the fact that DVCSs other than git manage quite nicely). But a global list of all commits in sequence isn't one of them; two people could commit at the same time and would therefore get the same ID and at least one of them would need to change the ID when the eventually synchronise. A local list is possible, but it's nothing like as useful as you might hope for since you can't tell those IDs to anyone else safely, yet one of the main reasons for having a commit ID is exactly so that you can talk to other people about it. To be clear, the lack of centrally-issued IDs is a fundamental thing. It can't really be hidden, though 95% of the time it isn't all that important with a sane user interface in front of the DVCS core.
It's not even what I hate about git. ;)
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
Yes, the pace of commits you described earlier is insane.
No doubt it appears insane in the face of the most common practices.... but, have you ever worked on a team that has used it successfully? If not, can a valid judgement really be made? [Presuming you at least accept my claim that there are teams which have benefited greatly - which I could easily support in a different forum/venue]
-
@jaloopa said in When did Git become terrible? Let's track down the specific commit...:
I've never really understood this assertion. If I've done a Get Latest on the solution I'm working on, I can make changes fine with no connection. I might need to manually remove the read only attribute from files and endure a couple of "can't find the TFS server" warnings, but apart from that the workflow is identical
Local Workspaces, and you don't have to worry about the RO bit, or the messages :)
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
Yes, the pace of commits you described earlier is insane.
No doubt it appears insane in the face of the most common practices.... but, have you ever worked on a team that has used it successfully? If not, can a valid judgement really be made? [Presuming you at least accept my claim that there are teams which have benefited greatly - which I could easily support in a different forum/venue]
I can't even imagine what you guys are doing such that every person is making 2-4 commits per hour (that's what I recall the math being based on one of your previous posts).
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Like why are "distributed" and "centralized" considered polar opposites? I don't get it.
You are not alone... But think for a minute, how can something be optimized for both working independently, and working in tight collaboration??? Everything (both human and tech) has significant elements which are the antithesis of the other.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
You are not alone... But think for a minute, how can something be optimized for both working independently, and working in tight collaboration???
Well I can tell you the solution is not "never attempt to work the problem be solving it sounds like it might be kind of hard".
The bigger problem with Git specifically is that they can't really iterate at all without pissing everybody off, because they stupidly made their API the same as their UI. But please tell me again how Linus Torvalds is such a great software engineer...
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
be kind of hard
Not talking about that. For example give me two positive integers that add up to 4 and also add up to 5....fundamentally impossible.
Now there are many sub-optimal points between the two endpoints, no dispute there; and tooling can exist which achieves those goals. But why not simply make a decision about what principles you believe in (Distributed or Centralized) and then go from there?
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Not talking about that. For example give me two positive integers that add up to 4 and also add up to 5....fundamentally impossible.
if( server_is_online() ) { send_stash_to_server(); } store_stash_locally();
Is not fundamentally impossible.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
There's nothing inherent in the software's design that prevents adding server-side stashes. It knows how to make stashes. It knows how to send stuff to a server.
$ git stash Saved working directory and index state WIP on master: 3d33584 $ git push origin refs/stash:refs/heads/foo Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 573 bytes | 0 bytes/s, done. Total 6 (delta 3), reused 0 (delta 0) To ssh://server/directory * [new branch] refs/stash -> foo
Yes, you can have server side stashes. They're called branches
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
I would suggest commit #1, except Git doesn't have proper revision numbers.
Of course it has, just refer to commit e83c5163316f89bfbde7d9ab23ca2e25604af290
-
Well, "Stash" has a meaning in the context of Git, and that is not it....
That being said, the idea that you have local work you want on the server, but not commited to the origin repo is quite common...
Just create a second remote (we are starting to distribute now - no longer having a single remote, which limits things to a pseudo centralized topology)... Push everything you want to that.
-
@cark said in When did Git become terrible? Let's track down the specific commit...:
Yes, you can have server side stashes. They're called branches
Scroll up. Every workplace I've worked doesn't let you create branches that aren't attached to a ticket in the ticketing system. Yes, yes, "this is not Git's fault", etc etc etc repeated ad-nauseum, but that doesn't change the fact that my experience with Git is always a horrible and miserable one.
It also doesn't fix the problem of having to enter a name for the junk commit you only made because you wanted the fucking code on the server, and then the name's there forever.
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Just create a second remote
Yeah that's gibberish to me. Remote what? Server I guess? Wouldn't it be great if the software just fucking worked without me having to do stuff with all this jargon?
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
we are starting to distribute now
And the good ol' bringing "we" into a conversation without defining who the fuck "we" is.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Yeah that's gibberish to me. Remote what? Server I guess? Wouldn't it be great if the software just fucking worked without me having to do stuff with all this jargon?
You have a local clone of an "origin" repository. You create multiple remotes (the origin is the first remote), others can clone from them, etc. etc. etc. -- No branches involved, and 99% of the time "no policies" in place either.
If you and I were working (as part of a larger team) we would create remote that you and I pushed/pulled and then when something was "ready" would push it to the team level remote (so the rest of the team could evaluate), then push it to the organizational remote...
True distribution of the code - completely different than the concept of just "offline" or "disconnected".
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
But please tell me again how Linus Torvalds is such a great software engineer...
I have never said that (or even anything close to that)
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Every workplace I've worked doesn't let you create branches that aren't attached to a ticket in the ticketing system.
I have SVN, and they don't let me create a branch without a new formal project. And sometimes I have to code stuff without a formal project and no branch because process!
Dumb employers can make you miserable with any technology.
-
@wharrgarbl You should install Mercurial locally and use that for your branches and stuff and then just check stuff into svn as required.
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
I can't even imagine what you guys are doing such that every person is making 2-4 commits per hour
We often get quite a bit higher rates than that. (It tends to be particularly when we're debugging the automated test environment, which is just enough different from the one on our desktops that there's no substitute for the fine detail we get out of reading the auto-build logs.) We've enough repositories and branches that we can sustain it without treading on each others toes.
We're a productive team. ;)
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Every workplace I've worked doesn't let you create branches that aren't attached to a ticket in the ticketing system.
That's your workplaces' policies. And it sounds like you've ended up using other mechanisms (stashes) to do the more speculative stuff that might or might not end up as tickets. It's not the tools, but the tools in management. SNAFU.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
automated test environment, which is just enough different from the one on our desktops that there's no substitute for the fine detail we get out of reading the auto-build logs
Curious, why not have the tests run, and (if they fail) review logs and remediate the situation before committing to the repository???
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
Yes, the pace of commits you described earlier is insane.
Do you do TDD? If so, do you follow "Red-Green-Refactor(Blue)"? How long does it take you to write a single minimal test? How long does it take you to write the minimal amount of code to pass that test (without breaking others)?
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Curious, why not have the tests run, and (if they fail) review logs and remediate the situation before committing to the repository???
Because the tests are run in a CI system that updates as a post-commit hook in the repository.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Every workplace I've worked doesn't let you create branches that aren't attached to a ticket in the ticketing system.
But if there was a stash-on-the-server feature, maybe your employer would not let you to create stashes without a ticket?
-
@adynathos said in When did Git become terrible? Let's track down the specific commit...:
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Every workplace I've worked doesn't let you create branches that aren't attached to a ticket in the ticketing system.
But if there was a stash-on-the-server feature, maybe your employer would not let you to create stashes without a ticket?
Why not go all the way and not allow commits without a ticket?
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
Because the tests are run in a CI system that updates as a post-commit hook in the repository.
Yeah, I figured.. My point was more along the lines of why is software not build (compiled and tested) on the server BEFORE there is a commit?? Any failure along the way and the commit simply does not happen [Rejection without server "residue"].
Post commit has many nasty side effects, including the fact that you end up with revision points in the software that are broken.
-
@pleegwat said in When did Git become terrible? Let's track down the specific commit...:
Why not go all the way and not allow commits without a ticket?
That is not "all the way".... Require separate tickets for sign-in on to the dev box and then one for each file that is going to be changed. (yes, I was involved long ago with a company that only granted checkout permission with a ticket).
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Do you do TDD?
No.
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Do you do TDD?
No.
Pity, you really should give it a try. Come to one of my next courses which include an exercise on "Ping Pong TDD" (combining TDD and Pair Programming) and see what can really be accomplished and the value provided.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Yeah, I figured.. My point was more along the lines of why is software not build (compiled and tested) on the server BEFORE there is a commit?
Because developers often have environments that differ a bit from the CI server (in what packages they have installed, etc.) so the only way to get reliable testing is to run them in a standardised environment, which is what the CI server does. There's never any long-term problem with, for example, new files forgetting to be committed this way; their absence shows up pretty much immediately.
Post commit has many nasty side effects, including the fact that you end up with revision points in the software that are broken.
On development branches, yes. On master or release branches, no.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Yeah, I figured.. My point was more along the lines of why is software not build (compiled and tested) on the server BEFORE there is a commit?
Because developers often have environments that differ a bit from the CI server (in what packages they have installed, etc.) so the only way to get reliable testing is to run them in a standardised environment, which is what the CI server does. There's never any long-term problem with, for example, new files forgetting to be committed this way; their absence shows up pretty much immediately.
Post commit has many nasty side effects, including the fact that you end up with revision points in the software that are broken.
On development branches, yes. On master or release branches, no.
You mis-read... I am talking about having all of the work done on the CI Server(s), simply changing the order so that the CI server runs the build and test BEFORE the commit!
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
Pity, you really should give it a try.
Right after bungee jumping.
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
Right after bungee jumping.
Unfortunately they closed the local place [https://www.facebook.com/Emerald-Coast-Bungee-Inc-167664039215/] so you would have to travel a bit between the two.... here are some handy references: https://thirstforadrenaline.com/adventures/bungee-jumping/bungee-jumping-in-florida/
Hope to see you soon :) :) :) :)
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
You mis-read... I am talking about having all of the work done on the CI Server(s), simply changing the order so that the CI server runs the build and test BEFORE the commit!
The CI server doesn't work that way. Nor do our development processes require every commit EEEVVVAAAARRR!!! to be flawless; our process is “work on a development branch, then review before merge” and our tools support that way of working just fine.
But know I know why it takes you so long to actually commit anything. Your tools are configured to block you just in case.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
You mis-read... I am talking about having all of the work done on the CI Server(s), simply changing the order so that the CI server runs the build and test BEFORE the commit!
The CI server doesn't work that way. Nor do our development processes require every commit EEEVVVAAAARRR!!! to be flawless; our process is “work on a development branch, then review before merge” and our tools support that way of working just fine.
Not flawless, simply never broken [every commit is of a condition that the version could be deployed to production. We have virtually eliminated any branching for development [branches are used for service updates to previous versions that are still supported]
But know I know why it takes you so long to actually commit anything. Your tools are configured to block you just in case.
Where do you get that idea. As previously indicated, developers each commit up to 4 times per hour (we also only load at 75% so 45 minutes of planned work per hour, and 15 minutes of "stuff happens"), With a team of 9, that is in the range of 25 commits per hour on average, each one build upon the common latest code with testing being run.
A merge requiring manual intervention (i.e. a checkin conflict is extremely rare, and may happen 1 or 2 times per week, and is always quite trivial, so less than 0.5% of the time) so there is no "blocking" and also very little waster work in "fixing" things to account for other developers efforts [and that alone is a huge savings]
-
@pleegwat said in When did Git become terrible? Let's track down the specific commit...:
Why not go all the way and not allow commits without a ticket?
I enforce that on one of the projects I administer.
-
@heterodox I mean, we do this, but it's enforced upon merging a pull request like it should be. No reason to disallow random branch names, and you don't keep people from naming commits they want to keep temporarily.
-
@jazzyjosh said in When did Git become terrible? Let's track down the specific commit...:
@heterodox I mean, we do this, but it's enforced upon merging a pull request like it should be. No reason to disallow random branch names, and you don't keep people from naming commits they want to keep temporarily.
We don't disallow random branch names. Commits developers want to keep temporarily are fine, but they'll have to keep them locally. Either that or give them a commit message that includes a ticket number, and honestly that might help them remember what they were doing. We've had zero complaints.
-
@pleegwat said in When did Git become terrible? Let's track down the specific commit...:
Why not go all the way and not allow commits without a ticket?
When I was at VMware, we did that. But only in the final release phase - plus the bug had to be approved. (That was on Perforce)