* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vtytxexjl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Subject: [PATCH] fast-import: count --max-pack-size in bytes
> if (!prefixcmp(option, "max-pack-size=")) {
> - option_max_pack_size(option + 14);
> + unsigned long v;
> + if (!git_parse_ulong(option + 14, &v))
> + return 0;
> + if (v < 1024 * 1024) {
> + warning("minimum max-pack-size is 1 MiB");
> + v = 1024 * 1024;
> + }
> + max_packsize = v;
How about for a transition period we do:
if (v < 8192) {
warning("max-pack-size is now in bytes, assuming %dm", v);
v *= 1024 * 1024;
}
So that existing users won't be completely broken if they are
relying on this flag, and have some time to adjust.
Given the huge magnitude between the old sane value range, and the
new sane value range, we can safely assume anything below a small
number like 8192 is an old user, warn them, and assume old behavior.
A local pack smaller than 1 MiB is mostly pointless coming out of
a tool like git repack or git fast-import, unless its a complete
copy of the repository. So the old style calling convention of
4096 for 4 GiB would now imply a pack so small, we probably can't
get more than 1 object per pack.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Junio C Hamano @ 2010-02-04 17:25 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100204171619.GA9367@cthulhu>
Larry D'Anna <larry@elder-gods.org> writes:
> * Larry D'Anna (larry@elder-gods.org) [100131 19:57]:
>> So i guess you're saying that it would be better for update_local_ref and
>> print_summary_for_push_or_fetch to clear the flags, and just pass a rev_info for
>> print_summary_for_push_or_fetch instead of quickref?
>
> So, should I submit a version of the patch that does it this way? Should it use
> a subprocess? Should the option be called something other than --summary?
I dunno. If it delegated to a subprocess it would certainly be easier to
review and get convinced that the change won't affect object flags for
other parts of the system in bad ways, but there obviously is a
performance downside.
I vaguely recall there also were comments on the output format not being
consistent with output of similar nature from other parts of the system,
but I am not the one who is particularly interested in this feature, so
I'll let you and the list decide.
^ permalink raw reply
* Re: Dealing with many many git repos in a /home directory
From: Nicolas Pitre @ 2010-02-04 17:35 UTC (permalink / raw)
To: demerphq; +Cc: Git
In-Reply-To: <9b18b3111002040029x1c7de0afw4a5ef883588f7a18@mail.gmail.com>
On Thu, 4 Feb 2010, demerphq wrote:
> At $work we have a host where we have about 50-100 users each with
> their own private copies of the same repos. These are cloned froma
> remote via git/ssh and are not thus automatically hardlinking their
> object stores.
>
> This is starting to take a lot of space.
You should keep a pristine copy of that common repository on that host
and make it readable to everyone, and then ask your users to use the
--reference argument with 'git clone' to borrow as much as possible from
that common repository.
For those who already cloned the repository in full i.e. without the
--reference switch, then it is possible to fix the situation simply by
adding the full path to the common repository's .git/objects directory
in their own .git/objects/info/alternates (create it if it doesn't
exist) and then run 'git gc'. That's what the --reference argument to
the clone command does: setting up that .git/objects/info/alternates
file.
> I was thinking it should be possible to hardlink all of the objects in
> the different repos to a canonical single copy.
>
> Would i be correct in thinking that if i have to repos with an
> equivalent .git/objects/../..... file in them that the files are
> necessarily identical and one can be replaced by a hardlink to the
> other?
Yes, you could do that. However you'll save very little by doing that
as the bulk of a repository content is normally stored into pack files,
and those may differ from one repository to another depending on what
exactly the pack contains. The alternates mechanism is more powerful as
it lets Git fetch objects from the canonical repository packed or not,
and more importantly it avoids creating local copy of new objects if
they already exists in that canonical copy meaning that you don't have
to constantly search in every user's repository for potential new
objects to hardlink.
> If this is correct then is there some tool known to the list that
> already does this? I whipped this together:
The "tool" exists in Git already and is what I describe above. The
actual tool you might need is probably a script to populate that
.git/objects/info/alternates file in all your users' repositoryes and
maybe run ,git gc' on their behalf.
Nicolas
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Nicolas Pitre @ 2010-02-04 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vtytxexjl.fsf@alter.siamese.dyndns.org>
On Thu, 4 Feb 2010, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] fast-import: count --max-pack-size in bytes
>
> Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
> pack-object' count in bytes, 2010-02-03) which made the option by the same
> name to pack-objects, this counts the pack size limit in bytes.
>
> In order not to cause havoc with people used to the previous megabyte
> scale, and because this is a sane thing to do anyway, a minimum size of 1
> MiB is enforced to avoid an explosion of pack files.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ACK.
> --max-pack-size=<n>::
> - Maximum size of each output packfile, expressed in MiB.
> - The default is 4096 (4 GiB) as that is the maximum allowed
> + Maximum size of each output packfile.
> + The default is 4 GiB as that is the maximum allowed
> packfile size (due to file format limitations). Some
> importers may wish to lower this, such as to ensure the
> resulting packfiles fit on CDs.
What file format limitation is alluded to here? It has been a while
since the 4GB limit on pack file format has been removed. If this is a
limitation of fast-import only then maybe this should be explained more
explicitly.
Nicolas
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Junio C Hamano @ 2010-02-04 17:55 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <7vwrysdiaq.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I dunno. If it delegated to a subprocess it would certainly be easier to
> review and get convinced that the change won't affect object flags for
> other parts of the system in bad ways, but there obviously is a
> performance downside.
You fundamentally cannot use the same "summary" logic for push and fetch,
and it is especially true if you are doing it inside the same process, I
think.
When you force a fetch, you will have the complete histories for both old
and new, as you started from old (and I am assuming that you are fsck
clean) and you successfully fetched new. When you force a push, however,
you may already have the old in your object store, but there is no
guarantee that you have the complete history leading to it (i.e. you may
have got the tip commit left by an earlier fetch done with a commit walker
that you interrupted in the middle).
So at the very least, your "summary_impossible" logic should work a lot
harder than a single lookup-commit-reference-gently; it needs to walk the
ancestry until you hit some ref to prove that you have a complete history
for that commit, without dying. Otherwise get_revision() loop inside
print_summary_for_push_or_fetch() would say "oops -- I don't have the
parent commit" when it tries to call add_parents_to_list() and die.
Doing the summary traversal inside a subprocess would simplify the
handling of the error for such a case, I guess.
My gut feeling from the beginning has been that a patch that touches
revision.c for this topic would add unacceptable cruft to the already
complex logic in that library for no real gain. Doing the traversal
inside a subprocess would allay that worry as well ;-)
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Nicolas Pitre @ 2010-02-04 17:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100204172421.GA18548@spearce.org>
On Thu, 4 Feb 2010, Shawn O. Pearce wrote:
> How about for a transition period we do:
>
> if (v < 8192) {
> warning("max-pack-size is now in bytes, assuming %dm", v);
> v *= 1024 * 1024;
> }
>
> So that existing users won't be completely broken if they are
> relying on this flag, and have some time to adjust.
For 'git fast-import' which is not meant to be directly user operated
this makes sense. I don't think this is a good idea for 'git repack'
though. In the later case it is best if the user simply adjust right
away.
Also the warning text above could be less ambigous. Something like:
"max-pack-size is now in bytes, assuming --max-pack-size=%dm"
Nicolas
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 17:59 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1002041249200.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 4 Feb 2010, Shawn O. Pearce wrote:
>
> > How about for a transition period we do:
> >
> > if (v < 8192) {
> > warning("max-pack-size is now in bytes, assuming %dm", v);
> > v *= 1024 * 1024;
> > }
> >
> > So that existing users won't be completely broken if they are
> > relying on this flag, and have some time to adjust.
>
> For 'git fast-import' which is not meant to be directly user operated
> this makes sense. I don't think this is a good idea for 'git repack'
> though. In the later case it is best if the user simply adjust right
> away.
>
> Also the warning text above could be less ambigous. Something like:
>
> "max-pack-size is now in bytes, assuming --max-pack-size=%dm"
ACK on the fixed warning text. I lacked enough coffee at the time
to write intelligent text.
--
Shawn.
^ permalink raw reply
* Re: rebase vs rebase -i
From: Johannes Schindelin @ 2010-02-04 18:00 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718491002040914t12956bb2gbe21ae89f31cbc7f@mail.gmail.com>
Hi,
On Thu, 4 Feb 2010, Jay Soffian wrote:
> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> >> change the list of commits in the latter case.)
> >
> > You can get _exactly_ the same behavior if you use -m.
>
> Or rather, -p. ;-)
No. -p tries to preserve merges, and it will use
git-rebase--interactive.sh for hysterical raisins.
I meant -m.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 18:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1002041243570.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> > --max-pack-size=<n>::
> > - Maximum size of each output packfile, expressed in MiB.
> > - The default is 4096 (4 GiB) as that is the maximum allowed
> > + Maximum size of each output packfile.
> > + The default is 4 GiB as that is the maximum allowed
> > packfile size (due to file format limitations). Some
> > importers may wish to lower this, such as to ensure the
> > resulting packfiles fit on CDs.
>
> What file format limitation is alluded to here? It has been a while
> since the 4GB limit on pack file format has been removed.
The pack index v1 32 bit offset thing. Which you fixed.
> If this is a
> limitation of fast-import only then maybe this should be explained more
> explicitly.
Damn. It is. fast-import can't write a v2 index. Ugh.
--
Shawn.
^ permalink raw reply
* Re: rebase vs rebase -i
From: Jay Soffian @ 2010-02-04 18:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1002041859000.4505@intel-tinevez-2-302>
On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 4 Feb 2010, Jay Soffian wrote:
>
>> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
>> >> change the list of commits in the latter case.)
>> >
>> > You can get _exactly_ the same behavior if you use -m.
>>
>> Or rather, -p. ;-)
>
> No. -p tries to preserve merges, and it will use
> git-rebase--interactive.sh for hysterical raisins.
>
> I meant -m.
I don't understand what you mean by "_exactly_ the same behavior" then.
"GIT_EDITOR=true git rebase -i" and "git rebase -p" both use
git-rebase--interactive.sh, and so are exactly the same behavior.
-m still uses git-rebase.sh, but calls merge instead of format-patch +
am. Perhaps the end-result is the same, but the behavior is different.
I guess I'm being a bit pedantic here, but I'm really just trying to
understand what you mean.
Thanks,
j.
^ permalink raw reply
* Re: rebase vs rebase -i
From: Johannes Schindelin @ 2010-02-04 18:46 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718491002041010k84ad55ct5c3e80529e8f8428@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 807 bytes --]
Hi,
On Thu, 4 Feb 2010, Jay Soffian wrote:
> On Thu, Feb 4, 2010 at 1:00 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 4 Feb 2010, Jay Soffian wrote:
> >
> >> On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> >> >> change the list of commits in the latter case.)
> >> >
> >> > You can get _exactly_ the same behavior if you use -m.
> >>
> >> Or rather, -p. ;-)
> >
> > No. -p tries to preserve merges, and it will use
> > git-rebase--interactive.sh for hysterical raisins.
> >
> > I meant -m.
>
> I don't understand what you mean by "_exactly_ the same behavior" then.
Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] fast-import: count --max-pack-size in bytes
From: Junio C Hamano @ 2010-02-04 19:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20100204175918.GB18548@spearce.org>
Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
pack-object' count in bytes, 2010-02-03) which made the option by the same
name to pack-objects, this counts the pack size limit in bytes.
In order not to cause havoc with people used to the previous megabyte
scale an integer smaller than 8092 is interpreted in megabytes but the
user gets a warning. Also a minimum size of 1 MiB is enforced to avoid an
explosion of pack files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
---
Ok, third-time lucky? Knock wood...
Documentation/RelNotes-1.7.0.txt | 8 ++++----
Documentation/git-fast-import.txt | 4 ++--
fast-import.c | 17 +++++++++++------
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/RelNotes-1.7.0.txt b/Documentation/RelNotes-1.7.0.txt
index e66945c..255666f 100644
--- a/Documentation/RelNotes-1.7.0.txt
+++ b/Documentation/RelNotes-1.7.0.txt
@@ -46,10 +46,10 @@ Notes on behaviour change
environment, and diff.*.command and diff.*.textconv in the config
file.
- * The --max-pack-size argument to 'git repack' and 'git pack-objects' was
- assuming the provided size to be expressed in MiB, unlike the
- corresponding config variable and other similar options accepting a size
- value. It is now expecting a size expressed in bytes, with a possible
+ * The --max-pack-size argument to 'git repack', 'git pack-objects', and
+ 'git fast-import' was assuming the provided size to be expressed in MiB,
+ unlike the corresponding config variable and other similar options accepting
+ a size value. It is now expecting a size expressed in bytes, with a possible
unit suffix of 'k', 'm', or 'g'.
Updates since v1.6.6
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 2691114..6764ff1 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -44,8 +44,8 @@ OPTIONS
not contain the old commit).
--max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
- The default is 4096 (4 GiB) as that is the maximum allowed
+ Maximum size of each output packfile.
+ The default is 4 GiB as that is the maximum allowed
packfile size (due to file format limitations). Some
importers may wish to lower this, such as to ensure the
resulting packfiles fit on CDs.
diff --git a/fast-import.c b/fast-import.c
index a6730d0..b477dc6 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2764,11 +2764,6 @@ static void option_date_format(const char *fmt)
die("unknown --date-format argument %s", fmt);
}
-static void option_max_pack_size(const char *packsize)
-{
- max_packsize = strtoumax(packsize, NULL, 0) * 1024 * 1024;
-}
-
static void option_depth(const char *depth)
{
max_depth = strtoul(depth, NULL, 0);
@@ -2798,7 +2793,17 @@ static void option_export_pack_edges(const char *edges)
static int parse_one_option(const char *option)
{
if (!prefixcmp(option, "max-pack-size=")) {
- option_max_pack_size(option + 14);
+ unsigned long v;
+ if (!git_parse_ulong(option + 14, &v))
+ return 0;
+ if (v < 8192) {
+ warning("max-pack-size is now in bytes, assuming --max-pack-size=%lum", v);
+ v *= 1024 * 1024;
+ } else if (v < 1024 * 1024) {
+ warning("minimum max-pack-size is 1 MiB");
+ v = 1024 * 1024;
+ }
+ max_packsize = v;
} else if (!prefixcmp(option, "big-file-threshold=")) {
unsigned long v;
if (!git_parse_ulong(option + 19, &v))
--
1.7.0.rc1.199.g9253ab
^ permalink raw reply related
* Re: [PATCH] fast-import: count --max-pack-size in bytes
From: Shawn O. Pearce @ 2010-02-04 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7v4olwbyvf.fsf_-_@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
> pack-object' count in bytes, 2010-02-03) which made the option by the same
> name to pack-objects, this counts the pack size limit in bytes.
>
> In order not to cause havoc with people used to the previous megabyte
> scale an integer smaller than 8092 is interpreted in megabytes but the
> user gets a warning. Also a minimum size of 1 MiB is enforced to avoid an
> explosion of pack files.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Acked-by: Nicolas Pitre <nico@fluxnic.net>
> ---
>
> Ok, third-time lucky? Knock wood...
Yea, I like it. Thanks Junio.
--
Shawn.
^ permalink raw reply
* [Announce] git-subtree v0.3
From: Avery Pennarun @ 2010-02-04 19:55 UTC (permalink / raw)
To: Git Mailing List
Hi all,
git-subtree is an alternative to git submodules. It makes it easier
to use git's "subtree" merge strategy, and also provides a "split"
operation to do the opposite (extracting a subtree back into the
parent project) so you can go back and forth.
It's been awhile since I made an actual official release, so I just
tagged v0.3. You can find it at
http://github.com/apenwarr/git-subtree.
Main changes in this version:
- a new 'git subtree pull' command to complement 'git subtree merge'
- improvements to docs and license notices
- various bugfixes.
Jakub Suder has also written a new tutorial on how to use git-subtree:
http://psionides.jogger.pl/2010/02/04/sharing-code-between-projects-with-git-subtree/
git-subtree appears to be gaining in popularity (it how has 94
followers on github, and people are obviously using it enough to
submit patches). Thoughts about whether (and how) to submit it for
inclusion into core git are welcome.
Amiel Martin (2):
fixed order of assertion in tests
sort assertion to make it more generic
Arlen Cuss (1):
Fix refspecs in given example for git subtree pull.
Avery Pennarun (13):
Docs: when pushing to github, the repo path needs to end in .git
Improve patch to use git --exec-path: add to PATH instead.
Fix behaviour if you have a branch named the same as your --prefix
Add a README that says to email me instead of using github mail.
Merge branch 'master' of git://github.com/voxpelli/git-subtree
If someone provides a --prefix that ends with slash, strip the slash.
Fix a minor problem in identifying squashes vs. normal splits.
cmd_pull didn't support --squash correctly.
Add some tips for how to install.
Oops, forgot a COPYING file. It's GPLv2.
Weird, I forgot to have 'make test' call test.sh.
Merge branch 'master' of git://github.com/psionides/git-subtree
Jakub's changes broke the progress message slightly.
Ben Walton (2):
add installation support to Makefile
make git version dynamic when building documentation
Jakub Suder (9):
added -p alias for --prefix
added -m/--message option for setting merge commit message
allow using --branch with existing branches if it makes sense
fix for subtree split not finding proper base for new commits
changed alias for --prefix from -p to -P
fixed bug in commit message for split
added tests for recent changes
added temporary test dirs to gitignore
improved rev_is_descendant_of_branch() function
Pelle Wessman (1):
Check that the type of the tree really is a tree and not a commit
kTln2 (1):
Add explicit path of git installation by 'git --exec-path'.
Have fun,
Avery
^ permalink raw reply
* Re: rebase vs rebase -i
From: Jay Soffian @ 2010-02-04 19:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1002041946170.4505@intel-tinevez-2-302>
On Thu, Feb 4, 2010 at 1:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Both "rebase -i" and "rebase -m" are really a cherry-pick in a loop.
Well then I'm still confused. I see where pick_one() in
git-rebase--interactive.sh is using cherry-pick.
But call_merge() in git-rebase.sh is using git-merge-recursive (absent
specifying another strategy).
?
j.
^ permalink raw reply
* Re: [PATCH] fast-import: count --max-pack-size in bytes
From: Ilari Liusvaara @ 2010-02-04 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Nicolas Pitre, git
In-Reply-To: <7v4olwbyvf.fsf_-_@alter.siamese.dyndns.org>
On Thu, Feb 04, 2010 at 11:10:44AM -0800, Junio C Hamano wrote:
> Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
> pack-object' count in bytes, 2010-02-03) which made the option by the same
> name to pack-objects, this counts the pack size limit in bytes.
>
> In order not to cause havoc with people used to the previous megabyte
> scale an integer smaller than 8092 is interpreted in megabytes but the
Typo? Shouldn't it be 8192?
> user gets a warning. Also a minimum size of 1 MiB is enforced to avoid an
> explosion of pack files.
-Ilari
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Giuseppe Bilotta @ 2010-02-04 20:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git, Johannes Schindelin, Johan Herland
In-Reply-To: <201002041821.22864.jnareb@gmail.com>
On Thu, Feb 4, 2010 at 6:21 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 4 Feb 2010, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>>
>>>> + my %notes = () ;
>>>> + foreach my $note_ref (@note_refs) {
>>>> + my $obj = "$note_ref:$co{'id'}";
>>>
>>> I think this look-up is wrong (meaning: will stop working anytime in the
>>> future, and needs to be rewritten).
>>
>> IOW, the code should be reading output from:
>>
>> GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
>>
>> as the notes tree may not be storing notes in a flat one-level namespace
>> like you are assuming.
>
> First, for some mechanism of deployment (IIRC Apache's mod_perl) changes
> to environment variables from CGI script are not passed to invoked
> commands (I guess for security reasons). That is why gitweb uses --git-dir
> parameter to git wrapper, and not GIT_DIR environment variable since
> 25691fb (gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'},
> 2006-08-28). So for proper support we would need --notes-ref (or similar)
> option to git wrapper
>
> git --notes-ref=$note_ref show -s --format=%N $co{'id'}
As I mentioned on the cover letter, I was hoping to be able to make
something that could be deployable without requiring core changes and
thus a specific minimum git version. I do realize however that this is
inherently not robust (unless the code is updated if and when the
notes storage mechanism changes).
The wrapper is probably needed anyway, I would say, so it makes sense
to implement it. However, see below for a caveat about its
implementation.
> Second, parse_commit / parse_commits use
>
> git rev-list -z --parents --header --max-count-X
>
> If this command automatically shows notes (or it can be modified to
> automatically show notes) after unindented "Notes:" line (as per
> git-notes documentation), then the only thing that needs to be
> changed to fill %commit{'notes'} is parse_commit_text subroutine.
>
> There would be no need for extra subroutine (and extra command, or
> even up to two extra commands per note) to get notes data.
But unless the --notes-ref is made to accept multiple refspecs, this
will only access _one_ note namespace. It is not hard to envision
situations where multiple namespaces are used for the same repo (e.g.
one to store git-svn metadata, one for bugzilla-related entries), in
which case you'd want _all_ of them to be accessible in gitweb.
And if we do support multiple refspecs for --notes-ref, we also need
some way to identify which note belongs to which namespace, of course,
in any of the output formats that include notes.
An alternative approach would be some git notes-list command that
accepts both multiple namespaces and multiple commits, and is
specifically dedicated to display notes-commits relationships
(together with notes content, obviously)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Junio C Hamano @ 2010-02-04 21:03 UTC (permalink / raw)
To: Giuseppe Bilotta
Cc: Jakub Narebski, Junio C Hamano, git, Johannes Schindelin,
Johan Herland
In-Reply-To: <cb7bb73a1002041208q54ff1f57y3202e88ae2f5f44e@mail.gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> As I mentioned on the cover letter, I was hoping to be able to make
> something that could be deployable without requiring core changes and
> thus a specific minimum git version. I do realize however that this is
> inherently not robust (unless the code is updated if and when the
> notes storage mechanism changes).
AFAIU, the note code on the core side already creates a fan-out structure
when notes tree gets large (see recent "What's cooking"; the series is
parked in 'pu' but that is primarily because we are in feature freeze); it
is not just "inherently not robust" but is much closer to "broken from day
one" ;-). Otherwise I wouldn't have wasted time to point it out.
Your code is a very good proof-of-concept, though.
Regarding support of multiple notes hierarchies, listing, etc.
See for example:
http://thread.gmane.org/gmane.comp.version-control.git/138079/focus=138128
I expect more ideas from needs by end-user would come, as we gain
experience with using notes in real projects. You will certainly find
some other needs of your own, like the "not an environment but a command
line option" which Jakub mentioned, and "multiple hierarchies" like both
you and I found need for. Share them and let us together make the notes
mechanism nicer to use.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Junio C Hamano @ 2010-02-04 21:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Giuseppe Bilotta, git, Johannes Schindelin,
Johan Herland
In-Reply-To: <201002041821.22864.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> IOW, the code should be reading output from:
>>
>> GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
>>
>> as the notes tree may not be storing notes in a flat one-level namespace
>> like you are assuming.
>
> First, for some mechanism of deployment (IIRC Apache's mod_perl) changes
> to environment variables from CGI script are not passed to invoked
> commands (I guess for security reasons).
I do not believe you are unable to spawn
open $fd, '-|' 'sh', '-c', "GIT_NOTES_REF=$note_ref git show ..."
and read from it ;-).
For possible enhancement to make notes easier to use, see the other
response.
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Nicolas Pitre @ 2010-02-04 18:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20100204180015.GC18548@spearce.org>
On Thu, 4 Feb 2010, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@fluxnic.net> wrote:
> > > --max-pack-size=<n>::
> > > - Maximum size of each output packfile, expressed in MiB.
> > > - The default is 4096 (4 GiB) as that is the maximum allowed
> > > + Maximum size of each output packfile.
> > > + The default is 4 GiB as that is the maximum allowed
> > > packfile size (due to file format limitations). Some
> > > importers may wish to lower this, such as to ensure the
> > > resulting packfiles fit on CDs.
> >
> > What file format limitation is alluded to here? It has been a while
> > since the 4GB limit on pack file format has been removed.
>
> The pack index v1 32 bit offset thing. Which you fixed.
>
> > If this is a
> > limitation of fast-import only then maybe this should be explained more
> > explicitly.
>
> Damn. It is. fast-import can't write a v2 index. Ugh.
Isn't it using write_idx_file()? That function would do it all for you
already.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-clean: fix the description of the default behavior
From: Jay Soffian @ 2010-02-04 21:16 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <dafb1423c81bc2207d06cf2a97205bcbd9a4968e.1265299086.git.git@drmicha.warpmail.net>
On Thu, Feb 4, 2010 at 11:01 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> fatal: clean.requireForce defaults to true and -n or -f not given; refusing to clean
Bike shed:
fatal: clean.requireForce defaults to true and neither -n nor -f
given; refusing to clean
j.
^ permalink raw reply
* [PATCH] update git-repack documentation wrt repack.UseDeltaBaseOffset
From: Nicolas Pitre @ 2010-02-04 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This default for repack.UseDeltaBaseOffset has been "true" since
Git v1.6.0.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index e2f2fa2..8c67d17 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -109,15 +109,15 @@ other objects in that pack they already have locally.
Configuration
-------------
-When configuration variable `repack.UseDeltaBaseOffset` is set
-for the repository, the command passes `--delta-base-offset`
-option to 'git pack-objects'; this typically results in slightly
-smaller packs, but the generated packs are incompatible with
-versions of git older than (and including) v1.4.3; do not set
-the variable in a repository that older version of git needs to
-be able to read (this includes repositories from which packs can
-be copied out over http or rsync, and people who obtained packs
-that way can try to use older git with it).
+By default, the command passes `--delta-base-offset` option to
+'git pack-objects'; this typically results in slightly smaller packs,
+but the generated packs are incompatible with versions of Git older than
+version 1.4.4. If you need to share your repository with such ancient Git
+versions, either directly or via the dumb http or rsync protocol, then you
+need to set the configuration variable `repack.UseDeltaBaseOffset` to
+"false" and repack. Access from old Git versions over the native protocol
+is unaffected by this option as the conversion is performed on the fly
+as needed in that case.
Author
^ permalink raw reply related
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 21:20 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1002041309090.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Thu, 4 Feb 2010, Shawn O. Pearce wrote:
> > Nicolas Pitre <nico@fluxnic.net> wrote:
> > > > --max-pack-size=<n>::
> > > > - Maximum size of each output packfile, expressed in MiB.
> > > > - The default is 4096 (4 GiB) as that is the maximum allowed
> > > > + Maximum size of each output packfile.
> > > > + The default is 4 GiB as that is the maximum allowed
> > > > packfile size (due to file format limitations). Some
> > > > importers may wish to lower this, such as to ensure the
> > > > resulting packfiles fit on CDs.
> > >
> > > What file format limitation is alluded to here? It has been a while
> > > since the 4GB limit on pack file format has been removed.
> >
> > The pack index v1 32 bit offset thing. Which you fixed.
> >
> > > If this is a
> > > limitation of fast-import only then maybe this should be explained more
> > > explicitly.
> >
> > Damn. It is. fast-import can't write a v2 index. Ugh.
>
> Isn't it using write_idx_file()? That function would do it all for you
> already.
Nope. Its still using its own code. I never ported it to
write_idx_file(). And I don't have the CRC32 data available for
each object (it failed to compute/save it as it wrote).
I mean to port to write_idx_file() but didn't... :-(
--
Shawn.
^ permalink raw reply
* Can I exclude .gitmodules (or any file) from git-format-patch?
From: Timur Tabi @ 2010-02-04 22:10 UTC (permalink / raw)
To: git
Is there a way I can get git-format-patch to ignore specific files?
Specifically, I want it to ignore .gitmodules. This file is changed
whenever a submodule is added or removed, but I don't want git
format-patch to pick it up. I already specify --ignore-submodules, so
I was expecting format-patch to ignore *everything* related to
sobmodules.
Perhaps --ignore-submodules should also ignore any changes to .gitmodules?
(Why is .gitmodules not in the .git directory, anyway?)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Jakub Narebski @ 2010-02-04 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Johannes Schindelin, Johan Herland
In-Reply-To: <7vwrys7lrm.fsf@alter.siamese.dyndns.org>
Dnia czwartek 4. lutego 2010 22:07, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> IOW, the code should be reading output from:
>>>
>>> GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
>>>
>>> as the notes tree may not be storing notes in a flat one-level namespace
>>> like you are assuming.
>>
>> First, for some mechanism of deployment (IIRC Apache's mod_perl) changes
>> to environment variables from CGI script are not passed to invoked
>> commands (I guess for security reasons).
>
> I do not believe you are unable to spawn
>
> open $fd, '-|' 'sh', '-c', "GIT_NOTES_REF=$note_ref git show ..."
>
> and read from it ;-).
You meant here
my $git_command = quote_command(git_cmd(), 'show', ...);
open my $fd, '-|', 'sh', '-c', "GIT_NOTES_REF=$note_ref $git_command"
So you need to take care to quote parameters ($note_ref fortunately
doesn't need to be quoted)... and you have one more process (shell)
spawned.
Therefore I think it would be nice to have --notes-ref option to git
wrapper,... especially that it should be easy to set it up in such way
that it would be possible to pass --notes-ref multiple times, e.g.:
git --notes-ref=commits --notes-ref=git-svn show ...
--
Jakub Narebski
Poland
^ 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