Any of you Git Junkies?

[Benjamin Liyanage]

Any of you git junkies?  I'm a bit stuck on this right now.

http://stackoverflow.com/questions/10820118/your-branch-is-ahead-of-origin-master-by-1-commit-after-merge


Ben Liyanage
b...@perfectresolution.com
410.336.2464

[Luke Orland]

Ben,

does issuing the following command in your remote server

git reset --hard origin/master

fix the "Your branch is ahead of 'origin/master' by 1 commit." message?

--Luke

> --
> You received this message because you are subscribed to the Google Groups
> "baltimore-node-discussion" group.
> To post to this group, send email to
> baltimore-no...@googlegroups.com.
> To unsubscribe from this group, send email to
> baltimore-node-dis...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/baltimore-node-discussion?hl=en.

[Matthias Lee]

Only do a reset if you are absolutely sure you have your changes backed up.. 

--
Matthias Lee

SDSS/Johns Hopkins University
Performance @ Rational/IBM

Matthia...@gmail.com
Matth...@jhu.edu
(978) 930 4886

To know recursion, you must first know recursion.

[Benjamin Liyanage]

Yes, ultimately that's what I did.  What I don't understand is why is my remote considered ahead of the master if I have merged in a branch with all of its changes?  Shouldn't it be in sync at that point?

[Kyle Fritz]

Ben-

the commit you are ahead with is the merge commit. even a fast-forward merge will make a commit. if you had pushed that commit, very likely you'd have gotten the 0 differences message.

also are you intentionally pushing a different branch to master? that's not standard practice (although it's definitely supported). more common would be to checkout master, merge your local branch in, then push local master to remote master (in which case the colon notation is not required).

Kyle

--
You received this message because you are subscribed to the Google Groups "baltimore-node-discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msg/baltimore-node-discussion/-/ZXKFthNd79MJ.

[Benjamin Liyanage]

I really have no clue what a standard practice would be. I've taken
over this repository from our marketing firm after being incredibly
disgruntled with the way they developed.

I believe my typical flow is something like:

1. Pull from Origin/Master to Remote/Master
2. Make changes on Remote/Master
3. Push Remote/Master to Origin Master:mybranch
4. Merge Origin/Master with Origin/Master:mybranch.

In my mind, at this point the Origin should have all the changes that
I made on my remote server. Should I be pushing the master directly
from my remote server to the Origin? I can be pretty confident that
the Origin has the same master that I started with as for the moment I
am the only one using this repository.

Sometimes git just makes my head explode. I am so much more used to
subversion, with a GUI like TortoiseSVN/AnkSVN.

On May 30, 7:31 pm, Kyle Fritz <kyle.p.fr...@gmail.com> wrote:
> Ben-
>
> the commit you are ahead with is the merge commit. even a fast-forward
> merge will make a commit. if you had pushed that commit, very likely you'd
> have gotten the 0 differences message.
>
> also are you intentionally pushing a different branch to master? that's not
> standard practice (although it's definitely supported). more common would
> be to checkout master, merge your local branch in, then push local master
> to remote master (in which case the colon notation is not required).
>
> Kyle
>
> On May 30, 2012, at 6:56 PM, Benjamin Liyanage <b...@perfectresolution.com>
> wrote:
>
> Yes, ultimately that's what I did.  What I don't understand is why is my
> remote considered ahead of the master if I have merged in a branch with all
> of its changes?  Shouldn't it be in sync at that point?
>
> On Wednesday, May 30, 2012 12:31:39 PM UTC-4, Luke Orland wrote:
>
> > Ben,
>
> > does issuing the following command in your remote server
>
> >   git reset --hard origin/master
>
> > fix the "Your branch is ahead of 'origin/master' by 1 commit." message?
>
> > --Luke
>
> >  --
>
> You received this message because you are subscribed to the Google Groups
> "baltimore-node-discussion" group.

> To view this discussion on the web visithttps://groups.google.com/d/msg/baltimore-node-discussion/-/ZXKFthNd79MJ.

[Adam D Bachman]

It's standard practice for "master" to be master everywhere. The end goal is for everyone to have the same copy of the repository, so when you and I talk about "master", we're both talking about the same exact thing.

In a lot of cases the workflow looks just like svn: you and I `git pull origin master` to make sure our copy of master is up to date. Where it gets different is that if you make a branch, you merge the branch locally (on your machine) into master before pushing master (with changes) to origin. Then when you're all like, "hey, I pushed my changes", I do `git pull origin master` again and we're all (you, me, and origin) in sync. Pushing your branch is optional and really depends on how your team works. I almost never push branches to origin because they're usually small and I'm usually the only one working on them.

"Should I be pushing the master directly from my remote server to the Origin?"

Yes. To be sure everything in master is the same everywhere, it doesn't hurt to do `git pull origin master; git push origin master` just to make sure.

- Adam

[Benjamin Liyanage]

So really I should be doing something like:

1. Pull from Origin/Master to Remote/Master (git pull origin master)
2. Make and commit changes on Remote/Master(git add, git commit)
   
3. Push Remote/Master to Origin Master (git push origin master)
   
4. My master should now match the origin without doing a pull or hard reset.

Does that sound about right?

I'm also a little confused about how I should set up file permissions.  Currently (and IMHO this is a very wonky setup) on our production there is a git repository ontop of our website.  The .GIT folder is in the webroot, though I have removed apache access from it when I took over this repository.  This seems like bad practice in a production environment.  Should my repository be located elsewhere on the server (aka not a web root)?  I've seen some comments floating around on the web where you can hook in scripts that will happen at various commands in the git process.  Presumably I could do a hook that copies the repository to the web root after a push, and chown/mod the files to the appropriate apache user after.

Or is that going a bit off of the deep end, and dishing out the site from the repository is legit?  I've run into some issues where conflict files (which I guess won't happen since I won't be merging branches given the new routine) get jammed onto the website, thus breaking it.

Thanks for the advice on this, I really appreciate it.

-Ben

[Luke Orland]

> Does that sound about right?

That looks good. Also, if you are dealing with multiple remote
repositories and remote branches, you have to be more careful, and it
might be advisable to use fetch + merge instead of pull.

http://longair.net/blog/2009/04/16/git-fetch-and-merge/

I think that permissions are relative to the user who clones the repo;
would it work to clone the repo into a useful location on the
production server with the user who has the necessary permissions?

If you aren't using a service like a GitHub, Bitbucket, or a dedicated
git server, I would use a central (if you will) bare git repository on
one of your servers --
http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html

--Luke

> --
> You received this message because you are subscribed to the Google Groups
> "baltimore-node-discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/baltimore-node-discussion/-/NiQ6e0Sw2bcJ.

[Adam D Bachman]

Does that sound about right?

Yes, like Luke said. That workflow is more or less the easiest "so you're used to svn?" path. Everyone master all the time. The big difference is that your local repo is where all commits live until you push. Good because it means you can work quickly and/or offline, bad because it means your working copy might be different than your teammate's, even though you've both `git pull origin master`ed if you forget to git push. 

Don't feel bad about having to google your way out of git's occasional mind-bending edge cases. Every time I have a problem merging, pulling, rebasing, or pushing I'm looking it up and reading through a half dozen Stack Overflow posts on the same question. The problems are rare enough that the answers don't stick with me.

Regarding deployment, there's no reason you can't serve directly from master. As long as you're not hot-fixing production, there won't be conflicts because all merge conflicts will be sorted out on your local machine. If you accidentally check in a conflicted file and push it, you're screwed, though. But that's what tests are for.

The script hooks you're looking for live in ".git/hooks" if you're using a regular git project or just "hooks/" if you're using the --bare style luke mentioned (common for central-git-repo-on-a-server setups: http://git-scm.com/book/ch4-4.html). The hook you want to mess with is "post-receive" if that's an executable script, it will get called after the repo has a changeset pushed to it. You can write the script in pretty much any language you want. I just worked on a Rails app this weekend and we used git-deploy (https://github.com/mislav/git-deploy) which is Rails specific, but handled all the repository and post-* script setup on the remote server.

This site: http://toroid.org/ams/git-website-howto a super simple split repo / application directory setup. 

My advice on deployment usually boils down to: find a tool that works and use that, but then I don't really enjoy operations / sysadmin work.

- Adam

--

You received this message because you are subscribed to the Google Groups "baltimore-node-discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msg/baltimore-node-discussion/-/NiQ6e0Sw2bcJ.

[Benjamin Liyanage]

Thanks this has been super useful.

-Ben