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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jun 3, 2010, 08:40 UTC
Message-ID: <4C076A6C.601@drmicha.warpmail.net>
In-Reply-To: <7v4ohlatwn.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 03.06.2010 01:36:

Show 17 quoted lines

> 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.

Show 8 quoted lines

> --------------------------------------------------
> [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).

Show 14 quoted lines

> --------------------------------------------------
> [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@drmicha.warpmail.net>, 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 :)

Show 5 quoted lines

> * 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? ;)

Show 10 quoted lines

> 
> * 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