Re: What's cooking in git.git (Jun 2010, #01; Wed, 2)

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 [ref], 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