# update-server-info logic

2 messages from 2009-04-28 to 2009-04-28. Participants: Mike Gaffney, Shawn O. Pearce.
Thread: https://gitlist.dev/t/19109

## Mike Gaffney, 2009-04-28 15:29

Subject: update-server-info logic
Message-ID: <49F720BC.9080604@gmail.com>
URL: https://gitlist.dev/e/49F720BC.9080604%40gmail.com

```
Folks,
    I was wondering if someone could reply with a quick rundown of the 
update-server-info logic. I'm looking at implementing it in JGit and 
wanted to make sure I had it correct.

-Mike

```

## Shawn O. Pearce, 2009-04-28 15:39

Subject: Re: update-server-info logic
Message-ID: <20090428153911.GR23604@spearce.org>
URL: https://gitlist.dev/e/20090428153911.GR23604%40spearce.org
In-Reply-To: <49F720BC.9080604@gmail.com>

```
Mike Gaffney <mr.gaffo@gmail.com> wrote:
>    I was wondering if someone could reply with a quick rundown of the  
> update-server-info logic. I'm looking at implementing it in JGit and  
> wanted to make sure I had it correct.

Its two things:

* rewrite $GIT_DIR/info/refs to be a complete catalog of all refs.
  IIRC this format is one ref per line, sorted by the full ref name,
  with the line format being "$SHA1\t$NAME\n".

  Most of this is already implemented in RefWriter.
  See writeInfoRefs().

* rewrite $GIT_DIR/objects/info/packs to be a complete catalog of the
  packs in $GIT_DIR/objects/pack.  The format is one pack per line,
  written as "P pack-$HASH.pack\n".  A final blank line is written
  on the end of the file, for I don't know why.  Its a good idea to
  sort the lines by the last modified date of the pack, descending,
  as clients will evaulate the file in order when searching for a
  missing object, and the usually need the more recent pack first.

  Most of this is already implemented in WalkRemoteObjectDatabase.
  See writeInfoPacks().

-- 
Shawn.

```