[ANNOUNCE] GIT 1.5.3

[ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

The latest feature release GIT 1.5.3 is available at the usual
places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.3.tar.{gz,bz2}			(tarball)
  git-htmldocs-1.5.3.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.5.3.tar.{gz,bz2}		(preformatted docs)
  RPMS/$arch/git-*-1.5.3-1.$arch.rpm	(RPM)

GIT v1.5.3 Release Notes
========================

Updates since v1.5.2
--------------------

* The commit walkers other than http are officially deprecated,
  but still supported for now.

* The submodule support has Porcelain layer.

  Note that the current submodule support is minimal and this is
  deliberately so.  A design decision we made is that operations
  at the supermodule level do not recurse into submodules by
  default.  The expectation is that later we would add a
  mechanism to tell git which submodules the user is interested
  in, and this information might be used to determine the
  recursive behaviour of certain commands (e.g. "git checkout"
  and "git diff"), but currently we haven't agreed on what that
  mechanism should look like.  Therefore, if you use submodules,
  you would probably need "git submodule update" on the
  submodules you care about after running a "git checkout" at
  the supermodule level.

* There are a handful pack-objects changes to help you cope better
  with repositories with pathologically large blobs in them.

* For people who need to import from Perforce, a front-end for
  fast-import is in contrib/fast-import/.

* Comes with git-gui 0.8.2.

* Comes with updated gitk.

* New commands and options.

  - "git log --date=<format>" can use more formats: iso8601, rfc2822.

  - The hunk header output from "git diff" family can be customized
    with the attributes mechanism.  See gitattributes(5) for details.

  - "git stash" allows you to quickly save away your work in
    progress and replay it later on an updated state.

  - "git rebase" learned an "interactive" mode that let you
    pick and reorder which commits to rebuild.

  - "git fsck" can save its findings in $GIT_DIR/lost-found, without a
    separate invocation of "git lost-found" command.  The blobs stored by
    lost-found are stored in plain format to allow you to grep in them.

  - $GIT_WORK_TREE environment variable can be used together with
    $GIT_DIR to work in a subdirectory of a working tree that is
    not located at "$GIT_DIR/..".

  - Giving "--file=<file>" option to "git config" is the same as
    running the command with GIT_CONFIG=<file> environment.

  - "git log" learned a new option "--follow", to follow
    renaming history of a single file.

  - "git filter-branch" lets you rewrite the revision history of
    specified branches. You can specify a number of filters to
    modify the commits, files and trees.

  - "git cvsserver" learned new options (--base-path, --export-all,
    --strict-paths) inspired by "git daemon".

  - "git daemon --base-path-relaxed" can help migrating a repository URL
    that did not use to use --base-path to use --base-path.

  - "git commit" can use "-t templatefile" option and commit.template
    configuration variable to prime the commit message given to you in the
    editor.

  - "git submodule" command helps you manage the projects from
    the superproject that contain them.

  - In addition to core.compression configuration option,
    core.loosecompression and pack.compression options can
    independently tweak zlib compression levels used for loose
    and packed objects.

  - "git ls-tree -l" shows size of blobs pointed at by the
    tree entries, similar to "/bin/ls -l".

  - "git rev-list" learned --regexp-ignore-case and
    --extended-regexp options to tweak its matching logic used
    for --grep fitering.

  - "git describe --contains" is a handier way to call more
    obscure command "git name-rev --tags".

  - "git gc --aggressive" tells the command to spend more cycles
    to optimize the repository harder.

  - "git repack" learned a "window-memory" limit which
    dynamically reduces the window size to stay within the
    specified memory usage.

  - "git repack" can be told to split resulting packs to avoid
    exceeding limit specified with "--max-pack-size".

  - "git fsck" gained --verbose option.  This is really really
    verbose but it might help you identify exact commit that is
    corrupt in your repository.

  - "git format-patch" learned --numbered-files option.  This
    may be useful for MH users.

  - "git format-patch" learned format.subjectprefix configuration
    variable, which serves the same purpose as "--subject-prefix"
    option.

  - "git tag -n -l" shows tag annotations while listing tags.

  - "git cvsimport" can optionally use the separate-remote layout.

  - "git blame" can be told to see through commits that change
    whitespaces and indentation levels with "-w" option.

  - "git send-email" can be told not to thread the messages when
    sending out more than one patches.

  - "git send-email" can also be told how to find whom to cc the
    message to for each message via --cc-cmd.

  - "git config" learned NUL terminated output format via -z to
    help scripts.

  - "git add" learned "--refresh <paths>..." option to selectively refresh
    the cached stat information.

  - "git init -q" makes the command quieter.

  - "git -p command" now has a cousin of opposite sex, "git --no-pager
    command".

* Updated behavior of existing commands.

  - "gitweb" can offer multiple snapshot formats.

    ***NOTE*** Unfortunately, this changes the format of the
    $feature{snapshot}{default} entry in the per-site
    configuration file 'gitweb_config.perl'.  It used to be a
    three-element tuple that describe a single format; with the
    new configuration item format, you only have to say the name
    of the format ('tgz', 'tbz2' or 'zip').  Please update the
    your configuration file accordingly.

  - "git clone" uses -l (hardlink files under .git) by default when
    cloning locally.

  - URL used for "git clone" and friends can specify nonstandard SSH port
    by using sh://host:port/path/to/repo syntax.

  - "git bundle create" can now create a bundle without negative refs,
    i.e. "everything since the beginning up to certain points".

  - "git diff" (but not the plumbing level "git diff-tree") now
    recursively descends into trees by default.

  - "git diff" does not show differences that come only from
    stat-dirtiness in the form of "diff --git" header anymore.
    It runs "update-index --refresh" silently as needed.

  - "git tag -l" used to match tags by globbing its parameter as if it
    has wildcard '*' on both ends, which made "git tag -l gui" to match
    tag 'gitgui-0.7.0'; this was very annoying.  You now have to add
    asterisk on the sides you want to wildcard yourself.

  - The editor to use with many interactive commands can be
    overridden with GIT_EDITOR environment variable, or if it
    does not exist, with core.editor configuration variable.  As
    before, if you have neither, environment variables VISUAL
    and EDITOR are consulted in this order, and then finally we
    fall back on "vi".

  - "git rm --cached" does not complain when removing a newly
    added file from the index anymore.

  - Options to "git log" to affect how --grep/--author options look for
    given strings now have shorter abbreviations.  -i is for ignore case,
    and -E is for extended regexp.

  - "git log" learned --log-size to show the number of bytes in
    the log message part of the output to help qgit.

  - "git log --name-status" does not require you to give "-r" anymore.
    As a general rule, Porcelain commands should recurse when showing
    diff.

  - "git format-patch --root A" can be used to format everything
    since the beginning up to A.  This was supported with
    "git format-patch --root A A" for a long time, but was not
    properly documented.

  - "git svn dcommit" retains local merge information.

  - "git svnimport" allows an empty string to be specified as the
    trunk/ directory.  This is necessary to suck data from a SVN
    repository that doe not have trunk/ branches/ and tags/ organization
    at all.

  - "git config" to set values also honors type flags like --bool
    and --int.

  - core.quotepath configuration can be used to make textual git
    output to emit most of the characters in the path literally.

  - "git mergetool" chooses its backend more wisely, taking
    notice of its environment such as use of X, Gnome/KDE, etc.

  - "gitweb" shows merge commits a lot nicer than before.  The
    default view uses more compact --cc format, while the UI
    allows to choose normal diff with any parent.

  - snapshot files "gitweb" creates from a repository at
    $path/$project/.git are more useful.  We use $project part
    in the filename, which we used to discard.

  - "git cvsimport" creates lightweight tags; there is no
    interesting information we can record in an annotated tag,
    and the handcrafted ones the old code created was not
    properly formed anyway.

  - "git push" pretends that you immediately fetched back from
    the remote by updating corresponding remote tracking
    branches if you have any.

  - The diffstat given after a merge (or a pull) honors the
    color.diff configuration.

  - "git commit --amend" is now compatible with various message source
    options such as -m/-C/-c/-F.

  - "git apply --whitespace=strip" removes blank lines added at
    the end of the file.

  - "git fetch" over git native protocols with "-v" option shows
    connection status, and the IP address of the other end, to
    help diagnosing problems.

  - We used to have core.legacyheaders configuration, when
    set to false, allowed git to write loose objects in a format
    that mimicks the format used by objects stored in packs.  It
    turns out that this was not so useful.  Although we will
    continue to read objects written in that format, we do not
    honor that configuration anymore and create loose objects in
    the legacy/traditional format.

  - "--find-copies-harder" option to diff family can now be
    spelled as "-C -C" for brevity.

  - "git mailsplit" (hence "git am") can read from Maildir
    formatted mailboxes.

  - "git cvsserver" does not barf upon seeing "cvs login"
    request.

  - "pack-objects" honors "delta" attribute set in
    .gitattributes.  It does not attempt to deltify blobs that
    come from paths with delta attribute set to false.

  - "new-workdir" script (in contrib) can now be used with a
    bare repository.

  - "git mergetool" learned to use gvimdiff.

  - "gitview" (in contrib) has a better blame interface.

  - "git log" and friends did not handle a commit log message
    that is larger than 16kB; they do now.

  - "--pretty=oneline" output format for "git log" and friends
    deals with "malformed" commit log messages that have more
    than one lines in the first paragraph better.  We used to
    show the first line, cutting the title at mid-sentence; we
    concatenate them into a single line and treat the result as
    "oneline".

  - "git p4import" has been demoted to contrib status.  For
    a superior option, checkout the "git p4" front end to
    "git fast-import" (also in contrib).  The man page and p4
    rpm have been removed as well.

  - "git mailinfo" (hence "am") now tries to see if the message
    is in utf-8 first, instead of assuming iso-8859-1, if
    incoming e-mail does not say what encoding it is in.

* Builds

  - old-style function definitions (most notably, a function
    without parameter defined with "func()", not "func(void)")
    have been eradicated.

  - "git tag" and "git verify-tag" have been rewritten in C.

* Performance Tweaks

  - "git pack-objects" avoids re-deltification cost by caching
    small enough delta results it creates while looking for the
    best delta candidates.

  - "git pack-objects" learned a new heuristcs to prefer delta
    that is shallower in depth over the smallest delta
    possible.  This improves both overall packfile access
    performance and packfile density.

  - diff-delta code that is used for packing has been improved
    to work better on big files.

  - when there are more than one pack files in the repository,
    the runtime used to try finding an object always from the
    newest packfile; it now tries the same packfile as we found
    the object requested the last time, which exploits the
    locality of references.

  - verifying pack contents done by "git fsck --full" got boost
    by carefully choosing the order to verify objects in them.

  - "git read-tree -m" to read into an already populated index
    has been optimized vastly.  The effect of this can be seen
    when switching branches that have differences in only a
    handful paths.

  - "git add paths..." and "git commit paths..." has also been
    heavily optimized.

Fixes since v1.5.2
------------------

All of the fixes in v1.5.2 maintenance series are included in
this release, unless otherwise noted.

* Bugfixes

  - "gitweb" had trouble handling non UTF-8 text with older
    Encode.pm Perl module.

  - "git svn" misparsed the data from the commits in the repository when
    the user had "color.diff = true" in the configuration.  This has been
    fixed.

  - There was a case where "git svn dcommit" clobbered changes made on the
    SVN side while committing multiple changes.

  - "git-write-tree" had a bad interaction with racy-git avoidance and
    gitattributes mechanisms.

  - "git --bare command" overrode existing GIT_DIR setting and always
    made it treat the current working directory as GIT_DIR.

  - "git ls-files --error-unmatch" does not complain if you give the
    same path pattern twice by mistake.

  - "git init" autodetected core.filemode but not core.symlinks, which
    made a new directory created automatically by "git clone" cumbersome
    to use on filesystems that require these configurations to be set.

  - "git log" family of commands behaved differently when run as "git
    log" (no pathspec) and as "git log --" (again, no pathspec).  This
    inconsistency was introduced somewhere in v1.3.0 series but now has
    been corrected.

  - "git rebase -m" incorrectly displayed commits that were skipped.

----------------------------------------------------------------

Shortlog since v1.5.2.5 is too long, so I'll list just the names
of contributors here and thank everybody.

Adam Roben: 5
Alberto Bertogli: 1
Alecs King: 1
Alexandre Julliard: 9
Alexandre Vassalotti: 1
Alex Riesen: 27
Andrew Ruder: 2
Andy Whitcroft: 3
Aneesh Kumar K.V: 2
Arjen Laarhoven: 2
Benjamin Sergeant: 1
Bradford C. Smith: 2
Brian Downing: 13
Brian Gernhardt: 5
Brian Hetro: 5
Carlos Rica: 13
Christian Stimming: 1
CJ van den Berg: 1
Dana L. How: 8
Daniel Barkalow: 8
Dan McGee: 1
Dave O'Neill: 1
Dave Watson: 1
David Kågedal: 1
David Kastrup: 16
David Soria Parra: 1
David Symonds: 1
Elvis Pranskevichus: 1
Emil Medve: 2
Eric Wong: 11
Fernando J. Pereda: 1
Francis Moreau: 1
Frank Lichtenheld: 12
Geert Bosch: 1
Gerrit Pape: 5
Giuseppe Bilotta: 2
Greg KH: 1
Han-Wen Nienhuys: 30
Ismail Dönmez: 1
Jakub Narebski: 27
James Bowes: 3
Jari Aalto: 1
J. Bruce Fields: 9
Jeff King: 14
Jeffrey C. Ollie: 2
Jens Axboe: 1
Jim Meyering: 6
Joe Perches: 1
Johan Herland: 1
Johannes Schindelin: 77
Johannes Sixt: 14
Jonas Fonseca: 3
Jon Loeliger: 1
Josh Triplett: 2
Julian Phillips: 3
Junio C Hamano: 160
Jyotirmoy Bhattacharya: 1
Kevin Green: 1
Kristian Høgsberg: 1
Kumar Gala: 1
Lars Hjemli: 12
Linus Torvalds: 21
Luben Tuikov: 1
Luiz Fernando N. Capitulino: 3
Lukas Sandström: 1
Marco Costalba: 3
Marcus Fritzsch: 1
Marius Storm-Olsen: 8
Mark Levedahl: 13
martin f. krafft: 2
Martin Koegler: 5
Martin Waitz: 1
Matthias Lederhofer: 21
Matthieu Moy: 2
Matthijs Melchior: 1
Matt Kraai: 3
Matt McCutchen: 4
Michael Ellerman: 2
Michael Hendricks: 2
Michael Krelin: 1
Michael S. Tsirkin: 1
Mike Hommey: 2
Miklos Vajna: 2
Miles Bader: 1
Nanako Shiraishi: 5
Nguyễn Thái Ngọc Duy: 1
Nicolas Pitre: 14
Paul Mackerras: 37
Peter Hagervall: 1
Petr Baudis: 6
Pierre Habouzit: 3
Quy Tonthat: 2
Randal L. Schwartz: 2
Reece H. Dunn: 1
René Scharfe: 10
Richard MUSIL: 1
Robert Ewald: 1
Robert Schiele: 2
Robin Rosenberg: 5
Sam Vilain: 3
Scott Lamb: 2
Sean Estabrooks: 6
Seth Falcon: 1
Shawn O. Pearce: 140
Simon Hausmann: 231
Stefan Sperling: 1
Steffen Prohaska: 3
Stephen Rothwell: 1
Steve Hoelzer: 3
Steven Grimm: 4
Steven Walter: 1
Sven Verdoolaege: 7
Theodore Ts'o: 4
Thomas Schwinge: 2
Tom Clarke: 1
Uwe Kleine-König: 5
Väinö Järvelä: 1

Re: [ANNOUNCE] GIT 1.5.3

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> * For people who need to import from Perforce, a front-end for
>   fast-import is in contrib/fast-import/.
> 

There seems to be an issue with this and RPMS.

In particular, there is no longer a git-p4 RPMS, which prevents git from 
getting upgraded at all by yum.

Anyone who knows yum well enough to explain what needs to be done so 
that yum knows this is obsolete?

	-hpa

Re: [ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Junio C Hamano wrote:
>>
>> * For people who need to import from Perforce, a front-end for
>>   fast-import is in contrib/fast-import/.
>
> There seems to be an issue with this and RPMS.
>
> In particular, there is no longer a git-p4 RPMS, which prevents git
> from getting upgraded at all by yum.
>
> Anyone who knows yum well enough to explain what needs to be done so
> that yum knows this is obsolete?

Geez.  Is this only about upgrading, or is initial install also
affected?

Re: [ANNOUNCE] GIT 1.5.3

[David Kastrup]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Junio C Hamano wrote:
>>
>> * For people who need to import from Perforce, a front-end for
>>   fast-import is in contrib/fast-import/.
>>
>
> There seems to be an issue with this and RPMS.
>
> In particular, there is no longer a git-p4 RPMS, which prevents git
> from getting upgraded at all by yum.
>
> Anyone who knows yum well enough to explain what needs to be done so
> that yum knows this is obsolete?

Probably a matter of the correct spec file.  In auctex.spec, we have

Summary: 	Enhanced TeX modes for Emacsen
Name: 		auctex
Version: 	11.84
Release: 	1%{distri}
License: 	GPL
Group: 		%{commongroup}
URL: 		http://www.gnu.org/software/auctex/
Source0:        ftp://ftp.gnu.org/pub/gnu/auctex/%{name}-%{version}.tar.gz
BuildArchitectures: noarch
BuildRoot: 	%{_tmppath}/%{name}-root

%description
AUCTeX is [...]

%package emacs
Summary: 	Enhanced TeX modes for GNU Emacs
Group:          %{commongroup}
Requires: 	emacs >= 21
Obsoletes:      ge_auc emacs-auctex auctex preview-latex-emacs
Conflicts:      emacspeak < 18
Provides:       auctex


So auctex-emacs obsoletes the previous "auctex" package and some other
packages.  It also provides "auctex" since some other packages might
require it.

Basically, you need to provide everything that a third-party package
might have asked for, and you need to obsolete everything that you
intend to replace.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [ANNOUNCE] GIT 1.5.3

[H. Peter Anvin]

David Kastrup wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> Junio C Hamano wrote:
>>> * For people who need to import from Perforce, a front-end for
>>>   fast-import is in contrib/fast-import/.
>>>
>> There seems to be an issue with this and RPMS.
>>
>> In particular, there is no longer a git-p4 RPMS, which prevents git
>> from getting upgraded at all by yum.
>>
>> Anyone who knows yum well enough to explain what needs to be done so
>> that yum knows this is obsolete?
> 
> Probably a matter of the correct spec file.  In auctex.spec, we have
> 

 From the looks of it, there is still a git-p4, it just moved to contrib 
and uses fast-import, so removing its rpm package was probably broken in 
the first place.

"make rpm" is also broken for "dirty" builds, which is bad for testing.

	-hpa

Re: [ANNOUNCE] GIT 1.5.3

[Alex Riesen]

Arkadiusz Miskiewicz, Sun, Sep 02, 2007 10:43:38 +0200:
> *** t0001-init.sh ***
> * FAIL 1: plain
> 
>                 (
>                         unset GIT_DIR GIT_WORK_TREE &&
>                         mkdir plain &&
>                         cd plain &&
>                         git init
>                 ) &&
>                 check_config plain/.git false unset
> 
> *   ok 2: plain with GIT_WORK_TREE
> * FAIL 3: plain bare
> 
>                 (
>                         unset GIT_DIR GIT_WORK_TREE GIT_CONFIG &&
>                         mkdir plain-bare-1 &&
>                         cd plain-bare-1 &&
>                         git --bare init
>                 ) &&
>                 check_config plain-bare-1 true unset
> 

Do you have bash-2.05b as /bin/sh ?

Re: [ANNOUNCE] GIT 1.5.3

[Sean]

On Sun, 02 Sep 2007 10:57:03 +0100
"H. Peter Anvin" <hpa@zytor.com> wrote:

>  From the looks of it, there is still a git-p4, it just moved to contrib 
> and uses fast-import, so removing its rpm package was probably broken in 
> the first place.

Hi Peter,

Items in contrib aren't officially supported, so it doesn't sound like
a good idea to offer installs for them.  Of course, it might be a good
idea to promote git-p4 up out of contrib and add it to the spec file.

As things stand now, do you get an error when trying to upgrade Git via
yum?   I'd have thought things would upgrade fine but leave the old git-p4
rpm hanging around.  Either way, the obsoletes line mentioned by David
sounds like the right solution.

As an aside, when I sent the patch removing git-p4import from the spec
file I mentioned that I had no way to test it and asked for testers.
Git needs a spec file maintainer so that issues like this can be caught
before release.  Without a maintainer, it should probably be demoted
to contrib itself.

Sean

Re: [ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

Sean <seanlkml@sympatico.ca> writes:

> On Sun, 02 Sep 2007 10:57:03 +0100
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>>  From the looks of it, there is still a git-p4, it just moved to contrib 
>> and uses fast-import, so removing its rpm package was probably broken in 
>> the first place.
> ...
> As an aside, when I sent the patch removing git-p4import from the spec
> file I mentioned that I had no way to test it and asked for testers.
> Git needs a spec file maintainer so that issues like this can be caught
> before release.  Without a maintainer, it should probably be demoted
> to contrib itself.

For majority of general public, I thought the spec file _I_
ship, along with RPM files _I_ build, are contrib status
already.  Don't distro people do their own RPM packages, instead
of using what I placed on k.org?

Assuming that we do not give the old git-p4import script
packaged in "git-p4 package", would the following patch be all
that is needed, or do we need other things in the spec file?

-- snipsnap clipcrap --

diff --git a/git.spec.in b/git.spec.in
index fe7b3d8..3d56e17 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -13,6 +13,7 @@ Source: 	http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
 BuildRequires:	zlib-devel >= 1.2, openssl-devel, curl-devel, expat-devel  %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 Requires:	git-core, git-svn, git-cvs, git-arch, git-email, gitk, git-gui, perl-Git
+Obsoletes:	git-p4
 
 %description
 Git is a fast, scalable, distributed revision control system with an

Re: [ANNOUNCE] GIT 1.5.3

[Sean]

On Sun, 02 Sep 2007 15:13:09 -0700
Junio C Hamano <gitster@pobox.com> wrote:

Hi Junio,

> For majority of general public, I thought the spec file _I_
> ship, along with RPM files _I_ build, are contrib status
> already.  Don't distro people do their own RPM packages, instead
> of using what I placed on k.org?

Didn't know you used RPM yourself, so I guess this is just
a case of something slipping through rather than the spec file
needing a maintainer.  Having said that, it seems odd that you
would say the spec file included with git is "contrib status
already".   How can something be contrib status unless it
is in the contrib directory of Git?
 
> Assuming that we do not give the old git-p4import script
> packaged in "git-p4 package", would the following patch be all
> that is needed, or do we need other things in the spec file?

Given the comment from David, I suspect your patch is all
that's needed; hopefully Peter can give it a quick test.

Sean

Re: [ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

Sean <seanlkml@sympatico.ca> writes:

> On Sun, 02 Sep 2007 15:13:09 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> For majority of general public, I thought the spec file _I_
>> ship, along with RPM files _I_ build, are contrib status
>> already.  Don't distro people do their own RPM packages, instead
>> of using what I placed on k.org?
>
> Didn't know you used RPM yourself, so I guess this is just
> a case of something slipping through rather than the spec file
> needing a maintainer.

Well, I do not _use_ it, but the RPM I have on k.org and mention
as part of the announcement are built by me by typing "make
rpm".  What I meant to say was that these RPM files may not be
"official" at all from the point of view of distro users, and I
suspect that distro "package maintainers" for git would not be
doing just a plain vanilla "make rpm" using the spec file that
comes as part of git.git repository.

Re: [ANNOUNCE] GIT 1.5.3

[H. Peter Anvin]

Sean wrote:
> On Sun, 02 Sep 2007 10:57:03 +0100
> "H. Peter Anvin" <hpa@zytor.com> wrote:
> 
>>  From the looks of it, there is still a git-p4, it just moved to contrib 
>> and uses fast-import, so removing its rpm package was probably broken in 
>> the first place.
> 
> Hi Peter,
> 
> Items in contrib aren't officially supported, so it doesn't sound like
> a good idea to offer installs for them.  Of course, it might be a good
> idea to promote git-p4 up out of contrib and add it to the spec file.

Well, the old one was out of contrib, too.  Maybe it should never have 
been packaged up, but it was...

> As things stand now, do you get an error when trying to upgrade Git via
> yum?   I'd have thought things would upgrade fine but leave the old git-p4
> rpm hanging around.  Either way, the obsoletes line mentioned by David
> sounds like the right solution.

Yes, it gets an error, because all the git RPMs are tied together by 
explicit version number and so can only be upgraded as a group.

> As an aside, when I sent the patch removing git-p4import from the spec
> file I mentioned that I had no way to test it and asked for testers.
> Git needs a spec file maintainer so that issues like this can be caught
> before release.  Without a maintainer, it should probably be demoted
> to contrib itself.

Well, git on kernel.org (and many other places) critically depends on 
rpms being available.

	-hpa

Re: [ANNOUNCE] GIT 1.5.3

[H. Peter Anvin]

Sean wrote:
> 
> Given the comment from David, I suspect your patch is all
> that's needed; hopefully Peter can give it a quick test.
> 

It sounds like it; I don't know how to test it other than placing in the 
repository and try to upgrade.  It can't be any worse, so I don't see 
any harm in just doing it.

	-hpa

Re: [ANNOUNCE] GIT 1.5.3

[Junio C Hamano]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Sean wrote:
>>
>> Given the comment from David, I suspect your patch is all
>> that's needed; hopefully Peter can give it a quick test.
>
> It sounds like it; I don't know how to test it other than placing in
> the repository and try to upgrade.  It can't be any worse, so I don't
> see any harm in just doing it.

Ok, should I then do that single change, cut 1.5.3.1 with it and
ping you?

Re: [ANNOUNCE] GIT 1.5.3

[H. Peter Anvin]

Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> Sean wrote:
>>> Given the comment from David, I suspect your patch is all
>>> that's needed; hopefully Peter can give it a quick test.
>> It sounds like it; I don't know how to test it other than placing in
>> the repository and try to upgrade.  It can't be any worse, so I don't
>> see any harm in just doing it.
> 
> Ok, should I then do that single change, cut 1.5.3.1 with it and
> ping you?

Sounds good to me.

	-hpa

Re: [ANNOUNCE] GIT 1.5.3

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> Assuming that we do not give the old git-p4import script
> packaged in "git-p4 package", would the following patch be all
> that is needed, or do we need other things in the spec file?
> 
> -- snipsnap clipcrap --
> +Obsoletes:	git-p4

That depends. If packages outside of git requires the git-p4 package to function
then this will not suffice and a line saying

	Provides: git-p4

would have to be added instead. If some other already installed package Require:'s
/usr/bin/git-p4import, then that other package is broken and we're toast.

I have a hard time seeing what other package would depend on the git-p4import
script so this was more along the lines of "how rpm dependencies work, kinda"
than a real issue.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231