Git - WTF?!

Oohhh .... did baby have its first merge conflict and decided just because of that git sucks?

not sure about alternatives. I like fossil. Also pijul looks sexy

companies everywhere use Linux instead of BSD kernels and? Linux kernel is shit and looks like school project

you mean merging a feature branch into mainline?
merge conflicts are to be expected if your mainline branch has changed since you branched the feature off

if git was unreliable, no corporation would ever use it internally. but the vast majority of corporations use either git or svn.

i think reason of usage is: hype and no famous/good known alternatives. Companies don't like big risks. For example, why not to try Fossil, it's using by Tcl/Tk project and was written by very good programmer (Richard Hipp)

Also mhy not to use commersial VCS: Perforce, TFVC? Why to use numerous Linus shit?!

That's interesting, I've never used those VCS's.

Do they offer the same decentralized benefits that git provides and make it easy for regular developers to make branches and rebase commits?

its pretty clear this threads made by a retard

you shouldnt have hard opinions if you know nothing about the technology.

anonymous already done verdict: faggot. Not retard :)

congrats faggot

Fossil is decentralized too and is supported by chisel and SF. Darcs IMHO is decentralized too (not sure), pijul IMHO too but it's beta. Also there is MErcurial, bazaar, monotone - all are decentralized

To be faggot, or not to be, that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take the Git and not to be?

I've heard about mercurial and bzr before, never used them though.

But I guess my question is: what do all these different systems have over git?

Suppose I am familiar with git and have a decent understanding of it's major features. What benefits do the other systems have that would make me want to switch?

Mercurial and Bazaar - both are mature and Mercurial was 1st famous decentralized VCS, was hyped like Git today. It was default VCS in Bitbucket (today they support Git as well as Mercurial).

simpler commands, concepts, workflow. A lot of plugins

i tried using git to version control some data analysis
it kept throwing errors about the upload being over the limit so fuck it
fuck everyone that tries to make it sound like this shit is easy or like everyone has time for this shit git can go fuck itself

sounds like PEBKAC or a bad hosting service, git has no inherent file size limits

so alternatives: SVN, Mercurial, Bazaar, Fossil, Darcs (and forks), TFVC, Perforce, Monotone, what else?

what's an easy way to set up git server on my computer so my friend can clone/push/pull/whatever on local network without giving him full SSH access or installing full-blown nginx/apache?

What the fuck is wrong with you, you massive degenerate?

good* old CVS

There are many legitimate problems with git's UI. push --force is not one of them.

>tried using ftp
>uploading some files, threw gibberish errors about "quota"
wtf I hate ftp now

OP is a fag that can't into tech

>>>
> Anonymous 07/01/18(Sun)12:11:05 No.66566193▶
>OP is a fag that can't into tech
1. push force is not UI at all
2. No, I can see real nature of some software, not hype and marketing bullshit. You - can not :D

Linus Torvals is a fag that can't into CVS. Teo de Raadt can, Linus - can not.

Git is ok, glad it's standard over some SVN
Another interesting SCM is Fossil, but even the creator (Richard Hipp,SQLite dev) claims to not have ambitions to overthrow git, but rather help to address it's issues. He uses it to manage SQLite development and as testing software so at least he has reasons to maintain it.

simpler abstraction:
>Working directory and working check-in tight to branch, never detached head. Stronger sync with remote repo and globally named branches (option for private branches ofc.), but it's not all pink, see cons. In contrast to git's working directory, staging area, local head, local copy of the remote head and remote head.
>fewer commands
human friendly features:
>central management of user's repositories
>Packed with web server, wiki, tickets and bugtracker, visualization etc. Fossil's website is running instance of this. Git has this with 3rd party (cgit, git-web, ...) or self-hosted gitlab/gitea, ... But honestly - git builds on being distributed collaboration tool and it's non-trivial to set up server and the simpler methods has no sauce around it.
>tk gui for interactive tasks
>undo to quickly fix few fuckups.
Not yet checked scripting capabilities of Fossil. It provides familiar SQL and dialect of Tcl (Hipp is Tcl/Tk fanboy). SQL builtin gives much stronger analysis on repo.

there is some criticism on Fossil, nothing is perfect
>Never know where to put the repository file :^) Fossil has separate file for repository (.git directory inside working directory) and it's separate from the working directory. First unfamiliar things you will encounter.
>can't push single branch, sync with remote repo provides less control than Git
>Had issues on giant repos because of consistency checking (NetBSD with over 40 years of development blocked on commit for seconds)
>binary format from relational database for config files. At least it gets the consistency and durability guarantees from sqlite.
>no rebase, too strict for history being immutable

Attached: fossil.jpg (1200x828, 194K)

It's dangerous to go alone, take this:
learngitbranching.js.org/

nice site, taught me something
but did not touch the hardest thing: merge conflicts

git mergetool
Literally the first thing that comes up when you search for "how to merge conflicts in git"

Attached: 1515606600547.jpg (1332x843, 121K)

Good site, 10x!

not problem to merge conlicts: they exist since CVS :) But problem is when I get conflicts with own code. Which means for me, that something is wrong in Git workflow model.

I already shows example in another thread: there are CAD/CAM systems. They are super big and complex (UX, SolidWorks, etc). They are using in different corps to project airplanes, ships, etc and automates all design workflow of such big corporations in the world. Teams are very big. They have version control too. Can you imagine how will look their version control if it will be done by Linus Torvalds?! So, my recap is that problem is not in the Git but in Linus Torvalds as architecture, designer. Kernel of Linux is not nice too - opinion of FreeBSD core teams and K. Thompson. Linux as well as Git is example of such architecture fail: it's complex and entangled. Git is not clean and elefant. Modification of history is strange decision too.

I've seen some FreeBSD comment on this recently and why they still use Subversion
blog.feld.me/posts/2018/01/git-is-not-revision-control/
and addressed in Fossil's philosophy comparison to Git as targeting cathedral development and being in sync with main repo as much as possible

Are you legit retarded?

Did you not even bother to read what it does before complaining about it? It seems perfectly reasonable to not do destructive pushes without a force option.

>not using Magit

Also, OP is either underage or retarded. And a faggot.

that's what i'm talking about: Git workflow seems unreasonably confused and can be done in simpler way

Why are needed commands to manipulate the history?! Cherrypick, rebase? Only one such command is needed: "undo". So, set: add/rm, ci/co, push/pull, undo, diff. All other things must be problem of VCS, not mine

ITT: retards that don't understand what git is for

obviously not to solve problems, but to create them.

JetBrains merge tool makes resolving merge conflicts a breeze.

Why is it Git's fault that you don't know how to use it?

Such position guards any failed due to complexity design. Why not to program backend on x86 asm? :) Because of complexity. Git is not clean solution of simple task: queueing of changesets in easy task. But first design bug was to use snapshots instead of intuitively clean "delta"/"diff".

You're confused, not git.

But what if I want to rebase? Undo won't help me there.
Rebase is a very useful tool, if you are too dumb to use it then please consider a career outside of programming so nobody else will have to deal with your brainlet code.

then Linus added manipulation with history. OK. How can be done this in clean way?

git move 5464ab..cd456de 32545b

only one command with SRC DST. SRC is range/one commit, dst is one commit. Moving without DST removes range. That's all! But again, VERSION control should not allow history manipulation.

git is good.
anyone who says otherwise is an incompetent developer or has literally zero experience with svn, hg, or some other garbage that came before it.

After a couple weeks of using git when I first started my job and it was fine, dont see any issues with it. Merge conflicts could be handled better and some of the things when trying to switch to another branch and having files in different locations and it not letting you is annoying, so sometimes a stash save and stash apply just won't work

> But what if I want to rebase?
But what if Microsoft will sell not Windows but their sources with different blobs, which will not compiles from time to time? Or if Google will publish not search tool on google.com but repo with ... Perl scripts? :)) Each tool should simplify complex things to clean and easy solution - to be useful. Why not to use old cars of 60s? Git is not adequate for simple task: manipulating with diffs

sure, no problem to solve conflicts: KDiff3, Meld, Spacemacs, Visual Studio Code, JetBrain IDEs are out friends, even simple vim, but this does not make Git adequate on design level.

- blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/
- medium.com/@ottovw/forget-git-just-use-subversion-or-perforce-8412dc1b1644
- enux.pl/article/en/2014-01-21/why-git-sucks
etc, etc, etc. Web is full of articles about bad Git design.

Great, now you have a command that can only do a small part of what rebase can do. And if you now add commands for the other things then combining them will become a mess.

Rebase is the correct way to manipulate history, it makes intuitive sense that if I am rewriting from some commit onwards then I have a choice of what to do with each following commit.

And history manipulation should be allowed, I want to be able to fix a typo in the commit message I just made before I push it. It's useful and there is no good reason to disallow it.

Rebase is simple.

>Modification of history is strange decision too.

can you fucking children stop spreading this fud? history revisions are kept around for up to a month or so by default and you can spin them off into another branch.
I swear to christ, can you anti git dipshits learn how to use git and how it works before making such retarded bullshit fud?

Web is also full of shit.

Agree.

If push fails you need to pull from remote and fix your goddamn local before you can push again.

This isn't a bad design of git, this is you being bad at communicating with your team and probably a shitty coder too.

When I go to the site for some program, I want the site so clearly state what the prigram does. Maybe have the docs online. Maybe some screenshots. The package should be in a tar file. The configure file obviously should be in the package.

With github, none of the above happens. Stupid zip file, no configure. Fuck github.

git archive dipshit.

you can fetch tar or zip of the remote or local repo. this is why people think pajeets are incompetent. the 95% like this retard.

If you rewrite history, it's not more "history".

Somebody calls me retard. Can you imagine, Linus uses... MicroEmacs! :) Men, have you even try this shit? :) Even more: it modificated it :))) Git came into the world because Linux CAN NOT LEARN EXISTING VCSs :) He can not learn Vim/Emacs. So it use MicroEmacs :)

Watch the thought:
Vim/Emacs -> MicroEmacs!
CVS/SVN/arch/Monotone -> Git

Who is retard? :)

Attached: image.jpg (596x380, 42K)

it literally is more history kid.

git tracks everything in immutable refs that are sha1 summed. you can try it yourself if you don't believe me. do you think a history rewrite doesn't generate a new commit? jesus fucking christ. the only way you can LITERALLY change history is if you find a way to edit an existing commit and make it so it collides with the sha1 sum.

I know what is git reflog, but this is not argument to allow submitted commit to be modified :)

Yes, those objects still exist in git but they are never pushed I think.

But he's still wrong because if I made some mistake in my local development I don't want to have to push extra shit to undo things, I want it to not be part of the patch. Because then it's a clearer, better history and easier to review before merging.

>fix a typo in the commit message
you really do that with rebase or just an example of useful history change?

If you remember what is CVS (tools to manipulate diffs, like driver for RCS commands), so I can recap: Git is too to manipulate diffs in decentralized way. What difficult is this task? Simple and short commands set with simple options. But... MicroEmacs... Git... True is that Linus is not good in clean design.

The latter

history revisions of things already out in the wild will cause issues for people. if they accept your changes--this also includes git masters. They can just fetch and spin off a branch from your history revision and thus preserve the previous state themselves if they want it.

there is not a single good argument to restrict history revision, especially for a tool that's designed to be decentralized.

git is a dumpster fire with a terrible command line interface. Mercurial is better in every way, especially since it's written in Python.

>>Mercurial is better in every way

>fetch remotes
>have local "bookmarks" because hg is hot garbage that didn't even have branches at first.
>get conflicts because mercurial bookmarks share the same global namespace

you don't even have good history revision like git. hg is just svn pleb garbage in the decentralized age of vcs.

That whole post didn't make any point at all.

> git add
> git commit
> [git pull]
> git push
> git /out/
and most importantly
> git gud

he's a pajeet that doesn't have a point.

>Yes, those objects still exist in git but they are never pushed I think.

that's the point. you can only "push" branches, you can make branches of history revisions and people who have conflicting branches will have to manually intervene to accept history revision. it makes perfect sense.

btw, its "critical" parts were written in C IMHO

ok

1) make feature branch
2) make series of commits working on feature branch
3) once satisfied feature works, you rebase your work into one commit with a very well written and concise commit that describes all the work you did.
4) make pull/merge request on master with changes or however you share your work to get merged up to master.

Please use IIRC instead of IMHO in this instance. You are trying to remember something, not having an opinion.

Are you here to whine about the git system itself or github in particular?

Attached: the-indian-programmer-starter-pack-does-i-wsr-leave-it-26270725.png (500x622, 99K)

problems happen when you begin to update feature branch, master branch... may be good is to use some workflow tool, i dont know

about Git itself

funny in Indian Programmers humor is that most top managers in CA (or USA at whole?) are Indians :DDDDD

or maybe your master branch shouldn't be getting conflicting features merged into it while you have feature branches being worked on retard. this is a problem with ALL VCS, not just git.

fuck off back india.
is it really this hard for you LITERAL children to admit you're wrong? jesus fucking christ. you're wrong. it's that simple.

Git was created because it's creator was tired of other revision control systems, and decided to create a better one himself.

And instead here you are hoping to share a cry with fellow pajeets instead of doing something productive about it.

Attached: Char_25546.jpg (210x240, 7K)

you mean the best of the best from india aren't pajeet tier? wow, shocker.

>most top managers in CA (or USA at whole?) are Indians
You're right, most 7/11 managers are Indians.

>here you are hoping to share a cry with fellow pajeets instead of doing something productive about it.
Do you mean to write another MicroEmacs? :)

I think will be good to learn from the great Indian nation: their history is longer than history of Europe + USA :D They can manage and can do it very good. Without any problems. I compare Satya and Steve. Also their girls are beauty and better than most white women.

Ah, I forget: their cuisine. Ah, and music, man!!! Ah, Buddhism. Ah, and myths. Vedas... There are a lot good things

Attached: image.jpg (740x492, 61K)

Fossil is 1000 times better than Git.

/thread

absolutely! And Hipp is super programmer! And I like Tk/Tcl! And Sqlite sure. And him TkHTML was good. I like how works his mind.

It's simplest to think of the state of your git repository as a point in a high-dimensional code-space, in which branches are represented as n-dimensional membranes, mapping the spatial loci of successive commits onto the projected manifold of each cloned repository. Once you grasp your mind around these basic concepts and used data structures it is then easy to navigate individual commands.

Attached: :^).png (455x400, 6K)

I thought so! And all my life I adhered to a stationary model which is not longer true after Linus :(

>implying i'm not indian.

Whats your beef with linus man? I for one am quite happy I don't have to use Mac or windows.

I did not say so :)

it;s typical case: somethign has risen because it eats all resources. BSD kernels are better, but Linux eats all dev resources due to hype. Like Git

Since you're stupid, detail how to fix up a WIP branch on a remote repo without using git push -f