* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Josef Weidendorfer @ 2006-12-07 2:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Parkins, git
In-Reply-To: <Pine.LNX.4.63.0612070022180.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Thursday 07 December 2006 00:23, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 6 Dec 2006, Josef Weidendorfer wrote:
>
> > On Wednesday 06 December 2006 13:07, Andy Parkins wrote:
> > > The [branch "master"] section is such that there is no change to the
> > > functionality of git-pull, but that functionality is now explicitly
> > > documented.
> >
> > Nice. However, changing "git-clone" for this is an adhoc solution and
> > looks wrong.
>
> Not to me. There is _no_ other place to put this, if you want to help
> people graps the concept of branch.*.merge.
As far as I understand, git-clone defaults to kind of a mirror operation
while changing remotes ref names slightly as tracking branches, and
afterwards, it sets up a local branch for development, which is
branched off from the branch which tracks remote's master.
IMHO there only should be one place/command which is creating new branches,
and which is called by other porcelain commands [*1*]. This way, if we add
some further action to "branching off" (like adding a default merge branch),
we will not miss any place where a new branch will be created, thus keeping
everything consistent.
Why should we not setup branch.*.merge when a create a new development
branch from a tracking branch via "git branch", or "git checkout -b" ?
Josef
[*1*] I recently made up my mind about this. I suggested a patch (see
"[PATCH/RFC] Convenient support of remote branches in git-checkout"
in the mail archive), which also set up "branch.*.merge" in a similar
way as this patch is doing. And I got - rightly - the same response
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Liu Yubao @ 2006-12-07 1:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Alex Riesen, git
In-Reply-To: <20061206181302.GA20320@spearce.org>
Shawn Pearce wrote:
>
> You are just *very unlucky*. :-)
>
> The Linux kernel has case sensitive file names. In other words there
> are two files in the kernel:
>
> net/netfilter/xt_MARK.c
> net/netfilter/xt_mark.c
>
> and they have different content! On NTFS or FAT, where filenames
> are not case sensitive, these become the same file. So Git now
> starts to think that the file was modified, because one of those
> files overwrote the other when they were checked out.
>
> Moral of the story: You cannot work with the linux.git repository
> on a case insensitive filesystem, like NTFS, FAT (Windows), or HFS+
> (Mac OS X).
>
Yes, you are very right.
$ git ls-files |tr A-Z a-z | sort | uniq -c |grep -v "1 "
2 include/linux/netfilter/xt_connmark.h
2 include/linux/netfilter/xt_dscp.h
2 include/linux/netfilter/xt_mark.h
2 include/linux/netfilter_ipv4/ipt_connmark.h
2 include/linux/netfilter_ipv4/ipt_dscp.h
2 include/linux/netfilter_ipv4/ipt_ecn.h
2 include/linux/netfilter_ipv4/ipt_mark.h
2 include/linux/netfilter_ipv4/ipt_tcpmss.h
2 include/linux/netfilter_ipv4/ipt_tos.h
2 include/linux/netfilter_ipv4/ipt_ttl.h
2 include/linux/netfilter_ipv6/ip6t_hl.h
2 include/linux/netfilter_ipv6/ip6t_mark.h
2 net/ipv4/netfilter/ipt_ecn.c
2 net/ipv4/netfilter/ipt_tos.c
2 net/ipv4/netfilter/ipt_ttl.c
2 net/ipv6/netfilter/ip6t_hl.c
2 net/netfilter/xt_connmark.c
2 net/netfilter/xt_dscp.c
2 net/netfilter/xt_mark.c
^ permalink raw reply
* Re: [PATCH] change the unpack limit treshold to a saner value
From: Linus Torvalds @ 2006-12-07 1:08 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612061420410.2630@xanadu.home>
On Wed, 6 Dec 2006, Nicolas Pitre wrote:
>
> This is why I think the current default treshold should be 3 instead of
> the insane value of 5000. But since it feels a bit odd to go from 5000
> to 3 I setled on 10.
Definitely not.
We have a much easier time handling many loose packed objects than many
pack-files. For many reasons, but two really obvious ones:
- pack-file indexes get read in on startup, and we maintain an explicit
list of them. Having lots of pack-files adds overhead that doesn't
exist for lots of loose objects.
- loose files are spread out over 256 subdirectories to make lookup
easier, packfiles are not (and always create an index file too).
So in general, as a trivial heuristic, you probably want about 512 times
as many loose objects as you want pack-files, i fonly because of the
latter issue, because you can much more easily handle lots of loose
objects than lots of pack-files. So it's _not_ a factor of 3. Or even 10.
But since there _is_ reason to do pack-files too, and since using too big
a value means that you never end up keeping a pack-file _at_all_ if you
pull often, I'd suggest that rather than use a limit of 512 you go for
something like 100-200 objects as the threshold (of course, the proper one
would depend on the distribution of the size of your pack-files, but I'll
just hand-wave and say that together with occasional re-packing, something
in that range is _generally_ going to be a good idea).
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Linus Torvalds @ 2006-12-07 0:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Marco Costalba, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0612070025450.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 7 Dec 2006, Johannes Schindelin wrote:
>
> Because, depending on what you do, the revision machinery is not
> reentrable. For example, if you filter by filename, the history is
> rewritten in-memory to simulate a history where just that filename was
> tracked, and nothing else. These changes are not cleaned up after calling
> the internal revision machinery.
Well, it really wouldn't be that hard to add a new library interface to
"reset object state". We could fairly trivially either:
- walk all objects in the object hashes and clear all the flags.
- just clear all objects _and_ the hashes.
Yes, it implies a small amount of manual "management", but considering
that the reason it needs to be manual is that the functions simply _need_
the state, is that such a big deal?
^ permalink raw reply
* Re: [PATCH] change the unpack limit threshold to a saner value
From: Nicolas Pitre @ 2006-12-07 0:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejrcy860.fsf@assigned-by-dhcp.cox.net>
On Wed, 6 Dec 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Let's assume the average object size is x. Given n objects, the needed
> > storage size is n*(x + b), where b is the average wasted block size on
> > disk.
> > ...
> > This is why I think the current default treshold should be 3 instead of
> > the insane value of 5000. But since it feels a bit odd to go from 5000
> > to 3 I setled on 10.
>
> I see you are optimizing for disk footprint, and this will
> result in tons of tiny packs left between "repack -a".
Depends how often i.e. how big pushes are, and how often you repack.
> I have not benched it yet, but the runtime pack handling code
> was written assuming we have only a handful of big packs; I
> suspect this change would affect the performance at runtime in
> quite a bad way.
Possibly.
Still a treshold of 5000 is way too large IMHO.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2006-12-06 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekoyb79.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 6 Dec 2006, Junio C Hamano wrote:
> Here is a list of topics that are cooking; the commits marked
> with '+' are in 'next', '-' are in 'pu'. Dates are when the
> topic was last touched [*1*].
I like the combined pu/next "What's new".
> * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
> [...]
> I think it is sensible to merge to 'master' after that change.
Me, too. I really would like this to go in.
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
> + git-merge: preserve and merge local changes when doing fast forward
> [...]
> It has been in next for some time and unless we hear somebody scream I
> think it is Ok to merge to 'master'.
This is something I am looking forward to to test. Maybe in "next" for
while before putting it into "master"?
> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
> - git-explain
I vote for putting this into "next" for a wider audience. It also would
help people to submit patches (it is kind of a hassle to branch "pu", so I
rarely do it myself, whereas my git is based on "next" at all times).
> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
>
> merge-recursive that does not rely on RCS "merge". I use this
> exclusively these days. Perhaps cook a little further and
> merge to 'master'.
Yes, definitely cook it for at least a week; maybe I find the time to
check the conflicted merges in git.git at least.
> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)
>
> Probably with a better documentation of its limitations and caveats,
> this should be mergeable to 'master'.
The more I see the missing reaction, the less sure I am this is a sensible
thing to do.
And it would need more safety valves, not just documentation. For example,
I am not sure if a push from/to a shalow repo is safe.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Jakub Narebski @ 2006-12-06 23:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612070020580.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Wed, 6 Dec 2006, Jakub Narebski wrote:
>
>> Michael Loeffler wrote:
>>
>>> Am Montag, den 04.12.2006, 20:48 +0100 schrieb Jakub Narebski:
>>> ...
>>>> I'm not sure if regexp support is truly better than the usual path globbing,
>>>> as in fnmatch / glob.
>>>
>>> The current code does not do a real glob, this was the reason for me to
>>> think about regex support, I thought it is easy to use sed for this. Now
>>> I know it better.
>>
>> We could use perl for that, but embedded perl is a bit horrible.
>
> Not to talk about portable, and as we saw, dependent on the C compiler
> (you would have to make git compile with the same C compiler that perl was
> compiled with).
>
> So, please look into other options first.
No, not embedded in C, but embedded in shell script.
Use perl -ip instead of sed.
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-06 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7virgo511i.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 12087 bytes --]
On Wed, 06 Dec 2006 10:31:21 -0800, Junio C Hamano wrote:
> I am not sure what needs to be commented on at this point, since
> it is not yet clear to me where you want your proposal to lead
> us.
Thanks for the comments you made here---that's the kind of thing I was
looking for.
As for where I'm trying to lead us, what I really want to do is to
help improve the learnability of git. A big part of that is about
improving the set of "use-oriented" documentation, (which describes
how to achieve tasks, as opposed to what might be termed "technically
oriented" documentation which describes how individual tools work). I
think too much of the existing documentation falls into the second
class.
A parallel thread is already talking about some of the important
organizational aspects of use-oriented documentation. And I agree with
that thread is that the short "attention span" is a primary
consideration for this kind of documentation. The user has a task to
be accomplish, and any text or concepts that aren't contributing to
the solution of that task should be eliminated.
Note that when I talk about eliminating unnecessary concepts, I do not
mean lying to the user about the underlying model or any concepts. We
can't have a sugar-coated tutorial that says one thing, and then
expect users to "unlearn" that if they go deeper into the reference
manual. That's a recipe for disaster.
Also, when I say "use-oriented" I'm not suggesting that the
documentation be shallow. It can go as deep as any workflow we care to
document and introduce whatever concepts of git are necessary to
support that workflow. (There is, though a level at which "technically
oriented" documentation is all that's needed, or even desired, and
that's when the documentation is targeting authors of interfaces that
build on top of git---not users trying to use git to get work done at
the command line).
OK, so if my concern is all about documentation, then what am I doing
proposing new commands or new ways of thinking about existing commands
rather than just sending documentation patches? The problem is that
the current semantics of the following variations of "git commit":
git commit
git commit -a
git commit paths...
defeat the goal of writing good, clean use-oriented documentation. So
there's some adjustment that should be made first. And I don't even
care what the adjustment is, (for example, it doesn't have to be
"commit -a by default"), but please recognize the problem and help me
come up with an acceptable way to fix it.
To demonstrate, let's take the simplest of use cases and try to
document it in as clear a way as possible. Let's imagine we're in a
tutorial where we've just guided the user to making modifications to
several existing, tracked files, (starting from an initial clone, not
an init-db), and the next task to teach the user commit for the first
time. We would like to document both "commit a single modified file"
and "commit all modified files". Here are two approaches that I can
come up with:
1. Any commit involves first "add"ing together new content, and then
committing the result. For example to commit a single file:
git add file # add new content from file
git commit # commit the result
As a shortcut, "commit -a", (or --all) can be used to automatically
"add" the content of all tracked files before the commit. So the
common case of committing all tracked files is as easy as:
git commit -a # commit content of all tracked files
2. The new content of modified files can be committed by naming the
files on the "git commit" command line. For example:
git commit file # commit new content of file
As a shortcut, "commit -a", (or --all) can be used to commit the
content of all tracked files:
git commit -a # commit content of all tracked files
Neither of the above is totally satisfactory.
In (1) the user is not presented with a framework that will make sense
of "git commit files...". The expansion of "-a" as "--all" could
easily give the user the impression that "git commit files..." is a
shortcut for "git add files...; git commit", but that's wrong and
could lead to unexpected results and confusion.
In (2) the user is not presented with a framework that will make sense
of "git commit" with no arguments. The user is left to wonder about
why the --all is needed and what it means exactly, (particularly since
"git commit" also commits the content of all tracked files.
Various fixes have been proposed for these potential confusions. For
example, making "git commit files..." default to the behavior of
--include instead of --only would eliminate the confusion I described
for (1). And making -a the default for "git commit" would eliminate
the confusion I described for (2).
However, actually implementing either of those fixes would then break
the initial "commit one file" example from the other approach. Because
of that, the conversation has often fallen into debate over whether
(1) or (2) is the "one true way" to describe git, and which one leads
the user to have an incorrect mental model.
But I think that debate is misguided since both descriptions are
worthwhile and valid. (1) is based around an explanation of what "git
commit" does, and (2) is based around an explanation of what "git
commit files..." does. And both of these commands are very useful
exactly how they are.
It's almost coincidental that "commit -a" fits in logically with
either description.
So what I was trying to get across in this latest thread is that git's
command-line interface already has two slightly different models for
what's going on in a commit. You don't agree with me on that point
yet, (more on that below in my reply).
I really don't care what the final fix is, but I would love to see
documentation with no more complexity than the above that accurately
captures the useful functionality.
And I don't actually have a concrete proposal for a fix yet---I was
just offering the commit-index-content and commit-working-tree-content
ideas as ways to think about the issue. Maybe the two documentation
blurbs above capture it in a better way.
Do you feel like you have a better understanding of what I'm trying to
do now?
> I do not agree with your "three commands" or "two semantics"
> characterization of the current way "git commit" works. "git
> commit" without any optional argument already acts as if a
> sensible default arguments are given, that is "no funny business
> with additional paths, commit just what the user has staged
> already."
I agree that "git commit" does nothing funny by default. What I was
pointing out is that "git commit" and "git commit paths..." do not
have the same semantics. There's really nothing to debate about
there. There is no argument you can substitute for <paths...> to give
you identical behavior as "git commit". That's a fact.
> "git commit" is primarily about committing what has been staged
> in the index, and "--all" is just a type-saver short-hand (just
> like "--include" is) to perform update-index the last minute and
> nothing more. In other words, "--all" is a variant of the
> pathname-less form "git commit". It is not a variant of "git
> commit --only paths..." form, as you characterized.
I hope the documentation blurbs (1) and (2) above show how "commit -a"
can be seen as a variant of either "commit" or "commit files...",
(which themselves are both useful semantics, but demonstrably
distinct).
> The pathname form (the "--only" variant) on the surface seem to
> work differently, but when you think about it, it is not all
> that different from the normal commit. We explain that it
> ignores index, but in the bigger picture, it does not really.
No, it really is different.
> the first commit does "jump" the changes already made to the
> index, but after it makes the commit, the index has the same
> contents as if you did "git update-index a b" where you ran that
> "git commit". In other words, it is just a handy short-hand to
> pretend as if you did the above sequence in this order instead:
How could you document "git commit files..." as a shorthand? A
shorthand for what exactly? A shorthand for pretending you didn't just
type the commands you did type that got the index into its current
state, but had instead typed different commands before the commit and
other commands afterwards?
That's crazy. That's not a shorthand. That's just plain different
semantics. The current "git commit files..." command never does commit
the contents of "the" index as a concept presented by "git
commit". (This is independent of the fact that the implementation of
"git commit files..." certainly does use an index file somewhere and
uses it to create a commit object in the same way that "git commit"
uses "the" index).
> So I actually think it is a mistake to stress the fact that "git
> commit --only paths..." seems to act differently from the normal
> "git commit" too much.
I think that would be lying to the users and setting them up to get
confused later. I discussed this above as the confusion that can
result with the explanation of (1). If you teach "git commit" as
commiting "the" index, and de-emphasize that "git commit files..."
is semantically distinct, then how is a user ever supposed to learn
what it is that "git commit files..." is actually doing?
> In short, while I understand that your "proposal" shows your own
> way to summarize the semantics of "git commit", I am not seeing
> what it buys us, and I do not see the need to come up with a
> pair of new two commands for making commits (if that is what the
> proposal is about, that is, but it is not clear to me if that is
> what you are driving at). I think it would only confuse users.
Forgive me again for being obtuse. I don't think we should necessarily
add two new commands. I was trying to illustrate a problem in the
existing command set, and propose a new way of thinking about the
tasks that the current commands help a user to perform, (committing
content from the working tree or committing content from the index). I
don't actually have a concrete proposal for how to take that way of
thinking and map it to a command set, (and one that would disrupt
current git users as little as possible). I'd love to have some help
with that part.
> Is it just me who finds the above a very much made-up example?
Fine. We can ignore that example.
> In any case, I should clarify my aversion to partial commits a
> bit. What is more important is to notice that, while you cannot
> compile-and-run test what is in the index in isolation (without
> a fuse that exports the index contents as a virtual filesystem
> -- anybody interested?), you _can_ preview and verify the text
> that is going to be committed by comparing the index and the
> HEAD. And for that, your "staging" action (i.e. Nico's "git
> add") needs to be a separate step from your "committing" action.
Yes, I often use the index as a place to preview things. And it is
true that I find myself using update-index when I could have used
"commit paths..." precisely because I can preview it once more. But I
do use the "commit paths..." form at times as well. If I have just
reviewed things in "git diff" and there are _really_ obviously
separable pieces I will commit them alone with staging into the index
and reviewing again.
It's probably the case that I skip the explicit staging and extra
preview when I can use a single pathname as the argument to "git
commit".
> In other words, I would even love Johannes's "per hunk commit"
> idea, at least if it had an option to preview the whole thing
> just one more time before committing, and I would love it better
> if it had an option for not committing but just updating.
Yes! I've wanted tools to help with per-hunk separation before, but
since I'm so likely to make mistakes while doing that I would only
want that to go into the index so that I could review it before
committing. I guess I might need a per-hunk way to fix up my mistakes
too if I put a hunk into the index that I didn't want to be there.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Johannes Schindelin @ 2006-12-06 23:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <20061206192800.GC20320@spearce.org>
Hi,
On Wed, 6 Dec 2006, Shawn Pearce wrote:
> Marco Costalba <mcostalba@gmail.com> wrote:
> > The time it takes to read, without processing, the whole Linux tree
> > with this approach it's almost _double_ of the time it takes 'git
> > rev-list' to write to a file:
> >
> > 3) Other suggestions? ;-)
>
> The revision listing machinery is fairly well isolated behind some
> pretty clean APIs in Git. Why not link qgit against libgit.a and just
> do the revision listing in process?
Because, depending on what you do, the revision machinery is not
reentrable. For example, if you filter by filename, the history is
rewritten in-memory to simulate a history where just that filename was
tracked, and nothing else. These changes are not cleaned up after calling
the internal revision machinery.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Johannes Schindelin @ 2006-12-06 23:23 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Andy Parkins, git
In-Reply-To: <200612061800.17087.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 6 Dec 2006, Josef Weidendorfer wrote:
> On Wednesday 06 December 2006 13:07, Andy Parkins wrote:
> > The [branch "master"] section is such that there is no change to the
> > functionality of git-pull, but that functionality is now explicitly
> > documented.
>
> Nice. However, changing "git-clone" for this is an adhoc solution and
> looks wrong.
Not to me. There is _no_ other place to put this, if you want to help
people graps the concept of branch.*.merge.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Johannes Schindelin @ 2006-12-06 23:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el6sni$re3$1@sea.gmane.org>
Hi,
On Wed, 6 Dec 2006, Jakub Narebski wrote:
> Michael Loeffler wrote:
>
> > Am Montag, den 04.12.2006, 20:48 +0100 schrieb Jakub Narebski:
> > ...
> >> I'm not sure if regexp support is truly better than the usual path globbing,
> >> as in fnmatch / glob.
> >
> > The current code does not do a real glob, this was the reason for me to
> > think about regex support, I thought it is easy to use sed for this. Now
> > I know it better.
>
> We could use perl for that, but embedded perl is a bit horrible.
Not to talk about portable, and as we saw, dependent on the C compiler
(you would have to make git compile with the same C compiler that perl was
compiled with).
So, please look into other options first.
Ciao,
^ permalink raw reply
* Re: Topic descriptions
From: Junio C Hamano @ 2006-12-06 22:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612062153.30639.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> -----
> <sha1>
> <anything at all>
> -----
>
> I don't know where the UI would go; but it would let Junio generate his what's
> cooking emails with cat .git/refs/*/*
I think the right place to store that <anything at all>
information is per-branch configuration item. Perhaps:
[branch "ap/clone-origin"]
description = we talk about what this thing does and \
what the current status of it is.
I am unlikely to use such a thing for the "What's in" message,
though. The part that talks about "what the current status is"
is much easier to write when I need to talk about "the current";
otherwise I'd be forced to remember to think if I need to update
the information, every time I touch topic branches.
But that description thing would be useful in gitweb, for
example.
^ permalink raw reply
* Re: [PATCH] change the unpack limit threshold to a saner value
From: Junio C Hamano @ 2006-12-06 22:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612061420410.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Let's assume the average object size is x. Given n objects, the needed
> storage size is n*(x + b), where b is the average wasted block size on
> disk.
> ...
> This is why I think the current default treshold should be 3 instead of
> the insane value of 5000. But since it feels a bit odd to go from 5000
> to 3 I setled on 10.
I see you are optimizing for disk footprint, and this will
result in tons of tiny packs left between "repack -a".
I have not benched it yet, but the runtime pack handling code
was written assuming we have only a handful of big packs; I
suspect this change would affect the performance at runtime in
quite a bad way.
^ permalink raw reply
* Re: git newbie problems
From: Daniel Barkalow @ 2006-12-06 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Graham Percival, git
In-Reply-To: <7v4ps9byca.fsf@assigned-by-dhcp.cox.net>
On Tue, 5 Dec 2006, Junio C Hamano wrote:
> For new people, we recommend to:
>
> * make sure you were on a right branch (I think you are. You
> are on your 'master' branch and may not even have any other
> branches, which is fine.)
>
> * make sure all your changes are committed.
>
> before initiating a "git pull". And after a conflicted "git
> pull", if you choose to punt,
>
> $ git reset --hard
>
> would take you back to the state before you started the pull.
If there are uncommitted changes, and there are conflicts, shouldn't it
leave you in the state before the pull, especially if the uncommitted
changes conflict with the merge? Git has determined that it can't present
all of the conflicts to the user, so the user can't possibly resolve all
of the conflicts, except by discarding new work or pushing it into the
merge inappropriately.
I think that a lot of new users will pull with uncommitted changes, and
they'd benefit from just being told that you're supposed to commit first
and then merge. It should definitely roll back perfectly to the state
before the pull if it wasn't able to present all the conflicts, since even
somebody who knows what's going on is going to have to roll back here.
Possibly there should even be an option (defaulting to true) which
completely blocks "pull" with uncommitted changes. Even if the in-index
merge works (and the working directory is entirely unneeded), it's pretty
likely that the user would do better to be in the habit of doing it in the
other order anyway.
-Daniel
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-06 22:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el7dsn$9a6$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
>> + git-merge: preserve and merge local changes when doing fast forward
>>
>> This allows you to run a 'git merge' (or 'git pull') that
>> results in a fast-forward merge that updates a path your
>> working tree has modified locally; it merges your local changes
>> into the updated version, in the same way the branch switching
>> 'git checkout -m' works. It has been in next for some time and
>> unless we hear somebody scream I think it is Ok to merge to
>> 'master'.
>
> Very nice. Less suprises for CVS users (with "update then commit"
> mentality/habits).
This only makes "update; edit; update; commit" to work. "edit;
commit; edit; commit; edit; update; commit" would not work,
because you would be faced to resolving the conflicts upon the
last update while your working tree is already contaminated with
your own changes (it can be done and experienced people have
done so, but you are talking about "CVS users" here).
We'd be much better off to encourage users to shake "update then
commit" habit, especially if they are on a slow link.
>> * jc/web (Wed Nov 8 14:54:09 2006 -0800)
>> - gitweb: steal loadavg throttle from kernel.org
>
> Is having loadavg in gitweb, and not configured in server good idea?
Have you looked at the code to see what it does?
>> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
>> + git-branch: let caller specify logmsg
>> + rename_ref: use lstat(2) when testing for symlink
>> + git-branch: add options and tests for branch renaming
>>
>> I do not rename branches myself and do not see a need for this
>> nor I have tested it in real-world setting. The code seemed
>> clean and may be 'master' material.
>
> I'd like to have this, but it MUST work well with reflogs for me.
Then test it and fix breakage if any please.
^ permalink raw reply
* Topic descriptions
From: Andy Parkins @ 2006-12-06 21:53 UTC (permalink / raw)
To: git
Hello,
I was just reading Junio's "what's cooking" summary, and it occurred to me
that it would be excellent if git had support for this sort of thing.
It seems fairly easy - it wouldn't have to be versioned information. Could we
simply make .git/refs files be more flexible in their syntax.
-----
<sha1>
<anything at all>
-----
I don't know where the UI would go; but it would let Junio generate his what's
cooking emails with cat .git/refs/*/*
Just an idea...
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: Seeking git recipe to grab a single file
From: Alex Riesen @ 2006-12-06 21:51 UTC (permalink / raw)
To: Mitch Bradley; +Cc: git
In-Reply-To: <4577348E.4090105@firmworks.com>
On 12/6/06, Mitch Bradley <wmb@firmworks.com> wrote:
> I want to grab a single file from a remote git repository into the
> current directory, which is not a git tree. Is there an easy way to do
> that? I have tried using git-fetch and git-cat-file, without success.
If the remote repo has a gitweb interface than it's simple:
wget 'http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;h=0451f69353bad4d07de34fd4658f40b805bd467a;f=Kbuild'
Otherwise, there is no simple way to do it yet.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2006-12-06 21:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vvekoyb79.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Here is a list of topics that are cooking; the commits marked
> with '+' are in 'next', '-' are in 'pu'. Dates are when the
> topic was last touched [*1*].
>
> ----------------------------------------------------------------
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)
> + git-merge: preserve and merge local changes when doing fast forward
>
> This allows you to run a 'git merge' (or 'git pull') that
> results in a fast-forward merge that updates a path your
> working tree has modified locally; it merges your local changes
> into the updated version, in the same way the branch switching
> 'git checkout -m' works. It has been in next for some time and
> unless we hear somebody scream I think it is Ok to merge to
> 'master'.
Very nice. Less suprises for CVS users (with "update then commit"
mentality/habits).
> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)
> - git-explain
>
> This was just a discussion starter. I tried to reuse existing
> status markers various existing command leaves, but it might be
> a good idea to invent a unified status marker to help 'git
> explain' (or 'git wtf') command, so that everybody can write
> into the same file and 'explain' has to know only about that
> file. I dunno.
I think it would be nice to have... but as it is very fresh
it probably should cook for a while in next.
> * jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
> - rev-list --left-right.
>
> When reviewing "git log --merge" I often wish which side each
> of the commits comes from, and this is to achieve that. I
> haven't met with an enthusiastic support for it, though.
> Perhaps people do not find need for that, or do not do
> complicated merges, or have other tools that I do not regularly
> use that is better than this approach; in which case I should
> probably drop this.
Looks nice, as an alternative to git-cherry-pick (which sometimes
doesn't do - because it cannot - it's work).
> * jc/web (Wed Nov 8 14:54:09 2006 -0800)
> - gitweb: steal loadavg throttle from kernel.org
Is having loadavg in gitweb, and not configured in server good idea?
What next, log generation in gitweb? Just kidding.
> * js/merge (Wed Dec 6 16:45:42 2006 +0100)
> + merge-file: support -p and -q; fix compile warnings
> + Add builtin merge-file, a minimal replacement for RCS merge
> + xdl_merge(): fix and simplify conflict handling
> + xdl_merge(): fix thinko
> + xdl_merge(): fix an off-by-one bug
> + merge-recursive: use xdl_merge().
> + xmerge: make return value from xdl_merge() more usable.
> + xdiff: add xdl_merge()
>
> merge-recursive that does not rely on RCS "merge". I use this
> exclusively these days. Perhaps cook a little further and
> merge to 'master'.
Very nice, especially with zealous (tight) merge conflicts.
> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
> + git-branch: let caller specify logmsg
> + rename_ref: use lstat(2) when testing for symlink
> + git-branch: add options and tests for branch renaming
>
> I do not rename branches myself and do not see a need for this
> nor I have tested it in real-world setting. The code seemed
> clean and may be 'master' material.
I'd like to have this, but it MUST work well with reflogs for me.
> [Footnote]
>
> *1* I am trying out an alternative to short-log. I think the
> above format is easier to see what is going on than separate
> short-log for 'next' and 'pu'. It is based on the "TO" script
> found in 'todo' branch but hand edited.
It looks and reads better. I usually read only description,
as shortlog is not that useful unless you are interested in
given topic. At least for me.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: J. Bruce Fields @ 2006-12-06 21:45 UTC (permalink / raw)
To: Graham Percival; +Cc: Johannes Schindelin, hanwen, git
In-Reply-To: <45773002.5020409@gmail.com>
On Wed, Dec 06, 2006 at 01:02:58PM -0800, Graham Percival wrote:
> I'm in the middle of exam period, I have a term papers to write, and I
> have two weeks of lilypond bug reports and doc typos to process. I
> don't care if git can do branches really nicely or walk my dog or cure
> cancer. I can look at that stuff later -- right now I just want to fix
> things and upload them.
Yeah. It's a tricky problem; different people need different things,
and to cover everything (and explain it correctly) the documentation
needs to be long; but to ensure that impatient people can get to what
they need quickly, there needs to be a short, clear path to their
particular need.
A few down-to-earth approaches that could help:
- Clearer section/chapter titles, so we can generate tables of
contents where people can quickly find stuff--so, titles that
explain what the section will show you how to do with
minimized use of jargon that the user doesn't know yet ("how
to keep a repository up-to-date" as opposed to "git-fetch and
remotes").
- As in "Everyday Git", think about what different groups of
users need. But where possible, try to order documentation
with the stuff needed by the largest group of people first.
(For example, right now all the tutorials start with "git
init-db" and "git commit", assuming people are starting a
project from scratch, when the more typical usage is probably
someone joining an existing project, and possibly doing only
read-only stuff at first.)
- Clearer ordering and dependencies, so when people find the "how
to resolve merges" section, they can quickly see what else
they'd need to read before that. (And, yeah, I realize 99% of
the time they won't actually do that--they'll just dive right
in and try a few examples. But at least they'll know where to
turn if that gets them in trouble....)
^ permalink raw reply
* pushglobs
From: Andy Parkins @ 2006-12-06 21:40 UTC (permalink / raw)
To: git
Hello,
The glob support in the fetches has gone down so well that I'm looking into
doing the same for pushrefs.
The push work is done in C; so there is obviously no globbing support from the
shell. I know that git does globbing in other places, so wanted to ask if
it's appropriate to use that rather than me write my own hacked up version?
The context is this: I'm extending builtin-push.c:add_ref() to catch globbed
refs and then recursively expand them.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Seeking git recipe to grab a single file
From: Mitch Bradley @ 2006-12-06 21:22 UTC (permalink / raw)
To: git
I want to grab a single file from a remote git repository into the
current directory, which is not a git tree. Is there an easy way to do
that? I have tried using git-fetch and git-cat-file, without success.
Thanks,
Mitch Bradley
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-06 21:19 UTC (permalink / raw)
To: git
Here is a list of topics that are cooking; the commits marked
with '+' are in 'next', '-' are in 'pu'. Dates are when the
topic was last touched [*1*].
----------------------------------------------------------------
* ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)
+ Explicitly add the default "git pull" behaviour to .git/config on clone
This makes 'git clone' to mark the local 'master' to explicitly
merge with the corresponding remote branch, which would be a
sensible default.
As discussed on the list earlier, I think it also would make
sense to forbid 'git pull' to make a merge when:
(1) branch.*.merge entries exist in $GIT_DIR/config (which
signals that the user is using this new mechanism), and
(2) branch.<current-branch>.merge entry does not exist for the
current branch.
I think it is sensible to merge to 'master' after that change.
* jc/3way (Wed Nov 29 18:53:13 2006 -0800)
+ git-merge: preserve and merge local changes when doing fast forward
This allows you to run a 'git merge' (or 'git pull') that
results in a fast-forward merge that updates a path your
working tree has modified locally; it merges your local changes
into the updated version, in the same way the branch switching
'git checkout -m' works. It has been in next for some time and
unless we hear somebody scream I think it is Ok to merge to
'master'.
* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800)
- git-blame: show lines attributed to boundary commits differently.
This was discussed in a thread on grouping the short-log entries
differently and measuring the importance of each commit. While
it does not break things per-se, nobody seems to want to use it
for scripting yet, so it is staying in 'pu'.
* jc/commit-careful (Tue Oct 24 21:48:55 2006 -0700)
+ git-commit: show --summary after successful commit.
I think this is safe to merge to 'master'.
* jc/diff (Mon Sep 25 23:03:34 2006 -0700)
- para-walk: walk n trees, index and working tree in parallel
This has been backburnered for a long time. No time to work on
and no immediate need to use it for scripts myself yet.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700)
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
This changes the output of "git diff" for a filename with
embedded SP and requires everybody to switch to its predecessor
commit ce74618d (which is in v1.4.4 but not in v1.4.3 series)
which prepared for this change. Perhaps sometime in February.
* jc/explain (Mon Dec 4 19:35:04 2006 -0800)
- git-explain
This was just a discussion starter. I tried to reuse existing
status markers various existing command leaves, but it might be
a good idea to invent a unified status marker to help 'git
explain' (or 'git wtf') command, so that everybody can write
into the same file and 'explain' has to know only about that
file. I dunno.
* jc/fpc (Sun Nov 26 16:29:07 2006 -0800)
- (experimental) per-topic shortlog.
This was my attempt to give a different grouping of the
short-log entries. Will drop soon from 'pu'.
* jc/leftright (Sun Oct 22 17:32:47 2006 -0700)
- rev-list --left-right.
When reviewing "git log --merge" I often wish which side each
of the commits comes from, and this is to achieve that. I
haven't met with an enthusiastic support for it, though.
Perhaps people do not find need for that, or do not do
complicated merges, or have other tools that I do not regularly
use that is better than this approach; in which case I should
probably drop this.
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800)
- blame: --show-stats for easier optimization work.
* jc/read-tree-ignore (Tue Dec 5 23:44:23 2006 -0800)
+ read-tree: document --exclude-per-directory
+ Loosen "working file will be lost" check in Porcelain-ish
+ read-tree: further loosen "working file will be lost" check.
I think this is a 'master' material modulo bugs. Will cook
further in 'next'.
* jc/web (Wed Nov 8 14:54:09 2006 -0800)
- gitweb: steal loadavg throttle from kernel.org
* js/merge (Wed Dec 6 16:45:42 2006 +0100)
+ merge-file: support -p and -q; fix compile warnings
+ Add builtin merge-file, a minimal replacement for RCS merge
+ xdl_merge(): fix and simplify conflict handling
+ xdl_merge(): fix thinko
+ xdl_merge(): fix an off-by-one bug
+ merge-recursive: use xdl_merge().
+ xmerge: make return value from xdl_merge() more usable.
+ xdiff: add xdl_merge()
merge-recursive that does not rely on RCS "merge". I use this
exclusively these days. Perhaps cook a little further and
merge to 'master'.
* js/shallow (Fri Nov 24 16:00:13 2006 +0100)
+ fetch-pack: Do not fetch tags for shallow clones.
+ get_shallow_commits: Avoid memory leak if a commit has been reached already.
+ git-fetch: Reset shallow_depth before auto-following tags.
+ upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
+ fetch-pack: Properly remove the shallow file when it becomes empty.
+ shallow clone: unparse and reparse an unshallowed commit
+ Why didn't we mark want_obj as ~UNINTERESTING in the old code?
+ Why does it mean we do not have to register shallow if we have one?
+ We should make sure that the protocol is still extensible.
+ add tests for shallow stuff
+ Shallow clone: do not ignore shallowness when following tags
+ allow deepening of a shallow repository
+ allow cloning a repository "shallowly"
+ support fetching into a shallow repository
+ upload-pack: no longer call rev-list
The shallow clone. I do not use it myself but it does not seem
to break the system for users that do not use shallow
repositories. Probably with a better documentation of its
limitations and caveats, this should be mergeable to 'master'.
* lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)
+ git-branch: let caller specify logmsg
+ rename_ref: use lstat(2) when testing for symlink
+ git-branch: add options and tests for branch renaming
I do not rename branches myself and do not see a need for this
nor I have tested it in real-world setting. The code seemed
clean and may be 'master' material.
* np/addcommit (Mon Dec 4 11:13:39 2006 -0500)
+ make 'git add' a first class user friendly interface to the index
* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100)
- git-svn: re-map repository URLs and UUIDs on SVK mirror paths
- git-svn: collect revision properties when fetching
- git-svn: collect SVK source URL on mirror paths
- git-svn: let libsvn_ls_fullurl return properties too
- git-svn: make test for SVK mirror path import
Eric already commented on them but no progress since then.
Parked in 'pu' only for discussion and these will be replaced
when resubmitted.
[Footnote]
*1* I am trying out an alternative to short-log. I think the
above format is easier to see what is going on than separate
short-log for 'next' and 'pu'. It is based on the "TO" script
found in 'todo' branch but hand edited.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-06 21:18 UTC (permalink / raw)
To: git; +Cc: linux-kernel
* The 'maint' branch has produced a new release 1.4.4.2
* In the 'master' branch:
- we now officially favor 'remotes' information to be in
$GIT_DIR/config, and 'git clone' records origin in there,
not in $GIT_DIR/remotes/origin (thanks to Andy Parkins).
- "git send-pack $URL :refs/heads/$branch" can be used to
delete a remote branch (so does "git push $URL :$ref" over
git native protocols).
- built-in shortlog lets you directly say "git shortlog
v2.6.18..master", instead of piping an output from the
corresponding "git log v2.6.18..master" into it.
- git-svn updates
- gitweb updates
- gitk updates
- bash completion updates
The shortlog since the last announcement for 'master' is:
Alex Riesen (2):
git-blame: fix rev parameter handling.
Make perl/ build procedure ActiveState friendly.
Andreas Ericsson (2):
ls-files: Give hints when errors happen.
git-diff: Introduce --index and deprecate --cached.
Andy Parkins (3):
Use .git/config for storing "origin" shortcut repository
Document git-repo-config --bool/--int options.
De-emphasise the symbolic link documentation.
David Miller (1):
Pass -M to diff in request-pull
Eric Wong (10):
git-svn: use ~/.subversion config files when using SVN:: libraries
git-svn: enable delta transfers during fetches when using SVN:: libs
git-svn: update tests for recent changes
git-svn: error out when the SVN connection fails during a fetch
git-svn: fix output reporting from the delta fetcher
git-svn: color support for the log command
git-svn: documentation updates
git-svn: fix multi-init
git-svn: avoid fetching files twice in the same revision
git-svn: avoid network timeouts for long-running fetches
Han-Wen Nienhuys (1):
ident.c: Trim hint printed when gecos is empty.
J. Bruce Fields (1):
cvs-migration: improved section titles, better push/commit explanation
Jakub Narebski (4):
gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
git-clone: Rename --use-immingled-remote option to --no-separate-remote
Document git-diff whitespace flags -b and -w
gitweb: Allow PNG, GIF, JPEG images to be displayed in "blob" view
Jim Meyering (1):
Set permissions of each new file before "cvs add"ing it.
Johannes Schindelin (10):
Build in shortlog
shortlog: do not crash on parsing "[PATCH"
shortlog: read mailmap from ./.mailmap again
shortlog: handle email addresses case-insensitively
shortlog: fix "-n"
shortlog: use pager
sha1_object_info(): be consistent with read_sha1_file()
git-mv: search more precisely for source directory in index
diff -b: ignore whitespace at end of line
cvs-migration document: make the need for "push" more obvious
Junio C Hamano (24):
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
merge: allow merging into a yet-to-be-born branch.
Store peeled refs in packed-refs (take 2).
git-fetch: reuse ls-remote result.
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: allow glob pattern in refspec
Allow git push to delete remote ref.
git-shortlog: fix common repository prefix abbreviation.
git-shortlog: make common repository prefix configurable with .mailmap
git-fetch: allow forcing glob pattern in refspec
fetch-pack: do not barf when duplicate re patterns are given
git-merge: tighten error checking.
git-merge: do not leak rev-parse output used for checking internally.
cvsimport: style fixup.
git blame -C: fix output format tweaks when crossing file boundary.
tutorial: talk about user.name early and don't start with commit -a
git-merge: fix confusion between tag and branch
receive-pack: do not insist on fast-forward outside refs/heads/
unpack-trees: make sure "df_conflict_entry.name" is NUL terminated.
git-reset to remove "$GIT_DIR/MERGE_MSG"
git-merge: squelch needless error message.
git-merge: fix "fix confusion between tag and branch" for real
Michael Loeffler (1):
git-fetch: ignore dereferenced tags in expand_refs_wildcard
Nicolas Pitre (2):
builtin git-shortlog is broken
pack-objects: remove redundent status information
Paul Mackerras (1):
gitk: Fix enabling/disabling of menu items on Mac OS X
René Scharfe (1):
shortlog: remove range check
Sean Estabrooks (1):
Update documentation to remove incorrect GIT_DIFF_OPTS example.
Shawn O. Pearce (15):
Teach git-completion.bash how to complete git-merge.
Hide plumbing/transport commands from bash completion.
Teach bash how to complete options for git-name-rev.
Add current branch in PS1 support to git-completion.bash.
Teach bash how to complete git-format-patch.
Teach bash how to complete git-cherry-pick.
Teach bash how to complete git-rebase.
Teach bash about git log/show/whatchanged options.
Support bash completion of refs/remote.
Teach bash about git-repo-config.
Support --strategy=x completion in addition to --strategy x.
Cache the list of merge strategies and available commands during load.
Teach bash about git-am/git-apply and their whitespace options.
Teach bash how to complete long options for git-commit.
Fix broken bash completion of local refs.
^ permalink raw reply
* [PATCH] change the unpack limit treshold to a saner value
From: Nicolas Pitre @ 2006-12-06 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Let's assume the average object size is x. Given n objects, the needed
storage size is n*(x + b), where b is the average wasted block size on
disk.
If those objects are packed, the needed storage becomes n*x + b so we
save on the block overhead. But there is the pack index which is
1024 + n*24 + b.
Trying to find the value of n where packed objects become an advantage,
we have:
n*x + n*b > n*x + n*24 + 2*b + 1024
n*b - 2*b > n*24 + 1024
(n - 2)*b > n*24 + 1024
So given this we need at least 3 objects for the whole to use more space
than a pack, and only if b is greater than 1096. Since a common block
size is 4096 then the value of b is likely to converge towards 2048. 3
objects is also where more directory entries are used over an constant
of 2 for a pack (assuming that both objects would end up with the same
first 2 bytes of hash which is overly optimistic). So 3 should be the
optimal number of objects for not exploding a pack. And of course
larger packs are likely to take even less space due to delta compression
kicking in.
This is why I think the current default treshold should be 3 instead of
the insane value of 5000. But since it feels a bit odd to go from 5000
to 3 I setled on 10.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
Sidenote: I think it is OK for pushes to _not_ use thin packs. When
not exploding thin packs, they must be completed by adding objects
creating duplicates and using more disk space. The penalty for not
using thin packs is a slight increase in bandwidth for push operations,
but since pushes are normally much less frequent than fetches it seems
OK to penalize the push a bit for a better disk usage on servers.
diff --git a/receive-pack.c b/receive-pack.c
index d62ed5b..9140312 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -11,7 +11,7 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
static int deny_non_fast_forwards = 0;
-static int unpack_limit = 5000;
+static int unpack_limit = 10;
static int report_status;
^ permalink raw reply related
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Graham Percival @ 2006-12-06 21:02 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, hanwen, git
In-Reply-To: <20061206172450.GE1714@fieldses.org>
J. Bruce Fields wrote:
> We should start out with the assumption that a shared repo is already
> set up and make it:
>
> committing to a shared repository
> creating a shared repository
> importing a cvs archive
>
> which puts it in stuff-most-people-need-to-know to
> stuff-less-people-need-to-know order. Maybe the current introduction
> should even be postponed to later.
Yes, definitely!
I'm not complaining about changing to git, but Dscho's comment really
rings true:
> A developer, especially those whom Git is forced upon, have an
> attention span shorter than their pub1c hair.
I'm in the middle of exam period, I have a term papers to write, and I
have two weeks of lilypond bug reports and doc typos to process. I
don't care if git can do branches really nicely or walk my dog or cure
cancer. I can look at that stuff later -- right now I just want to fix
things and upload them.
Cheers,
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox