We don't understand TFS and we don't want to.
-
@blakeyrat And if you discard the shelveset without merging it it similarly defeats the purpose of the exercise.
You fast-forward merge the temporary branch with the rest of your work then amend the commit. Or soft-reset it.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@bulb said in We don't understand TFS and we don't want to.:
@blakeyrat said in We don't understand TFS and we don't want to.:
Git has nothing equivalent to those "useless ™" server-side shelvesets
It does. Developer branches. And they are more useful, because they can contain multiple changesets.
If you don't have a space where you can push random work in progress on the server (usually
user/<username>/
oru/<username>
or similar), that's an organisation problem, not a technical one.Totally different. The concept of a Shelveset is short term, and no retention.
Shelveset exists until you delete it (gated checkin does it for you). Git ref (branch) also exists until you delete it (and at least Gitlab has option to delete it when merging it via pull-request). Where is the difference again?
@thecpuwizard said in We don't understand TFS and we don't want to.:
If I want to share a set of files with another developer (and just that one other developer) so they can take a look, or if I want to submit code to the build environment without having a record in SCM, then TFVC can easily do it.
Sharing changes between developers was one of the main reasons we started using Git-Tfs. You can do it with shelveset, but when the other developer unshelves it, the changes will become hopelessly tangled with their own. Git keeps them as separate changesets as long as you tell it to.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Make one change, and the layout of the entire file may change (in fact this is the nature of every XML file, unless the schema declares "Sequence"). So merge can be tedious/painful/errorprone and require manual intervention. Having a checkout time as short of the above virtually eliminates it.
Oh my fucking god, you just made me remember a horrible project with 10 MB generated XMLs that changed on almost every feature, and were generated with magic incantations known only to the guy that did the generation, and then duly forgotten.
And sometimes, they even needed incantations that were not compatible, and the person doing merges were neither of the developers that generated the XML, nor was involved in the features in any way.
Holy hell, I need some brain detergent tonight. (And the repo was ClearCase with an ample sprinkling of shell scripts to do magic stuff that broke in strange and mysterious ways when they could smell that you were in a hurry...)Not that this has anything to do with Git or TFS, so I'll just leave this ratherrandom rant and bow out.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
If I could push a stash to a server without having to make a commit or giving it a name or giving the branch it's in a name, then I wouldn't say that Git lacks server-side shelvesets, because it'd have something equivalent.
Why do you not want to create a commit? A shelveset contains exactly the same kind of information a Git commit does, and is exactly as persistent (exists until you dispose it).
Also, shelvesets do have names, don't they? So why do you suddenly require not having a name in the git case?
-
@lucas1 said in We don't understand TFS and we don't want to.:
This problem would not have happened at all if we were using Git
Because nobody would have been able to work out how to get close to the same position without 100 other problems cropping up first
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
go take a bio break
Is that really how you say "go for a shit" or are you just trying to sound clever?
-
@lucas1 said in We don't understand TFS and we don't want to.:
I rather my source control problems don't get in some zombie state. Git cannot get into that situation as of its nature.
HAHAHAHAHAHAHAHAHAHAHA
-
@lucas1 said in We don't understand TFS and we don't want to.:
I dunno what is so controversial about code review
Nobody is arguing against code reviews. People are saying that in cases where merging doesn't make sense, if it gets to the point of a review there has been wasted work. Try arguing with what's actually been said rather than your shoulder aliens
-
@lucas1 said in We don't understand TFS and we don't want to.:
EDIT: Clarity
This cracks me up every time you add it.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
waitwhat...
Last I checked, diesel pumps DO have a special pumps. Every station I've ever seen has red or black pumps for gas, and yellow pumps for diesel. They are also explicitly marked "DIESEL". Also, the gastank holes are different sizes for gas and diesel so you explicitly CAN'T put a diesel nozzle into a gas tank (or vice versa). I may or may not know this first hand when I pumped gas before getting a coffee.
Is this different in the UK?!?It's similar over here, the universal scheme is:
Diesel: Big nozzle, BLACK colour handle.
Unleaded: Small nozzle, GREEN colour for normal octane/BLUE colour for high octane.Modern cars seem to have very fancy petrol holes now, for emissions control purposes, so I'm guessing even though an unleaded nozzle is smaller than a diesel nozzle the valving wouldn't open unless it's the correct diameter. A WAG though as I've never tried it.
Proper lorries get even bigger diesel nozzles, as I found when I tried to refill a box van from a lorry pump as all the other pumps were in use.
-
@jaloopa said in We don't understand TFS and we don't want to.:
People are saying that in cases where merging doesn't make sense
If there are files where merging doesn't make sense, do those files belong in source control in the first place? Sometimes, yes (e.g., small assets) but they're very much the exception (e.g., DLLs really don't as they're either derived works or background assets). But ultimately, if there's a conflict over such a file as to whether it should change as Developer A thinks it should or as Developer B thinks it should, the major responsibility of the software is to make it possible to decide how to proceed (and the project/organisation has to actually pick how to resolve the disagreement).
Merge tools make social problems (e.g., “whose changes to favour”) easier to resolve, but they don't actually resolve conflicts entirely for you, and there's no particular reason that you have to have a tool. Software won't fix a dysfunctional workplace…
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@lucas1 said in We don't understand TFS and we don't want to.:
We are now making the argument again that people don't know how to use the tools they have and thus we should use them all badly.
Not at all.... Some tools have the ability for one person to know what the others are working on and provide some level of safety against accidentally wasting work....Other tools do not have this capability.... EOD.
That's not really different from normal programming. Sure, tools can handle the merging of text files, but if you're not coordinating development and writing incompatible stuff (or just using different designs for the same thing) then you're wasting a lot of work, too.
Obviously technical solutions can be a band aid for this type of thing but the more I think about it the more I agree with @dkf that it's a social problem.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@greybeard It becomes permanent when you catch the bus, then come back the next morning and have to merge it with the rest of your work. If you delete the branch without merging it anywhere, it kind of defeats the entire purpose of the exercise.
FUCKING BUY SOME BACKUP SOFTWARE ALREADY
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@lucas1 said in We don't understand TFS and we don't want to.:
As for Shelvesets, just push checkout a new branch from your existing working branch and push it to the server.
But then you have to name it, and the names become permanent even if they're just shit like "checking in unfinished because I'm about to miss the bus". Jesus, people, we've had this discussion on this site like 500,000 times, I'm really sick of it. Please anticipate I'm going to make the same arguments as last time and save me some typing, ok?
Because branch names in git (and other DVCS) ARE NOT PERMANAENT.
@blakeyrat said in We don't understand TFS and we don't want to.:
@greybeard It becomes permanent when you catch the bus, then come back the next morning and have to merge it with the rest of your work. If you delete the branch without merging it anywhere, it kind of defeats the entire purpose of the exercise.
Not if you cherry-pick it. Which is, incidentally, exactly the same operation you do with the shelveset when you unshelve, except it can remain a separate changeset if you chose so, which the shelveset won't.
-
@bulb said in We don't understand TFS and we don't want to.:
Because branch names in git (and other DVCS) ARE NOT PERMANAENT.
Branch names are merely labelings applied to the underlying structure.
-
@bulb I read Blakey as saying the commit was permanent. Which it isn’t.
-
@greybeard It's permanent-ish. Except for the things which aren't (such as stashes/shelving).
-
@bulb said in We don't understand TFS and we don't want to.:
@blakeyrat said in We don't understand TFS and we don't want to.:
@lucas1 said in We don't understand TFS and we don't want to.:
As for Shelvesets, just push checkout a new branch from your existing working branch and push it to the server.
But then you have to name it, and the names become permanent even if they're just shit like "checking in unfinished because I'm about to miss the bus". Jesus, people, we've had this discussion on this site like 500,000 times, I'm really sick of it. Please anticipate I'm going to make the same arguments as last time and save me some typing, ok?
Because branch names in git (and other DVCS) ARE NOT PERMANAENT.
@blakeyrat said in We don't understand TFS and we don't want to.:
@greybeard It becomes permanent when you catch the bus, then come back the next morning and have to merge it with the rest of your work. If you delete the branch without merging it anywhere, it kind of defeats the entire purpose of the exercise.
Not if you cherry-pick it. Which is, incidentally, exactly the same operation you do with the shelveset when you unshelve, except it can remain a separate changeset if you chose so, which the shelveset won't.
I wouldn't make a separate branch/stash for this situation.
Generally when I have this situation I just do a commit and push on my feature branch with the prefix "WIP" and a message that indicates things are either broken or very incomplete.
I usually only worry about these kind of commits if it's Friday afternoon or the day before I'll be out for a while on PTO. If it's just a regular Tuesday to Wednesday end of day, I'll just leave the changes uncommitted on my box.
-
@mikehurley Yeah, depends on whether one already has a feature branch or not. If yes, I do the same — push with
[WIP]
prefix and rewind with final version the next day. But that's incidental to whether it covers the same use-case the tfs shelvesets do—it does either way.
-
@greybeard said in We don't understand TFS and we don't want to.:
@bulb I read Blakey as saying the commit was permanent. Which it isn’t.
@dkf said in We don't understand TFS and we don't want to.:
@greybeard It's permanent-ish. Except for the things which aren't (such as stashes/shelving).
It is not permanent. It is immutable as long as something points to it. But for work in progress, you rewrite it and drop the reference to the original and then it's gone.
-
@dkf No it isn’t. As I said, amend or soft-reset it and it’s as if it never happened.
-
@mikehurley said in We don't understand TFS and we don't want to.:
If it's just a regular Tuesday to Wednesday end of day, I'll just leave the changes uncommitted on my box.
About 8 years ago, a client [NYC, big firm, office in a nice building] got robbed. every desktop (mainly laptops with security locks) was gone in the morning. I was interesting seeing the difference between those who always "put" (via various techniques) their work on to a server and those who just left it on their boxes...
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
@mikehurley said in We don't understand TFS and we don't want to.:
If it's just a regular Tuesday to Wednesday end of day, I'll just leave the changes uncommitted on my box.
About 8 years ago, a client [NYC, big firm, office in a nice building] got robbed. every desktop (mainly laptops with security locks) was gone in the morning. I was interesting seeing the difference between those who always "put" (via various techniques) their work on to a server and those who just left it on their boxes...
I'm usually committing and pushing small enough commits that if something like that happened I'd be out for less than a day's work. Not always, but certainly in line with the 80/20 rule. Even if you're out a few days work in that situation, that's still a much lesser problem than developer laptops or workstations being gone.
-
@greybeard said in We don't understand TFS and we don't want to.:
You fast-forward merge the temporary branch with the rest of your work then amend the commit. Or soft-reset it.
Yeah there's no button for that in my Git client.
Here's where you tell me that I'm a stupid moron idiot dumbshit. Go ahead. I'll wait.
-
@bulb said in We don't understand TFS and we don't want to.:
Why do you not want to create a commit? A shelveset contains exactly the same kind of information a Git commit does, and is exactly as persistent (exists until you dispose it).
? Git doesn't even have shelvesets, that's a TFS feature.
@bulb said in We don't understand TFS and we don't want to.:
Also, shelvesets do have names, don't they? So why do you suddenly require not having a name in the git case?
Yes they have names, but the name doesn't go into the actual finished commit when I finish the code.
If you use a branch as a stash, like all these idiot Git fans are telling me to do, that name becomes permanent forever. Even if it's "late for bus gotta go".
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Yeah there's no button for that in my Git client.
Clearly you have to use
git baffle -d -t --finagle-wranglers
but make sure you don't use-D
because that will change a random commit somewhere in the past to replace every.h
file with a lolcat
-
@dkf said in We don't understand TFS and we don't want to.:
If there are files where merging doesn't make sense, do those files belong in source control in the first place?
They belong in change control.
It's convenient to have all files related to the project in the same change control system. Unfortunately, since Git was written by dumbshit jerkwads, that's not possible for several reasons. (TFS is far better at that use case.)
The header image on your application's About screen is source code for the application. Only the morons who created Git would argue otherwise. I guess because you can't display images on the 1983 terminals they use for everything because they hate the modern world and all it stands for.
@dkf said in We don't understand TFS and we don't want to.:
Merge tools make social problems (e.g., “whose changes to favour”) easier to resolve, but they don't actually resolve conflicts entirely for you, and there's no particular reason that you have to have a tool. Software won't fix a dysfunctional workplace…
Nobody's arguing it would.
People are just saying that TFS has a handy feature to tell a developer "hey Jill's already working on this, maybe you should go talk to her before working on the same file". And Git does not. Because Git is terrible.
@bulb said in We don't understand TFS and we don't want to.:
Because branch names in git (and other DVCS) ARE NOT PERMANAENT.
The branch names aren't, but the commit name you have to provide before the code goes into the branch is.
@bulb said in We don't understand TFS and we don't want to.:
Not if you cherry-pick it.
I'm writing code, not fixing a power line.
@greybeard said in We don't understand TFS and we don't want to.:
@bulb I read Blakey as saying the commit was permanent. Which it isn’t.
Via some magical features my Git client doesn't have, apparently. What the fuck ever.
@mikehurley said in We don't understand TFS and we don't want to.:
Generally when I have this situation I just do a commit and push on my feature branch with the prefix "WIP" and a message that indicates things are either broken or very incomplete.
That's what I do, too. It's just less friction than trying to simulate a handy feature that Git simply does not have. I've gotten complaints about it from my manager before, but the response is simply, "hey I'm not the one who chose to adopt Git."
@mikehurley said in We don't understand TFS and we don't want to.:
If it's just a regular Tuesday to Wednesday end of day, I'll just leave the changes uncommitted on my box.
You're probably in violation of your company's computer usage policies. Look it up. I'll wait.
-
@blakeyrat Mine has a checkbox for amending in the commit dialog. I never bother with soft resets; I just amend or interactive rebase the whole feature branch.
But it would be helpful for some if there was a command that combined cherry-pick and soft-reset. Or if the stash commands could track origin.
-
@lorne-kates said in We don't understand TFS and we don't want to.:
Last I checked, diesel pumps DO have a special pumps.
I know diesel pumps won't fit in gasoline cars, but I didn't know there was any protection for the reverse scenario.
Either way, the real point to solving an identified a problem isn't:
I AM SO SMART THAT PROBLEM NEVER OCCURS FOR ME are you a moron idiot moorn STUPID moron idiot? We don't need to fix the problem because only MORON idiot STUPID moron idiots see the problem I am too SMART for that!!!!!
It's more like:
Ok; what can we do to fix that problem for everybody in one fell swoop? Especially since everybody rational (excluding of course lucas1) realizes that even intelligent people make mistakes.
-
@greybeard So far the way to solve this problem is:
- Fast-forward (I have a button like that on my DVD player)
- Amend
- Soft Reset (which I guess is like a soft-boiled egg, but a reset?)
- Cherry-pick (Why cherries? Why picking? What does this even mean?)
So it's great that Git is so usable and discoverable. There's only 4 ways of doing this task, three of them have nonsense gibberish names. Good jorb Git developers.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@mikehurley said in We don't understand TFS and we don't want to.:
If it's just a regular Tuesday to Wednesday end of day, I'll just leave the changes uncommitted on my box.
You're probably in violation of your company's computer usage policies. Look it up. I'll wait.
I just double checked and neither my company's computer use policy nor our data retention policy mention anything about backing up general business data. Specific items are mentioned in the retention policy and does not mention source code or anything else engineering related.
-
@blakeyrat Cherry pick, at least, is definitely in Visual Studio; you can cherry pick all changes on a commit, and they get copied to your local branch much like unshelving a shelveset. It seems to work fine. It still seems like more trouble. But yeah, it's in the right click menu for commits, at least in the history.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
you can't display images on the 1983 terminals
Pfft... Was displaying images well before 1983...
(Hey, I find myself agreeing with nearly everything Blakey has said on this topic - I HAD to find something to disagree with, or it would ruin or relationship :)
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Why cherries? Why picking? What does this even mean?
To cherry-pick is an English idiom, meaning to select only the best things or the things you want from a mixture. E.g, if someone's been cherry-picking the Celebrations, you might open the box to find there are only Bounties left.
-
@carrievs said in We don't understand TFS and we don't want to.:
To cherry-pick is an English idiom,
Great; now why is it in a widely-used source control program? Why not call it "flingeplar". Equally meaningful.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@carrievs said in We don't understand TFS and we don't want to.:
To cherry-pick is an English idiom,
Great; now why is it in a widely-used source control program? Why not call it "flingeplar". Equally meaningful.
Might be a bit limiting to exclude words/phrases that have been in common usage for over 50 years.....
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Great; now why is it in a widely-used source control program? Why not call it "flingeplar". Equally meaningful.
Does the term as used in said program not mean to select only the commits you want? I.e. to cherry pick them in the usual sense of the expression? In what way is it any less meaningful than "clone" or "stash"?
-
@blakeyrat
There are several problems here.- My original example about filling up your car with Diesel car with petrol was meant to address your quite broken thinking that somehow you should be able to use some incorrectly and expect it to work properly.
- You then as the idiot you are, decided to lecture me about shape of nozzles.
- You expect every garage in the UK to change the nozzles because some people are morons. You cannot make the whole world protect people from their stupidity.
- The pumps are colour coded btw in the UK.
- You still don't understand Git and are complaining about it being bad because you use it like a muppet.
-
@lucas1 said in We don't understand TFS and we don't want to.:
You still don't understand Git
To be fair though, you don't understand any of the counterpoints people have been bringing up. You're not even arguing against straw men because you seem to think they're actual arguments
-
@jaloopa I was mostly talking to blakey and he doesn't understand Git because he doesn't want to. Also this "we have a binary file" it might get clobbered ... you still have the history and just rollback the file.
EDIT: I did. Sorry I don't understand the point of exclusive locks, it just seems to make things difficult for no good reason IMHO.
-
@lucas1 If anyone can make a decent case as to why there should be exclusive locks on in TFS. Please tell me.
As I have mentioned I have manage to merge several hundreds of files by myself without issue from several other developers without issue. I don't have a problem doing it, because I am very disciplined when doing such work as I don't want to lose changes.
-
@lucas1 said in We don't understand TFS and we don't want to.:
I don't think you really understand Git. I used to bitch and moan about it until I learned how it work.
And then there are those of us who are sane, for which the opposite is true: the more we come to understand Git, the less we like it!
-
@masonwheeler I just don't see it. I used to bitch and moan a lot about stuff. But I worked in some really iffy places where everything was fucked and I am just not that precious about it.
I've used Git in largish teams and it works fine. Sure there is the odd thing I don't like but I can get over it.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@greybeard said in We don't understand TFS and we don't want to.:
You fast-forward merge the temporary branch with the rest of your work then amend the commit. Or soft-reset it.
Yeah there's no button for that in my Git client.
Here's where you tell me that I'm a stupid moron idiot dumbshit. Go ahead. I'll wait.
You stupid moron idiot dumbshit. Don't use a GUI client. They all suck.
-
@boomzilla I use the command line client a lot even in TFS. TBH in few years I think I will just be using Vim, Powershell and Web-browser.
-
@lucas1 I avoid GUI source control clients as a rule. Using the CLI has always been a superior experience.
-
@lucas1 said in We don't understand TFS and we don't want to.:
You then as the idiot you are, decided to lecture me about shape of nozzles.
You obviously missed the point.
The designers of gas nozzles (gas nozzles!!!) are doing a better job of accident-proofing their product than the developers of Git. And they have to change 5,000,000 pumps, not just one codebase.
Sooner or later, everybody's going to make a mistake. The point is the tools you use need to acknowledge that, and include features that make mistakes both less common and less harmful when they occur. Git doesn't. Because it's shitty.
@lucas1 said in We don't understand TFS and we don't want to.:
You still don't understand Git and are complaining about it being bad because you use it like a muppet.
My understanding of Git is not at all relevant. Have I said anything about Git in this thread that's objectively untrue? If so, point it out. Please do.
@lucas1 said in We don't understand TFS and we don't want to.:
Also this "we have a binary file" it might get clobbered ... you still have the history and just rollback the file.
You can't rollback wasted labor. Unless you have a Tardis I guess. That's a British reference for you British people out there. It's a time machine. Get it? Haha.
@lucas1 said in We don't understand TFS and we don't want to.:
If anyone can make a decent case as to why there should be exclusive locks on in TFS. Please tell me.
Been done in this thread by multiple people, you so far haven't indicated even slightly that you understand their arguments.
-
@boomzilla I agree. I really don't get Vim Diff so I use KDiff but otherwise yeah I am working mostly from the commandline.
-
@GodEmperor said in We don't understand TFS and we don't want to.:
If anyone can make a decent case as to why there should be exclusive locks on in TFS. Please tell me.
To annoy you. Solid.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
You can't rollback wasted labor. Unless you have a Tardis I guess. That's a British reference for you British people out there. It's a time machine. Get it? Haha.
This wasted labour argument is total crock. Fuck ups happen ever so often.