Git Tips for Beginners Interested in Open Source • Hacker News Board

Re: Git Tips for Beginners Interested in Open Source

#21

Post by jlgreco » Mon, Sep 09, 2013, 5:38 PM UTC

vsbuffalo wrote: post #20

sandyarmstrong wrote: post #17

"Never Work on Master" - yes! "Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner! (a) I never accidentally work on master anymore. (b) I never have to switch to master to pull the latest from the remote. (c) One less…

Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.

More reasonable is to say "never expect other people to accept your changes to master".

Even if you are collaborating, feel free to work on master. You just may (probably will) have to knock it over to another branch when it comes time to give it to other people. Think of it like rewriting history with rebase before you push; the objective is to make it look like you did everything 'correctly' the first time through.

Branches are a 'weaker' concept in git than some people seem to think. They are really just labels for commits that can be moved (unlike tags).

Re: Git Tips for Beginners Interested in Open Source

#22

Post by agumonkey » Mon, Sep 09, 2013, 6:25 PM UTC

sandyarmstrong wrote: post #17

"Never Work on Master" - yes! "Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner! (a) I never accidentally work on master anymore. (b) I never have to switch to master to pull the latest from the remote. (c) One less…

This has to be the smallest and most important git tip I've read. Suddenly I see branches as transactions and master a coherent backend.

Re: Git Tips for Beginners Interested in Open Source

#23

Post by ianstallings » Mon, Sep 09, 2013, 6:38 PM UTC

I wish he would add one more since he mentioned github - don't fork unless you actually need to. I see way too many forks of projects on github with no significant changes. If you have a bug fix make it on the same repo and then submit a pull request with your changes. Forks are for adding new features, making major changes, or if the original author is no longer maintaining the project.

Re: Git Tips for Beginners Interested in Open Source

#24

Post by js2 » Mon, Sep 09, 2013, 6:52 PM UTC

richardwhiuk wrote: post #3

Trunk is normally called origin in git nomenclature. git push -f needs a big red box round it, not as a normal thing to do. If you want to fix a pushed commit, do a new commit! If you keep pushing dodgy commits, try waiting between committing and pushing, or get better at reviewing your changes.

Trunk is normally called origin in git nomenclature.

Pedantically, when you refer to "origin", you're referring to the default branch for the remote named "origin" (i.e. the branch referred to by refs/remotes/origin/HEAD after cloning).

This is typically master, but not necessarily. In fact, you can update refs/remotes/origin/HEAD to point to any branch under refs/remotes/origin via "git remote set-head". (It's also possible that the remote repo's HEAD was something other than master when you cloned.)

If you want to be explicit, use origin/master, or refs/remotes/origin/master to be more explicit still.

The same applies for other remotes you may have configured in the same repo.

A related concept is the @{u}/@{upstream} token. Git resolves this token from the currently checked-out branch's configuration. e.g., if master is checked out (i.e. HEAD is refs/heads/master), git checks in .git/config for branch.master.remote and branch.master.merge and uses those to determine the upstream branch. In this example, those would typically be branch.master.remote=origin and branch.master.merge=refs/heads/master, which git resolves to refs/remotes/origin/master.

Finally, @{upstream} can be configured via git branch --set-upstream-to=... (in older versions of git the more confusing and now deprecated --set-upstream was used).

Re: Git Tips for Beginners Interested in Open Source

#25

Post by js2 » Mon, Sep 09, 2013, 6:55 PM UTC

lambda wrote: post #15

markberger wrote: post #5

Earlier quoted context omitted.

Thanks for the comments Richard. Since Github uses origin as user's fork of the project, I was trying to distinguish the project's main repository and the user's fork. Admittedly, after seeing comments from other people, trunk probably isn't the best name for it.

My convention is usually to clone from the upstream project, thus it winds up being "origin", and then adding my own repository as another remote, named after my username. If there are any other users whose repositories I'm following, I add theirs as other remotes named after their usernames as well, remaining consistent. That way, when I pull from origin, I'm pulling from whatever the official origin repository is;…

This is an excellent workflow and then one I use as well.

Re: Git Tips for Beginners Interested in Open Source

#26

Post by jedbrown » Mon, Sep 09, 2013, 7:25 PM UTC

ianstallings wrote: post #23

I wish he would add one more since he mentioned github - don't fork unless you actually need to. I see way too many forks of projects on github with no significant changes. If you have a bug fix make it on the same repo and then submit a pull request with your changes. Forks are for adding new features, making major changes, or if the original author is no longer maintaining the project.

How do you "make it on the same repo and then submit a pull request" without either (a) having write access to that repo or (b) forking?

This is one way in which 'git send-email' is lighter weight and more convenient, provided all involved know how to use it.

Re: Git Tips for Beginners Interested in Open Source

#27

Post by elasticdog » Mon, Sep 09, 2013, 8:03 PM UTC

duggieawesome wrote: post #13

+1 for checking trailing white space. Whenever I'm working on an OS project and I happen to open a file with white space or unnecessary blank lines, I delete them and send them the changes with my PR. Highly suggest it.

It annoys me too. If you do a git diff against the sha1 of a completely empty tree, you can see all of the whitespace errors that have been checked into a repository:

    $ git diff --check $(git hash-object -t tree /dev/null)

...although many projects frown upon whitespace-only commits since they screw with `git blame`.

Re: Git Tips for Beginners Interested in Open Source

#28

Post by sandyarmstrong » Mon, Sep 09, 2013, 9:54 PM UTC

vsbuffalo wrote: post #20

sandyarmstrong wrote: post #17

"Never Work on Master" - yes! "Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner! (a) I never accidentally work on master anymore. (b) I never have to switch to master to pull the latest from the remote. (c) One less…

Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.

OP was pretty clear that they were coming from a "collaborating in open source" point of view, I thought.

Re: Git Tips for Beginners Interested in Open Source

#29

Post by sandyarmstrong » Mon, Sep 09, 2013, 9:57 PM UTC

jlgreco wrote: post #21

vsbuffalo wrote: post #20

Earlier quoted context omitted.

Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.

More reasonable is to say "never expect other people to accept your changes to master". Even if you are collaborating, feel free to work on master. You just may (probably will) have to knock it over to another branch when it comes time to give it to other people. Think of it like rewriting history with rebase before you push; the objective is to make it look like you did everything 'correctly' the first time through.…

Sure. You can totally work on master. But I find that it's a lot easier to get confused about what's been merged, and to accidentally make mistakes, when you make a habit of working on master.

That's why I find that I make a lot fewer silly mistakes if I just get rid of the local master branch for any repo that I am actively contributing to in a team environment.

Re: Git Tips for Beginners Interested in Open Source

#30

Post by ianstallings » Mon, Sep 09, 2013, 10:38 PM UTC

jedbrown wrote: post #26

ianstallings wrote: post #23

I wish he would add one more since he mentioned github - don't fork unless you actually need to. I see way too many forks of projects on github with no significant changes. If you have a bug fix make it on the same repo and then submit a pull request with your changes. Forks are for adding new features, making major changes, or if the original author is no longer maintaining the project.

How do you "make it on the same repo and then submit a pull request" without either (a) having write access to that repo or (b) forking? This is one way in which 'git send-email' is lighter weight and more convenient, provided all involved know how to use it.

Jesus you're right I always use the community model where one can be added to the project and submit the changes that way. I wish there was an easier way to use the proper branching model because that's what it truly is, a branch.

That's not even really my beef, it's users that fork and never intend on making any changes because they don't understand how to clone. So when you search the name of the project you get a ton of results.