Mike, fwiw `git config --global --add push.default matching` will do
exactly as you specified with a simpler command (git push apache)
A value of "current" is a pretty safe bet too that lets you avoid the
refspec argument and will push the current branch by default.
http://git-scm.com/docs/git-config and search for push.default for a
nice write-up on the different options.
IMO, you can use Git however the heck you want (TIMTOWDI). But if you
mess up, I'll call you out on it ;)
On 2/20/14, 4:12 PM, Mike Drob wrote:
I recommend "git push apache : -n" where 'apache' is the name I have given
the asf remote and ':' indicates to push matching branches, and -n is dry
run.
On Thu, Feb 20, 2014 at 6:41 PM, Christopher <[email protected]> wrote:
Definitely avoid git push --all. I don't think the order is well
defined. But, I do agree that a good workflow is to do all the merges
in order, then go back and do all the pushes in order.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Feb 20, 2014 at 5:32 PM, Keith Turner <[email protected]> wrote:
On Thu, Feb 20, 2014 at 5:05 PM, Mike Drob <[email protected]> wrote:
I think the difference in workflow is that some committers push and
merge
branches one at a time, while other committers merge everything locally
and
then push all at once. I strongly prefer the second approach.
The second approach is best. Still need to be careful. AFAICT git push
-all is not an atomic operation across all branches. Need to push the
oldest branch first. Will 'git push -all' do this? If not, then should
push branches in correct order.
On Thu, Feb 20, 2014 at 4:54 PM, Christopher <[email protected]>
wrote:
I agree you definitely don't want to be skipping specific commits when
merging... but that's not what Mike nor I suggested. Rather, our
suggestion was that you can do a regular merge of any parentage,
before doing a -sours merge of your commit.
To John's point, this is essentially what the previous committer
should have done (in this case, me) before your commit arrived.
However, there is a race condition here... and the previous committer
may be in the process of doing this when you come on the scene. So,
you should always be extra careful about merging.... especially with
-sours.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Feb 19, 2014 at 4:21 PM, Bill Havanki <
[email protected]
wrote:
John's strategy can certainly work [1]. I don't think it's a good
idea
to
make it a typical part of workflow, though. It's complicated, and I
don't
want to have to look back through the history before each merge (3
of
them
for a 1.4 change) for commits to skip.
Also, skipped commits are still left behind, unmergeable, requiring
a
cherry-pick to be rescued later. So, to be safe, you'd have to wait
to
find
out what to do with them before skipping.
I don't know a better tactic, but I have the feeling it must involve
less
branches or less merging.
[1]
http://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging
On Wed, Feb 19, 2014 at 3:20 PM, Christopher <[email protected]>
wrote:
As Mike pointed out, you can't do it if there is unmerged parents.
You
have to merge the parents first, then your commit. If there's any
commits which are children of the commit you want to merge with
-sours, you can single out your specific commit by referencing the
sha1 in the merge instead of the branch name. That will leave the
children unmerged, still, but will isolate your -sours to just that
commit. Then you can merge the remaining children in a separate
merge.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Feb 19, 2014 at 3:03 PM, Bill Havanki <
[email protected]>
wrote:
Popping this out of JIRA since I am changing the subject
somewhat.
Christopher (or anyone, really): Can you give me an example of
doing a
merge with -sours but only with specific commits, as
recommended? It
makes
sense that this is safer vs. sweeping in HEAD. Just trying to
refine
my
workflow. Thanks!
Bill
---------- Forwarded message ----------
From: Christopher Tubbs (JIRA) <[email protected]>
Date: Wed, Feb 19, 2014 at 2:36 PM
Subject: [jira] [Commented] (ACCUMULO-1961) Fix trivial
compiler/javadoc
warnings
To: [email protected]
[
https://issues.apache.org/jira/browse/ACCUMULO-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905940#comment-13905940
]
Christopher Tubbs commented on ACCUMULO-1961:
---------------------------------------------
It looks like you are right. Be careful about -sours. You should
probably
only use that with specific commits, not the HEAD of the branch,
which
could reference multiple commits.
Don't worry about fixing it. I'll redo. There's some other
javadoc
errors/warnings and other trivial warnings in master that need
to be
fixed
anyway.
--
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -
