The three most common ways of making large packfiles

are git-fast-import, the first git-repack, or git-repack -a.

The first already supports a "--max-pack-size=N" option,

which limits the resulting packfiles to N megabytes.

This patchset adds the same option, with the same

behavior, to git-repack to handle the other two cases.
This iteration fixes miscellaneous issues discussed on the list

and introduces no behavior not seen elsewhere in git.

It is based on "next" in order to incorporate Nicolas Pitre's work.

-

Heh, since last night, 'master' and 'next' points at exactly the

same tree object, although their commit ancestry are vastly

different for obvious reasons.
Which leaves 'master' right now at v1.5.2-rc1 while 'next' at

v1.5.2-rc1-687-gcb3892c; we might want to do something about

this apparent discrepancy.
-

It's perfect - I'd say that it's exactly right.
git-describe is for making unique - human readable names for points in

history, not for describing the tree.  It makes no difference that A and B

have the same tree, they are different points.
I've always thought of git-describe as being a way of mapping a commit hash to

a nicer looking name.  If A and B are different commits then they should have

different names.
Andy

--

Dr Andy Parkins, M Eng (hons), MIET

andyparkins@gmail.com

-

Although 'next' and 'master' have vastly different histories

behind them, among 685 commits between master and next, only 27

are non-merges, among which 20 are "real" commits that tried to

advance various topics that failed, and 7 are reverts against

these 20 commits [*1*].
Even though hstory of failed attempts (why they initially seemed

good ideas, how they tried to solve problems, and why they

turned out not to be so good ideas in the end) are interesting,

if we ignore the failed attempts, iow, if we view the history

from the point of view of "surviving features", the development

history of 'next' and 'master' are moral equivalents.  Yes, most

of them were merged way earlier in 'next' than 'master', many of

them were merged in multiple steps of two and three to 'next'

and then finally merged to 'master' with a single merge, but the

changes did hit both 'master' and 'next' (obviously, that is why

we ended up with the same trees).
So the equivalence of 'master' and 'next' tonight is not quite

the same as equating two random commits that happen to have the

same tree.  v1.5.2-rc1 and v1.5.2-rc1-687-gcb3892c should

naturally have the same tree because they share conceptually the

same history.
But I was not talking about changing describe output because of

the above argument.  What I was wondering was that it might be a

good idea to loosen the promise of never rewinding 'next'.  It

might be easier to view the history of 'next' during development

for each cycle, if it started afresh after a feature release.
Since now we are in a stabilization freeze, I expect that

'master' and 'next' will always have identical trees until

v1.5.2 final.  We _could_ declare now that 'next' will be reset

to 'master' when v1.5.2 happens, and people who forked from

'next' to do their own customization can rebase any time that is

convenient for them between tonight and v1.5.2 final.
I was not sure if that is even a good idea, and I am now

inclined to think that keeping the failed attempt history ...
[ message continues ]

And what is the advantage of doing that, exactly?
Nicolas

-

Not much and that is why I am not sure if that is a good idea,

but one thing is:
	$ git log master..next

	$ git log --no-merges master..next
would start showing what are still pending in next without

noise.
With the current 'next', the output of the former is almost

useless, and the latter is useful only until 'next' starts

diverging again from the master and if you are interested in

what will never merged to 'master'.  Once 'next' starts growing

again, you will get mixture of what's cooking and what's killed;

the output from the latter would become useless again.
-

Hi,
Of course, you could graft a fake relationship there. Something like
echo $(git rev-parse master master^ next) >> .git/info/grafts
should do. And you can do it _locally_, since all you care about is the

higher-level relationship that _you_ know about. And this is the way to

teach Git about it.
Ciao,

Dscho
-

In case you did not get it, making the above usable is not about _me_.
-

If you do so, then please tag the branch before resetting it.  I think

it contains valuable data that would get lost otherwise.
Nicolas

-

This is an interesting philosophy-of-version-control question.  If two

identical trees fall in the forest and there is no one there to diff them,

was a release made? :-)
It's been my experience that failed attempts and dead-end branches are often

of equal value to the successful branches.  It's very handy when someone

asks "why can't we do it like this", to be able to answer "look at revision

xyz onwards".  Even just for your own reference, I've often looked back on

abandoned paths and thought "that wasn't as bad as I thought, I just need to

fix it here and here" - if I'd discarded that work it would be gone forever.
It's certainly true in academia, a large part of my doctoral thesis was

about "things that don't work" :-)  Documenting failure is as important as

documenting success.
Andy

--

Dr Andy Parkins, M Eng (hons), MIET

andyparkins@gmail.com

-

Are you considering rewinding next to master?  I'm not sure how

else we could cancel out all of those merges and reverts of bad

ideas from next.
One option might be to teach git-describe to look for matching trees,

and see if git-describe could match the tree that v1.5.2-rc1 points

at with the tree that cb3892c points and, and just call the latter

the former...  But that sounds a little risky to me in some projects,

I'm not convinced that is always the right way to describe a history.
--

Shawn.

-