I've been on projects where leads waste half their time getting
contributors up-to-speed on VCS policy. Painful.
Only I've ended up being that person when I try submit to ansible.
Part of the problem is there seem to be a ton of workflow
possibilities with git. Another part is that my shop uses Mercurial,
which is close enough to git to love them both, but different enough
that some good practices with Mercurial are not very good practices
with Git.
So...
Is there a place (ProGit, Github resources, Ansible docs?) that writes
up a submission workflow that's close to what works on this project?
Is it worth documenting succinctly this in the project pages? I'd
volunteer...once I get clear on it.
--Brad Olson
I’ve been on projects where leads waste half their time getting
contributors up-to-speed on VCS policy. Painful.
It’s hardly half my time. Most of my time is spent with code review, and if I get a series of 10 commits
versus one succinct commit, it’s pretty hard to review. Yes I will ask you to fix your commit rather than me
fixing it, which is what I used to do. That took way more time than teaching someone to alias ‘git pull’ to ‘git pull --rebase’.
Yes, if they submit that, I won’t take it, because it’s much harder to review.
Only I’ve ended up being that person when I try submit to ansible.
Part of the problem is there seem to be a ton of workflow
possibilities with git. Another part is that my shop uses Mercurial,
which is close enough to git to love them both, but different enough
that some good practices with Mercurial are not very good practices
with Git.
FWIW, mercurial, which I use at work, is relatively a tricycle in comparison.
Yes, there is a learning curve with the actual car 
So…
Is there a place (ProGit, Github resources, Ansible docs?) that writes
up a submission workflow that’s close to what works on this project?
I need to do it. Not at the immediate top of my queue, but it will happen.
I'm glad to resubmit while learning to drive, and thanks for the tips.
Okay, needing a bit more best practice advice on keeping a feature
branch properly rebased once I've pushed it to my remote fork.
First, should I be changing anything about how I set up for work?
1. Fork github's ansible/ansible.
2. Clone a local copy of my fork.
3. git remote add upstream https://github.com/ansible/ansible
4. git checkout devel #tracks my fork's devel
5. git checkout -b somefeature
To stay current with upstream/devel I:
(current branch is somefeature)
1. git fetch upstream
2. git rebase upstream/devel somefeature
I liked your idea to alias pull to pull --rebase, but not sure how to
make that work with this setup.
My worry is how to stay current once I've pushed somefeature to my
fork:
(current branch is somefeature)
1. git push origin somefeature
On the next day, if I edit somefeature locally and commit, then:
1. git fetch upstream
2. git rebase upstream/devel somefeature
3. git push
...doesn't that make problems due to pushing rebases of things already
pushed?
Brad,
Please keep documenting your workflow here. I need to set up exactly the
same thing.
-- Art Z.
the way to checkout and track is:
git checkout -t origin/devel
I actually clone from ansible proper and have added my repository as an additional remote.
(BTW, there is no point in anyone following my repository, it’s nothing more than a backup)
–Michael
I actually clone from ansible proper and have added my repository as an additional remote.
git checkout -t origin/devel
Yes! That's what I was looking for! Thanks, Michael.
How do you handle pushing rebased work (cf. example three posts back)
to your own remote repository?
Yeah you have to specify where to push, is all:
git push mpdehaan