threads / announce / 1640

[ANNOUNCE] GIT 0.99.5

Subject: [ANNOUNCE] GIT 0.99.5

## tl;dr

5 messages between Aug 25, 2005 and Aug 26, 2005.

replies: 4people: 4as markdown or json

Junio C Hamano· Aug 25, 2005, 02:38 UTC · lore

I've pushed out all of what has been in the proposed updates branch, along with documentation updates.

Many changes all over:
 - pulling from packed repository.
 - cvsimport.
 - documentation coverage.
 - usability.
 - terminology clarification.
 - hooks for updates and commits.
 - updated gitk.
 - multi-head push, fetch, pull, octopus merge.
 - faster merge-base.
 - git from subdirectories.
 - build procedure cleanups.
Have fun.

What to expect after 0.99.5 ===========================

This is written in a form of to-do list for me, so if I say "accept patch", it means I do not currently plan to do that myself. People interested in seeing it materialize please take a hint.

Documentation -------------

* Accept patches from people who actually have done CVS
  migration and update the cvs-migration documentation.
  Link the documentation from the main git.txt page.
* Update the SubmittingPatches document to add MUA specific
  hints on how to disable unwanted MIME and flowed-text by
  collecting past list postings.  Accept patches from people who
  was hit by shiny blue bat to update the same.
* Talk about using rsync just once at the beginning when
  initializing a remote repository so that local packs do not
  need to be expanded.  I personally do not think we need tool
  support for this.
* Update tutorial to cover shared repository style a bit more,
  maybe with a toy project that involves two or three
  repositories.
* Update tutorial to cover setting up repository hooks to do
  common tasks.
* Get help to properly use asciidoc in tutorial.
* Maybe justify and demonstrate an Octopus in the tutorial.  Add
  it to the glossary.

Technical (heavier) -------------------

* Tony Luck reported an unfortunate glitch in the 3-way merge.
  Encourage discussions to come up with a not-so-expensive way
  to catch the kind of ambiguities that led to his misery.

Technical (milder) ------------------

* When the branch head pointed by $GIT_DIR/HEAD changes while
  the index file and working tree are looking the other way
  (e.g. somebody pushed into your repository, or you ran "git
  fetch" to update the ref your working tree is on), "git
  checkout" without -f gets confused.  Figure out a good way to
  handle this.
* "git commit -m" should work for initial commits and perhaps
  merge commits as well.  Warning about merge is still a good
  thing to do, while -m is useful in scripted non-interactive
  use, so we need to be careful.
* Encourage concrete proposals to commit log message templates
  we discussed some time ago.
* Bug Ryan and work with him to update send-email easier to use.
* Look at portability fixes from Jason Riedy
    http://www.cs.berkeley.edu/~ejr/gits/git.git#portable 
* Accept patches to cause "read-tree -u" delete a directory when
  it makes it empty.
* Perhaps accept patches to introduce the concept of "patch flow
  expressed as ref mappings" Josef has been advocating about.
* MIMEified applymbox to grok B and Q encodings in headers and
  turn them into UTF-8; unwrap QP; explode multipart.
* "git cherry-pick" that applies the patch an existing commit
  introduces in its ancestry chain, possibly using the 3-way
  merge machinery; update rebase using the cherry-pick command.
  Carl's redo/undo might fall out naturally from this.
* A tool to detect, show and prune already merged topic
  branches.
* Perhaps "git branch -d" to delete a branch.
* Enhance "git repack" to not always use --all; this would be
  handy if the repository contains wagging heads like "pu" in
  git.git repository.
* Remove "git clone-dumb-http".
Martin Langhoff· Aug 25, 2005, 03:30 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 0.99.5

On 8/25/05, Junio C Hamano <junkio@cox.net> wrote:
> Have fun.
Yay!
> What to expect after 0.99.5
> ===========================
> Documentation
> -------------

Perhaps link the 'howto' docs from the git formal docs, so they are visible via http://www.kernel.org/pub/software/scm/git/docs/

> * Accept patches from people who actually have done CVS
>   migration and update the cvs-migration documentation.
>   Link the documentation from the main git.txt page.

Yup, run trial conversions for about half a dozen cvs repos, and currently tracking external cvs projects with git too. Will update docs as I find time.

> * Update tutorial to cover shared repository style a bit more,
>   maybe with a toy project that involves two or three
>   repositories.

I recently wrote one such 'shared repo' tutorial for internal consumption at work. Should clean it up, and add to the howto dir. The incentive here would be to see the howtos on the web - and then I can point people at it directly.

> Technical (milder)
> ------------------

Personally, I want to complete the Arch import. I'm interested in feedback on the current code -- anyone has an interest in migration from Arch or similar patch-centric SCM?

cheers,
martin
Darrin Thompson· Aug 25, 2005, 19:05 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 0.99.5

On Wed, 2005-08-24 at 19:38 -0700, Junio C Hamano wrote:
> * Update tutorial to cover shared repository style a bit more,
>   maybe with a toy project that involves two or three
>   repositories.
> 
Shameless plug: Feel free to use/modify/steal my writeup:
http://willowbend.cx/archives/2005/08/24/git-epiphany/

-- Darrin

Eric W. Biederman· Aug 26, 2005, 15:12 UTC · re: Junio C Hamano · lore

Re: [ANNOUNCE] GIT 0.99.5

Junio C Hamano <junkio@cox.net> writes:
> Documentation
> -------------

A nit but possibly an important for 1.0 there are quite a few git commands that don't have man pages or whose man pages are currently very poor.

Getting the code sane and stable of course comes first but if people can't figure out how to use git...

Eric
Junio C Hamano· Aug 26, 2005, 16:24 UTC · re: Eric W. Biederman · lore

Re: [ANNOUNCE] GIT 0.99.5

ebiederm@xmission.com (Eric W. Biederman) writes:
Show 6 quoted lines
> A nit but possibly an important for 1.0 there are
> quite a few git commands that don't have man pages
> or whose man pages are currently very poor.
>
> Getting the code sane and stable of course comes first
> but if people can't figure out how to use git...

I have been worried about that since I posted my first "last mile" message. My excuse is that there are only 24 hours in a day. Patches welcome.

← back to recent threads