Re: [RFC/PATCH] Introduce branch.name.pushremote

[Blind]

2013/2/19 Ramkumar Ramachandra:
 No.  I don't see why push.default is limiting.

I just want to find a way to exclude a branch (or infact a group of
branches) from $git push --all.
so when I read your thing, I thought for a second that it could be a
possibility... But seems its not the case.

... or branch.name.pushremote can support some kind of a none value?

Blind.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] Introduce branch.name.pushremote

[Blind]

2013/2/19 Ramkumar Ramachandra:

 What is your usecase?  If you have a local branch with the same name
 as on the remote, why wouldn't you want to push-to-update it when you
 make changes in the branch?  In other words, why doesn't push.default
 = matching suffice for most practical purposes.

 ... or branch.name.pushremote can support some kind of a none value?

 Not a bad idea at all, provided you tell me your usecase.

The question is infact about branches who are not on the remote.
push.default=matching wouldn't upload the branches which are not there already.
push --all on other hand pushes .. all (as expected :-))...

Its difficult for me to manage quickly, lets say, news-to-push/* and
crazy-ideas/* branches ...

Blind.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question on for-each-ref and --contains

[St. Blind]

Hi.

In order to make some analyses here I had to build certain report
lists of our remote refs, based on various containing and merged
rules. We have more than hundred such refs at a time usually. So my
poor script which tries to make decisions with the help of rev-list
for each ref on each arbitrary commit is not really fast. The
git-branch --contains and --merged are not very handy too, because the
output is not really flexible, and the --merged works on HEAD only.

Do you think is a good idea to have the option --contains in
for-each-ref too (and/or in rev-list directly)?
If yes, then probably also the --(no-)merged options, but hopefully
with the arbitrary commit this time?

Thank you in advance,
Blind.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html