* Re: fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-27 2:41 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027014229.GA28407@spearce.org>
On Thu, 26 Oct 2006, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 27 Oct 2006, Eran Tromer wrote:
> >
> > > Hi,
> > >
> > > On 2006-10-26 17:08, Nicolas Pitre wrote:
> > > > On Thu, 26 Oct 2006, Eran Tromer wrote:
> > > >> This creates a race condition w.r.t. "git repack -a -d", similar to the
> > > >> existing race condition between "git fetch --keep" and
> > > >> "git repack -a -d". There's a point in time where the new pack is stored
> > > >> but not yet referenced, and if "git repack -a -d" runs at that point it
> > > >> will eradicate the pack. When the heads are finally updated, you get a
> > > >> corrupted repository.
> > > >
> > > > And how is it different from receiving a pack through git-unpack-objects
> > > > where lots of loose objects are created, and git-repack -a -d removing
> > > > those unconnected loose objects before the heads are updated?
> > >
> > > git-repack -a -d does not touch unconnected loose objects.
> > > It removes only unconnected packed objects.
> >
> > Right.
> >
> > > Only git-prune removes unconnected loose objects, and that's documented
> > > as unsafe.
> >
> > Well, the race does exist. Don't do repack -a -d at the same time then.
>
> This is an issue for "central" repositories that people push into
> and which might be getting repacked according to a cronjob.
>
> Unfortunately I don't have a solution. I tried to come up with
> one but didn't. :-)
Just continue to explode received packs into loose objects then. It is
that simple. I said there were advantages and inconvenients to both
methods. This one is a nice example.
I won't repack from a cron job, so I don't expect to run a repack and a
fetch at the same time on my private repositories. I therefore don't
care about that race and so is the case for the vast majority of users.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Eran Tromer @ 2006-10-27 2:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061027014229.GA28407@spearce.org>
On 2006-10-27 03:42, Shawn Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
>> On Fri, 27 Oct 2006, Eran Tromer wrote:
>> Well, the race does exist. Don't do repack -a -d at the same time then.
>
> This is an issue for "central" repositories that people push into
> and which might be getting repacked according to a cronjob.
AFAICT, the bottom line of the "Re: auto-packing on kernel.org? please?"
thread last October was "sure, go ahead".
> Unfortunately I don't have a solution. I tried to come up with
> one but didn't. :-)
Here's one way to do it.
Change git-repack to follow references under $GIT_DIR/tmp/refs/ too.
To receive or fetch a pack:
1. Add references to the new heads in
`mktemp $GIT_DIR/tmp/refs/XXXXXX`.
2. Put the new .pack under $GIT_DIR/objects/pack/.
3. Put the new .idx under $GIT_DIR/objects/pack/.
4. Update the relevant heads under $GIT_DIR/refs/.
5. Delete the references from step 1.
This is repack-safe and never corrupts the repo. The worst-case failure
mode is if you die before cleaning the refs from $GIT_DIR/tmp/refs. That
may mean some packed objects will never be removed by "repack -a -d"
even if they lose all references from $GIT_DIR/refs, so do "tmpwatch -m
240 $GIT_DIR/tmp/refs" to take care of that.
Eran
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 3:00 UTC (permalink / raw)
To: Eran Tromer; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <45417205.6020805@tromer.org>
Eran Tromer <git2eran@tromer.org> wrote:
> > Unfortunately I don't have a solution. I tried to come up with
> > one but didn't. :-)
>
> Here's one way to do it.
> Change git-repack to follow references under $GIT_DIR/tmp/refs/ too.
> To receive or fetch a pack:
> 1. Add references to the new heads in
> `mktemp $GIT_DIR/tmp/refs/XXXXXX`.
> 2. Put the new .pack under $GIT_DIR/objects/pack/.
> 3. Put the new .idx under $GIT_DIR/objects/pack/.
> 4. Update the relevant heads under $GIT_DIR/refs/.
> 5. Delete the references from step 1.
>
> This is repack-safe and never corrupts the repo. The worst-case failure
> mode is if you die before cleaning the refs from $GIT_DIR/tmp/refs. That
> may mean some packed objects will never be removed by "repack -a -d"
> even if they lose all references from $GIT_DIR/refs, so do "tmpwatch -m
> 240 $GIT_DIR/tmp/refs" to take care of that.
That was actually my (and also Sean's) solution. Except I would
put the temporary refs as "$GIT_DIR/refs/ref_XXXXXX" as this is
less code to change and its consistent with how temporary loose
objects are created.
Unfortunately it does not completely work.
What happens when the incoming pack (steps #2 and #3) takes 15
minutes to upload (slow ADSL modem, lots of objects) and the
background repack process sees those temporary refs and starts
trying to include those objects? It can't walk the DAG that those
refs point at because the objects aren't in the current repository.
From what I know of that code the pack-objects process will fail to
find the object pointed at by the ref, rescan the packs directory,
find no new packs, look for the object again, and abort over the
"corruption".
OK so the repository won't get corrupted but the repack would be
forced to abort.
Another issue I just thought about tonight is we may need a
count-packs utility that like count-objects lists the number
of active packs and their total size. If we start hanging onto
every pack we receive over the wire the pack directory is going to
grow pretty fast and we'll need a way to tell us when its time to
`repack -a -d`.
--
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Sean @ 2006-10-27 3:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061027030054.GB28407@spearce.org>
On Thu, 26 Oct 2006 23:00:54 -0400
Shawn Pearce <spearce@spearce.org> wrote:
> What happens when the incoming pack (steps #2 and #3) takes 15
> minutes to upload (slow ADSL modem, lots of objects) and the
> background repack process sees those temporary refs and starts
> trying to include those objects? It can't walk the DAG that those
> refs point at because the objects aren't in the current repository.
As long as there was standard naming for such temporary refs,
they could be completely ignored by the repack process, no?
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Jakub Narebski @ 2006-10-27 3:20 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP03992F75428088AF83AE39AE040@CEZ.ICE>
Sean wrote:
> On Thu, 26 Oct 2006 23:00:54 -0400
> Shawn Pearce <spearce@spearce.org> wrote:
>
>> What happens when the incoming pack (steps #2 and #3) takes 15
>> minutes to upload (slow ADSL modem, lots of objects) and the
>> background repack process sees those temporary refs and starts
>> trying to include those objects? It can't walk the DAG that those
>> refs point at because the objects aren't in the current repository.
>
> As long as there was standard naming for such temporary refs,
> they could be completely ignored by the repack process, no?
You meant I think: half ignored. Taken into account when finding
which parts are referenced to delete (-d part), but not complain
if they don't point to anything (validation).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Sean @ 2006-10-27 3:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehrtt8$rm3$1@sea.gmane.org>
On Fri, 27 Oct 2006 05:20:53 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> You meant I think: half ignored. Taken into account when finding
> which parts are referenced to delete (-d part), but not complain
> if they don't point to anything (validation).
Yes, ignored by repack, not ignored by prune.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Eran Tromer @ 2006-10-27 4:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061027030054.GB28407@spearce.org>
Hi,
On 2006-10-27 05:00, Shawn Pearce wrote:
>> Change git-repack to follow references under $GIT_DIR/tmp/refs/ too.
>> To receive or fetch a pack:
>> 1. Add references to the new heads in
>> `mktemp $GIT_DIR/tmp/refs/XXXXXX`.
>> 2. Put the new .pack under $GIT_DIR/objects/pack/.
>> 3. Put the new .idx under $GIT_DIR/objects/pack/.
>> 4. Update the relevant heads under $GIT_DIR/refs/.
>> 5. Delete the references from step 1.
> That was actually my (and also Sean's) solution. Except I would
> put the temporary refs as "$GIT_DIR/refs/ref_XXXXXX" as this is
> less code to change and its consistent with how temporary loose
> objects are created.
If you do that, other programs (e.g., anyone who uses rev-list --all)
may try to walk those heads or consider them available before the pack
is really there. The point about $GIT_DIR/tmp/refs is that only programs
meddling with physical packs (git-fetch, git-receive-pack, git-repack)
will know about it.
> What happens when the incoming pack (steps #2 and #3) takes 15
> minutes to upload (slow ADSL modem, lots of objects) and the
> background repack process sees those temporary refs and starts
> trying to include those objects? It can't walk the DAG that those
> refs point at because the objects aren't in the current repository.
>
>>From what I know of that code the pack-objects process will fail to
> find the object pointed at by the ref, rescan the packs directory,
> find no new packs, look for the object again, and abort over the
> "corruption".
Good point. Then I guess we'll need to change git-repack to ignore
missing objects if they're referenced from $GIT_DIR/tmp/refs but not
from $GIT_DIR/refs. Ugly, but shouldn't be too hard.
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 4:42 UTC (permalink / raw)
To: Eran Tromer; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <4541850B.8060608@tromer.org>
Eran Tromer <git2eran@tromer.org> wrote:
> On 2006-10-27 05:00, Shawn Pearce wrote:
> >> Change git-repack to follow references under $GIT_DIR/tmp/refs/ too.
> >> To receive or fetch a pack:
> >> 1. Add references to the new heads in
> >> `mktemp $GIT_DIR/tmp/refs/XXXXXX`.
> >> 2. Put the new .pack under $GIT_DIR/objects/pack/.
> >> 3. Put the new .idx under $GIT_DIR/objects/pack/.
> >> 4. Update the relevant heads under $GIT_DIR/refs/.
> >> 5. Delete the references from step 1.
>
> > That was actually my (and also Sean's) solution. Except I would
> > put the temporary refs as "$GIT_DIR/refs/ref_XXXXXX" as this is
> > less code to change and its consistent with how temporary loose
> > objects are created.
>
> If you do that, other programs (e.g., anyone who uses rev-list --all)
> may try to walk those heads or consider them available before the pack
> is really there. The point about $GIT_DIR/tmp/refs is that only programs
> meddling with physical packs (git-fetch, git-receive-pack, git-repack)
> will know about it.
Doh. Yes, of course, that makes much sense.
Hmm... Looking at git-repack we have two things currently pending
to rework in there:
- Historical vs. active packs.
- Don't delete a possibly still incoming pack during -d.
These have a lot of the same implementation issues. We need to
be able to identify a set of packs which should be allowed for
repack with -a, and allowed for removal with -d if -a was also used.
A newly uploaded pack cannot be in that list unless its contents are
referenced by one or more refs (which implies that the receive-pack
process has completed).
I'm thinking that the ref thing might be unnecessary. We just
need to fix repack so it builds a list of "active packs" whose
objects should be copied into the new pack, and then only packs
loose objects and those objects contained by an active packs.
So the receive-pack process becomes:
a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
c. Write pack and index.
d. Move pack to $GIT_DIR/objects/pack/...
e. Move index to $GIT_DIR/objects/pack...
f. Update refs.
g. Arrange for new pack and index to be considered active.
And the repack -a -d process becomes:
1. List all active packs and store in memory.
2. Repack only loose objects and objects contained in active packs.
3. Move new pack and idx into $GIT_DIR/objects/pack/...
4. Arrange for new pack and idx to be considered active.
5. Delete active packs found by step #1.
Junio was originally considering making historical packs
historical by placing their names into an information file (such as
`$GIT_DIR/objects/info/historical-packs`) and then consider all other
packs as active. Thus step #1 is list all packs and removes those
whose names appear in historical-packs, while step #4 is unnecessary.
I was thinking about just changing the "pack-" prefix to "hist-" for
the historical packs and assuming all "pack-*.pack" to be active.
Thus step #1 is a simple glob on the pack directory and step #4
is unnecessary.
In the latter case its easy to mark an existing pack as historical
(just hardlink hist- names for pack, then idx, then unlink previous
names) and its also easy to mark new incoming packs as non active
by using a different prefix (e.g. "incm-") during step #d/#e and
then relinking them as "pack-" during step #g. Its also very safe
on systems that support hardlinks.
We shouldn't ever need to worry about race conditions with repacking
historical packs. For starters historical packs will tend to be
several years' worth of object accumulation and will be so large
that repacking them might take 45 minutes or more. Thus they
probably will never get repacked. An active pack will simply move
into historical status after it gets so large that its no longer
worthwhile to keep repacking it. They also will tend to have objects
that are so old that at least one ref in the repository will point
at their entire DAG and thus everything would carry over on a repack.
So this would be cleaner then messing around with temporary refs and
gets us the historical pack feature we've been looking to implement.
--
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-27 4:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Erik B?gfors, Matthieu Moy, bazaar-ng, Sean, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610211353070.3962@g5.osdl.org>
On Sat, Oct 21, 2006 at 02:04:56PM -0700, Linus Torvalds wrote:
> On Sat, 21 Oct 2006, Erik B?gfors wrote:
> > bzr is a fully decentralized VCS. I've read this thread for quite some
> > time now and I really cannot understand why people come to this
> > conclusion.
>
> Even the bzr people agree, so what's not to understand?
>
> The revision numbers are totally unstable in a distributed environment
> _unless_ you use a certain work-flow. And that work-flow is definitely not
> "distributed" it's much closer to "disconnected centralized".
>
> Now, you could be truly distributed: BK used the same revision numbering
> thing, but was distributed. But BK didn't even try to claim that their
> revision numbers were "simple" and that fast-forwarding is sometimes the
> wrong thing to do.
>
> So BK always fast-forwarded, and the revision numbers were just randomly
> changing numbers. They weren't stable, they weren't simple, and nobody
> claimed they were.
>
> So bzr can bite the bullet and say: "revision numbers are changing and
> meaningless, and we should just fast-forward on merges", or you should
> just admit that bzr is really more about "disconnected operation" than
> truly distributed.
>
> You can't have your cake and eat it too. Truly distributed _cannot_ be
> done with a stable dotted numbering scheme (unless the "dotted numbering
> scheme" is just a way to show a hash like git does - so the numbering has
> no _sequential_ meaning).
>
> Btw, this isn't just an "opinion". This is a _fact_. It's something they
> teach in any good introductory course to distributed algorithms. Usually
> it's talked about in the context of "global clock".
>
> Anybody who thinks that there exists a globally ticking clock in the
> system (and stably increasing dotted numbers are just one such thing) is
> talking about some fantasy-world that doesn't exist, or a world that has
> nothing to do with "distributed".
>
> Linus
Actually bzr used to have slightly different numbering scheme not long
ago. There was a revision-history in each branch listing the revisions
in order in which they were commited or merged in. Some time ago it was
changed to numbering along the leftmost parent, which was, IIRC, deemed
simpler and a little more logical. But in the light of these arguments,
maybe the former system was better -- it was more dependent on the
actual location, but on the other hand it allowed (or could allow --
IIRC there was some problem with it) to fast-forward merge while
_locally_ keeping the meaning of old revision numbers. In fact, the
revision-history used to be almost exactly the same as git reflog,
except it only stored the revids, not the times.
--------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH] Documentation: add upload-archive service to git-daemon.
From: Christian Couder @ 2006-10-27 4:59 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
This patch minimaly documents the upload-archive service,
hoping that someone with better knowledge will improve upon.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-daemon.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 4b2ea2d..a72ed39 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -37,6 +37,8 @@ from `git-fetch`, `git-ls-remote`, and `
This is ideally suited for read-only updates, i.e., pulling from
git repositories.
+An `upload-archive` also exists to serve `git-archive`.
+
OPTIONS
-------
--strict-paths::
@@ -155,6 +157,9 @@ upload-pack::
disable it by setting `daemon.uploadpack` configuration
item to `false`.
+upload-archive::
+ This serves `git-archive --remote`.
+
EXAMPLES
--------
git-daemon as inetd server::
--
^ permalink raw reply related
* [PATCH] Documentation: add git in /etc/services.
From: Christian Couder @ 2006-10-27 5:00 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/everyday.txt | 7 +++++++
Documentation/git-daemon.txt | 7 +++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index f1b2265..450ee76 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -372,6 +372,13 @@ example of managing a shared central rep
Examples
~~~~~~~~
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
Run git-daemon to serve /pub/scm from inetd.::
+
------------
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index a72ed39..dea25af 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -162,6 +162,13 @@ upload-archive::
EXAMPLES
--------
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
git-daemon as inetd server::
To set up `git-daemon` as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
--
^ permalink raw reply related
* Question on multi-level git repository heiarchy.
From: Ben Greear @ 2006-10-27 5:12 UTC (permalink / raw)
To: git
Some time back, I cloned from the official kernel site. I have created
several
branches and patches and such, recently branching off of 2.6.18
I want to create an intermediate level..something like:
kernel.org git tree
|
my git master tree
/ \
work-station-1 work-station-2 ....
Each of the work-station repositories should push/pull from my git
master tree, and occasionally
the git master tree will also pull from the kernel.org git tree.
To attempt this, I uploaded the .git tree from my local work
station..the tree I cloned a while
back, to the public server.
I was then able to clone the public server git tree on my local
work-station in a clean directory.
So far so good...
Both pub server and work station had the current branch set to
lf_v2.6.18, and gitk showed
the head and latest patch as what I would expect. I then did a git
checkout -f master on the
pub server and did a pull from the upstream kernel.
This seemed to work fine.
Then, on the work-station, I did a git checkout -f master, and also did
a pull.
In this case, it seems that it is trying to merge with changes in the
lf_v2.6.18 branch
instead of the the main 'master' tree (see below).
So, am I going about this all wrong, or did I just run into a glitch of
some sort? I should
mention that the work-station below is running git 1.3, where the master
is running git 1.4.2.4 (latest in FC4).
[greear@xeon-dt linux-2.6.dev]$ git checkout -f master
[greear@xeon-dt linux-2.6.dev]$ git pull
greearb@ns2.lanforge.com's password:
Generating pack...
Done counting 1553 objects.
Result has 1056 objects.
Deltifying 1056 objects.
100% (1056/1056) done
Unpacking 1056 objects
Total 1056, written 1056 (delta 894), reused 0 (delta 0)
100% (1056/1056) done
* refs/heads/master: fast forward to branch 'master' of
greearb@ns2.lanforge.com:/pub/linux-2.6
from 04fed361dadb7921507a470947ac23d2f26352cf to
e80391500078b524083ba51c3df01bbaaecc94bb
* refs/heads/lf_v2.6.17.x: same as branch 'lf_v2.6.17.x' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lk_v2.6.16.x.sts: same as branch 'lk_v2.6.16.x.sts' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lf_v2.6.17: same as branch 'lf_v2.6.17' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lf_v2.6.16.x: same as branch 'lf_v2.6.16.x' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lk_v2.6.15.x.sts: same as branch 'lk_v2.6.15.x.sts' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lk_v2.6.17.x: same as branch 'lk_v2.6.17.x' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lf_v2.6.16: same as branch 'lf_v2.6.16' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/origin: same as branch 'lf_v2.6.18' of
greearb@ns2.lanforge.com:/pub/linux-2.6
* refs/heads/lk_v2.6.16.x: same as branch 'lk_v2.6.16.x' of
greearb@ns2.lanforge.com:/pub/linux-2.6
greearb@ns2.lanforge.com's password:
Auto-following refs/tags/v2.6.19-rc3
greearb@ns2.lanforge.com's password:
Generating pack...
Done counting 1 objects.
Deltifying 1 objects.
100% (1/1) done
Total 1, written 1 (delta 0), reused 0 (delta 0)
Unpacking 1 objects
100% (1/1) done
* refs/tags/v2.6.19-rc3: storing tag 'v2.6.19-rc3' of
greearb@ns2.lanforge.com:/pub/linux-2.6
Warning: fetch updated the current branch head.
Warning: fast forwarding your working tree from
Warning: 04fed361dadb7921507a470947ac23d2f26352cf commit.
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with ea50583c9fba2e289d434bda9798a7b77ee8e3b4
Merging:
e80391500078b524083ba51c3df01bbaaecc94bb Merge
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
ea50583c9fba2e289d434bda9798a7b77ee8e3b4 Initial work of merging pktgen
changes into 2.6.18.
found 1 common ancestor(s):
e478bec0ba0a83a48a0f6982934b6de079e7e6b3 Linux v2.6.18. Arrr!
Auto-merging net/core/skbuff.c
Auto-merging include/net/sock.h
Auto-merging net/core/pktgen.c
CONFLICT (content): Merge conflict in net/core/pktgen.c
Auto-merging net/decnet/dn_table.c
CONFLICT (content): Merge conflict in net/decnet/dn_table.c
Auto-merging net/ipv4/fib_frontend.c
CONFLICT (content): Merge conflict in net/ipv4/fib_frontend.c
Auto-merging arch/i386/kernel/tsc.c
Auto-merging net/ipv4/fib_rules.c
CONFLICT (content): Merge conflict in net/ipv4/fib_rules.c
Auto-merging net/core/dev.c
Auto-merging drivers/net/e1000/e1000_main.c
CONFLICT (content): Merge conflict in drivers/net/e1000/e1000_main.c
Auto-merging net/ipv4/arp.c
CONFLICT (content): Merge conflict in net/ipv4/arp.c
Auto-merging net/decnet/dn_fib.c
CONFLICT (content): Merge conflict in net/decnet/dn_fib.c
Auto-merging net/socket.c
Auto-merging include/linux/if.h
Auto-merging include/linux/compat_ioctl.h
Auto-merging include/linux/skbuff.h
Auto-merging include/linux/rtnetlink.h
CONFLICT (content): Merge conflict in include/linux/rtnetlink.h
Auto-merging fs/cifs/cifsglob.h
Auto-merging include/linux/if_vlan.h
Auto-merging net/ipv4/route.c
CONFLICT (content): Merge conflict in net/ipv4/route.c
Auto-merging net/core/ethtool.c
CONFLICT (content): Merge conflict in net/core/ethtool.c
Auto-merging net/packet/af_packet.c
Auto-merging include/linux/nfs_fs_sb.h
CONFLICT (content): Merge conflict in include/linux/nfs_fs_sb.h
Auto-merging net/8021q/vlan_dev.c
Auto-merging net/ipv6/route.c
CONFLICT (content): Merge conflict in net/ipv6/route.c
Auto-merging net/ipv4/fib_trie.c
Auto-merging include/linux/sunrpc/xprt.h
Auto-merging include/net/neighbour.h
Auto-merging include/net/ip_fib.h
CONFLICT (content): Merge conflict in include/net/ip_fib.h
Auto-merging drivers/net/e100.c
Auto-merging drivers/net/e1000/e1000.h
CONFLICT (content): Merge conflict in drivers/net/e1000/e1000.h
Auto-merging net/ipv4/fib_semantics.c
CONFLICT (content): Merge conflict in net/ipv4/fib_semantics.c
Auto-merging drivers/pci/quirks.c
Auto-merging net/ipv4/fib_lookup.h
CONFLICT (content): Merge conflict in net/ipv4/fib_lookup.h
Auto-merging net/ipv4/fib_hash.c
Auto-merging net/core/sock.c
Auto-merging net/Makefile
CONFLICT (content): Merge conflict in net/Makefile
Auto-merging net/decnet/dn_rules.c
CONFLICT (content): Merge conflict in net/decnet/dn_rules.c
Auto-merging include/linux/netdevice.h
Auto-merging net/decnet/dn_route.c
Auto-merging net/sunrpc/xprtsock.c
Auto-merging net/Kconfig
Auto-merging drivers/net/e1000/e1000_ethtool.c
CONFLICT (content): Merge conflict in drivers/net/e1000/e1000_ethtool.c
Auto-merging include/net/dn_fib.h
CONFLICT (content): Merge conflict in include/net/dn_fib.h
Auto-merging fs/nfs/super.c
CONFLICT (content): Merge conflict in fs/nfs/super.c
Auto-merging fs/cifs/connect.c
CONFLICT (content): Merge conflict in fs/cifs/connect.c
Automatic merge failed; fix conflicts and then commit the result.
[greear@xeon-dt linux-2.6.dev]$ git branch
lf_v2.6.16
lf_v2.6.16.x
lf_v2.6.17
lf_v2.6.17.x
lf_v2.6.18
lk_v2.6.15.x.sts
lk_v2.6.16.x
lk_v2.6.16.x.sts
lk_v2.6.17.x
* master
origin
[greear@xeon-dt linux-2.6.dev]$ gitk
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Question on multi-level git repository heiarchy.
From: Shawn Pearce @ 2006-10-27 5:25 UTC (permalink / raw)
To: Ben Greear; +Cc: git
In-Reply-To: <45419529.3010207@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
> I want to create an intermediate level..something like:
>
> kernel.org git tree
> |
> my git master tree
> / \
> work-station-1 work-station-2 ....
> I then did a git checkout -f master on the
> pub server and did a pull from the upstream kernel.
> This seemed to work fine.
Ah, what you really want here is to make your "my git master tree"
a bare repostiory and use fetch instead of pull. This way you
don't need to maintain a working directory of files associated
with that repository. So assuming you have "mygitmastertree"
as the directory do:
mv mygitmastertree/.git mygitmastertree.git
rm -rf mygitmastertree
and update your workstation .git/remotes/origin files such
that the URL line reads ".../mygitmastertree.git" rather than
".../mygitmastertree/.git".
Then to update "mygitmastertree" with recent changes you can use
git fetch rather than git pull:
git --git-dir mygitmastertree.git fetch
> Then, on the work-station, I did a git checkout -f master, and also did
> a pull.
> In this case, it seems that it is trying to merge with changes in the
> lf_v2.6.18 branch
> instead of the the main 'master' tree (see below).
When you use "git pull" with no additional arguments the first
branch listed in a Pull: line of .git/remotes/origin will be the
branch merged into the current branch. I don't know what that
branch is listed as in your workstation tree but from what you
described it sounds like it may be that lf_v2.6.18 branch, which
is why its trying to merge it.
--
^ permalink raw reply
* Re: gitweb.cgi and git instaweb
From: Aneesh Kumar K.V @ 2006-10-27 5:56 UTC (permalink / raw)
To: Aneesh Kumar K.V, git
In-Reply-To: <ehr00n$vbe$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Aneesh Kumar K.V wrote:
> I am getting errors as below with git instaweb.
>
>
> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ git instaweb
> 2006-10-27 00:12:56: (log.c.75) server started
> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ [Fri Oct 27
> 00:12:57 2006] gitweb.cgi: "our" variable $stylesheet masks earlier
> declaration in same scope at
>
The attached patch should fix it.
-aneesh
[-- Attachment #2: gitweb.perl.diff --]
[-- Type: text/x-patch, Size: 445 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ba7a42a..1962c76 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -55,8 +55,6 @@ our $stylesheet;
# default is not to define style sheet, but it can be overwritten later
undef $stylesheet;
-# URI of default stylesheet
-our $stylesheet = "++GITWEB_CSS++";
# URI of GIT logo (72x27 size)
our $logo = "++GITWEB_LOGO++";
# URI of GIT favicon, assumed to be image/png type
^ permalink raw reply related
* Re: fetching packs and storing them as packs
From: Junio C Hamano @ 2006-10-27 6:57 UTC (permalink / raw)
To: Sean; +Cc: Shawn Pearce, Nicolas Pitre, Eran Tromer, git
In-Reply-To: <BAYC1-PASMTP10C050A5FAA4C70AD57679AE040@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Thu, 26 Oct 2006 21:42:29 -0400
> Shawn Pearce <spearce@spearce.org> wrote:
>
>> This is an issue for "central" repositories that people push into
>> and which might be getting repacked according to a cronjob.
>>
>> Unfortunately I don't have a solution. I tried to come up with
>> one but didn't. :-)
>
> What about creating a temporary ref before pushing, and then removing
> it only after the HEAD has been updated?
That won't work. If repack is faster than index-pack, repack
would fail to find necessary objects, barf, and would not remove
the existing or new pack, and then index-pack would eventually
succeed and when it does at least your repository is complete
even though it may still have redundant objects in packs.
So in that sense, it is not a disaster, so it might be a good
enough solution.
I'd almost say "heavy repository-wide operations like 'repack -a
-d' and 'prune' should operate under a single repository lock",
but historically we've avoided locks and instead tried to do
things optimistically and used compare-and-swap to detect
conflicts, so maybe that avenue might be worth pursuing.
How about (I'm thinking aloud and I'm sure there will be
holes -- I won't think about prune for now)...
* "repack -a -d":
(1) initially run show-ref (or "ls-remote .") and store the
result in .git/$ref_pack_lock_file;
(2) enumerate existing packs;
(3) do the usual "rev-list --all | pack-objects" thing; this
may end up including more objects than what are reachable
from the result of (1) if somebody else updates refs in the
meantime;
(4) enumerate existing packs; if there is difference from (2)
other than what (3) created, that means somebody else added
a pack in the meantime; stop and do not do the "-d" part;
(5) run "ls-remote ." again and compare it with what it got in
(1); if different, somebody else updated a ref in the
meantime; stop and do not do the "-d" part;
(6) do the "-d" part as usual by removing packs we saw in (2)
but do not remove the pack we created in (3);
(7) remove .git/$ref_pack_lock_file.
* "fetch --thin" and "index-pack --stdin":
(1) check the .git/$ref_pack_lock_file, and refuse to operate
if there is such (this is not strictly needed for
correctness but only to give an early exit);
(2) create a new pack under a temporary name, and when
complete, make the pack/index pair .pack and .idx;
(3) update the refs.
^ permalink raw reply
* Re: gitweb.cgi and git instaweb
From: Junio C Hamano @ 2006-10-27 7:05 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <45419F75.6060103@gmail.com>
"Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
> Aneesh Kumar K.V wrote:
>> I am getting errors as below with git instaweb.
>>
>>
>> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ git instaweb
>> 2006-10-27 00:12:56: (log.c.75) server started
>> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ [Fri Oct 27
>> 00:12:57 2006] gitweb.cgi: "our" variable $stylesheet masks earlier
>> declaration in same scope at
>>
>
> The attached patch should fix it.
>
> -aneesh
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ba7a42a..1962c76 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -55,8 +55,6 @@ our $stylesheet;
> # default is not to define style sheet, but it can be overwritten later
> undef $stylesheet;
>
> -# URI of default stylesheet
> -our $stylesheet = "++GITWEB_CSS++";
> # URI of GIT logo (72x27 size)
> our $logo = "++GITWEB_LOGO++";
> # URI of GIT favicon, assumed to be image/png type
Removing the extraneous undef would also be a good idea,
wouldn't it?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index aceaeb7..7999b1a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -51,12 +51,10 @@ our $site_footer = "++GITWEB_SITE_FOOTER
# URI of stylesheets
our @stylesheets = ("++GITWEB_CSS++");
-our $stylesheet;
-# default is not to define style sheet, but it can be overwritten later
-undef $stylesheet;
-
# URI of default stylesheet
-our $stylesheet = "++GITWEB_CSS++";
+# default is not to define style sheet, but it can be overwritten later.
+our $stylesheet = undef;
+
# URI of GIT logo (72x27 size)
our $logo = "++GITWEB_LOGO++";
# URI of GIT favicon, assumed to be image/png type
^ permalink raw reply related
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-10-27 7:27 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0610260842x52413570k3971bcdc54b3ccb5@mail.gmail.com>
On Thursday 2006 October 26 16:42, Alex Riesen wrote:
Thanks for your suggestion.
> Use "git checkout HEAD oops/file1"
This returned:
"git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'oops/file1' which can not be resolved as commit?"
I'm not sure that checkout will do what I want anyway because it would
overwrite the working directory copy of oops/file1. I want to keep the
changes but reset the index to have oops/file1 from HEAD.
Maybe I need to say a little more about what I'm trying to do:
I converted a subversion repository to git. In that repository I maintained
my own set of patches in one branch against an upstream branch; I'm now using
git-cherry-pick to pull a subset of those patches onto a new branch against
the upstream head. This is all working fine. The problem is that I've come
across a patch that should rightly be two patches instead of one.
So, I cherry-pick a patch, which updates the working directory and index,
leaving me with...
# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#
# modified: oops/file1
# modified: good/file2
# modified: good/file3
# modified: good/file4
Instead, what I would like is
# On branch refs/heads/newmaster
# Updated but not checked in:
# (will commit)
#
# modified: good/file2
# modified: good/file3
# modified: good/file4
#
# On branch refs/heads/newmaster
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# modified: oops/file1
I've actually found a way around the problem. I do git-reset HEAD, which
restores the index entirely but leaves the working directory. Then I
git-update-index the good/* set. However, it led me to wonder what the
inverse of git-update-index is.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Shawn Pearce @ 2006-10-27 7:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610270827.17659.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> wrote:
> However, it led me to wonder what the inverse of git-update-index is.
git-update-index :-)
You can use something like:
git ls-tree HEAD oops/file1 | git update-index --index-info
to restore the index state of oops/file1.
Which leads us to the always interesting, fun and exciting:
git ls-tree -r HEAD | git update-index --index-info
which will undo everything except 'git add' from the index, as
ls-tree -r is listing everything in the last commit.
--
^ permalink raw reply
* Re: [PATCH] cogito: Honor either post-commit script name; fail if both are executable
From: Jim Meyering @ 2006-10-27 7:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061027020549.GY20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Oct 20, 2006 at 06:15:51PM CEST, I got a letter
> where Jim Meyering <jim@meyering.net> said that...
>> I promised this patch some time ago, made the changes,
>> and then never sent them. This is slightly different
>> from the current implementation in that it fails when both
>> scripts are executable. Also, it factors out the script names and
>> adds tests.
>>
>> Signed-off-by: Jim Meyering <jim@meyering.net>
>
> I'm not sure I like this (of course, I always like additional tests,
> though). The problem is that this loses a smooth upgrade path, things
> suddenly break and you can't commit without having to think about fixing
> your environment.
How would such a tiny change affect the upgrade path?
Failing when both scripts are executable feels more like doing the
(confused) user a favor than complicating their upgrade experience :-)
In case it wasn't clear, the only change induced by that patch is to
make cg-commit fail if *both* commit-post and post-commit scripts
exist and are executable. I'll bet that is unusual enough not to matter.
> deprecation warnings. So if we want to get rid of commit-post, we should
> rather start printing deprecation warnings if commit-post exists, and in
> few months cut commit-post off.
If you want to retire "commit-post", that's mostly independent.
IMHO, the things to do:
-- announce and document the name change (leaving mention of the old
name at least temporarily in the documentation)
-- later, start warning if the old name is used
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Alex Riesen @ 2006-10-27 7:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061027044233.GA29057@spearce.org>
> So the receive-pack process becomes:
>
> a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
On 10/27/06, Shawn Pearce <spearce@spearce.org> wrote:
> Eran Tromer <git2eran@tromer.org> wrote:
> > On 2006-10-27 05:00, Shawn Pearce wrote:
> > >> Change git-repack to follow references under $GIT_DIR/tmp/refs/ too.
> > >> To receive or fetch a pack:
> > >> 1. Add references to the new heads in
> > >> `mktemp $GIT_DIR/tmp/refs/XXXXXX`.
> > >> 2. Put the new .pack under $GIT_DIR/objects/pack/.
> > >> 3. Put the new .idx under $GIT_DIR/objects/pack/.
> > >> 4. Update the relevant heads under $GIT_DIR/refs/.
> > >> 5. Delete the references from step 1.
> >
> > > That was actually my (and also Sean's) solution. Except I would
> > > put the temporary refs as "$GIT_DIR/refs/ref_XXXXXX" as this is
> > > less code to change and its consistent with how temporary loose
> > > objects are created.
> >
> > If you do that, other programs (e.g., anyone who uses rev-list --all)
> > may try to walk those heads or consider them available before the pack
> > is really there. The point about $GIT_DIR/tmp/refs is that only programs
> > meddling with physical packs (git-fetch, git-receive-pack, git-repack)
> > will know about it.
>
> Doh. Yes, of course, that makes much sense.
>
> Hmm... Looking at git-repack we have two things currently pending
> to rework in there:
>
> - Historical vs. active packs.
> - Don't delete a possibly still incoming pack during -d.
>
> These have a lot of the same implementation issues. We need to
> be able to identify a set of packs which should be allowed for
> repack with -a, and allowed for removal with -d if -a was also used.
> A newly uploaded pack cannot be in that list unless its contents are
> referenced by one or more refs (which implies that the receive-pack
> process has completed).
>
> I'm thinking that the ref thing might be unnecessary. We just
> need to fix repack so it builds a list of "active packs" whose
> objects should be copied into the new pack, and then only packs
> loose objects and those objects contained by an active packs.
>
> So the receive-pack process becomes:
>
> a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
> c. Write pack and index.
> d. Move pack to $GIT_DIR/objects/pack/...
> e. Move index to $GIT_DIR/objects/pack...
> f. Update refs.
> g. Arrange for new pack and index to be considered active.
>
> And the repack -a -d process becomes:
>
> 1. List all active packs and store in memory.
> 2. Repack only loose objects and objects contained in active packs.
> 3. Move new pack and idx into $GIT_DIR/objects/pack/...
> 4. Arrange for new pack and idx to be considered active.
> 5. Delete active packs found by step #1.
>
> Junio was originally considering making historical packs
> historical by placing their names into an information file (such as
> `$GIT_DIR/objects/info/historical-packs`) and then consider all other
> packs as active. Thus step #1 is list all packs and removes those
> whose names appear in historical-packs, while step #4 is unnecessary.
>
> I was thinking about just changing the "pack-" prefix to "hist-" for
> the historical packs and assuming all "pack-*.pack" to be active.
> Thus step #1 is a simple glob on the pack directory and step #4
> is unnecessary.
>
> In the latter case its easy to mark an existing pack as historical
> (just hardlink hist- names for pack, then idx, then unlink previous
> names) and its also easy to mark new incoming packs as non active
> by using a different prefix (e.g. "incm-") during step #d/#e and
> then relinking them as "pack-" during step #g. Its also very safe
> on systems that support hardlinks.
>
> We shouldn't ever need to worry about race conditions with repacking
> historical packs. For starters historical packs will tend to be
> several years' worth of object accumulation and will be so large
> that repacking them might take 45 minutes or more. Thus they
> probably will never get repacked. An active pack will simply move
> into historical status after it gets so large that its no longer
> worthwhile to keep repacking it. They also will tend to have objects
> that are so old that at least one ref in the repository will point
> at their entire DAG and thus everything would carry over on a repack.
>
> So this would be cleaner then messing around with temporary refs and
> gets us the historical pack feature we've been looking to implement.
>
> --
> Shawn.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 7:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <81b0412b0610270042w29279b90t7c94d8590d701519@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> >So the receive-pack process becomes:
> >
> > a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> >b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
>
> Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
Because there is a race condition.
The contents of the new pack must be accessable as a normal pack
before we update and unlock the refs that are being changed. This
means it must be a normal pack in $GIT_DIR/objects/pack.
Currently all packs under $GIT_DIR/objects/pack are deleted during
`repack -a -d`. Those packs may have been added to that directory
after the repack started resulting in them getting deleted when
the repack completes, but with none of their contained objects in
the newly created pack. Thus the repository is suddenly missing
everything that was just pushed (or fetched).
--
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-10-27 8:01 UTC (permalink / raw)
To: git
In-Reply-To: <20061027073834.GC29057@spearce.org>
On Friday 2006 October 27 08:38, Shawn Pearce wrote:
> git ls-tree HEAD oops/file1 | git update-index --index-info
> git ls-tree -r HEAD | git update-index --index-info
Absolute gold. Exactly what I wanted. Thanks so much.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Alex Riesen @ 2006-10-27 8:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20061027075229.GD29057@spearce.org>
>> >So the receive-pack process becomes:
>> >
>> > a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
>> >b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
>>
>> Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
>
> Because there is a race condition.
Oh, right. Incidentally, is there a lockfile for packs?
On 10/27/06, Shawn Pearce <spearce@spearce.org> wrote:
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > >So the receive-pack process becomes:
> > >
> > > a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> > >b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
> >
> > Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
>
> Because there is a race condition.
>
> The contents of the new pack must be accessable as a normal pack
> before we update and unlock the refs that are being changed. This
> means it must be a normal pack in $GIT_DIR/objects/pack.
>
> Currently all packs under $GIT_DIR/objects/pack are deleted during
> `repack -a -d`. Those packs may have been added to that directory
> after the repack started resulting in them getting deleted when
> the repack completes, but with none of their contained objects in
> the newly created pack. Thus the repository is suddenly missing
> everything that was just pushed (or fetched).
>
> --
> Shawn.
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andreas Ericsson @ 2006-10-27 8:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Parkins, git
In-Reply-To: <20061027073834.GC29057@spearce.org>
Shawn Pearce wrote:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> However, it led me to wonder what the inverse of git-update-index is.
>
> git-update-index :-)
>
> You can use something like:
>
> git ls-tree HEAD oops/file1 | git update-index --index-info
>
> to restore the index state of oops/file1.
>
>
> Which leads us to the always interesting, fun and exciting:
>
> git ls-tree -r HEAD | git update-index --index-info
>
> which will undo everything except 'git add' from the index, as
> ls-tree -r is listing everything in the last commit.
>
... and also shows The Power of the Pipe, which Daniel@google was
missing in recent versions of git. ;-)
Btw, this is most definitely not a documented thing and requires a bit
of core git knowledge, so perhaps the "shell-scripts were good for
hackers to learn what to pipe where" really *is* a very important point.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 8:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <81b0412b0610270108t7b93d04y2c99be20b7f41387@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> >>>So the receive-pack process becomes:
> >>>
> >>> a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> >>>b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
> >>
> >>Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
> >
> >Because there is a race condition.
>
> Oh, right. Incidentally, is there a lockfile for packs?
No, we have never needed them before. And I think we'd like to
avoid adding them now.
We do have the rule that a pack can only be accessed if its .idx
file exists; therefore we generate a pack and its index, then place
the pack into the object directory, then the index. That way the
pack is there before the index but another process won't attempt
to read the pack until the index exists. It also means we should
never put an index into the pack directory before its associated
pack. :-)
If we are pruneing packs or loose objects after the repack we delete
only after the pack and index are in place. Running processes
rescan the existing packs once if they look for an object and
cannot find it in the loose objects directory or in the packs it
already knows about; this lets most running processes automatically
recover should a parallel repack delete the loose objects it needs
(as they were just packed).
--
^ 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