| 1. | BTW, I'm unsure whether I'll keep both 'scripts' and 'sources' folders side to side in the root. I tend to click on 'scripts' when wanting to view PHP files, and 'sources' when wanting to see JS files, so... Maybe it's just me, but if any of you has a suggestion on renaming the 'scripts' folder to something short and sweet and understandable, knowing that the name 'js' is already taken by the JS cache, I'm very open about this. |
| 1. | Maybe with the hope that I can use Nao/Wedge as my proper work place, and Wedge/Wedge as the place for stable code to be moved to, so that I can afford messing up my pushes and force-pushing them again, with the hope that no one will be forking my own work repo..???? |
- I didn't have to play with rebase at any point. Does that mean I'm free from it, or not? Is rebasing needed only when committing from another branch...?
Basically, if I consider my local repo to be the 'official' one, then I guess the workflow is completely different, and I'll have to learn it (again).
Why the hell does the 'Signed-off' mention only show up in the extended log (i.e. I have to click the '...'), meaning that if I want to check for sign-off status, I have to click Commits, then for each commit open the ..., and pray that it's there..? Why can't github 'simply' add a 'signed-off' *icon* next to the commit entry, so I can immediately tell if it's okay..?
| 1. | pull is equivalent to fetch + merge, so "grab the remote history and merge it into your local branch" |
If you are doing things "right" you should *never* use rebase (unless of merge conflicts, but that's another topic).Quote from Nao on December 15th, 2013, 10:58 PM - I didn't have to play with rebase at any point. Does that mean I'm free from it, or not? Is rebasing needed only when committing from another branch...?
You can work with a sort of "centralized" repo, yes (that is basically what the "upstream" in your case is), the only problem I can see is this:
* repo upstream => commit 1 (let's say)
* I do a commit in my local and push => repo emanuele commit 2
* in the meantime you do a commit on your local repo => origin commit 3
* I send a PR and you merge it from github => repo upstream commit => 4
Now, you'd have to synch your local repo and the remote one (upstream) but: if you push you get a fast-forward (or whatever it is) error because you have new commits locally and new commits in the remote, so you have first to "pull"[1] the remote repo and then push it again.
1. pull is equivalent to fetch + merge, so "grab the remote history and merge it into your local branch"
It's not so different in fact (and probably for your work-flow it could make more sense), the only difference is what is considered the "master" repository: doing the pull request way is the one that belongs to he organization (like for Elk and SMF, in this case you never commit to the org repo, but always to your local one and then synch), in the other you consider your local repo the original one and you could even ignore PR at github and instead fetch the other repos and do the merges directly on your local copy (sorry, I'm one of the few that apparently loves git workflow and can't stop thinking about all the alternatives to do the same thing LOL).
Good question... you should suggest it to them.
Probably because sign-off is not *so* popular...I think, but dunno.
AFAIK, rebase is pretty much the same as merge, it's just the way it shows up in the history log that changes..? I mean, in terms of merging the actual files together, etc.
Now, here's the process I used recently for my workflow...
- master
- Committed theme removal code. Decided to use 'new branch' in the commit window, typed 'byebye-themes'.
- Worked on that branch, then I wanted to switch to PHP 5.3-only. Instead of stashing, switching to master, unstashing, then committing to a new branch (WTF?!), I simply did another 'new branch' in the commit window, and typed 'php-5.3', and committed my changes.
- Wanted to come back to byebye-themes to commit my theme-related changes, but it didn't want to switch, because of the uncommitted stuff. First problem: why the hell can I commit to a 'new branch', but NOT to an existing, prior branch...?! Why would I need to stash, then checkout, then unstash, then uncommit?! I think I could use cherry-picking to move an existing commit to a prior branch, but I'm not very familiar with that, and I don't know if it's the 'recommended way'.
- Okay, now, it gets more complicated... If I try to delete the byebye-themes branch, it tells me that HEAD doesn't have all of the commits in it (!), even though I'd created the new branch from that one. What I want to do at this point, is merge everything back into master.
- I thought, okay, I'll just merge branches manually, one by one. So I went to the master branch, then requested a merge from byebye-themes. (I also tried rebase, with the same effect.) It told me there were conflicts. Which is HORRIBLY WRONG, because byebye-themes was committed FROM master, and master was 100% clean after that commit, so a simple fast-forward should have been enough, but it still found 40+ completely silly merge conflicts, which I'm not willing to fix manually.
(Why is everybody so frigging happy to use git when it's just systematically the same mess, and with SVN around the corner, they could just choose to forego all of that crap?)
I actually tried to do that with Pandos's repo, so that I wouldn't have to bother with duplicate merges. However, now every time I try to commit, it asks me WHERE I should commit. It doesn't accept a 'default' remote, it wants to know which remote every time, so I'm going to have to remove all of my extra remotes. Pff...
I doubt everyone's using a DCO..? :-/
Or maybe pull requests are considered, by practice, to be a de facto sign-off..?
- So, attempting to merge byebye-themes into master WOULD result in conflicts.
What I'd need to do first is reset --hard the master branch to origin/master, or basically, merge my local byebye-themes into origin/master. Or, remove the master branch, and then rename the php-5.3 branch to master. What is best..?
| 1. | and on that there was a fight too with people (from SM) accusing others (developers mainly) to have masked (purposefully) the real meaning of the DCO, etc, but that's completely OT. |