Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing unlimited private repositories

github.com

Post reply on HN
Print view View original

651–660 of 662 posts

Re: Introducing unlimited private repositories

#651

Post by marssaxman »

simoncion wrote: post #636
marssaxman wrote: post #629

Earlier quoted context omitted.

Commonly: pull, push, commit -a, reset --hard HEAD, checkout $FILE, status, log, show $HASH. Sometimes: commit --amend, rebase -i, add, rm, mv, stash [pop|apply]. Rarely: branch, revert. Git's documentation uses such a wide and flagrantly inconsistent variety of terminology and maintains such a poor distinction between its interface and its implementation that trying to read it actually worsens my understanding and r…

Thanks for the reply! I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's…

Thanks for your thoughtful dig into these commands.

Perhaps my biggest point of confusion with git comes from that nebulous intermediate structure which sits between the real working directory and the real repository, which sort of acts like a repository and sort of acts like a working directory. It has many names and no clear purpose, and it doesn't fit into my mental model of the work to be done when working with a VCS.

Your explanation of merges makes more sense from that context. I don't think of add/mv/rm as operations on the nebulous repository, because I don't have any idea why one operates on the nebulous repository; what I'm trying to do is tell git to track a file, or stop tracking a file, or notice that I've moved a file from one place to another. The fact that these operations also kind of half-commit changes to this semi-repository is just... confusing, because I don't know why one would care.

If the pseudo-semi-repository thingy actually made sense, perhaps it would seem more natural that add/mv/rm do things to it during merges. I suspect the behavior of checkout, reset, and commit might also make more sense; as is, they seem to be needlessly complex, because I am never manipulating the semi-repository on purpose: I'm either trying to move my changes from the working directory into the local repository, or I'm trying to update my working directory to match the local repository, but in no case am I ever trying to half-update the intermediate state I can't actually see.

Given this somewhat confused explanation and the fact that you've done a great job of explaining what git is doing so far, can you point me at something not written by the git authors that explains what the hell is going on here and why? I would like to understand the tools I'm using instead of just blindly typing arcane rituals cribbed from the internet, but as I said before trying to read the git documentation just leaves me more confused than before I started.

Re: Introducing unlimited private repositories

#652

Post by ascendantlogic »

hrez wrote: post #580
ascendantlogic wrote: post #317

Earlier quoted context omitted.

The sheer irony of this statement is staggering. Github is a business and their goal is to make money. If you have 5x the number of people doing dev work on your code, then by definition you are a "larger" organization from their vantage point. Why wouldn't you pay more?

"Why wouldn't you pay more?" comments are rather annoying. Why would you pay more if you don't have to? Bitbucket caps their price at $200/month for unlimited users. That would pay for only ~25 users on github. Basically they are 9 times as expensive per user as bitbucket.

So then what is your solution? Per-repo pricing still?

Re: Introducing unlimited private repositories

#653

Post by paddyoloughlin »

marssaxman wrote: post #651
simoncion wrote: post #636

Earlier quoted context omitted.

Thanks for the reply! I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's…

Thanks for your thoughtful dig into these commands. Perhaps my biggest point of confusion with git comes from that nebulous intermediate structure which sits between the real working directory and the real repository, which sort of acts like a repository and sort of acts like a working directory. It has many names and no clear purpose, and it doesn't fit into my mental model of the work to be done when working with a…

Is the semi-repository thing you are talking about the index?

If so, I would describe the index as a sort of staging area for preparing your commit. You might not necessarily want to include every single change in your workspace in your next commit. The index allows you to pick which things you want to go into the commit then git-commit creates the commit from what's in the index. If you don't care for such behaviour, and you just want to commit all changes in tracked files in your workspace, git-commit -a does that.

This[0] is one of the best tools I've seen for understanding git commands and even a bit of how git works. It's interactive, divides things into the different 'places' that content can be in git and then shows you how each command moves content between those places. Click on the workspace and it will show each command which does things to content in your workspace, the bar the command is written on shows what the other area it interacts with is and the direction that the command moves content. I hope it helps. [0] http://ndpsoftware.com/git-cheatsheet.html

Re: Introducing unlimited private repositories

#654

Post by simoncion »

marssaxman wrote: post #651
simoncion wrote: post #636

Earlier quoted context omitted.

Thanks for the reply! I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's…

Thanks for your thoughtful dig into these commands. Perhaps my biggest point of confusion with git comes from that nebulous intermediate structure which sits between the real working directory and the real repository, which sort of acts like a repository and sort of acts like a working directory. It has many names and no clear purpose, and it doesn't fit into my mental model of the work to be done when working with a…

paddyoloughlin's explanation of the index is a good explanation.

I might add that if you didn't have the index, then you could not make a commit that contained an add, a rename, and a deletion. If you think far too deeply about how Subversion handles these operations, it becomes clear that -conceptually- Subversion had an index/"staging area", too. Ferinstance, the output of 'svn help add' says

  add: Put files and directories under version control, scheduling
  them for addition to repository.  They will be added in next commit.
  usage: add PATH...
What's git's index but a list of changes that have been enqueued to be performed with the next commit?

The big conceptual distinction between SVN and git is that with SVN you tie exactly one repository to a given working copy. In git you can tie multiple repos to a given working copy and (by default) one of those repos is stored in the same place as the working copy.

Does that make sense, or is the index still somewhat-to-rather unclear and/or mystifying? (I mean, other than its kinda crappy name.)

> ...can you point me at something not written by the git authors that explains what the hell is going on here and why?

If "here" is "with git in general", I read the Git Book [0] ages ago, and combined what I learned from it with a fair amount of fucking around with my repo, and also with the contents of the gittutorial(7), gittutorial-2(7) and (parts of) gitglossary(7) man pages. [1]

From looking at the ToC of the Git Book, it looks like chapters 1, 2, 3, and 7 would be relevant to your interest. Chapters 5 and 10 might be relevant. I can't offer any guarantees, as I last read the Git Book ages ago, and this look like it's a new version... the one I read didn't make any mention of Github.

Though, if you were asking about something more specific, I'm happy to take a stab at answering that question once I know what it is. :)

[0] https://git-scm.com/book/en/v2

[1] Even though you asked for things not written by the git guys, I got a fair bit of value from the official git tutorials. It's also possible that you've overlooked them, so I bring them up.

Re: Introducing unlimited private repositories

#655

Post by frostymarvelous »

brianwawok wrote: post #433
CameronBanga wrote: post #405

Earlier quoted context omitted.

I hope that any team using github to share passwords is driven to move away from that method because of this price change. That's a bad bad idea.

Why? If it is Encrypted in ansible vault or something it's not a terrible way to keep your creds.

What's wrong with using Dropbox or something like that?

Re: Introducing unlimited private repositories

#656

Post by Aissen »

Scea91 wrote: post #78
Aissen wrote: post #68

I know a lot of companies that are too cheap to pay for hosting (or even host in-house), and therefore use bitbucket with its unlimited private repos. It's their gateway drug, and once they get used to that, good luck having them move over to github.

Why use the derogaroty 'too cheap'? Maybe they are just not 'too stupid' to pay more than they have to.

I guess my critic is that you should always know why you use a service, and not just use it because it's the cheapest solution out there. In particular, is bitbucket(/github/gitlab…) adapted to your needs ? Will it support your growth ? Is it ok to have your source code on someone else's (or another country's) server ? Lots of question to be answered, and a conscious choice to make, without looking at only pricing. I was talking about companies doing the latter, not all bitbucket free users (of which I am one myself).

Re: Introducing unlimited private repositories

#657

Post by atonse »

sytse wrote: post #426
atonse wrote: post #273

Earlier quoted context omitted.

I have some private repos on gitlab and it is sloooooooow to push and pull. It routinely takes 10 seconds to push or pull. That itself makes deploys seem like a chore. And it's enough to make me come back to github for a mere $7.

I'm sorry GitLab.com is slow, we're working to make it faster in https://gitlab.com/gitlab-com/operations/issues/42

No worries – It's just not a good fit right now but can change back once the performance improves. My loyalty to github is 95% about the performance, not really anything else.

I've actually been following that thread and it's been interesting to read and watch the progress.

Re: Introducing unlimited private repositories

#658

Post by sytse »

atonse wrote: post #657
sytse wrote: post #426

Earlier quoted context omitted.

I'm sorry GitLab.com is slow, we're working to make it faster in https://gitlab.com/gitlab-com/operations/issues/42

No worries – It's just not a good fit right now but can change back once the performance improves. My loyalty to github is 95% about the performance, not really anything else. I've actually been following that thread and it's been interesting to read and watch the progress.

OK, thanks!

Re: Introducing unlimited private repositories

#660

Post by andromeduck »

msbarnett wrote: post #546
Kratisto wrote: post #479

Earlier quoted context omitted.

Any reason why? Just wondering.

GitLab's UI is pretty terrible, even compared to the not-so-great-either BitBucket UI. GitLab's UI/UX is regressive to the point that when you visit a repo, you have to click another link just to see the damn sourcecode. It's as though they ignored every advance in source-code UX post-Sourceforge. The stacked global and per-repo sidebars are confusing in a way that baffled me for several minutes, as well. They need a…

IDK, you have the option of whether to show files vs readme on landing but I actually actually prefer landing on readme first as it gives me an idea of what it is I'm looking at before deciding to dig into the code or not.

The main issue with GitLab right now IMO is that it's so fucking slow at times -- ike seconds per page slow...

Post reply on HN