50 Versions of Shed Control Wars
-
But how can you talk to your colleagues when they are distributed?
It helps if you can yell really loudly, like me.
-
No. There can be no centralization. Git is not compatible with centralization.
-
I'm sure many people have been making this joke since git was created, but did the creator name it after himself?
git
/ɡit/
noun BRITISH informal
an unpleasant or contemptible person.
-
I'm sure many people have been making this joke since git was created, but did the creator name it after himself?
i like to pretend that he did, because he was misinformed at what
gitactually meant and by the time anyone stopped laughing long enough to correct his definition the name was already far too widespread to change.
-
From the git FAQ:
[quote=Linus Torvalds]I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'.[/quote]I like to think that's true, and it certainly matches what little I know of him.
-
No. There can be no centralization. Git is not compatible with centralization.
But...but...easy change! 95% needs none! How can this be‽
-
i like that. and even better it's not incompatible with my "version" of the truth!
in fact, they can be automerged!
-
There have been, at least, three mutually incompatible explanations of why the people against locking don't want to think about how to implement locking.
- It is unnecessary.
- It is impossible.
- Just talk to your teammates.
According to proponents of 1, you shouldn't ever need to lock files. Git is distributed, so just the notion that a centralized system could exist at all is contra natura. It doesn't matter if it is possible or impossible. Doing it by talking to people is just as wrong as implementing an automated system to do it.
People claiming 2. recognize that the requirement exists and could be useful at times. But given the distributed nature of git, it isn't possible. This is incompatible with it not being necessary.
If someone says that it is not necessary, and on top of it, it can't be done, they would fall under 1. The same as someone saying "it isn't necessary, but this is how you'd do this wrong thing you shouldn't ever do".
The third group contradicts the second, of course, because while they also admit that it could be useful, they show that it is in fact possible to do it (by using mechanisms that bypass git such as skype or irc). Why it is that you can rely on these centralized systems, but git can't, is not explained.
The really amazing thing is how the same people can switch between these incompatible positions.
-
Why it is that you can rely on these centralized systems, but git can't, is not explained.
There's a fourth, that says that if people have local copies prior to the lock being made, people can get around the locks.
A lot of the argument was people saying that locks often cause more problems than they solve.
-
did we figure out how to lock a file in git, yet?
If I really truly had to do this, in git or any other DVCS, despite the fact that the requirement makes very little sense to me, I'd do it by having the dev teams adopt the following convention:
-
Any file deemed impractical to merge (e.g. contentious.png) would have a normally-empty text file added next to it in the tree (e.g. contentious.png.lock).
-
Before doing major surgery on contentious.png, alter contentious.png.lock to contain just your own username or email address, and make sure you can push it to the central repo without generating a merge conflict.
-
When you're done messing with contentious.png, make contentious.png.lock empty again before pushing both to the central repo.
This would not actually prevent devs from working independently on contentious.png, but seeing a merge conflict on contentious.png.lock would alert you before doing any such work that you might be better off waiting for the other dev to finish up first.
-
-
contentious.png
Straight up from the West Coast, kickin' dope old-skool rhymes yo, it's the Contentious P.N.G.
-
The really amazing thing is how the same people can switch between these incompatible positions.
They don't see them as being incompatible. For a lock to actually work, you have to have an authority on what is and isn't locked. With a DVCS, you don't have such an authority. On the other hand, a DVCS also doesn't lose your work. Just because someone else has made a change doesn't mean that you can't. You “just” get a divergence, i.e., an unexpected branch. What that exactly looks like depends on the DVCS; git has one model, but it is surely not the only viable one.
The way to resolve divergences is through team communication so that you can agree what the overall results should be, and then someone has to make it be like how people have agreed it ought to be (a suitably smart merge tool might help with this, but it's still ultimately a person who does it). Or you can agree that certain files are typically only edited by a single person, so making it much less likely that that file will be the immediate cause of a divergence1. DVCSs don't deal with that sort of thing; there are many other fine approaches (and innumerable terrible ones ;-)).
1 Some people are a bit of a disaster area here. To be fair, they also cause trouble for a centralised system too.
-
Hm, would the bitcoin way of reaching consensus work? Though I think requiring proof of work could be problematic.
-
After all this, you still don't get it. The point is communicating that a users branch will be unmergeable before they spend time making it.
-
Git has branching, your point is invalid.
-
Git has branching, your point is invalid.
I don't think you understood my point: blakeyrat oversimplifies and misunderstands. I'll grant that it was a bit of an indirect shot.
-
I the kind of person who is always holding down Shift when I delete files in a UI, to save having to then perform an unrelated task to get the disk space back.
Me too.
I often follow it up by trying to recover the file back via a deleted file recovery program like recuva.
-
The point is communicating that a users branch will be unmergeable before they spend time making it.
Actually, the deep point is that people who spend ages working on something without committing any of it are bad at collaborating. If you're committing reasonably frequently, the amount that things can diverge is pretty small (unless the developers deliberately choose otherwise, i.e., they set out to start a new branch).
For all the above (hundreds of posts of discussion), I've never seen a team where two developers deliberately set out to edit the same piece of non-source at once. Teams usually split up responsibilities quite well when it comes to those things; the level of conflict tends to be low.
-
-
-
I always think of the country when I see PNG1. I have friends there.
1Ok, not always; I do sometimes think of the image format.
-
I'm sorry, I'd gone into a mode where I was just repeating a parody of the other side's arguments back at them, without rhyme or reason. I normally assume that blakey is suffering from the same thing socrates had: the belief that if you point out what's wrong with everything that people will eventually fix all the problems and thank you for your insight.
As for me, I like git. It's my VCS of choice, though it mostly seems like an iceberg that I haven't yet scratched the surface of. What set me off was that a bunch of people were saying that something was literally impossible. I did a bit of research to see if there was a good way to do it, and wasn't satisfied with any of the solutions I saw, compared to the type of thing I could imagine, so I rolled up my sleeves and jumped into the flamewar, hoping to be enlightened.
-
I always think of the country when I see PNG
I think of kicking people out of a country.
-
so I rolled up my sleeves and jumped into the flamewar, hoping to be enlightened.
What could go wrong‽
-
jumped into the flamewar, hoping to be enlightened
The light/heat ratio tends to be rather low.
-
What would be a good choice [for large assets]?
Set up a git annex containing all your large assets and use it as a submodule in your main project.
Advantages of this approach are:
- Git annex does intelligent packing: if parts of multiple versions of you binary asset are the same, they are stored only once and referred to multiple times
- The large binary files aren't stored in git itself, only some metadata. Git becomes really slow when used on large repositories. Git annex circumvents that frustration.
- In your main project, you reference a specific version of the subproject. Your code and the assets it uses are in sync. If you revert your main project to an earlier version, the corresponding earlier version of the assets repo will be used.
- Git annex doesn't require you to download any large binary files if you don't want to. If you don't have a file that is part of the annex, it will just be a dangling symlink.
Downsides are the usual caveats with git submodules. They are not immediately intuitive to use, it takes some time before you have wrapped your head around how they work.
You also have to not only lean plain git, but also git submodule commands and git annex commands.
-
Disadvantage: usability NIGHTMARE, nobody can figure out how to work the fucking thing, oh crap someone did the wrong thing and now everything's broken.
-
Disadvantage: usability NIGHTMARE, nobody can figure out how to work the fucking thing, oh crap someone did the wrong thing and now everything's broken.
git makes it pretty hard to irrevocably break shit. Granted, it may take some time and effort to revert back to a usable state if you screw up, but there is a way back.
If the expected workflow is well documented, there should be no chance of someone fucking it up. If you or your coworkers can't be bothered to read instructions on how things need to be done, well, then there are bigger problems.
Both git submodules and git annex have GUI frontends, by the way.
It's only a NIGHTMARE if you expect to work the system like a pro without requiring any education on how the system works.
-
It's only a NIGHTMARE if you expect to work the system like a pro without requiring any education on how the system works.
Exactly this, although one must always remember the audience they are talking to and adjust expectations accordingly.
-
Exactly this, although one must always remember the audience they are talking to
Yes.
and adjust expectations accordingly.
No, at least not always.
The whole principle is wrong; it’s like demanding that grown men live on skim milk because the baby can’t eat steak.
<footer>- The Man Who Sold the Moon, Robert A. Heinlein</footer>
-
Point taken.
-
EVERYONE WHO WANTS TO EAT STEAK SHOULD BE ABLE TO EAT STEAK. COWS ARE TERRIBLE ANIMALS BECAUSE NOT EVERYONE CAN EAT THEM AS STEAKS.
<invalid>
-
EVERYONE WHO WANTS TO EAT STEAK SHOULD BE ABLE TO EAT STEAK. COWS ARE TERRIBLE ANIMALS BECAUSE NOT EVERYONE CAN EAT THEM AS STEAKS.
I agree, and as a solution, I propose we kill all the cows for being terrible animals.
-
EVERYONE WHO WANTS TO EAT STEAK SHOULD BE ABLE TO EAT STEAK. COWS ARE TERRIBLE ANIMALS BECAUSE NOT EVERYONE CAN AFFORD TO EAT THEM AS STEAKS, SO THE GOVERNMENT SHOULD PROVIDE EVERYONE WITH STEAKS.
FTF whoever is on the other side of that debate.
-
-
Somebody said that about git?
Well, it's true. It's also true that it remains not intuitive for rather a long time after “immediately” as well. Just when you think you're getting the hang of it, *bam* it gets you with yet more confusion.
I do not like git. I just don't dislike it quite as much as I dislike svn; svn's the one that has been a real burden on me in the past, as opposed to being merely irksome.
-
svn's the one that has been a real burden on me in the past
Was that before or after they figured out how to do merging?
-
Was that before or after they figured out how to do merging?
Pass. Don't know.
I learned to use git because we took a policy decision to move our code to github (for social networking reasons) and I got the task to do the migration. Someone had to do it…FWIW, the code was better for the move. Before, it'd been one gigantic ball of mud (the poster child for Jeffing a SVN repo) so part of what I was doing was extracting everything and stopping it all from being one mulched morass. It was not a textbook migration…
-
I normally assume that blakey is suffering from the same thing socrates had: the belief that if you point out what's wrong with everything that people will eventually fix all the problems and thank you for your insight.
Not even. Socrates was good at it.
-
-
Of course, he could have just taken the plea bargain. Funny that lawyers are taught the Socratic method as a basis for negotiation.
-
IRC? Skype chat? Discourse?
My colleagues are distributed across a hallway. I usually just get up and walk to their offices.
The ones in other states, I pick up this archaic thing on my desk called a phone, and call them.
-
My colleagues are distributed across a hallway.
Just because I sit next to my colleague doesn't mean that I won't use electronic means to communicate with them. It sure beats spelling URLs out loud.
-
Just because I sit next to my colleague doesn't mean that I won't use electronic means to communicate with them. It sure beats spelling URLs out loud.
Sure, use the appropriate method.
-
-
use the appropriate method.
For a lot of non technical colleagues, it's the cluebat. Unfortunately it needs administering remotely most of the time, and work won't invest in such technology.
-
Unfortunately it needs administering remotely most of the time, and work won't invest in such technology.
I'm not sure that an internet-delivered cluebat is current off-the-shelf technology. Business opportunity perhaps?
-
I'm not sure that an internet-delivered cluebat is current off-the-shelf technology.
Quite. I told the people with money we'd be first to market but apparently being the ISP who remotely assaults customers and/or employees doesn't improve NPS.
-
Quite. I told the people with money we'd be first to market but apparently being the ISP who remotely assaults customers and/or employees doesn't improve NPS.
Awwww, and I was already thinking about the domain. (Apparently,
clueb.atis athinghost already…)
-
Papua New Guinea - Wikipedia
