Hit with the stupid branch...
-
@blakeyrat said:
It's doubly stupid because I might need to actually run (or at least build) the code to determine what the correct resolution to a conflict is, and in Git-world that option is lost to me.
Suppose this is true, and that your tool didn't update the file yet, because it couldn't merge without conflicts. What code would you actually run to make your decision? I don't think you've thought this through. Now, if you had the conflict right in the source file, you could simply comment out one side of the conflict or the other, because all of the information is right there in front of you, in an easy to work with format (well, easy if you're used to editing code in your IDE / editor).
@blakeyrat said:
What should happen is during the merge process I should get a handy-dandy diff window with one file on one side and another file on the other side, and it should let me resolve my conflicts quickly and efficiently-- you know, like how ALMOST ALL SCM TOOLS ALREADY FUCKING WORKED BEFORE GIT CAME ALONG AND SERVED US UP DIARRHEA WHILE TELLING US IT WAS GOLD.
Which tools were these, exactly? I seem to recall you saying that you'd used very few SCM tools in the past.
-
@PJH said:
Pot/kettle.
Oh well good thing you gave us that little aphorism instead of actually engaging me in debate over the points I raised or, for that matter, even explaining how exactly the aphorism applies.
If you're confused about the difference between "SCM should corrupt your source code" and "software should be accessible to all human beings no matter who they are", it's that the latter is an ideal and a moral imperative and the former is merely an opinion.
-
@blakeyrat said:
If you're confused about the difference between "SCM should corrupt your source code" and "software should be accessible to all human beings no matter who they are", it's that the latter is an ideal and a moral imperative and the former is merely an opinion.
I agree that your SCM should not corrupt your source code. I disagree that putting conflict information into the files is corrupting the source code.
I would consider forcing me to use some graphical tool before I could proceed to be an act of making the software less accessible rather than more. I'm not saying that having such a tool available for people to use is a bad thing, but if some SCM tool forced me to do that, and I was forced to use that SCM tool, I'd probably rant about it in all capitals with lots of expletives. I'd rather learn to productively use
emacsvied.
-
@boomzilla said:
@Cassidy said:
@boomzilla said:
For completeness (at least as far as I can get off the top of my head): Getting a compile error forces you to resolve the issue before continuing (fail fast!)
Agreed - although I thought Blakey objected to the error message populating his source.Yes, but...why?!
Because he'd have preferred the message separate from the source - perhaps in a separate file? Dunno, was some time back.
@boomzilla said:
I agree that your SCM should not corrupt your
source code. I disagree that putting conflict information into the
files is corrupting the source code.I'm going to have to declare ignorance here: what conflict information is actually added? (do you have some example to clarify?)
If it's something in the form of a source comment and distinguishable from original source then I have no issue. I got the impression it was as if someone typed all over my source code and it became difficult for me to determine which words were mine and what was Git's
@boomzilla said:
@Cassidy said:
You a git, then?
I use Mercurial when it's up to me (it could probably be reasonably described as git-lite). I'm occasionally compelled to use Subversion these days.
That should have been "you a git user?", sorry.
I've heard good stories about Mercurial, but that's from Mac people so not sure if it's biased. Subversion is what I've used, so Flab's link to fossil looked more what I'm used to (in terms of provided features).
-
@Smitty said:
As an added bonus, I'm trying to teach ~50 offshore devs that I'm forbidden to speak to directly.
That could be a good thing - you can simply make a demo on youtube and not have to face embarrasing questions.
-
@TheCPUWizard said:
So you want a "scripting front end" to a gui front end that sits on top of a command line based (scriptable) baseline....
I didn't know you could avoid the GUI front end to TortoiseSVN client and issue commands to it. I know you could use "svn co" under my *nixbox but didn't know if that was possible in Windows.@TheCPUWizard said:
next you will want a GUI for your new front end, and then scripting for that gui...and then...
I know. Meta, eh?
-
@boomzilla said:
disagree that putting conflict information into the files is corrupting the source code.
Does the code + conflict information work without special actions from either programmer?
Yes -> not corrupted
No -> corrupted
@boomzilla said:
I would consider forcing me to use some graphical tool before I could proceed to be an act of making the software less accessible rather than more.
Well, you have to resolve those conflicts at some point. You can't just pretend it's all okay and continue development in that file until the conflicts are resolved. If you do, you're basically implicitly branching without anybody or anything being aware of it, including the SCM and the actual software you're building.
And besides, you have this whole shiny SCM tool that manages your source in neat history stacks and has branching and merging and all that jazz, all stored in the database of the tool so that it can be worked with intelligently— and suddenly merge conflict information gets dumped into the code itself? That sounds crazy! Might as well keep the entire history as a massive commented block in the code. Why make an exception for merge conflicts? Why not keep the merge conflicts in the tool where they can be looked at, reviewed, resolved, diffed, backed up, etc etc etc?
-
findexe is a utility I wrote in 2008 to find items in %path% like which
-
@MiffTheFox said:
findexe is a utility I wrote in 2008 to find items in %path% like which
Sweet. Now make it so that each result has a number and you can immediately run it with findexe -r n so that you don't have to type the path anyway.
-
@dhromed said:
@boomzilla said:
disagree that putting conflict information into the files is corrupting the source code.
Does the code + conflict information work without special actions from either programmer?
Yes -> not corrupted
No -> corrupted
Yes it works without special actions. Here, I'm defining "works" as "does what you would expect it to do." You have code* that is not defined. What should it do? If it uses either one or the other, then it is broken, because we've done a merge, and there is no way (until a human intervenes) to determine which should take precedence. Or if the two need to be combined somehow, as opposed to simply accepting one or the other (this one fixes a potential null pointer, that one fixes an off-by-one error...I need both of those!). If your software appears to work when you have conflicts, then you have a problem.
@dhromed said:@boomzilla said:
I would consider forcing me to use some graphical tool before I could proceed to be an act of making the software less accessible rather than more.
Well, you have to resolve those conflicts at some point. You can't just pretend it's all okay and continue development in that file until the conflicts are resolved. If you do, you're basically implicitly branching without anybody or anything being aware of it, including the SCM and the actual software you're building.Of course. There are a couple of issues. First, workflow flexibiliy. Maybe I want to try some things out. Maybe I want to leave it alone on Friday afternoon and come back to it (in the middle of working resolutions). Maybe I want to use a different tool for different parts of the conflicts. Maybe the mandated tool simply sucks ass (most likely outcome).
@dhromed said:And besides, you have this whole shiny SCM tool that manages your source in neat history stacks and has branching and merging and all that jazz, all stored in the database of the tool so that it can be worked with intelligently— and suddenly merge conflict information gets dumped into the code itself? That sounds crazy! Might as well keep the entire history as a massive commented block in the code. Why make an exception for merge conflicts? Why not keep the merge conflicts in the tool where they can be looked at, reviewed, resolved, diffed, backed up, etc etc etc?
I have lots of tools for dealing with my source files (IDE, text editors, various file utilities) and I know right where my source files are. Now you want me to abandon all of that useful software and do all of this with software where editing is at best secondary? That sounds crazy! I also lose all of the redundancy that inline conflict handling provides (like compiler errors!). The tool can't make conflict resolution decisions for me, though it can help out, like by allowing me to tell it to accept changes from one parent over another. I do all of those things ( look at, review, resolve, diff, back up) right in my suite of tools (which includes the SCM software) all the time. Should the SCM implement things like intellisense and all of the other handy parts of your IDE? The conflict information takes a standard form in all of the tools I've used. This allows us to use the tools we like the best to do our job.
I expect the successful merge information to go into the source files. Why make an exception for conflicts? The SCM tool didn't break your code. You did when you asked it to do contradictory updates to your files.
* ObPedanticDickweed: OK, if the conflict was just a comment or something, then that shouldn't fit my definition of works.
-
Unless it's a file that doesn't get compiled, and suddenly you're trying to figure out why your HTML has conflict information slathered all over it.
-
@boomzilla said:
I expect the successful merge information to go into the source files. Why make an exception for conflicts? The SCM tool didn't break your code. You did when you asked it to do contradictory updates to your files.
The SCM creates a temp file with the delineated conflicts, but the working copy remains in its pre-merge state. A command like 'scm resolve' pops up the temp file in your editor of choice. Once you've edited the temp file to resolve the conflicts, the SCM replaces the working copy with the temp file. If you don't resolve the conflicts in the temp file, the working copy remains unmerged. Something like 'scm list-unresolved-files' in the command line exists so you can remind yourself if there are any files you haven't merged yet. Win-win for everyone.
This is how Perforce works, if I'm not mistaken.
-
@blakeyrat said:
I don't know how you can sit down and say, "oh BTW Git didn't bother making their tool usable for people with any kind of disability no matter how minor" without being FUCKING OUTRAGED AT HOW HORRIBLE THAT FUCKING IS.
I can do that because I don't expect every tool to solve every problem.
If your employer is fucked in the head enough not to install an elevator, don't criticize the stairs; criticize your employer.
-
@dhromed said:
Why not keep the merge conflicts in the tool where they can be looked at, reviewed, resolved, diffed, backed up, etc etc etc?
Because there's no need to. All of the conflicting files involved are already in the repo, where they can be looked at, reviewed, diffed, backed up, etc etc etc. There is no reason why git should treat edits that resolve merge conflicts any differently from any other kind of edits, and there's no need to treat the conflicts themselves as first-class objects since they will simply recur in the same places whenever anybody tries to merge the same pair of revisions.
Files with merge conflicts are inherently corrupted in that a source tree containing them no longer expresses a coherent statement of developer intent; a build that includes them should fail in an easily recognizable way that says to the developer "hey, you made a mistake, you ignored the VCS's merge conflict reports and tried to do a build from incoherent sources". The simplest way to achieve that failure, given that git is not in charge of the build process and needs to work with any build process, is to insert merge conflict markers in some easily recognizable standard form that will pretty much guarantee compile-time syntax errors.
When you do a merge, git does tell you which files failed to merge automatically; seeing some compiler barf on the merge conflict markers emitted into the affected files is not, or should not be, your first hint that a conflict has occurred. For each un-mergeable file, git also knows where to find the two conflicting versions and their common ancestor, and supplies a command (git mergetool) for running whatever visual conflict resolution tool you prefer against temporary copies of all of these. It doesn't have its own visual conflict resolution tool built in. Nor does it come with an inbuilt text editor, an inbuilt compiler, nor an inbuilt kitchen sink; git is a VCS, not an IDE.
If you prefer not to use a visual conflict resolution tool, or can't be arsed configuring git to invoke one, you could fix merge conflicts just by editing the files containing the conflict markers. For very simple cases that might even be the best way to do it. Maybe even using Notepad. This is why a file containing as much as possible of what can be merged, and merge conflict markers for the rest, is better output from a failed merge than a missing file or an empty file or a file containing the standard text "Can't auto-merge this, please run git mergetool to do it by hand".
What would not be a good thing is conflict markers that look just like source code comments, or no conflict markers at all. Because if you did ignore the merge failure reports that come out of git merge, and just did a build anyway, there would be a fair chance that a file containing a merge conflict would appear to compile successfully. Fuck knows what the resulting code would do.
So no, git does not "scribble all over" or "corrupt" your source files. It alerts you to those places where somebody else has made a source file change that conflicts with one of yours, it does that in a simple and direct and unambiguous way, and only when you ask it to, and it provides hooks on which you can hang your own preferred conflict resolution tools.
-
@flabdablet said:
This is where I point out that with VSS (in its default mode) you can't have file merge conflicts .. so that entire class of problems doesn't even exist.Files with merge conflicts are inherently corrupted in that a source tree containing them no longer expresses a coherent statement of developer intent.
-
@OzPeter said:
with VSS (in its default mode) you can't have file merge conflicts .. so that entire class of problems doesn't even exist.
Presumably you're talking about having checked-out files locked so that only one dev at a time can work on them. Yes, doing that certainly does remove the possibility of file merge conflicts; it trades them off against file editing time conflicts. Practical experience shows that as the team size grows, time wasted due to file unavailability will tend to exceed that required to resolve merge conflicts; for anything more than a handful of developers, a non-locking VCS with decent merge tools is usually the more productive choice.
Merge conflicts can be made less frequent by being careful about who is going to work on what and when. This sounds kind of fiddly and annoying until you realize that it's also exactly what's required to minimize editing time conflicts with a locking VCS.
The other thing to keep in mind is that kind of intra-file conflict we're talking about here usually pales into insignificance compared to inter-file conflict (e.g. a change in a header file that affects every source file including that header) and that neither a locking nor a merging VCS is going to help much with that; resolving those conflicts requires actual skill.
-
@Cassidy said:
I'm going to have to declare ignorance here: what conflict information is actually added? (do you have some example to clarify?)
-
@flabdablet said:
@Cassidy said:
I'm going to have to declare ignorance here: what conflict information is actually added? (do you have some example to clarify?)
Yeah that would mess up something like HTML with no obvious error. God forbid if it's in a language like Javascript or Lua that fails halfway through running with a cryptic error instead of failing entirely with a logical syntax error. That might actually even be executable Perl or bash.
-
@flabdablet said:
Files with merge conflicts are inherently corrupted in that a source tree containing them no longer expresses a coherent statement of developer intent;
Blah blah blah.
Ok, say I need to build a C# file to figure out whether the conflicting variable name I used is correct, or the one in the repository is correct. I'm using Git, so I hit build and-- oh wait about 473,324032432423 syntax errors that was fucking useless. Well as you say, "Fabdablet", the original pre-merge file is in my local repo so I can switch back to that (ignoring the technicality that, for the moment, no I can't because Git's UI is too incompetent). Bam switch back, now I hit build, ok now I know variable name is correct. Oh but wait, now I can't resolve the conflict because I no longer have the merge conflict markers, so I have to resolve every OTHER file, then try checking in this file again and waiting for it to fail and NOW I can fix it but oh wait that took so long I forgot which variable name was correct. There's a simple practical answer.
Practicality aside, there's also a philosophical reasoning here: Git is closer to a FTP client than it is to a editor. It's purpose is to store and preserve files, NOT to change files. So why is it changing files? Why is it doing it as a completely invisible side-effect of something else entirely? Why does it let you just decree a file is conflict-free and then check it in, even if the conflict markers are still in it? Who the fuck designed this piece of shi-- oh right "our Holy Father Torvalds", who badly needs to stick to OS kernels.
Of course you wouldn't need to do any of this bullshit in files if you just bothered to build a decent UI to do it in the first fucking place. You know, like they should have done approximately 6 months before releasing this broken trash upon the world.
@flabdablet said:
When you do a merge, git does tell you which files failed to merge automatically;
Liar.
Oh. Maybe "one particular incomprehensible UI of Git does". But the UI I was using most certainly does not. And it was made by the largest Git-using site on the web, for the most popular computing platform anywhere. The reason for this is: Git is a terrible product.
@flabdablet said:
seeing some compiler barf on the merge conflict markers emitted into the affected files is not, or should not be, your first hint that a conflict has occurred.
It shouldn't be, I agree. Duh. But it WAS.
I find it amusing that you don't even seem to realize exactly how shitty Git is.
@flabdablet said:
It doesn't have its own visual conflict resolution tool built in.
Why fucking not? Isn't that like 80% of what you do with it?
@flabdablet said:
Nor does it come with an inbuilt text editor, an inbuilt compiler, nor an inbuilt kitchen sink; git is a VCS, not an IDE.
I'm not saying it should be an IDE, but it's not a finished product until it can integrate with an IDE-- you can't do that by shitting all over files.
@flabdablet said:
If you prefer not to use a visual conflict resolution tool, or can't be arsed configuring git to invoke one, you could fix merge conflicts just by editing the files containing the conflict markers.
As far as I know, that's the ONLY way to do it.
I mean I could break out ExamDiff, but ExamDiff doesn't know Git's weird-ass syntax and I have no (practical) way of getting a hold of the original files to compare, and even if I did, I'd have to dive into a text editor to get rid of Git's stupid markers anyway. So why didn't anybody on the Git team ensure it worked with Diff programs like ExamDiff? Oh yeah! Because it's a TERRIBLE PRODUCT made by TERRIBLE DEVELOPERS. I almost forgot for a second.
The Murder She Wrote Super Cabot Cove Super Sum Up:
@flabdablet said:
So no, git does not "scribble all over" or "corrupt" your source files.
Yes it does.
@flabdablet said:
It alerts you to those places where somebody else has made a source file change that conflicts with one of yours,
No it doesn't.
@flabdablet said:
it does that in a simple and direct and unambiguous way,
It does it in a confusing, disorienting way with no warning and no UI to even tell you what's happening.
@flabdablet said:
and it provides hooks on which you can hang your own preferred conflict resolution tools.
Except since it scripples all over my file, it makes my preferred conflict resolution tool completely useless.
Git is terrible software.
-
@MiffTheFox said:
Yeah that would mess up something like HTML with no obvious error.
The point is that the HTML in question is already inherently messed up because there's an unresolved merge conflict, and that git has not only already reported that fact but is also quite capable of telling you which files still have unresolved conflicts, if you ask it. The conflict markers emitted into partially-merged files are not the primary way to discover unresolved conflicts, and the fact that they cause compilation errors in most compiled languages is gravy.
@MiffTheFox said:
God forbid if it's in a language like Javascript or Lua that fails halfway through running with a cryptic error instead of failing entirely with a logical syntax error.
If your current revision contains unresolved merge conflicts, you shouldn't be running it at all.
@MiffTheFox said:
That might actually even be executable Perl or bash.
If you're writing Perl or bash that looks like that, you're doing it wrong.
Here's the thing: conflict markers in this form are absolutely standard. Every VCS since rcs (yes, including VSS) has used them. They work. They should be uncontroversial. Why all the fuss?
-
@flabdablet said:
@Cassidy said:
I'm going to have to declare ignorance here: what conflict information is actually added? (do you have some example to clarify?)
Okay, that looks pretty ugly to me - I had to examine it several times to (a) realise the only difference was an additional (blank) line and also realise what the chevrons actually meant. I guess I could get used to it, but still...
-
@flabdablet said:
@MiffTheFox said:
Yeah that would mess up something like HTML with no obvious error.
The point is that the HTML in question is already inherently messed up because there's an unresolved merge conflict, and that git has not only already reported that fact but is also quite capable of telling you which files still have unresolved conflicts, if you ask it. The conflict markers emitted into partially-merged files are not the primary way to discover unresolved conflicts, and the fact that they cause compilation errors in most compiled languages is gravy.
@MiffTheFox said:
God forbid if it's in a language like Javascript or Lua that fails halfway through running with a cryptic error instead of failing entirely with a logical syntax error.
If your current revision contains unresolved merge conflicts, you shouldn't be running it at all.
@MiffTheFox said:
That might actually even be executable Perl or bash.
If you're writing Perl or bash that looks like that, you're doing it wrong.
Here's the thing: conflict markers in this form are absolutely standard. Every VCS since rcs (yes, including VSS) has used them. They work. They should be uncontroversial. Why all the fuss?
VSS does that? Last I checked it used it's own diff tool. And if it's such a standard, why is there a shortage of tools to handle it?
And of course I'm not writing Perl or bash that looks like that. I'm saying Perl or bash might not see that as a syntax error.
Then again I've never had a intra-project conflict error with Git so I wouldn't be too familiar with fixing that sort of thing. I have however had a inter-project conflict that Git refused to even touch, resulting from committing without pulling first.
-
@blakeyrat said:
As far as I know, that's the ONLY way to do it.
That's because, as usual, you don't know very far.
@blakeyrat said:
since it scripples all over my file, it makes my preferred conflict resolution tool completely useless.
Does not either too.
@blakeyrat said:
So why didn't anybody on the Git team ensure it worked with Diff programs like ExamDiff?
-
@flabdablet said:
That's because, as usual, you don't know very far.
And I don't know because Git has no learning curve. Because it's terrible software.
@flabdablet said:
Does not either too.
Uh. No comprende?
@flabdablet said:
LMGTFY.
Unless you're getting a different page than I am, that link says nothing about using ExamDiff with Git. It mentions you can use a commandline to start up ExamDiff with two files to compare, but the problem with Git is: you don't have two files to compare, you only have one, and a bunch of extra bullshit telling you which parts came from the repo and which parts came from your editing).
So you know, kudos points for your succinct and insultingly condescending reply, but I have to detract all of them back because you didn't spend 47 milliseconds verifying the link returned actually solved the issue.
Why should anybody have to Google for it? Why shouldn't it Just. Fucking. Work? Maybe if Git wasn't so terrible you wouldn't have to spend all this time trying to convince people of that, hum? Ever think about that little issue?
You're so used to this buggy broken shitty software that it's like your brain can't even hold the concept of good software anymore. You're basically living in my own personal hell and you've loving it and trying to get others to move in with you.
No. Git is fucking awful. It's a terrible product. You've said nothing to change my mind.
-
@blakeyrat said:
Practicality aside, there's also a philosophical reasoning here: Git is closer to a FTP client than it is to a editor. It's purpose is to store and preserve files, NOT to change files.
This is one of the stupider things you've said, at least in this thread. Of course a major purpose in git (and any other VCS) is to change the files in your working copy when you tell them to. Also, to do merges when you need those. Perhaps your problem is that you don't really understand what's going on behind the glowing screen?
-
@blakeyrat said:
Ok, say I need to build a C# file to figure out whether the conflicting variable name I used is correct, or the one in the repository is correct. I'm using Git, so I hit build and-- oh wait about 473,324032432423 syntax errors that was fucking useless. Well as you say, "Fabdablet", the original pre-merge file is in my local repo so I can switch back to that (ignoring the technicality that, for the moment, no I can't because Git's UI is too incompetent). Bam switch back, now I hit build, ok now I know variable name is correct. Oh but wait, now I can't resolve the conflict because I no longer have the merge conflict markers, so I have to resolve every OTHER file, then try checking in this file again and waiting for it to fail and NOW I can fix it but oh wait that took so long I forgot which variable name was correct. There's a simple practical answer.
So, let's imagine a world in which the conflict markers aren't put into your source. What would you build? Are you just going to pick one parent or another? That seems likely to create more problems than it solves. Are you going to try merging stuff by hand? That seems more dangerous than having the conflict markers right there to work with. When I've needed to test something like this, you know what I used? Comments! You can comment out one side of the conflict or the other, and see what happens. This is pretty rare, though.
Also, if you refuse to learn how to use the tool, then I think we can all agree that you won't be able to do even simple things. Now, I tend to agree with you that GUI VCS is TRWTF. Using the CLI versions is pretty straightforward, though, and even faster, at least for a large source tree. And they actually tend to be fairly discoverable. I know, I know, this is just a waste of pixels...
-
@boomzilla said:
@blakeyrat said:
Practicality aside, there's also a philosophical reasoning here: Git is closer to a FTP client than it is to a editor. It's purpose is to store and preserve files, NOT to change files.
This is one of the stupider things you've said, at least in this thread. Of course a major purpose in git (and any other VCS) is to change the files in your working copy when you tell them to. Also, to do merges when you need those. Perhaps your problem is that you don't really understand what's going on behind the glowing screen?
I'd hate to agree with Blakeyrat here, but no, that's an editor. A VCS keeps track of history and branches, and synchronizes them across systems. Git, and every other DVCS, has big problems with the latter, which is why I hate them.
-
@MiffTheFox said:
@boomzilla said:
@blakeyrat said:
Practicality aside, there's also a philosophical reasoning here: Git is closer to a FTP client than it is to a editor. It's purpose is to store and preserve files, NOT to change files.
This is one of the stupider things you've said, at least in this thread. Of course a major purpose in git (and any other VCS) is to change the files in your working copy when you tell them to. Also, to do merges when you need those. Perhaps your problem is that you don't really understand what's going on behind the glowing screen?
I'd hate to agree with Blakeyrat here, but no, that's an editor. A VCS keeps track of history and branches, and synchronizes them across systems. Git, and every other DVCS, has big problems with the latter, which is why I hate them.
An editor updates your local files from the repository? So, you look at the changes someone else did and then manually merge them into your changes using your editor?
I think you've previously brought up that you think the distributed nature of DVCS is TRWTF. When I hear this from people, it usually turns out that they have some major misconceptions about how the system works. The whole point is to make repositories sync up with each other, and I've never had a problem doing so, though I will admit to not working on something as crazy as the Linux kernel. Would you mind expanding your DVCS-killed-my-dog story?
-
Computer A: close a get repo, make a large, complicated binary file (such as a word document) in it, then PCP (git pull && git commit && git push).
Computer B: close the repo, make changes to the file, then PCP
Computer A: make different changes to the file, then commit without pulling first
Congratulations. Computer A now has a fork (not a branch) of the main git repo.
-
@MiffTheFox said:
Computer A: close a get repo, make a large, complicated binary file (such as a word document) in it, then PCP (git pull && git commit && git push).
Computer B: close the repo, make changes to the file, then PCP
Computer A: make different changes to the file, then commit without pulling first
Congratulations. Computer A now has a fork (not a branch) of the main git repo.
Uh, OK. As I've said, I'm not familiar with git, but in Mercurial, this is just an anonymous branch. Of course, trying to manage binary files with SCM tools usually leads to pain (though I've heard that there are, but not used, svn extensions that deal with Office documents). If these were normal source code / text files, you'd simply merge the changes together and get on with life. Since you've got a complicated blob, you'll have to do that stuff more manually.
And, yes, this seems like a misconception about the system on your part.
-
@boomzilla said:
@MiffTheFox said:
Computer A: close a get repo, make a large, complicated binary file (such as a word document) in it, then PCP (git pull && git commit && git push).
Computer B: close the repo, make changes to the file, then PCP
Computer A: make different changes to the file, then commit without pulling first
Congratulations. Computer A now has a fork (not a branch) of the main git repo.
Uh, OK. As I've said, I'm not familiar with git, but in Mercurial, this is just an anonymous branch. Of course, trying to manage binary files with SCM tools usually leads to pain (though I've heard that there are, but not used, svn extensions that deal with Office documents). If these were normal source code / text files, you'd simply merge the changes together and get on with life. Since you've got a complicated blob, you'll have to do that stuff more manually.
And, yes, this seems like a misconception about the system on your part.
Yeah. Maybe Mercurial has a thing to say "hey, throw out my changes, just grab the latest version from the master". In svn, it's as simple as deleting the conflicted file then updating, as the commit failed. I got the the point where I figured out how to roll back my commit, but that wouldn't put the two forks back in sync, so I just deleted the entire project directory and cloned up a fresh copy rather then spend time fighting it any more.
-
@MiffTheFox said:
Yeah. Maybe Mercurial has a thing to say "hey, throw out my changes, just grab the latest version from the master".
Uh...you would just grab whatever version you wanted and then commit it.
@MiffTheFox said:
In svn, it's as simple as deleting the conflicted file then updating, as the commit failed.
This is a major reason why svn sucks.
-
I don't feel like replicating the entire process to prove a point, but as I recall it wouldn't ever let me pull or push again.
Also svn sucks because it's intuitive for me and uses tools I'm obviously familiar with (in this case, a file manager)?
-
@MiffTheFox said:
I don't feel like replicating the entire process to prove a point, but as I recall it wouldn't ever let me pull or push again.
Sounds like something got corrupted because, again, you just described an everyday occurrence (anonymous branch). I've heard many people who don't grok DVCS go apeshit when they've encountered this phenomenon.
@MiffTheFox said:
Also svn sucks because it's intuitive for me and uses tools I'm obviously familiar with (in this case, a file manager)?
I disagree. It sucks because it uses the merge-commit paradigm. This is a design flaw in svn, not anything inherent in centralized version control.
-
@boomzilla said:
@MiffTheFox said:
Also svn sucks because it's intuitive for me and uses tools I'm obviously familiar with (in this case, a file manager)?
I disagree. It sucks because it uses the merge-commit paradigm. This is a design flaw in svn, not anything inherent in centralized version control.
Doesn't git use the merge-commit paradigm too? And every VCS, distributed or not?
-
@MiffTheFox said:
@boomzilla said:
@MiffTheFox said:
Also svn sucks because it's intuitive for me and uses tools I'm obviously familiar with (in this case, a file manager)?
I disagree. It sucks because it uses the merge-commit paradigm. This is a design flaw in svn, not anything inherent in centralized version control.
Doesn't git use the merge-commit paradigm too? And every VCS, distributed or not?
No. That's what happened with your "fork." But commit-merge is pretty much required for DVCS, since you cannot know what's happening in remote repositories, and you need a way to resolve parallel development (even though it may mostly be work being done on completely different files).
But the way svn works, if you work on a file, and someone else makes a commit that conflicts with what you've done, you have to update and resolve the conflict before you can make your commit. Now your changes are tainted, since they've been mixed with the changes that were committed in the mean time. So, suppose you were working off of r100, and someone checks in r101. When you go to commit, you are creating a diff from r101, not r100, even though that's what you've been working on.
With a DVCS, when you check in your changes, they're still creating a diff from r100. So you end up with:
r100 - r101 - r103 \ r102 /Now, you have to merge r101 and r102 just like you would with any other branch. But you have a clear record of both of those changes. Most of the time, this isn't a problem with svn. But when it is, it can be very difficult to deal with, especially when there are significant changes. And you risk getting your stuff wiped out, or at least severely messed up when svn forces you to merge r101 into your working copy before you were able to record r102, because your r102 changes are transient. So if you mess up with the merge and reconciliation, you can't simply roll back to a previous change (unless you backed up / copied your source tree before updating from the repository).
-
@blakeyrat said:
Then you are a cargo-cult programmer and are already beyond redemption.Ok, say I need to build a C# file to figure out whether the conflicting variable name I used is correct, or the one in the repository is correct.
-
@blakeyrat said:
You've said nothing to change my mind.
I don't think I've ever actually seen that done. You have one of the most change-resistant minds I've ever encountered; your persistent refusal to learn anything at all about git makes my own loathing for The Ribbon look positively rational by comparison So I'm going to make one last attempt to clear this particular issue up for you, and then I'm going to let it go.
@blakeyrat said:
Unless you're getting a different page than I am, that link says nothing about using ExamDiff with Git. It mentions you can use a commandline to start up ExamDiff with two files to compare
Look at it again. Hint: start at the part right in the middle of the page headed "Using ExamDiff Pro as an External Merge Tool", then skip down to the part headed "Git".
@blakeyrat said:
but the problem with Git is: you don't have two files to compare, you only have one, and a bunch of extra bullshit telling you which parts came from the repo and which parts came from your editing).
I have already linked to many sources of information on this, all of them trivially discoverable with Google. The git mergetool command exists specifically to start up your preferred merge conflict resolution tool and supply it with all four files it needs for the job: the two conflicting sources, the common ancestor of those sources, and the output file (which last is the only one you seem to believe still exists). Read this. If you can't follow those directions, get somebody else at your workplace to explain them to you; I'm done.
-
@flabdablet said:
If you can't follow those directions, get somebody else at your workplace to explain them to you; I'm done.
You know there wouldn't have to be 20 websites, directions, explanations... if Git was FUCKING USABLE IN THE FIRST FUCKING PLACE, right? You're almost DEFINING "terrible software" right now, you realize that I hope.
I concede it's possible to use ExamDiff with Git. (Although, ironically, this means Git *does* fucking keep my files intact-- at least it can feed an intact file into an external tool which means it's SOMEWHERE on disk! It just munges the filename I look at because-- uh... kicks? Just to be an asshole? Fuck.)
-
@blakeyrat said:
You know there wouldn't have to be 20 websites, directions, explanations... if Git was FUCKING USABLE IN THE FIRST FUCKING PLACE, right? You're almost DEFINING "terrible software" right now, you realize that I hope.
That argument only makes sense f by "terrible" you mean "complex and useful". Git is a programmer's tool. Team programming is complex. Get over it. If you want a no-brainer kiddy toy that's not up to the job, don't use git. If your employer mandates the use of git, learn about tree felling before picking up that chainsaw. If you're silly enough to stand downhill, it's not the chainsaw's fault when the tree falls on you.
@blakeyrat said:
I concede it's possible to use ExamDiff with Git
At fucking last! Fuck, you're hard work.
@blakeyrat said:
Although, ironically, this means Git does fucking keep my files intact
That would have to be "I-wrong-ically", because there is nothing ironic about a VCS keeping files intact; that's the point of a VCS.
@blakeyrat said:
at least it can feed an intact file into an external tool which means it's SOMEWHERE on disk!
The external tool doesn't need "an" intact file; it needs at least the two conflicting versions, and perhaps their common ancestor as well, all of which are safely socked away in your local repo. Have you truly still grasped nothing about how DVC works?
@blakeyrat said:
It just munges the filename I look at because-- uh... kicks? Just to be an asshole?
Because it's not your file any more. You did a merge that revealed that somebody else has made their own changes to the version you both started with, and those changes conflict with yours. Until you resolve that conflict, the merged source tree is not self-consistent and you should not expect to be able to build with it. Leaving either of the changed versions in your working directory would not help you, because the conflict must be resolved in order to restore self-consistency to the source tree. Whether you do that resolution work the simple-minded way by editing the marked-up merge output that git merge creates for you, or whether you do it the easy way with git mergetool, is up to you.
Seriously, this stuff is DVCS 101. None of it is peculiar to git; every DVCS works this way. So unless you can mount a serious case that either (a) DVCS as a concept is not fucking usable or (b) git's commands for doing these necessary things are too arcane or too hard to configure or not discoverable enough (despite the ready availability of vast amounts of online help and knowledge): you're talking out of your arse again from your customary position of treasured ignorance, and you need to quit whining and put on a goddamn coat.
-
@blakeyrat said:
@flabdablet said:
If you can't follow those directions, get somebody else at your workplace to explain them to you; I'm done.
You know there wouldn't have to be 20 websites, directions, explanations... if Git was FUCKING USABLE IN THE FIRST FUCKING PLACE, right? You're almost DEFINING "terrible software" right now, you realize that I hope.
I concede it's possible to use ExamDiff with Git. (Although, ironically, this means Git *does* fucking keep my files intact-- at least it can feed an intact file into an external tool which means it's SOMEWHERE on disk! It just munges the filename I look at because-- uh... kicks? Just to be an asshole? Fuck.)
Ladies and gentlemen of TDWTF, I'm just a caveman. I fell on some ice and was later thawed by some of your scientists. Your world frightens and confuses me! Sometimes I try to use software, and I wonder if it can work by randomly clicking buttons and reading my mind...
-
@flabdablet said:
That argument only makes sense f by "terrible" you mean "complex and useful".
When there exists less complex but equally useful software, then yes the more complex version is terrible.
@flabdablet said:
If your employer mandates the use of git,
My employer doesn't; the moron co-worker who wants to suck Ruby-on-Rails' cock and didn't know the word "threading" until I introduced it to him made the decision.
@flabdablet said:
learn about tree felling before picking up that chainsaw.
Chainsaws are an order of magnitude easier-to-use than Git.
@flabdablet said:
At fucking last! Fuck, you're hard work.
It's not my fault you linked to the wrong page.
@flabdablet said:
That would have to be "I-wrong-ically", because there is nothing ironic about a VCS keeping files intact; that's the point of a VCS.
WHICH IS WHY I'M SO UPSET THAT GIT SCRIBBLES SHIT ALL OVER THEM! WTF!!!!! Do you have Momento disease? WTF!!!!!
@flabdablet said:
The external tool doesn't need "an" intact file; it needs at least the two conflicting versions, and perhaps their common ancestor as well, all of which are safely socked away in your local repo. Have you truly still grasped nothing about how DVC works?
No I understood that perfectly. But the only file I could see was the one with the scribble in it.
Even if I didn't, it's the SOFTWARE'S duty to make facts like that known to me, not mine. If Git wasn't terrible software we wouldn't be having this discussion.
@flabdablet said:
Because it's not your file any more. You did a merge that revealed that somebody else has made their own changes to the version you both started with, and those changes conflict with yours.
Then I want to see both copies. Not some bullshit mutated not-at-all-what-I-just-hit-save-on crap Git's feeding me.
@flabdablet said:
Whether you do that resolution work the simple-minded way by editing the marked-up merge output that git merge creates for you, or whether you do it the easy way with git mergetool, is up to you.
Ok; show me a version of those tools I'm capable of using.
Oh you can't? That would be because Git is terrible software.
@flabdablet said:
Seriously, this stuff is DVCS 101.
Then why haven't I discovered any of it from the behavior of Git? You don't even understand what good software is and you're lecturing me about it! At least when you're not having Momento disease! Goddamned man.
@flabdablet said:
So unless you can mount a serious case that either (a) DVCS as a concept is not fucking usable
I've never used any except Git, so that perhaps could be true.
@flabdablet said:
(b) git's commands for doing these necessary things are too arcane or too hard to configure or not discoverable enough
The real amazing part is that VCS's have always had shit usability, and Git somehow managed to do it worse. How is that even possible?! The only thing I can think of is the Linux dorks made it that difficult on purpose to maintain the "high priesthood of technology" from 1975 they hallucinate still exists. Or in more succinct terms, "we got ours, fuck everybody else."
Well guess what? I don't agree with that philosophy. I think it's criminal. I think it's immoral. I think if you don't bother to make your software usable (or even attempt it) you should be put out of business, you should be shunned, and you should be liable for when your failed software causes losses. (You know, exactly like what would happen if a contractor build a new building but neglected to install wheelchair ramps and refused to add them once the problem was pointed out. At least here in the civilized world.) The Git developers are troglodytes. They're worse than Lotus Notes-- at least the Notes team tries and fails instead of not trying at all!
So until you stop denying there's a fucking problem and start giving the Git developer guff for the shitty product they've created and start pressuring Git developers to FIX THEIR SHIT, you will never, EVER, EVER, convince me that Git isn't terrible or broken. The only post you should be making on this forum should read:
@Fictional Sane Flabdablet said:
Yes, Git's usability is criminally bad, and I've been asking for improvement the entire time I've used but, but I think it still has the potential to become something good in the future once those problems are sorted out.
If you think Git is perfectly fine software in its current form, you're not just wrong, you're morally bankrupt. Software is power. Telling someone they can't wield software power because their capabilities are different than yours is WRONG. WRONG WRONG WRONG WRONG WRONG. Go huddle in a dark closet and think about that.
This shit is important.
-
@blakeyrat said:
If you think Git is perfectly fine software in its current form, you're not just wrong, you're morally bankrupt. Software is power. Telling someone they can't wield software power because their capabilities are different than yours is WRONG. WRONG WRONG WRONG WRONG WRONG. Go huddle in a dark closet and think about that.
This shit is important.
Oh, so now I'm ableist.
You find command line interfaces frustrating and opaque. I find GUIs that are light on text and heavy on inscrutable icons equally frustrating and opaque. But my difficulty working with The Ribbon makes me a change-fearing Luddite, while your difficulty working with the git CLI makes git objectively terrible? Fuck off, and take your entitlement issues with you.
-
I don't understand why we do not all just use Mercurial and get along?
It's close enough to Git that gits shouldn't have much issue with it.
It's close enough to SVN that it doesn't include the WTF's that Git has.
It's got a decent windows interface, though it could be better.
Admittedly, it still scribbles all over your source files if it gets a conflict, but it also prompts you to change that right away.
In any case, Git is just horrible, I tend to agree. Every time I went to do anything with git, it either blew up the repository, committed changes to a different place than I meant to or just generally fucked up what I wanted to do.
The Github windows interface is/was a fucking joke. I thought it was looking graphically and awesome, until I got a conflict, and it prompted to open the fucking console. That was a real WTF moment.
OK, WTF, explain why I need to enter the linebreaks as HTML myself :S?
-
@Aeolun said:
Admittedly, it still scribbles all over your source files if it gets a conflict
Just lost Blakey as a customer, there.
-
@Aeolun said:
OK, WTF, explain why I need to enter the linebreaks as HTML myself :S?
Because this forum is a relic that pre-dates Chrome.
-
Mercurial intrigues me if only for it's history. It was created to replace the proprietary DVCS that Linux used, but within a few days of it's announcement, the Git project spun up. Hg was never chosen to be used for the kernel since Linus Torvalds was on the Git project, and then some aspie created Github.
Honestly, I think that's the only reason Git's so popular. Hell, I think Google Code dropped Hg as their VCS of choice in favor of SVN.
-
@MiffTheFox said:
Apple has also baked Git support into Xcode, which is the only reason I know anything about Git. MS has also announced Git support in TFS . When DVCS' were becoming all the rage I looked at the various choices and liked Hg, but ended up using Git.Honestly, I think that's the only reason Git's so popular. Hell, I think Google Code dropped Hg as their VCS of choice in favor of SVN.
-
@OzPeter said:
MS has also announced Git support in TFS
Que? That's weird.
Isn't that like gecko supporting webkit, and Photoshop supporting GIMP?
Maybe you mean Git support in VS?
I am blissfully unaware, so that's why I ask these questions.
-
@dhromed said:
@OzPeter said:
MS has also announced Git support in TFS
Que? That's weird.
It's ... not quite accurate.
Microsoft has released a VS plug-in to support Git directly. They also announced ... something ... about TFS but honestly from the press release I couldn't figure out what it was-- the plug-in doesn't require TFS to run as far as I can tell. (Maybe TFS can export into Git? Or vice versa? Or something else entirely? I dunno, I don't have TFS installed.)
I've been meaning to try out the Microsoft Git plug-in, but I haven't had the time to fiddle so I've been working with the devil-I-know instead of moving on to the devil-I-don't. Plus the Microsoft plug-in was just released like two weeks ago, so it's very very beta.
