* Re: [PATCH 0/4] Add git-pack-intersect
From: Junio C Hamano @ 2005-11-10 0:15 UTC (permalink / raw)
To: git
In-Reply-To: <43728523.1040209@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 924 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> Perhaps if git-daemon ever does caching of packfiles, removing the smaller
> packfiles might not be optimal.
Ah, that reminds me of something.
I did not advertise it too much, but you can put a prepackaged
packs in $GIT_DIR/pack-cache/ and it is used when upload-pack
notices it is creating that exact pack.
This is useless for ordinary repository, but can be useful for
historical repositories whose heads/tags never change (e.g. the
Linux kernel repository resurrected from bkcvs). There you
could:
$ git repack -a -d
$ ln $GIT_DIR/objects/pack/pack-* $GIT_DIR/pack-cache/.
and a clone request would feed the pack, without regenerating
the pack data from scratch. upload-pack still reads, sorts and
computes SHA1 hash of the list of objects to find the pack name,
but that is a fairly quick operation, compared to the rest of
the pack generation process.
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Pavel Machek @ 2005-11-10 0:08 UTC (permalink / raw)
To: Petr Baudis
Cc: Catalin Marinas, Chris Mason, Chuck Lever, Theodore Ts'o,
Joel Becker, Junio C Hamano, git
In-Reply-To: <20051109233255.GI30496@pasky.or.cz>
Hi!
> Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> said that...
...
> A night city, the snow slowly falling. Approaching the roofs covered in
> white and illuminated by the yellow street lighting, dark windows - but
> one dimly glowing, a computer screen inside. Close-up on a hacker:
> $EDITOR opened, lost deep in hack mode, fingers dancing over the
> keyboard. Dreamy-monumental music in the background.
>
> StGIT user, only part of the patches in stack, and the rest depends on
> the one currently edited, and I want to record my work on this one.
> I can either:
Are you sure you are git hacker? Maybe you should have been fiction
writer :-).
> (i) Just keep per-patch history only.
>
> (ii) Keep _both_ per-patch and per-stack history (since I don't want to
> record the stack when I have to keep some patches out of it - the
> history would look like randomly removing and adding tons of patches,
> and jumping around would be difficult because of this too).
>
> (iii) Keep per-patchlist history - do not actually record only our
> current stack, but all the patches StGIT knows about. The patches
> depending on the one currently being changed will not be in consistent
> state, but that's tough. Actually, this seems to be the most viable
> strategy. One question is whether to record if some patch is actually
> applied right now or not (I'd say don't record it since you again have
> the "bouncing problem" otherwise).
I do not know if ii or iii is better, but please *do* record what
patches were applied at what moment. That is useful info. "I'd like to
go back to know working configuration". If I do not know what patches
were applied at what moment, going back to working config is hard to
do.
Pavel
--
Thanks, Sharp!
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-10 0:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051109234212.GJ30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm not sure I follow you here - what exactly does not feel disturbing
> and what good reasons are there for whatever they are? :-)
My misunderstanding, I guess. I somehow thought you were
suggesting that recursive should implement mergeFile through
merge-index. Going the other way, to make the current
merge-index users to feed mergeFile with what is stored as three
stages in an index file, would make a lot more sense.
^ permalink raw reply
* To you pay not enough money? You want more?
From: Earnestine @ 2005-11-09 22:07 UTC (permalink / raw)
To: git
Thank You for Your interest.capo
Job for you! just
MakePay Corporation offers the External Financial Management Services leadership,
experience and results in cash flow management. mail
We offer You the job of finance manager.
Thank You for Your interest.hot
Contact us on our post client and specify the. here
Full name
Address
Contact info (e-mail, phone, fax)
And we shall contact you within one day
Details on a site www.makepay.biz
Contact as support@makepay.biz
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-09 23:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com>
Dear diary, on Thu, Nov 10, 2005 at 12:43:04AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> > what mechanism are you talking about?
>
> I suspect you haven't seen the git-merge mechanism in action -- or
> perhaps I'm a bit lost and we're talking about different things. At
> least last time I merged with git-merge.sh, it tried several
> strategies in order in a temporary index. Actually, it tried in order:
> stupid, resolve, recursive... It shortcuts if one merges cleanly, but
> it'll definitely work through them. It's very nice to see this in
> action.
But that's something different that I'm talking about. :-)
As I said, I'm talking about per-file automergers. git-merge-one-file
and that stuff. I know about merge strategies and they are cool.
> The mergers and things like git-merge-base are probably the areas of
> git that need the most focus and polish -- that's why I'm
> uncomfortable with cg-merge doing its own thing, as it gets a lot less
> review than git-merge-XX resolvers.
Yes. My longer plan is to use the strategy resolvers as well, but my
TODO list is big... And I don't perceive this as a critical thing (the
standard strategy seems to work well enough), although I would like to
see this before 1.0.
> Right now I am seeing some slightly abnormal things (*) in how some
> our our merges are going, so I' ll have to roll up my sleeves at some
> point and try and figure out what's going on. And as I look into
> cg-merge and cg-Xmergefile, not many eyes have been through it...
At least this is the one area of Cogito that has at least a bit
reasonable automated testing suite. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Problems with binary patches (pull) and spaces in filenames (gitk)
From: Peter Eriksen @ 2005-11-09 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xvxbg9y.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 09, 2005 at 02:36:09PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Hmm. Perhaps a suboption to git-apply --stat to tell it not to
> > barf is helpful? In the meantime, could you pull with -n flag?
>
> Would this help?
>
> -- >8 -- cut here -- >8 --
> [PATCH] git-apply: do not barf on binary diff when not applying.
Yes, it seems to work. With my example it now shows the diff stats and
puts a "Bin" instead of the number of line changed. It could show the
change in the size, but as it is, it's fine with me. Please apply.
Peter
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-11-09 23:47 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Petr Baudis, git
In-Reply-To: <20051109233614.GA4051@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:
>
>> > ...; is it safe to assume that the
>> > default template post-update hook shipped with GIT will be
>> > good-to-be-autoenabled on public repositories
>>
>> Please yell loudly when somebody posts a patch or brings up a
>> proposal to break that assumption in the future.
>
> Wouldn't this be a problem on public repositories that are hosted with
> DAV?
Not unless you arrange the DAV server to honor hooks. ;-).
IOW, yeah, there may be problems.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-11-09 23:44 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051109233614.GA4051@reactrix.com>
Dear diary, on Thu, Nov 10, 2005 at 12:36:14AM CET, I got a letter
where Nick Hengeveld <nickh@reactrix.com> said that...
> Wouldn't this be a problem on public repositories that are hosted with
> DAV?
Hmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current
server info, update it at the pusher's side and send it back?
And add a warning to some documentation that HTTP push won't trigger the
update hooks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Expected Behavior?
From: Martin Langhoff @ 2005-11-09 23:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <20051109231248.GL16061@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> what mechanism are you talking about?
I suspect you haven't seen the git-merge mechanism in action -- or
perhaps I'm a bit lost and we're talking about different things. At
least last time I merged with git-merge.sh, it tried several
strategies in order in a temporary index. Actually, it tried in order:
stupid, resolve, recursive... It shortcuts if one merges cleanly, but
it'll definitely work through them. It's very nice to see this in
action.
> All the scripts have it hardcoded
Well, no. git-merge -s 'foo' works pretty well and isn't hardcoded.
Even if we agree on defaulting to only one relatively smart merger for
simplicity's sake, the mechanism we have in git-merge.sh (thanks to
Junio I think) is excellent, and should be kept. Linus will probably
do his merges with "stupid resolve" or just "stupid" and the rest of
us will use something else.
The mergers and things like git-merge-base are probably the areas of
git that need the most focus and polish -- that's why I'm
uncomfortable with cg-merge doing its own thing, as it gets a lot less
review than git-merge-XX resolvers.
Right now I am seeing some slightly abnormal things (*) in how some
our our merges are going, so I' ll have to roll up my sleeves at some
point and try and figure out what's going on. And as I look into
cg-merge and cg-Xmergefile, not many eyes have been through it...
* - (nothing serious, just an annoying tendency to show spurious
conflicts with the mergebase commit itself)
cheers,
martin
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-09 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Langhoff, git
In-Reply-To: <7virv18kc3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 12:36:44AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Fredrik's using his own mergeFile is defensible from both
> performance and implementation point of view. After the rename
> processing stage, he already extracted enough information from
> trees involved, and there is no reason for him to be preparing
> three stages in the index file with that information (which is
> cumbersome because there is no interface to populate the higher
> stage directly using git-update-index --- you have to first
> create temporary tree objects and ask git-read-tree -m to do so)
> and asking git-merge-index to call git-merge-one-file. If you
> read git-merge-one-file, it is not a rocket science.
I'm not arguing against mergeFile but rather git-merge-one-file (and by
implication cg-Xmergefile), actually. My point is - couldn't be
mergeFile generalized a bit or padded with suitable interface to be
usable as git-merge-one-file's drop-in replacement?
> While we _may_ want to keep the logic that decides what to do in
> various cases across these three implementations, at least for me, it
> does not particularly feel disturbing, especially when there are good
> reasons.
I'm not sure I follow you here - what exactly does not feel disturbing
and what good reasons are there for whatever they are? :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Nick Hengeveld @ 2005-11-09 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v3bm59zxu.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 09, 2005 at 03:14:21PM -0800, Junio C Hamano wrote:
> > ...; is it safe to assume that the
> > default template post-update hook shipped with GIT will be
> > good-to-be-autoenabled on public repositories
>
> Please yell loudly when somebody posts a patch or brings up a
> proposal to break that assumption in the future.
Wouldn't this be a problem on public repositories that are hosted with
DAV?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-09 23:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
>> The world would be so much better if there would be just a _single_
>> per-file automerger instead of three right now...
>
> I don't quite agree with this. The multi-merger mechanism is something
> (relatively) unique and powerful in GIT.
If I am reading you two correctly, you are not disagreeing, but
are talking about different issues.
Pasky is talking about what to do after merge strategy finds
that a path (from three stages) needs to be merged. git-core
uses git-merge-one-file or git-merge-recursive::mergeFile (which
are the implementations of the same logic), and Pasky has his
own in Cogito.
Fredrik's using his own mergeFile is defensible from both
performance and implementation point of view. After the rename
processing stage, he already extracted enough information from
trees involved, and there is no reason for him to be preparing
three stages in the index file with that information (which is
cumbersome because there is no interface to populate the higher
stage directly using git-update-index --- you have to first
create temporary tree objects and ask git-read-tree -m to do so)
and asking git-merge-index to call git-merge-one-file. If you
read git-merge-one-file, it is not a rocket science. While we
_may_ want to keep the logic that decides what to do in various
cases across these three implementations, at least for me, it
does not particularly feel disturbing, especially when there are
good reasons.
^ permalink raw reply
* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-09 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virv1a0ro.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 Nov 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> >>
> >> H
> >> / \
> >> G A \
> >> |\ / \
> >> | B \
> >> | \ \
> >> \ C F
> >> \ \ /
> >> \ D /
> >> \ | /
> >> \| /
> >> E
> >>
> > So I think from a correctness standpoint, the only thing that matters is
> > "git-merge-base --all", and anything that doesn't know to return both E
> > and B looks potentially buggy.
>
> But the point of well-poisoning you did in merge-base was to
> detect that E is an ancestor of B and exclude it in the first
> place.
Ahh, you're right, and I'm wrong. That "E" is not a real merge-base, since
there _is_ a valid merge-base that is a direct descendant of it and thus
objectively better.
And as to why git-merge-base returns E in the first place: it really
shouldn't, but when it sees B, it can decide that C is uninteresting, and
so there are no interesting commits left. So it never continues to walk D
and thus never notices that D covers E and E is _also_ uninteresting.
So it thinks both E and B are interesting, and since E has a more recent
date, it will select that one when only showing one (and then show both
when asked to).
> I however do not see merge-base trying to take that into account
> and treat E differently from C and D in any way.
It doesn't. git-merge-base simply walks the chain in as close to date
order as it can, and when it decides that the rest of the chain is
provably uninteresting, it stops.
Which means that sometimes it can stop with too _many_ merge heads, just
because it hasn't realized that they are reachable through a chain that is
otherwise provably uninteresting.
This is because we define "uninteresting" as meaning "cannot reach any
more _new_ merge-heads". Which is true. The fact that such a chain could
reach some heads we found earlier and mark them as being pointless never
enters the picture ;)
> I agree we should try to stay away from "heuristic" and make
> things safer, but after seeing the above, I'd need a bit more
> time to convince myself that what 'git-merge-base --all' does is
> *the* safe approach.
Well, "git-merge-base --all" will be "safer" in the sense that it's
guaranteed to give a superset of the merge-heads (which itself is "safe"
in that it flags potentially interesting cases early).
Then, the recursive merge strategy could notice (in fact, _will_ notice,
if it tries to merge the merge-heads) that the merge of such a pair of
merge-heads is one of the heads itself (just a fast-forward), and thus the
recursive strategy should correctly have chosen "B" as the merge-head.
So yes, "git-merge-base --all" really is safe. Sometimes (under fairly odd
circumstances) a bit unnecessarily conservative, but always safe.
> Right now, it looks to me that both are heuristic that work most of the
> time (merge-base --all 99.99999% of the time, show-branch 99% of the
> time, or something like that).
The thing is, I don't see what guarantees that the show-branch brhaviour
is safe or conservative. It happened to pick B in this case, which was the
right choice, but I don't see how that was anything but just luck and
happenstance.
IOW, I can see that "git-merge-base --all" can return some unnecessary
heads, but I can also argue for how that becomes safe and fixes itself.
With git-show-branch --merge-base, I don't know what that argument is,
because I can't see how it _guarantees_ that it would always pick B over
E.
Linus
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Petr Baudis @ 2005-11-09 23:32 UTC (permalink / raw)
To: Catalin Marinas
Cc: Chris Mason, Chuck Lever, Theodore Ts'o, Joel Becker,
Junio C Hamano, pavel, git
In-Reply-To: <b0943d9e0511051223g74c2be43h@mail.gmail.com>
Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> said that...
> I would like to have a way of checking the changes to individual
> patches, just to be able to go back if some changes broke it.
Yes, that would be nice to have as well (although in general I lean to
recording the whole stack now). Model scenario:
A night city, the snow slowly falling. Approaching the roofs covered in
white and illuminated by the yellow street lighting, dark windows - but
one dimly glowing, a computer screen inside. Close-up on a hacker:
$EDITOR opened, lost deep in hack mode, fingers dancing over the
keyboard. Dreamy-monumental music in the background.
StGIT user, only part of the patches in stack, and the rest depends on
the one currently edited, and I want to record my work on this one.
I can either:
(i) Just keep per-patch history only.
(ii) Keep _both_ per-patch and per-stack history (since I don't want to
record the stack when I have to keep some patches out of it - the
history would look like randomly removing and adding tons of patches,
and jumping around would be difficult because of this too).
(iii) Keep per-patchlist history - do not actually record only our
current stack, but all the patches StGIT knows about. The patches
depending on the one currently being changed will not be in consistent
state, but that's tough. Actually, this seems to be the most viable
strategy. One question is whether to record if some patch is actually
applied right now or not (I'd say don't record it since you again have
the "bouncing problem" otherwise).
Ideas?
> It's also useful to have some kind of revision control for the whole
> stack, but this can be achieved with tags at the moment.
Yes, now let's sequence the tags... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH 0/4] Add git-pack-intersect
From: Lukas Sandström @ 2005-11-09 23:24 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson
In-Reply-To: <4371E472.4030902@op5.se>
Andreas Ericsson wrote:
> It would be better if it was in git-prune or a default action for
> git-repack. I can't imagine a scenario where keeping redundant packfiles
> is useful.
>
Perhaps if git-daemon ever does caching of packfiles, removing the smaller
packfiles might not be optimal.
Integrating it with git-prune sounds like a good idea though, I'll look
in to it.
/Lukas
^ permalink raw reply
* Re: Regarding: git-lost+found
From: Junio C Hamano @ 2005-11-09 23:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511091759520.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Why have git-lost+found write to files at all? It seems to me easiest to
> have the list go to standard out, and you could do "gitk `git-lost+found
> -t commit`" to see lost commits, and reconnect them as desired. (Making up
> command line syntax for listing only the commits.)
That is certainly cleaner. The only downside is fsck-objects
that lost+found uses tends to be expensive operation, and what
you would want to do with the information may be more than just
use it on the command line of gitk. But in any case the user
could store git-lost+found output in a file to do whatever she
wants, so it may not matter.
^ permalink raw reply
* [PATCH] Rename git-pack-intersect to git-pack-redundant
From: Lukas Sandström @ 2005-11-09 23:16 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, junkio
In-Reply-To: <20051109111917.GB30496@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Nov 09, 2005 at 02:20:59AM CET, I got a letter
> where Lukas Sandström <lukass@etek.chalmers.se> said that...
>
>>This patch series adds git-pack-intersect. It finds redundant packs
>>by calculating the union of all objects present in .git/objects/pack
>>and then computing the smallest set of packs which contain all the
>>objects in this union.
>
>
> Sounds nice, except the name - it does something else than what the name
> says, so perhaps something like 'git-pack-redundant' would be more
> appropriate.
>
Yes, it would. git-pack-intersect is a working name from before
I knew what the program would actually do. In the beginning
it just computed the intersection of two pack-files...
/Lukas Sandström
-- >8 -- cut here -- >8 --
Subject: [PATCH] Rename git-pack-intersect to git-pack-redundant
This patch renames git-pack-intersect to git-pack-redundant
as suggested by Petr Baudis. The new name reflects what the
program does, rather than how it does it.
Also fix a small argument parsing bug.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
.gitignore | 2 +-
Documentation/git-pack-redundant.txt | 6 +++---
Makefile | 2 +-
git-repack.sh | 4 ++--
pack-redundant.c | 10 ++++++----
5 files changed, 13 insertions(+), 11 deletions(-)
rename Documentation/{git-pack-intersect.txt => git-pack-redundant.txt} (86%)
rename pack-intersect.c => pack-redundant.c (98%)
applies-to: 85a2ca124a0579c98df5e6d9158a7ee358aeefef
4db829aa0d1811ccf3505aca232045d7970aec5d
diff --git a/.gitignore b/.gitignore
index 6ff2530..1d1aa57 100644
--- a/.gitignore
+++ b/.gitignore
@@ -60,7 +60,7 @@ git-mktag
git-name-rev
git-mv
git-octopus
-git-pack-intersect
+git-pack-redundant
git-pack-objects
git-parse-remote
git-patch-id
diff --git a/Documentation/git-pack-intersect.txt b/Documentation/git-pack-redundant.txt
similarity index 86%
rename from Documentation/git-pack-intersect.txt
rename to Documentation/git-pack-redundant.txt
index a73d9e3..3829616 100644
--- a/Documentation/git-pack-intersect.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -1,14 +1,14 @@
-git-pack-intersect(1)
+git-pack-redundant(1)
=====================
NAME
----
-git-pack-intersect - Program used to find redundant pack files.
+git-pack-redundant - Program used to find redundant pack files.
SYNOPSIS
--------
-'git-pack-intersect [ -v ] < -a | .pack filename ... >'
+'git-pack-redundant [ -v ] < -a | .pack filename ... >'
DESCRIPTION
-----------
diff --git a/Makefile b/Makefile
index 4c646c9..b4dca5f 100644
--- a/Makefile
+++ b/Makefile
@@ -122,7 +122,7 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- git-name-rev$X git-pack-intersect$X $(SIMPLE_PROGRAMS)
+ git-name-rev$X git-pack-redundant$X $(SIMPLE_PROGRAMS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
diff --git a/git-repack.sh b/git-repack.sh
index 3f28300..4ce0022 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -45,7 +45,7 @@ if [ -z "$name" ]; then
if test "$remove_redandant" = t ; then
echo "Removing redundant packs."
sync
- redundant=$(git-pack-intersect -a)
+ redundant=$(git-pack-redundant -a)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
@@ -63,7 +63,7 @@ exit
if test "$remove_redandant" = t
then
sync
- redundant=$(git-pack-intersect -a)
+ redundant=$(git-pack-redundant -a)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
diff --git a/pack-intersect.c b/pack-redundant.c
similarity index 98%
rename from pack-intersect.c
rename to pack-redundant.c
index 2267478..db3dcde 100644
--- a/pack-intersect.c
+++ b/pack-redundant.c
@@ -8,8 +8,8 @@
#include "cache.h"
-static const char pack_intersect_usage[] =
-"git-pack-intersect [ -v ] < -a | <.pack filename> ...>";
+static const char pack_redundant_usage[] =
+"git-pack-redundant [ -v ] < -a | <.pack filename> ...>";
int all = 0, verbose = 0;
@@ -522,8 +522,10 @@ int main(int argc, char **argv)
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- if(!strcmp(arg, "--"))
+ if(!strcmp(arg, "--")) {
+ i++;
break;
+ }
if(!strcmp(arg, "-a")) {
all = 1;
continue;
@@ -533,7 +535,7 @@ int main(int argc, char **argv)
continue;
}
if(*arg == '-')
- usage(pack_intersect_usage);
+ usage(pack_redundant_usage);
else
break;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-11-09 23:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051109223303.GG30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> ...; is it safe to assume that the
> default template post-update hook shipped with GIT will be
> good-to-be-autoenabled on public repositories
I do not think that is an unreasonable assumption. After all,
sample hooks are there to help people setting up common usage
patterns, not to show off flashy but irrelevant-to-the-real-world-needs
features ;-).
Please yell loudly when somebody posts a patch or brings up a
proposal to break that assumption in the future.
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-09 23:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com>
Dear diary, on Thu, Nov 10, 2005 at 12:04:11AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> > The world would be so much better if there would be just a _single_
> > per-file automerger instead of three right now...
>
> I don't quite agree with this. The multi-merger mechanism is something
> (relatively) unique and powerful in GIT.
I'm not talking about mechanism but about the recommended policy (if you
have something better, fine, use it - just keep _one_ default one
instead of three, since this doesn't have anything or much to do with
the actual merge strategy). Besides,
> Having fast+stupid, with fallback to slow+smart is an excellent
> strategy, and having the mechanism in place means that if someone is
> crazy enough to write a smarter merge script for a language or a
> particular project (say, to ease the transition to a new directory
> layout) it is entirely possible.
what mechanism are you talking about? All the scripts have it hardcoded
what to use, it seems - cg-Xmergefile, git-merge-one-file or some
subroutine...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Regarding: Debian: packaging updates.
From: Junio C Hamano @ 2005-11-09 23:06 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <4370FE57.7010304@debian.org>
Simon Richter <sjr@debian.org> writes:
> Junio C Hamano wrote:
>
>> Since you have debian.org e-mail address, perhaps you can feed
>> me patches to debian/ area and deb: rule in the main Makefile?
>
> Sure. I have also talked this over with a few people and am going to
> make official uploads occasionally.
Simon, I've received a patch to do *.changes file from Carl
Baldwin, and with his permission I am forwarding it to you,
hoping that you could include it (or reject it with explanation
to Carl and me) when you feed me your debian/ updates. Carl
says he wants to use dupload to populate his private apt-get
repository and the process wants the generated *.changes file.
Myself, I've been either installing with "dpkg -i" directly or
populating the apt-get repository by hand (yuck) but if dupload
is the preferred way to maintain private apt-get repository and
if having *.changes file helps that procedure, then...
---
diff --git a/Makefile b/Makefile
index bfdaf76..c1fcecb 100644
--- a/Makefile
+++ b/Makefile
@@ -452,8 +452,7 @@ rpm: dist
deb: dist
rm -rf $(GIT_TARNAME)
$(TAR) zxf $(GIT_TARNAME).tar.gz
- dpkg-source -b $(GIT_TARNAME)
- cd $(GIT_TARNAME) && fakeroot debian/rules binary
+ cd $(GIT_TARNAME) && dpkg-buildpackage -rfakeroot -us -uc
### Cleaning rules
@@ -464,6 +463,7 @@ clean:
rm -rf $(GIT_TARNAME)
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
rm -f git-core_$(GIT_VERSION)-*.dsc
+ rm -f git-core_$(GIT_VERSION)-*.changes
rm -f git-*_$(GIT_VERSION)-*.deb
$(MAKE) -C Documentation/ clean
$(MAKE) -C templates clean
^ permalink raw reply related
* Re: Regarding: git-lost+found
From: Daniel Barkalow @ 2005-11-09 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vvez1bjjv.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 Nov 2005, Junio C Hamano wrote:
> Maybe we could use .git/lost+found/{commit,other}/?{40} and hang
> committish under one directory and the rest in another? Then we
> could do this:
>
> $ gitk $(cd .git/lost+found/commit && echo ??*)
>
> After you find what you want, you would do 'git tag' or 'git
> branch' to reconnect them, but we can reasonably expect that is
> to happen soon after you ran lost+found and before the next time
> you run prune, because that was why you ran git-lost+found in
> the first place.
Why have git-lost+found write to files at all? It seems to me easiest to
have the list go to standard out, and you could do "gitk `git-lost+found
-t commit`" to see lost commits, and reconnect them as desired. (Making up
command line syntax for listing only the commits.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Expected Behavior?
From: Martin Langhoff @ 2005-11-09 23:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <20051109112452.GD30496@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> The world would be so much better if there would be just a _single_
> per-file automerger instead of three right now...
I don't quite agree with this. The multi-merger mechanism is something
(relatively) unique and powerful in GIT. Having fast+stupid, with
fallback to slow+smart is an excellent strategy, and having the
mechanism in place means that if someone is crazy enough to write a
smarter merge script for a language or a particular project (say, to
ease the transition to a new directory layout) it is entirely
possible.
In the end, merges are tricky and need to be controlled by the end
user. We can help this giving the user good control and good
visibility of what decisions the merger is taking.
> I'm planning to feed back the automerger stuff from Cogito to GIT like I
> already did once.
I use both mergers (cg and git) and I'd really _really_ like to turn
cg-merge into a wrapper for git-merge. The cg merger does the basics:
trivial merge, fast forwards and diff3 merges. Adding the rest is
_hard_ and debugging/auditing it is even harder. IMHO, having strong,
high quality mergers is a must, and it's a complex enough space that a
porcelain should align itself with git so we get a strong set of
mergers done in a way that all porcelains can hook into.
I made an initial half-attempt but it's trickier that I had expected
because cg-merge relies on cg-commit to wrap up, marke the index as
resolved, and commit, and I'm not entirely sure of how that works in
detail. My changes were going in the direction of breaking the current
usage patterns, so it was a no-go really.
cheers,
martin
^ permalink raw reply
* Re: Problems with binary patches (pull) and spaces in filenames (gitk)
From: Jan Harkes @ 2005-11-09 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyq5bhi2.fsf@assigned-by-dhcp.cox.net>
On Wed, Nov 09, 2005 at 02:09:41PM -0800, Junio C Hamano wrote:
> Another minor gitk gripe I have is that it does not look at
> subdirectories of refs/{heads,tags}/ so I do not get labels to
> my topic branch heads.
I've been using the following gitk 'customization'. ISTR that it can be
cleaned up a bit further and do everything in a single scan of the refs/
subtree. I'll take another look at that tonight.
Jan
diff --git a/gitk b/gitk
index a9d37d9..cd0b84f 100755
--- a/gitk
+++ b/gitk
@@ -237,16 +237,27 @@ proc parsecommit {id contents listed old
$comname $comdate $comment]
}
+# recursively list all files in a directory
+proc listTree {root} {
+ set files [glob -nocomplain -directory $root -types f *]
+ set nodes [glob -nocomplain -directory $root -types d *]
+ foreach node $nodes {
+ set children [listTree $node]
+ set files [concat $files $children]
+ }
+ return $files
+}
+
proc readrefs {} {
global tagids idtags headids idheads tagcontents
- set tags [glob -nocomplain -types f [gitdir]/refs/tags/*]
+ set tags [listTree [gitdir]/refs/tags]
foreach f $tags {
catch {
set fd [open $f r]
set line [read $fd]
if {[regexp {^[0-9a-f]{40}} $line id]} {
- set direct [file tail $f]
+ regexp {[gitdir]/refs/tags/(.*)} $f match direct
set tagids($direct) $id
lappend idtags($id) $direct
set tagblob [exec git-cat-file tag $id]
@@ -271,13 +282,13 @@ proc readrefs {} {
close $fd
}
}
- set heads [glob -nocomplain -types f [gitdir]/refs/heads/*]
+ set heads [listTree [gitdir]/refs/heads]
foreach f $heads {
catch {
set fd [open $f r]
set line [read $fd 40]
if {[regexp {^[0-9a-f]{40}} $line id]} {
- set head [file tail $f]
+ regexp {[gitdir]/refs/heads/(.*)} $f match head
set headids($head) $line
lappend idheads($line) $head
}
^ permalink raw reply related
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-09 22:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>>
>> H
>> / \
>> G A \
>> |\ / \
>> | B \
>> | \ \
>> \ C F
>> \ \ /
>> \ D /
>> \ | /
>> \| /
>> E
>>
> So I think from a correctness standpoint, the only thing that matters is
> "git-merge-base --all", and anything that doesn't know to return both E
> and B looks potentially buggy.
But the point of well-poisoning you did in merge-base was to
detect that E is an ancestor of B and exclude it in the first
place. If it matters what F does, it means checking ancestry
among B C D E and declare that B is a better ancestor than C, D,
E does not help or is sometimes harmful. No question that B is
always superiour ancestor than C and D, but arguably the
presence of F _might_ change situation for B vs E.
I however do not see merge-base trying to take that into account
and treat E differently from C and D in any way. Only because F
and E had newer timestamp than C and D, we ended up finding E
first and did not poison E through B, and that's why you got
both B and E. I think it was just an accident. If F were older
than B, I suspect the result would have been very different.
> Now, this case obviously depends on history being almost maximally insane
> (ie pretty much _all_ the dates are wrong). So in practice we probably
> don't care.
I agree. The above example was to answer my own question in
this message:
http://marc.theaimsgroup.com/?l=git&m=112382448222823
> ... personally I'd much rather always do a
> "git-merge-base --all", and only do the fast index merge if we only have
> one potential parent.
>
> That way there would never any question about what the "quick merge" does.
I agree we should try to stay away from "heuristic" and make
things safer, but after seeing the above, I'd need a bit more
time to convince myself that what 'git-merge-base --all' does is
*the* safe approach. Right now, it looks to me that both are
heuristic that work most of the time (merge-base --all 99.99999%
of the time, show-branch 99% of the time, or something like
that).
^ permalink raw reply
* Re: [cogito] cg-merge does not remove files removed upstream on fast-forward
From: Petr Baudis @ 2005-11-09 22:54 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200511090108.51776.blaisorblade@yahoo.it>
Dear diary, on Wed, Nov 09, 2005 at 01:08:33AM CET, I got a letter
where Blaisorblade <blaisorblade@yahoo.it> said that...
> Once again, (not the first time) when doing "cg-merge origin" (or cg-update I
> guess, too) I find a tons of files which were removed upstream and cogito
> didn't remove. It was a fast-forward merge on Linus' tree:
>
> $ cg merge origin
> Fast-forwarding d83c671fb7023f69a9582e622d01525054f23b66 ->
> a52e8381c430896d3bd6065a34fda99cb5c74c82
> on top of d83c671fb7023f69a9582e622d01525054f23b66...
Strange. I've just added a test against this, and it seems to work fine
for me. Hmm.
Could you please test any post-1936f62c0756d8051bd3a8ee4214e058f168d395
Cogito version?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ 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