Live data from Hacker News

Git Tips And Workflows

durdn.com

21–30 of 40 posts

Re: Git Tips And Workflows

#21
post #17

Earlier quoted context omitted.

Read ProGit: http://git-scm.com/book > "git commit origin master" That's not how to do it :) > I wanted to make it so that they could also commit code into the same repo No. Each developer works in her private repo, for sharing work you use a bare repo people push to / fetch from.

>No. Each developer works in her private repo, for sharing work you use a bare repo people push to / fetch from What do you mean by a "bare repo"? blhack wants to make it so that they commit code into the same repo. You could do that by setting up a repository somewhere, and then each person would clone it.

No, you are mixing things up here. commit is a local operation.

Re: Git Tips And Workflows

#22
post #17

Earlier quoted context omitted.

Read ProGit: http://git-scm.com/book > "git commit origin master" That's not how to do it :) > I wanted to make it so that they could also commit code into the same repo No. Each developer works in her private repo, for sharing work you use a bare repo people push to / fetch from.

>No. Each developer works in her private repo, for sharing work you use a bare repo people push to / fetch from What do you mean by a "bare repo"? blhack wants to make it so that they commit code into the same repo. You could do that by setting up a repository somewhere, and then each person would clone it.

--bare ensures you don't have a working directory. It is the bare .git directory only. You don't want people pushing to your working directory. Simple as that.

Re: Git Tips And Workflows

#23
post #12

Has anybody seen a "git for people who have no idea how to use git" tutorial? I use git for keeping track of some personal projects, but the extent to which I understand how to use it is: "git commit origin master" We had a hackathon this weekend, and our team had three people on it. I wanted to make it so that they could also commit code into the same repo (I think this it the right term?), but had absolutely no ide…

Use SVN. There's lack of "svn for people who have no idea how to use svn" tutorials, and when they're published, they tend to be single-paragraph.

I'm not sure git is a perfect solution for any project. Unless you intend to pull each other's modifications, the idea of a central "trunk" and custom "branches" is easy to explain to anybody in 5 minutes.

Re: Git Tips And Workflows

#24
post #12

Has anybody seen a "git for people who have no idea how to use git" tutorial? I use git for keeping track of some personal projects, but the extent to which I understand how to use it is: "git commit origin master" We had a hackathon this weekend, and our team had three people on it. I wanted to make it so that they could also commit code into the same repo (I think this it the right term?), but had absolutely no ide…

When I started with git, I really enjoyed the PeepCode Git Internals book: https://peepcode.com/products/git-internals-pdf

It's $12 (or $9 according to the preview) and the first thing it tells you to do is forget everything you know about source control. If you know SVN and want to use that knowledge to learn Git, I don't think you'd like this book. If you think knowing the underlying data model will help you be more effective with git, this book is for you.

The book has lots of diagrams and I thought it was pretty well written (and not too slow).

I use git for personal projects (not production code). Unlike many who think git is a hostile hateful thing, I think git has a brilliant command-line user interface. I don't know if this book made me that way, but I also use Vim so that might explain it (again, I disagree with the prevailing opinion of hostile hateful thing).

Re: Git Tips And Workflows

#25
post #9

>> Zero a branch to do something radically different There's another way to do this: git checkout --orphan new-branch

Last time I tried this, I was getting a lot of hassle when switching between branches that have no common ancestor; .gitignored files disappearing completely (very annoying when you keep a local config file around etc.), files left over and "not staged for commit" instead of being removed, etc. Maybe the "empty root commit" trick would help, I haven't tested that they.

You are going to have those issues anyway. Since there is no common ancestor you will have to commit a .gitignore from scratch to that new branch. Files left over is another common issue, if they are not committed then when you switch branches they are going to stick around, just like with any other branch switch...

Re: Git Tips And Workflows

#26
post #10

I was not aware of the `git config` option for wrapping long files, worth the price of admission just for that for me. Edit: there's a `git diff` tip in there, but this comes up a few times so if anyone needs to do patches from git for svn repos do `git patch --prefix=none $DIFF1 $DIFF2 > some.patch` share and apply with `patch -p0 < some.patch`.

I don't see that Git has a "patch" command, but svn does -- is that what you meant here? Where you have "git patch", did you maybe mean: git diff --no-prefix $OLD $NEW ...where $OLD and $NEW are the two commits you want to diff.

Yeah, my bad!

Re: Git Tips And Workflows

#27
post #21

Earlier quoted context omitted.

>No. Each developer works in her private repo, for sharing work you use a bare repo people push to / fetch from What do you mean by a "bare repo"? blhack wants to make it so that they commit code into the same repo. You could do that by setting up a repository somewhere, and then each person would clone it.

No, you are mixing things up here. commit is a local operation.

I didn't mean to indicate it wasn't.

You could setup a remote and each person could clone that remote.

I left out the details about what you do after you clone (push/pull), but the point was that there is nothing special about the remote repository as far as it being "bare". Which turns out isn't right. You can set up a bare repository with no working directory as 2mur has pointed out. I wonder if that is a requirement. I always thought that if you clone a repository you can just start using it as a remote without additional hassle.

Re: Git Tips And Workflows

#28
Git is full of nice tricks, this is a good collection. One it didn't mention that I use a lot, is manipulating history with human-readable dates:

  git whatchanged --since="yesterday"
  git revert master@{"1 month ago"}

Re: Git Tips And Workflows

#29
post #21

Earlier quoted context omitted.

No, you are mixing things up here. commit is a local operation.

I didn't mean to indicate it wasn't. You could setup a remote and each person could clone that remote. I left out the details about what you do after you clone (push/pull), but the point was that there is nothing special about the remote repository as far as it being "bare". Which turns out isn't right. You can set up a bare repository with no working directory as 2mur has pointed out. I wonder if that is a requireme…

> Which turns out isn't right.

Sorry, you lost me; what's not right?

> You can set up a bare repository with no working directory

A bare repository has no working tree per se.

> I wonder if that is a requirement. I always thought that if you clone a repository you can just start using it as a remote without additional hassle

You can use bare and non-bare repositories as remote, but you should use only bare repositories (unless you know what you are doing). Here's a good explanation: http://bare-vs-nonbare.gitrecipes.de/

Re: Git Tips And Workflows

#30
post #12

Has anybody seen a "git for people who have no idea how to use git" tutorial? I use git for keeping track of some personal projects, but the extent to which I understand how to use it is: "git commit origin master" We had a hackathon this weekend, and our team had three people on it. I wanted to make it so that they could also commit code into the same repo (I think this it the right term?), but had absolutely no ide…

Use SVN. There's lack of "svn for people who have no idea how to use svn" tutorials, and when they're published, they tend to be single-paragraph. I'm not sure git is a perfect solution for any project. Unless you intend to pull each other's modifications, the idea of a central "trunk" and custom "branches" is easy to explain to anybody in 5 minutes.

Isn't pulling each others modifications kind of the point of VCS?
Post reply on HN