Junio C Hamano venit, vidit, dixit 03.06.2010 01:36:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' while commits prefixed with '+' are in 'next'. The ones
> marked with '.' do not appear in any of the integration branches, but I am
> still holding onto them.
>
> Many topics that have been cooking since 1.7.1 pre-release freeze period
> are now in master; maybe it is a good time to start freezing feature
> branches for 1.7.2---I think I said I'll keep this cycle shorter, no?
>
> --------------------------------------------------
> [New Topics]
> * mg/status-b (2010-05-25) 2 commits
> - Documentation+t5708: document and test status -s -b
> - Show branch information in short output of git status
>
> There are a few style violations that snuck in, but otherwise looked
> sensible.
I tried to follow surrounding style. Or do you mean the "if(" and local
variable initialisations in David'd patch? Do you want any of us to
recheck and resubmit?
I'm running with David's -b all the time, btw, it dramatically reduced
my need for long-status. Works great.
> --------------------------------------------------
> [Stalled -- would discard unless there are some movements soon]
>
> * jc/rev-list-ancestry-path (2010-04-20) 1 commit
> - revision: --ancestry-path
>
> Just an illustration patch. merge simplification logic used when
> pathspecs are in effect interacts with this rather badly.
I think it's still useful. Do all rev-walker flags need to interact
sanely with each other? We could just discourage --ancestry-path with
merge-simplification (and later try to reconcile them).
> --------------------------------------------------
> [Cooking]
>
> * em/checkout-orphan (2010-05-21) 5 commits
> - bash completion: add --orphan to 'git checkout'
> - t3200: test -l with core.logAllRefUpdates options
> - checkout --orphan: respect -l option always
> - refs: split log_ref_write logic into log_ref_setup
> - Documentation: alter checkout --orphan description
>
> In <4BFE2461.5080501@xxxxxxxxxxxxxxxxxxxx>, Michael J Gruber raised a
> valid request for a better explanation of superfluous files left behind
> and then are cleaned. Other than that I think this is a sane thing to
> do.
Got no response but had the impression that retracting myself from the
discussion may improve the willingness of the submitter :)
> * mg/rev-parse-lrbranches-locals (2010-05-14) 1 commit
> - revlist: Introduce --lrbranches and --locals revision specifiers
> (this branch uses mg/rev-parse-option-sifter-deprecation.)
>
> Hmmm...
Now I know what to do ;)
Another approach would be to have something like "ref aliases". I often
use origin/next..origin/pu and origin/next@{1}..origin/next for example.
Maybe allowing something like
[refalias]
puextra = origin/next..origin/pu
punew = origin/next@{1}..origin/next
locals = HEAD --branches --tags
lrbranches = --branches --remotes
would make more sense and allows for personal choices. Hmmm? ;)
>
> * mg/rev-parse-option-sifter-deprecation (2010-05-14) 3 commits
> - t6018: make sure all tested symbolic names are different revs
> - t6018: add tests for rev-list's --branches and --tags
> - rev-parse: deprecate use as an option sifter
> (this branch is used by mg/rev-parse-lrbranches-locals.)
>
> Some people might interpret "Deprecate" too strongly; the intent is that
> we shouldn't keep piling parsing of new rev-list options to it and
> discourage the use of "option sifter" in new programs.
So, s/deprecated/discouraged/? Is there an alternative we should suggest
there for scripts needing to sift their options?
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html