Well-reasoned anti-Git article
-
Oh fuck off. There's no way that non-centralized issue tracking makes any sense at all. How do you plan bug fixing and give estimates if only a random selection of the team has even seen the bug? How do you document what bugs were fixed if it's not in a central server? You just wander around asking everybody? How do you manage any kind of certification or audit of your process? Just tell the auditors "trust us, we have bugs. Somewhere. Sometimes."?
Oh hey, now that I think about it, non-centralized issue tracking is a huge WTF in the exact same ways non-centralized source control is.
Now stop barfing wrong bullshit into my thread and go away.
-
What?
Decentralised bug tracking?! TDEMS.
edit: blakeyhanzo
-
Decentralised ≠ unsynchronised…
-
Decentralised ≠ unsynchronised…
Oh so by decentralized what you mean is "centralized." Sorry. For a moment I assumed you weren't being a fucking retard, but obviously that was my mistake.
-
Synchronised ≠ centralised…
-
Synchronised ≠ centralised…
now normally i'd be inclined to side with you against anyone else but.....
do you have a particular system in mind that is a decentralized synchronized bug tracker?
i mena theoretically such a thing is possible but i haven't ever heard of one.
-
do you have a particular system in mind that is a decentralized synchronized bug tracker?
…no.
-
<small><small><small>…no.
<!-- Emoji'd by MobileEmoji 0.2.0-->
aaah.
wanna make one?
i could use a new project to get my paws wet using Hg
-
Synchronised ≠ centralised…
DO ALL THE BUGS END UP IN THE SAME PLACE?!
YES?
THEN IT'S FUCKING CENTRALIZED AND GET THE FUCK OUT OF MY THREAD. <wanker>
-
DO ALL THE BUGS END UP IN THE SAME PLACE?!
Yes and no; they end up in several places all at the same time
-
So you have five separate systems of record for bugs, each used by one of the five developers on the team. A sixth developer joins, with a sixth system. How do persons 1-5 all know to get bugs from him? If it's at all automated, there's a master list someplace in a central location -- the system of record for maintaining the list of peers. Already, you're centralizing, in that you need a central location to get that list from.
Now, you want them to be synchronized, which means they can't get too far out of sync with each other. Which means after every action, each of them has to contact all six other peers. But two are in California, two are in New York, and two are in Singapore. So they're not synched unless they're always connected to the internet. When the Singapore nodes inevitably fix and close bugs the California nodes were working on because they didn't manage to grab the latest updates due to a connectivity issue, now you have conflicts to resolve in your fucking bug tracker on top of the inevitable conflicts in your repository. Really, what you want to do is replicate the California bug repository someplace that won't go offline ever, so that the Singapore people can always be sure they have the latest bug status. And hey, since you have this master list of peers on a server, you might as well put it there....
It's technically possible, maybe, if you're wiling to put in a ton of work manually and put up with a lot of error, but it's not a good idea.
-
It's technically possible, maybe, if you're wiling to put in a ton of work manually and put up with a lot of error, but it's not a good idea.
We're having a go anyway
-
@Bulb said:
The whole point in distributed is that you don't need to create the branch on server before you start to work.
Except you do, because you have to create it from JIRA/Stash so it has the correct branch name and is linked to the correct JIRA ticket number. And there's no way to create a local-only branch from the server.
That complicates the matter, because you have to go to the Stash interface and ask it to create the branch, but that still does not imply that you have to do that before creating your local branch or the relevant commits. Because the local branch and the remote branch are different things. So you can create a branch locally, test whatever you need there and then ask the server to create the branch and push the commits to it by explicitly giving the target name now it's been created by Stash.
Or you can use stash to emulate the Subversion way in a way that is still safer than subversion, because the stashed changes are a commit that can be returned to if you get into problems during the merge.
By the way, git does allow switching branches with local changes, it does not allow switching revisions. If the branch is created from the same revision on which you based the experiments, you should be able to switch just fine.
-
It's technically possible, maybe, if you're wiling to put in a ton of work manually and put up with a lot of error, but it's not a good idea.
well obviously!
but it'll be fun to have the project go down in flames. pretty too if we manage to make it to a minimum safe distance.
-
Oh, look, even you believe your own statement is bullshit. So Git is somehow simultaneously simpler and harder-to-understand. It exists in a quantum WTF state until you open the lid of the box and find out it killed your cat.
Simple and easy are not synonyms.
It's like with the quantum states. The Schrödinger's equation is simple: 
. That does not make it easy to understand. It is not.Besides, I didn't actually say git was simple. I said not having a central server makes things simpler. Which is does: most things can be done locally and the synchronization protocol needs fewer commands than if all the other operations need to communicate with the server and treating the history as simple directed acyclic graph used to avoid need for central server also happens to make mergeing simpler.
But Git is not simple. The low level model (which is basically the same as other DVCSs) is, but the UI is pretty complex. It also isn't very logical. Many places are a complete mess.
The problem is the now-possible features are ones nobody asked-for or wanted, but now everybody is stuck with the complexity. The complexity of the simplicity. Or whatever the fuck you were word-barfing earlier.
There is no additional complexity in the model. There is complexity in the UI of Git in particular. There is, however, a change in the model and if you treat distributed system as subversion, you'll be hitting it all the time. Because it is not more complex, but it is different and it is different at a level you need
You just told me I was doing it wrong.
You were. For one thing I didn't know
server you use, but for other I still think you are creating work for yourself by treating the git as subversion, which it isn't. The model is not more complex, but it is different and it is different at a level where it matters at the user level.File locking.
Yes, I mentioned it. It's a specialist feature most projects don't use. For the ones that do it is possible to add server on top of the distributed model. I am not sure if anybody did for git, but I am sure for at least one of bazaar or mercurial it exists.
-
But Git is not simple. The low level model (which is basically the same as other DVCSs) is, but the UI is pretty complex. It also isn't very logical. Many places are a complete mess.
QFT. I've seen it described as “misanthropic” in quite a few places, and that's pretty mild IMO. There are things that it is possible to do in git that are really hard with other systems, but $DEITY knows I'd really rather not tinker with things at that level. So I almost always use Git via Eclipse, and that keeps most of the crazy away from me. (Not all, but oh well, and then there's the “bonus” Eclipse-isms…)
-
There are things that it is possible to do in git that are really hard with other systems, but $DEITY knows I'd really rather not tinker with things at that level.
It's a bit ironic. We all rail about NIH, but then, this is part of why it happens. Whenever you try to use something someone else built, it seems like a case of, "It mostly does what I need, but not quite, and we'll have to hack some things in to make it work for what we need."
-
Is there a GitHub equivalent for Hg?
Yes. GitHub. Since Mercurial can clone and push to Git repositories and vice versa…
to that end i am working on migrating all my projects to mercurial
Just start using mercurial with them.
-
@accalia said:
to that end i am working on migrating all my projects to mercurial
Just start using mercurial with them.
It'd save having to migrate all the code to BitBucket (or elsewhere)…
-
-
BitBucket (or elsewhere)
I have stuff in hg repos on bitbucket and sourceforge and some other private places. Never tried using hg-git before. But I might if I ever need to work with something in git.
-
There is no additional complexity in the model. There is complexity in the UI of Git in particular. There is, however, a change in the model and if you treat distributed system as subversion, you'll be hitting it all the time. Because it is not more complex, but it is different and it is different at a level you need
What the hell are you talking about.
You were. For one thing I didn't know server you use, but for other I still think you are creating work for yourself by treating the git as subversion, which it isn't.
In what way am I treating Git as Subversion? Enlighten me.
-
In what way am I treating Git as Subversion? Enlighten me.
In thinking that there is any relation between local branch and remote branch. Or at least that's what I understood from the description of the problems you have with it. I might be wrong of course.
-
In thinking that there is any relation between local branch and remote branch. Or at least that's what I understood from the description of the problems you have with it. I might be wrong of course.
You should know by now that @blakeyrat is always right, even when he's wrong. Especially when he's wrong
-
In thinking that there is any relation between local branch and remote branch.
Obviously I know you can create branches locally, duh. And they don't get created on the server until I push/sync them, duh.
What you're not getting is that the Git server I'm using, Stash, doesn't allow push/sync on branches it hasn't created. (Not in so many words, but that's the de-facto limitation, since the branch needs to be associated with a JIRA ticket and the only way to associate a branch to a ticket is to create it in JIRA.)
Or at least that's what I understood from the description of the problems you have with it.
If you're confused, ask questions. Don't tell me I'm doing it wrong.
I might be wrong of course.
You're wrong on a great many things, just here in this little thread.
-
Stash, doesn't allow push/sync on branches it hasn't created.
Oh, I understood that. But I would still create a branch locally, test whatever I need and when I got something to push, I'd go to the server, tell it to create a branch and push to it. I would force the push if it let me, i.e. it would create the branch from current master, but since the thing I am about to push is based on older master, I'd just tell git to take whatever I am giving it, because the thing the server used as initial value is not relevant. If it didn't let me, I'd probably just merge from what it created first. Telling it to create the branch from older revision would be cleaner, but that's extra hassle.
-
That sounds like more work than just cleaning up the orphaned branches once a month or so.
-
Oh crap, I might be agreeing with @blakeyrat here...
I think I kind of like the idea of creating a branch on the central server to fix a bug, as it acts as a flag to say that the bug is being worked on.
If it includes the name of the associated developer then that'd be great, though I doubt that happens.
It's not like killing unnecessary branches is slow, and an empty branch has near zero overhead anyway.
-
I think I kind of like the idea of creating a branch on the central server to fix a bug, as it acts as a flag to say that the bug is being worked on.
Using a VCS as a bug tracker like that sounds worse than using a forum.
If it includes the name of the associated developer then that'd be great, though I doubt that happens.
He should show up in the commit log.
-
Only if she commits, and we know what blakey is like for commitment.
It's the anti-Unix: Do everything, and do it badly!
-
-
Only if she commits, and we know what blakey is like for commitment.
Maybe my git ignorance is showing. Git doesn't log branch creation?
-
Nope. In Git, "Branches" are just a pointer to a commit history.
They only have a name and an optional description, but no author (yet).
When you delete the branch, the pointer and metadata are erased but the history remains.You can only get the author of any actual commits in the branch.
I do think that's a bit silly, and hope it gets changed.
-
Maybe my git ignorance is showing. Git doesn't log branch creation?
It doesn't. It's revisions just record what their parent revision was; a branch happens either because you are at a point where there is a revision with two child revisions, or where there's a branch labelling placed explicitly. Git can give branches on different systems different names; this is usually used for branches that monitor the state of branches on other systems, but need not be.
Even knowing what is going on, git's branching is often confusing.
-
Using a VCS as a bug tracker like that sounds worse than using a forum.
You don't use the VCS as the bug tracker, but you want one system to be aware of the other.
-
I think I kind of like the idea of creating a branch on the central server to fix a bug, as it acts as a flag to say that the bug is being worked on.
If it includes the name of the associated developer then that'd be great, though I doubt that happens.
That's how our inhouse-developed CVCS works. When you want to make changes, you need to start a 'transaction', which is personal and may include meta information. So if I were to work on bug 123, then I'd type
... begintrans -bug 123and it would create a transactioon<myname>_bug-123, linked to the bug tracker, and any code review uploads would be linked to it as well.However, these do not become visible in the bug tracker when the TXN is created. There is only visibility on review upload, bug commit, and when the fix appears in (internal) releases.
-
svn co https://github.com/tdwtf/WtfWebAppTry it!
-
No!
-
the Git server I'm using doesn't allow push on branches it hasn't created
Which is quite surprising given that that company's git documentation says nothing anywhere near that.
Why do you need branches to be associated instead of individual commits? It makes a lot more sense to associate a change to the code/documentation with an issue ID than to associate a list of changes, starting from when the project was created, that isn't associated with the commits after you merge it back into the main branch, with an issue ID.
-
Which is quite surprising given that that company's git documentation says nothing anywhere near that.
It's probably a site-specific configuration (rejection of branching commits). Using a private branch and then rebasing it onto an existing server-created branch prior to pushing might work. Or maybe not. It sounds like that Git
serverrepository is configured very strangely.
-
configured very strangely.
He's often the victim of this sort of thing. No one expects the blakey configuration!
-
-
wait.... that works?
Whoah...
$ svn co https://github.com/tdwtf/WtfWebApp A WtfWebApp/branches A WtfWebApp/trunk A WtfWebApp/trunk/.gitignore A WtfWebApp/trunk/Docs ... A WtfWebApp/trunk/TheDailyWtf/favicon.ico A WtfWebApp/trunk/TheDailyWtf/robots.txt Checked out revision 185.
-
wow.
-
Which is quite surprising given that that company's git documentation says nothing anywhere near that.
Oh! Ben L's gonna teach me how the SCM at my workplace works. Ben L, who has never been to my workplace, who doesn't even know who I work for, he is going to enlighten me! Come, Ben L, share your knowledge!
Why do you need branches to be associated instead of individual commits? It makes a lot more sense to associate a change to the code/documentation with an issue ID than to associate a list of changes, starting from when the project was created, that isn't associated with the commits after you merge it back into the main branch, with an issue ID.
Well since you're obviously the expert, why don't you ask our administrators who set it up why they set it up that way? Then you can come back and tell me.
-
Why do you need branches to be associated instead of individual commits? It makes a lot more sense to associate a change to the code/documentation with an issue ID than to associate a list of changes, starting from when the project was created, that isn't associated with the commits after you merge it back into the main branch, with an issue ID.
People use branches different ways. The workflow you are describing assumes that all useful work happens on the trunk and branches are just tools to isolate changes until they are stable. Some companies will use a branch to collect many changes that will go through QA, then get merged and re-QA'ed before being released. Others create a branch when they are ready to release and QA the branch, backporting any fixes to main as they are found, then releasing code build from the branch.
-
wait.... that works?
You've never noticed the
You can clone with HTTPS, SSH, or Subversion.
on the right side of a GitHub project page before? Each of those 3 is a link that, when clicked, updates the repository url above it with the appropriate url type for the project.
-
You've never noticed the
nope, because it's github so i use git.
also outside of setting up the repo in the first place i pretty much only go to github to access pull requests.
-
You've never noticed the
I can't say that I've spent much time on Github. If I noticed it, I'd forgotten it.
-
It can be fairly natural, in systems development (as opposed to just software development). Consider designing a large, distributed application, with different kinds of nodes. Some nodes might need different configuration parameters. But you don't want build tools on the production system. So you have different versions of deployment files for each stage of deployment (i.e., testing, staging, production).
I am waiting for the day Darcs does this. They say it's coming.
