The Official Status Thread
-
-
Is @algorythmics your coworker?
-
It's less water, more hyper corrosive metamaterial. Bathing in it is the source of my superpowers.
-
Is @algorythmics your coworker?
Not that I'm aware of…To be fair, it is short for 'Analysis Codes', which is what the change involved.
-
-
It's less water, more hyper corrosive metamaterial. Bathing in it is the source of my superpowers.
Ah! Then roll for adding "heating water" to your superpowers...
I can see it, close to where you live at one time supplied the majority of the world's Chrome.[1]
Do you emit big silver flashes when you exercise your powers?
[1] Which wasn't a whole lot, because it was before the invention of '50's Automobiles. But still.
-
Status: of course, since it's my article on the front page today, @PaulaBean takes an unplanned vacation.
Paging @apapadimoulis.
-
Status: of course, since it's my article on the front page today, @PaulaBean takes an unplanned vacation.
Conspiracy!
Must be those damned Poles again!
-
Status: it is officially decided. I don't like programming. Sorry. I shall from today on put my efforts towards becoming a sysadmin.
-
Status: regular.
that's somehow a wtf on its own
-
Status: regular.that's somehow a wtf on its own
Can't tell if TMI or Discourse terminology.
-
Can't tell if TMI or Discourse terminology.
Either way, I'm jealous.
Wait, that was TMI, wasn't it...
-
Discourse
TMI == too many information?
-
Is English not your main language?
TMI = too much information. I was insinuating that your comment about being regular had to do with the function of the latter part of your digestive tract.
-
no, it isnt't.
i undestood the joke(in fact, in spanish you can do the same joke), just wasn't sure about the acronym.
-
wasn't sure about the acronym.
//TODO: make an acronym expander bot....
Either way, I'm jealous.
nice....
BTW you can now ask shadowmod for your TL3 trust status.
just PM shadowmod the following text and it should reply with your TL3 trust stats:
@shadowmod trust
(except don't include the ­ that i did to suppress the mention)
-
status: caught up .... 0 unread/0 new
that's not going to last long.
-
TRWTF is still being on Windows XP.
-
Status: it is officially decided. I don't like programming. Sorry. I shall from today on put my efforts towards becoming a sysadmin.
Wanna switch?
Filed under: Fuck your printers on five different versions of Windows connecting to a terminal server (still) using 2003 R2!
-
2003 R2 is still good for a few more months!
-
Ok so I have to work on this pri-1 bug that requires the front-end integration, so I yanked one of the front-end devs over to my desk and we spent a half-hour on this. And still we haven't been able to get their new build script working.
This shit is really pissing me off. Changing the script is annoying enough, but doing it WHILE we have a super important project in QA is just infuriating.
-
Status: About to write a bunch of cURL scripts as a workaround, that will likely stay in place until the heat death of the universe. $DEITY forgive me for the atrocities I am about to commit.
-
And still we haven't been able to get their new build script working.
That's horrible. WTF did they do? Forget to add some stuff or something?
-
I have no idea. We finally got it using the correct URLs for the API, but now it's giving me XSS errors where none occurred before.
I finally just gave up and reverted the file to Feb 2nd before they broke it, I have work to do.
EDIT: BTW about half my Git checkins here have comments that read "check-in to change branches". What a stellar source control system.
-
I just talked to the dev manager about how I lost like an hour and a half of work time due to a front-end guy making a breaking change without documenting it in any form. So.
EDIT: Oh and he scheduled a meeting to talk about it next week.
-
"check-in to change branches"
Huh. I can't even begin to understand how this might work. Not sure if I am TRWTF or git is...
-
basically you need to check in (or stash) your local changes to switch branches. otherwise when you switch branches your local changes would be lost and that's not good.
Filed under: assuming needs advice. assuming not a joke
-
Filed under: assuming needs advice. assuming not a joke, assuming not just wanting to complain
FTFY and added a larger leap of faith
-
Right but the only Git client worth shit on Windows is Visual Studio, which for some reason doesn't support stash.
-
I think we'll have to agree to disagree on that one. Personally i prefer the command line git to any UI laid on top of it.
of course that's probably got something to do with the fact that i know that git version and am less than interested in learning what the UI mapped all the commands to*
* because for some stupid reason they all change names of things on me. I know it's a bad name but you are only introducing confusion if you call it something different than everyone else does! Discoverable consistency beats clarity when you don't have the choice to change the underlying name!
-
EDIT: Oh and he scheduled a meeting to talk about it next week.
Woo hoo! More hours lost!
-
switch branches.
What is "switch branches", other than "sync branches/accalia01/..." instead "sync branches/blakey00/..." If syncing additional new files somehow trashes the existing working copy, I think you have bigger problems...
-
Huh. I can't even begin to understand how this might work. Not sure if I am TRWTF or git is...
Likely the reason you need to do it is the same reason you need to commit before merging, which is that it actually helps prevent data loss. If you bear with me while I commit a false dichotomy for a bit, consider what Subversion does when yousvn switch: It gets the diff between the tree that you are changing away from to the tree you are switching to, and applies that diff to your working copy. If a patch doesn't apply cleanly, then it sticks in conflict markers. Say you had a conflict, and decided that either you switched to the wrong branch, or you just want to deal with those conflicts at a later time.In fact, you don't even need a textual conflict for this to apply; a semantic conflict is good enough.What can you do? Nothing. You can't undo theswitch, because it was a lossy operation and Subversion has destroyed information for you. The same thing happens on 'svn up` (which is like a pull+merge in gitland). In Git, this problem doesn't exist, because switching branches isn't lossy.Edit: actually, I think I lied; I think it's not lossy when there's not a textual conflict.
Edit again: now that I think about it, there probably is technically enough information preserved both in the conflict marker sections and in thefoo.r1234files that you could build a tool that undoes a badswitchorup; though the fact that a quick Google doesn't find one and it's certainly not bundled is... telling.
-
Next week there's nothing going on. That would have been a perfect time for them to dick around with their grunt script.
-
I see, I've never seen a compelling use case for
svn switchin the first place: I just sync all the branches I need locally and work from there. It sounds like your scenario above is validating my choice of workflow?
-
I see, I've never seen a compelling use case for svn switch in the first place: I just sync all the branches I need locally and work from there.
I would love, love, love if Git allowed that.
-
I see, I've never seen a compelling use case for svn switch in the first place: I just sync all the branches I need locally and work from there. It sounds like your scenario above is validating my choice of workflow?
I had to use it to deal with repository rearrangement before -- i.e. someone moves where your project is located with respect to the repository root in a multi-project repo.
-
I just sync all the branches I need locally and work from there. It sounds like your scenario above is validating my choice of workflow?
I...don't really understand what you mean here? You mean you have separate working copies for separate branches?For larger projects, a
switch-based workflow will often be faster, sometimes much faster; it avoids the time for almost-duplicate checkouts, and for closely-related branches will avoid most rebuilding times.Though I will also point out that the same problem (with the caveat I edited in later) arises with plain
svn up.
-
You mean you have separate working copies for separate branches?
Yes. How else would you work on multiple branches at the same time?
-
You mean you have separate working copies for separate branches?
Sure why not?
For larger projects, a switch-based workflow will often be faster, sometimes much faster; it avoids the time for almost-duplicate checkouts, and for closely-related branches will avoid most rebuilding times.
That only applies when first checking it out. If I'm working on a feature, I'll need that branch for a couple weeks-- just the fact I don't have to do bullshit non-checkins in Git would pay for that time.
Yes. How else would you work on multiple branches at the same time?
If you're using Git, the answer is: "FUCK YOU!"
-
This post is deleted!
-
Yes. How else would you work on multiple branches at the same time?
It depends on what you mean by "same time". Sometimes I will have multiple checkouts for different tasks (actually I always go between a couple different checkouts with different build configurations anyway), but I tend to reuse those working copies because of the aforementioned build time benefits. (A full build for us is... 45min--1hr on a very wide machine that I can hammer hard; though there's a long step in there that "can't" be parallelized. So I don't want to go "I need a branch now" and then not be able to do anything for an hour.)If you're using Git, the answer is: "FUCK YOU!"
Wut? Git handles the situation tar is talking about just fine. Just clone your upstream repo again into a new directory.use git stash
If only he had addressed that upthread...Right but the only Git client worth shit on Windows is Visual Studio, which for some reason doesn't support stash.
Not that I agree with the first part, but there you go.
-
Well IDEMSIAR. :/
-
Wut? Git handles the situation tar is talking about just fine. Just clone your upstream repo again into a new directory.
You know very well that while Git may technically allow it, it certainly practically does not.
-
In what way? I honestly have no idea what your objection to its is.
-
I'm sure 1337 Git Haxor is going to prove me wrong, but:
There is no way to checkout a subfolder of a repo (like you can in TFS or SVN); you need to checking the entire repo every time. Not only does this take a long, long time, but it fills up disk a lot quicker.
-
There is no way to checkout a subfolder of a repo (like you can in TFS or SVN); you need to checking the entire repo every time. Not only does this take a long, long time, but it fills up disk a lot quicker.
That is basically true, yes.1That said, I view that issue as mostly orthogonal to branch workflows, which is why I didn't know what you meant. (A partial checkout would be useful regardless of what you do with branches.)
1 A couple caveats. First, if you clone from a local repo, at least on Linux it uses hard links so there is no meaningful increase in disk space; a quick search indicates that it probably should be using them on Windows as well. Obviously that doesn't help if you clone from your central repo instead of a local copy, so to get things all nice you'd have to clone your local copy then adjust the
originremote to point back to your central repo. Second, I don't know if VS Git exposes this, but command-line Git has something call sparse checkouts. This helps some, but isn't a full solution; there's conflicting information, but it seems like you need the whole repository local and it just gives you a partial working tree. I also think that it may still give you the parent directory structure.(Hey @discoursebot, why is the distance between baselines unchanged by <small>?)
-
i'm sure it can be done. something about submodules. anyway in SVN it's way easier
Found it: http://stackoverflow.com/questions/9380704/checkout-subfolder-in-git#9380738
not easy at all.Status Belgium with javascript and race conditions
-
@EvanED - Days Since Last Discourse Bug: -1
-
That said, I view that issue as mostly orthogonal to branch workflows, which is why I didn't know what you meant. (A partial checkout would be useful regardless of what you do with branches.)
True.
File it under "feature every other fucking source control system has but Git does not because Git was designed by shitheads".
