Skip to main content
Topic: Hating on git part 2 (Read 5265 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Hating on git part 2

Ok, since I "tried" to do some mobile work which failed miserably since I had so many problems with install, and now git it punishing me for not keeping my branch up to date after all the folder name changes with lower case.

How do I fix this little amigo.
https://github.com/IchBin/Elkarte/tree/mobile

Notice I have 2 Theme/theme folders in there.  For some F'n reason git is being a poptart. It doesn't recognize that I have put the mobile theme in the same directory as the default theme. Can't get git to see that there's an update that needs to happen. Half tempted to ditch the whole branch and just create a new one. This @#$% just pisses me off with git.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Hating on git part 2

Reply #1

Yep gave it proverbial middle finger. Deleted the branch and started over.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Hating on git part 2

Reply #2

I've done the delete and restart a few times as well ...

What you can do when Git gets in one of its moods is delete the local branch (assuming you do have everything on the remote), then start a new branch and cherry pick the commits from the remote branch back to your new local.  

I've never been able to figure out why some branches go "bad" but if they do get way behind the master even a rebase or merge gets difficult but cherry picking is sort of a way out, and you can fix conflicts on the fly as well.  That said if its really based on an old master, given how much has been moved/changed, yeah a restart can be less work!

Git generally works, but when it does not its incredibly frustrating, as are the tutorials, it has caused beer thirty to start early here a few times  :P

Re: Hating on git part 2

Reply #3

Yep, keep the master up-to-date is important.
As well as remember to always start working on a branch and never on master.
What I usually do when I'm not sure if a rebase will have conflicts or not is:
Code: [Select]
git checkout branch_to_rebase
git checkout -b branch_to_rebase_back
git checkout branch_to_rebase
git rebase master
[...]
git branch -D branch_to_rebase_back
So I create a backup branch, I do the rebase on the "original" branch and if successful (and if I remember) I delete the backup.
Bugs creator.
Features destroyer.
Template killer.

Re: Hating on git part 2

Reply #4

So you only work on branches - not on master?

Count me in as another unhappy Github user :P I've trashed master a few times, most often when I wanted to revert some major changes. I guess the best option is to keep creating branches every time theres major commit?

Re: Hating on git part 2

Reply #5

@Bloc,
From what I can tell, branches are the shizzle with git. The way I've seen master treated is to only use it to merge features/fixes in from other branches. Many people suggest to create a branch for every feature you add to the code base. Since branches can so easily be added and removed, they seem to be somewhat like toilet paper. :)

@ema
I've never used the rebase command. Guess I need to look that one up.

@Spuds
lol, well in my case it's cherry coke thirty. But lately I've been tempted to dip into the alcohol. ;)
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Hating on git part 2

Reply #6

Quote from: Bloc – So you only work on branches - not on master?
Yep.
Not a single commit to master unless I'm working alone on a repo (and I do quite a bit since for any forum I help out I have a repo).
Commit directly to master when you are working with others is the easiest way to have a broken repo.

master should basically be a clone of the "main" repo, on master I do only pulls (in the sense of update the code to the latest version) from elk master.
So my workflow is:
1) master => pull from elk master
2) new branch
3) commits
4) push (i.e. send to github or bitbucket)
5) [acronym="pull request"]PR[/acronym].
When the PR has been merged start again.

Obviously if I'm working alone on the repo (like with my mods or locally on someone else forum), I use branches only if I need to develop or test something "big" and I don't want to lose (i.e. I want/have to be able at any time to come back on the "current" stable code to fix things for example) the working code.

Quote from: IchBin – @ema
I've never used the rebase command. Guess I need to look that one up.
Be sure to have a copy of the repo somewhere (just copy the entire directory), rebase is the second easiest way to break a repo! :P
Bugs creator.
Features destroyer.
Template killer.

Re: Hating on git part 2

Reply #7

Ah, thanks for the tip(s). I am only one contributor at my Protendo repo(which is also private :P ) but I still manage to mess it up lol. I will def. use branches more then.

TBH I am tempted to just ditch the git/github thing and go back to SVN instead.

Re: Hating on git part 2

Reply #8

That's another option. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Hating on git part 2

Reply #9

The one thing that I really like with git is the ability to swap branches on my localhost and work on that branch, then switch to another branch and work on that, it basically swaps out one version of the site for another. 

So I can start a branch, go crazy, and then just swap to another one with no extra work.   That and being able to pull a PR in to a test branch, and really test it  .... and when done simply swap back to my branch, all without leaving the directory I'm running local on.  I think its the ease in which I can do that task/branch swapping that keeps me going with git.