* Re: [ANNOUNCE] GIT 1.5.3
From: David Kastrup @ 2007-09-02 8:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <46DA5F33.2020005@zytor.com>
"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
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-02 7:58 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git, linux-kernel
In-Reply-To: <46DA5F33.2020005@zytor.com>
"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?
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Junio C Hamano @ 2007-09-02 7:55 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git, Douglas Stockwell
In-Reply-To: <11887028854022-git-send-email-doug@11011.net>
Thanks for the patch. I think SMTP-AUTH is a worthy addition.
I however have a bit of reservation about making the password
itself a configuration variable. I understand this is good
enough for the simplest case that you have only single e-mail
identity and mailserver to talk to.
By defining the two "default" variables, you are encouraging
users who want to use different identity per project to define
the smtpauthuser and smtpauthpass variables in .git/config of
each repository. I see two issues with this.
(1) Suppose I interact with under one mail identity with
projects A and B and under another mail identity with
project C and D. I need to have duplicate variable
settings in .git/config of A and B for one and another
duplicated sets in C and D.
(2) Although the recommended BCP is not to allow other people
to interact with your private working repository (iow, you
keep a separate "bare" repository you use solely for
publishing, you push from your private working repository
to that publishing repository, and have others look at only
the publishing repository), people often do not follow this
BCP and expose their private working repository to their
colleages for fetching (or even pushing). We currently do
not allow reading remote repository's configuration over
the git protocol, but there were some cases in the past
that the ability to do so might lead to their solutions
discussed on the list. We might not keep .git/config in
the repository that is accessed by fetch clients private in
the future.
So it might be better to split the configuration variables in this
way:
(1) in ~/.gitconfig (that is hopefully readable only by the
user):
[sendemail "default"]
server = mail.isp.com
user = junkio
pass = junkio-password-for-mail-isp-com
[sendemail "git"]
server = mail.git.xz
user = gitster
pass = gitster-password-for-mail-git.xz
This defines two "mail identities" I could use, depending
on which project's repository I run send-email.
(2) in project/.git/config:
[sendemail]
identity = git
This defines which "mail identity" I want to use for this
particular project.
This way, you can maintain more than one identity by having
multiple [sendemail "$identity"] sections in ~/.gitconfig, and
avoid having to expose and duplicate user/pass in various
project's .git/config.
The look-up rules by send-email program would be:
* if anything is given explicitly from the command line, use
that; otherwise
* if sendemail.identity does not exist, pretend
"sendemail.identity = default" was given (let's call that
identity nickname $identity in the following);
* if sendemail.$identity.server.exists, use that as the smtp
server to contact; otherwise sendemail.smtpserver is used;
* for user/pass information, use sendemail.$identity.user and
sendemail.$identity.pass.
Hmm?
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: David Kastrup @ 2007-09-02 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <7vfy1xr1lz.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Just for the record: I believe that \{1,\} might be portable.
>
> Yeah, I obviously looked at the page I quoted that describes
> what's in and what's not in BRE definition ;-)
> As a maintainer of a public project I understand you have to deal
> with the current set of variations, and you might know better than
> me about the current portability situation.
Don't ask. That was what "just for the record" was about. In
practice, one uses the most simplistic expressions (and then some) and
prays, and your patches are quite in line with that.
Basically, one has to bear up under attack from two sides: the Windows
side with its idiosyncratic file names (and habitual spaces) under the
Cygwin and MSYS environments (which are quite Posix and GNU), and the
non-Posix madness from all sorts of Unices all across the utilities.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: David Kastrup @ 2007-09-02 7:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vodglr32i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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
> ========================
Initial info doc support might have been mentioned. While it is not
really something to write home about yet, the mention might draw
people willing to work on it, like providing indexing tags or muscling
AsciiDoc into including manpages in an appendix (both of which would
also benefit the Docbook output). Well, something for the 1.5.4
release announcement. Sorry for overlooking this before the actual
announcement.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Junio C Hamano @ 2007-09-02 7:02 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <85abs5v9q1.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Just for the record: I believe that \{1,\} might be portable.
Yeah, I obviously looked at the page I quoted that describes
what's in and what's not in BRE definition ;-)
But in practice, I do not recall ever seeing an older sed that
did not understand one-or-more \+ *and* understood \{1,\}. Do
you?
I had to deal with autoconf (hence various flavours of UNIX
implementations) in my previous life, but that was an ancient
history (back then the effect of SysV vs BSD war was still
felt). As a maintainer of a public project I understand you
have to deal with the current set of variations, and you might
know better than me about the current portability situation.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: H. Peter Anvin @ 2007-09-02 6:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vodglr32i.fsf@gitster.siamese.dyndns.org>
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
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: David Kastrup @ 2007-09-02 6:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <7vejhiu565.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This is a continuation of the other one to avoid one-or-more operator
> in sed. At the same time, it actually tightens error checking,
> because the numbers in the squash messages are not padded with
> leading zero and cannot begin with 0.
>
> With this, I think we do not have any more use of one-or-more
> (\+) in sed scripts.
Just for the record: I believe that \{1,\} might be portable.
As usual, <URL:info:autoconf#Limitations%20of%20Usual%20Tools> (aka as
(info "(autoconf) Limitations of Usual Tools")
) provides a real horror show of sed variants.
Actually, one can get the cursor right on the spot by typing
info autoconf (or the respective Emacs command C-h i g (autoconf))
i sed RET
There is something to be said for well-indexed documentation...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: problem with git cvsimport
From: Michael Haggerty @ 2007-09-02 6:37 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: git
In-Reply-To: <A74F186F-7C25-48D5-9354-C74576439AF1@gmail.com>
Jean-François Veillette wrote:
> I can't get git-cvsimport to convert a cvs project to git (full log
> bellow).
> I always get :
> fatal: Not a valid object name refs/heads/HEAD
> read-tree failed: 32768
>
> I'm a relatively new to git. I would like to convert my project and
> track external projects with git.
> But cvsimport seem to fail. Any pointer to help me resolve the issue is
> welcome !
I suggest you try the experimental support in cvs2svn for converting to
git. cvs2svn is very good about understanding strange CVS histories.
See the following thread for more information:
http://marc.info/?l=git&m=118592701426175&w=4
Michael
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2007-09-02 6:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vodglr32i.fsf@gitster.siamese.dyndns.org>
Now a new feature release is out, it's a good time to welcome new
people to the list. This message talks about how git.git is managed,
and how you can work with it.
* IRC and Mailing list
Many active members of development community hang around on #git
IRC channel on Freenode. Its log is available at:
http://colabti.de/irclogger/irclogger_log/git
The development however is primarily done on this mailing list
you are reading right now. If you have patches, please send
them to the list, following Documentation/SubmittingPatches.
I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use. But I am obviously not
perfect. If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.
The list archive is available at a few public sites as well:
http://marc.theaimsgroup.com/?l=git
http://news.gmane.org/gmane.comp.version-control.git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one.
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not
about the source tree of git: "todo", "html" and "man". The
first one was meant to contain TODO list for me, but I am not
good at maintaining such a list so it is not as often updated as
it could/should be. It also contains some helper scripts I use
to maintain git.
The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has
links to documentation of older releases.
The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested. It
is a good demonstration of how to use an update hook to automate
a task.
There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu". I may
add more maintenance branches (e.g. "maint-1.5.1") if we have
huge backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that himself.
The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting. There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major. Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The
last such release was v1.5.3 done on Sep 2nd this year. You
can expect that the tip of the "master" branch is always as
stable as any of the released versions, if not more stable.
Whenever a feature release is made, "maint" branch is forked off
from "master" at that point. Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it. The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was v1.5.2.5.
New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however. Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository. I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.
I judge the quality of topic branches, taking advices from the
mailing list discussions. Some of them start out as "good idea
but obviously is broken in some areas (e.g. breaks the existing
testsuite)" and then with some more work (either by the original
contributor or help from other people on the list) becomes "more
or less done and can now be tested by wider audience". Luckily,
most of them start out in the latter, better shape.
The "next" branch is to merge and test topic branches in the
latter category. In general, the branch always contains the tip
of "master". It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage. I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.
Note that being in "next" does not mean the change will be in
the next feature release.
The above three branches, "master", "maint" and "next" are never
rewound, so you should be able to safely track them (this
automatically means the topics that have been merged into "next"
are not rebased, and you can find the tip of topic branches you
are interested in from the output of "git log next").
The "pu" (proposed updates) branch bundles all the remainder of
topic branches. The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general. By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable). Similarly to the above, I
do it with this:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
However, being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), or even in any
future release. There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.
Starting from v1.5.0, "master" and "maint" have release notes
for the next release in Documentation/RelNotes-* files, so that
I do not have to run around summarizing what happened just
before the release.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines who your changes should
be sent to. As described in contrib/README, I would delegate
fixes and enhancements in contrib/ area to primary contributors
of them.
Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:
git-gui/ -- this subdirectory comes from Shawn Pearce's git-gui
project, which is found at:
git://repo.or.cz/git-gui.git
gitk -- this file is maintained by Paul Mackerras, at:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the
current shape. Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:
- Linus on general design issues.
- Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, and
Rene Scharfe on general implementation issues.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong on git-svn.
- Jakub Narebski, Petr Baudis, and Luben Tuikov on gitweb.
- J. Bruce Fields on documentaton issues.
- Johannes Schindelin and Johannes Sixt for their effort to
move things forward on the Windows front. Although my
repository does not have much from the effort of MinGW team,
I expect a merge into mainline will happen so that everybody
can work from the same codebase.
- People on non-Linux platforms for keeping their eyes on
portability; especially, Randal Schwartz, Theodore Ts'o,
Jason Riedy, Thomas Glanzmann, but countless others as well.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-02 6:31 UTC (permalink / raw)
To: git; +Cc: linux-kernel
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
^ permalink raw reply
* [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Douglas Stockwell @ 2007-09-02 3:14 UTC (permalink / raw)
To: git; +Cc: Douglas Stockwell
Allows username and password to be given using --smtp-authuser
and --smtp-authpass. SSL use is flagged by --smtp-ssl. These are
backed by corresponding defaults in the git configuration file.
Signed-off-by: Douglas Stockwell <doug@11011.net>
---
Documentation/git-send-email.txt | 21 +++++++++++++++-
git-send-email.perl | 50 ++++++++++++++++++++++++++++++-------
2 files changed, 60 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 8231286..471c268 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -79,6 +79,16 @@ The --cc option must be repeated for each user you want on the cc list.
`/usr/lib/sendmail` if such program is available, or
`localhost` otherwise.
+--smtp-authuser, --smtp-authpass::
+ Username and password for SMTP-AUTH. Defaults are the values of
+ the configuration values 'sendemail.smtpauthuser' and
+ 'sendemail.smtpauthpass'. If not set, authentication is not attempted.
+
+--smtp-ssl::
+ If set, connects to the SMTP server using SSL.
+ Default is the value of the 'sendemail.smtpssl' configuration value;
+ if that is unspecified, does not use SSL.
+
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
@@ -132,7 +142,16 @@ sendemail.chainreplyto::
parameter.
sendemail.smtpserver::
- Default smtp server to use.
+ Default SMTP server to use.
+
+sendemail.smtpauthuser::
+ Default SMTP-AUTH username.
+
+sendemail.smtpauthpass::
+ Default SMTP-AUTH password.
+
+sendemail.smtpssl::
+ Boolean value specifying the default to the '--smtp-ssl' parameter.
Author
------
diff --git a/git-send-email.perl b/git-send-email.perl
index f1a8855..38e8395 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -73,6 +73,12 @@ Options:
--smtp-server If set, specifies the outgoing SMTP server to use.
Defaults to localhost.
+ --smtp-authuser The username for SMTP-AUTH.
+
+ --smtp-authpass The password for SMTP-AUTH.
+
+ --smtp-ssl If set, connects to the SMTP server using SSL.
+
--suppress-from Suppress sending emails to yourself if your address
appears in a From: line. Defaults to off.
@@ -142,7 +148,6 @@ my $compose_filename = ".msg.$$";
my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
-my $smtp_server;
my $envelope_sender;
# Example reply to:
@@ -161,17 +166,34 @@ my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc);
+my ($smtp_server, $smtp_authuser, $smtp_authpass, $smtp_ssl);
-my %config_settings = (
+my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, 0],
"signedoffcc" => [\$signed_off_cc, 1],
+ "smtpssl" => [\$smtp_ssl, 0]
+);
+
+my %config_string_settings = (
+ "smtpserver" => [\$smtp_server, undef],
+ "smtpauthuser" => [\$smtp_authuser, undef],
+ "smtpauthpass" => [\$smtp_authpass, undef],
);
-foreach my $setting (keys %config_settings) {
+foreach my $setting (keys %config_bool_settings) {
my $config = $repo->config_bool("sendemail.$setting");
- ${$config_settings{$setting}->[0]} = (defined $config) ? $config : $config_settings{$setting}->[1];
+ ${$config_bool_settings{$setting}->[0]} = (defined $config)
+ ? $config
+ : $config_bool_settings{$setting}->[1];
+}
+
+foreach my $setting (keys %config_string_settings) {
+ my $config = $repo->config("sendemail.$setting");
+ ${$config_string_settings{$setting}->[0]} = (defined $config)
+ ? $config
+ : $config_string_settings{$setting}->[1];
}
@bcclist = $repo->config('sendemail.bcc');
@@ -190,6 +212,9 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"bcc=s" => \@bcclist,
"chain-reply-to!" => \$chain_reply_to,
"smtp-server=s" => \$smtp_server,
+ "smtp-authuser=s" => \$smtp_authuser,
+ "smtp-authpass=s" => \$smtp_authpass,
+ "smtp-ssl!" => \$smtp_ssl,
"compose" => \$compose,
"quiet" => \$quiet,
"suppress-from!" => \$suppress_from,
@@ -315,10 +340,7 @@ if ($thread && !defined $initial_reply_to && $prompting) {
$initial_reply_to =~ s/(^\s+|\s+$)//g;
}
-if (!$smtp_server) {
- $smtp_server = $repo->config('sendemail.smtpserver');
-}
-if (!$smtp_server) {
+if (!defined $smtp_server) {
foreach (qw( /usr/sbin/sendmail /usr/lib/sendmail )) {
if (-x $_) {
$smtp_server = $_;
@@ -548,8 +570,16 @@ X-Mailer: git-send-email $gitversion
print $sm "$header\n$message";
close $sm or die $?;
} else {
- require Net::SMTP;
- $smtp ||= Net::SMTP->new( $smtp_server );
+ if ($smtp_ssl) {
+ require Net::SMTP::SSL;
+ $smtp ||= Net::SMTP::SSL->new( $smtp_server, Port => 465 );
+ }
+ else {
+ require Net::SMTP;
+ $smtp ||= Net::SMTP->new( $smtp_server );
+ }
+ $smtp->auth( $smtp_authuser, $smtp_authpass )
+ or die $smtp->message if (defined $smtp_authuser);
$smtp->mail( $raw_from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
$smtp->data or die $smtp->message;
--
1.5.3.rc7.17.gd77cc
^ permalink raw reply related
* Re: git-gui i18n status?
From: Shawn O. Pearce @ 2007-09-02 2:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Christian Stimming, Miklos Vajna, Nanako Shiraishi,
Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Junio C Hamano, Irina Riesen, git
In-Reply-To: <20070902014242.GJ18160@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hmm. I am not enough involved in i18n stuff to form a proper opinion
> > here... Do you suggest to move the initialisation earlier?
>
> Yea, I think that's what we are going to have to do here. If we don't
> setup the directory for the .msg files early enough than we cannot do
> translations through [mc]. Unfortunately that means we have to also
> break up the library initialization.
>
> I'll try to work up a patch that does this.
This two patch series is based on my current master (gitgui-0.8.2).
Its also now in my pu branch.
>From fc703c209d415fe20ad5551465b5b68b8ab8b046 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Sat, 1 Sep 2007 21:58:29 -0400
Subject: [PATCH] git-gui: Locate the library directory early during startup
To support a localized version of git-gui we need to locate the
library directory early so we can initialize Tcl's msgcat package
to load translated messages from. This needs to occur before we
declare our git-version proc so that errors related to locating
git or assessing its version can be reported to the end-user in
their preferred language. However we have to keep the library
loading until after git-version has been declared, otherwise we
will fail to start git-gui if we are using a fake tclIndex that
was generated by our Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 25 +++++++++++++++----------
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index fa30ccc..4ea6e91 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -44,6 +44,20 @@ if {[catch {package require Tcl 8.4} err]
######################################################################
##
+## locate our library
+
+set oguilib {@@GITGUI_LIBDIR@@}
+set oguirel {@@GITGUI_RELATIVE@@}
+if {$oguirel eq {1}} {
+ set oguilib [file dirname [file dirname [file normalize $argv0]]]
+ set oguilib [file join $oguilib share git-gui lib]
+} elseif {[string match @@* $oguirel]} {
+ set oguilib [file join [file dirname [file normalize $argv0]] lib]
+}
+unset oguirel
+
+######################################################################
+##
## enable verbose loading?
if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
@@ -595,15 +609,6 @@ You are using [git-version]:
##
## configure our library
-set oguilib {@@GITGUI_LIBDIR@@}
-set oguirel {@@GITGUI_RELATIVE@@}
-if {$oguirel eq {1}} {
- set oguilib [file dirname [file dirname [file normalize $argv0]]]
- set oguilib [file join $oguilib share git-gui lib]
-} elseif {[string match @@* $oguirel]} {
- set oguilib [file join [file dirname [file normalize $argv0]] lib]
-}
-
set idx [file join $oguilib tclIndex]
if {[catch {set fd [open $idx r]} err]} {
catch {wm withdraw .}
@@ -637,7 +642,7 @@ if {$idx ne {}} {
} else {
set auto_path [concat [list $oguilib] $auto_path]
}
-unset -nocomplain oguirel idx fd
+unset -nocomplain idx fd
######################################################################
##
--
1.5.3.rc7.30.g947ad2
>From d4b0ccd931cc29f35e8f8493445af27ea72ed03e Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Sat, 1 Sep 2007 22:22:42 -0400
Subject: [PATCH] git-gui: Initialize Tcl's msgcat library for internationalization
Tcl's msgcat library and corresponding mc procedure can locate a
translated string for any user message, provided that it is first
given a directory where the *.msg files are located containing the
translations.
During installation we will place the translations in lib/msgs/,
so we need to inform msgcat of this location once we determine it
during startup. Our source code tree however will store all of
the translations within the po/ directory, so we need to special
case this variant.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 4ea6e91..486d36e 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -51,8 +51,12 @@ set oguirel {@@GITGUI_RELATIVE@@}
if {$oguirel eq {1}} {
set oguilib [file dirname [file dirname [file normalize $argv0]]]
set oguilib [file join $oguilib share git-gui lib]
+ set oguimsg [file join $oguilib msgs]
} elseif {[string match @@* $oguirel]} {
set oguilib [file join [file dirname [file normalize $argv0]] lib]
+ set oguimsg [file join [file dirname [file normalize $argv0]] po]
+} else {
+ set oguimsg [file join $oguilib msgs]
}
unset oguirel
@@ -76,6 +80,16 @@ if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
######################################################################
##
+## Internationalization (i18n) through msgcat and gettext. See
+## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
+
+package require msgcat
+namespace import ::msgcat::mc
+::msgcat::mcload $oguimsg
+unset oguimsg
+
+######################################################################
+##
## read only globals
set _appname [lindex [file split $argv0] end]
--
1.5.3.rc7.30.g947ad2
--
Shawn.
^ permalink raw reply related
* Re: git-gui i18n status?
From: Shawn O. Pearce @ 2007-09-02 1:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Christian Stimming, Miklos Vajna, Nanako Shiraishi,
Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Junio C Hamano, Irina Riesen, git
In-Reply-To: <Pine.LNX.4.64.0709020003480.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> > Looking at the repository on repo.or.cz it looks like it needs to be
> > merged/rebased onto 0.8.2. There is a trivial merge conflict, but there
> > are some more subtle ones caused by the movement of the library
> > directory initialization down lower in git-gui.sh. For example
> > translations won't be initialized if we have an issue with the output of
> > git-version and want to prompt the user.
>
> Hmm. I am not enough involved in i18n stuff to form a proper opinion
> here... Do you suggest to move the initialisation earlier?
Yea, I think that's what we are going to have to do here. If we don't
setup the directory for the .msg files early enough than we cannot do
translations through [mc]. Unfortunately that means we have to also
break up the library initialization.
I'll try to work up a patch that does this.
> > What is the current plan? Should I be looking at the master branch of
> > git://repo.or.cz/git-gui/git-gui-i18n.git for pulling? Or are folks
> > expecting that this series will be cleaned up before I pull it?
>
> My plan is to put out a cleaned up patch series:
...
> All these patches will go through the mailing list, so that people can
> comment and suggest improvements.
OK, that works well for me. Nice clean series to apply.
> I'll also try to bug Christian into looking through the output of
>
> git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
>
> to make sure that we did not forget a string. ATM the output consists of
> 300+ lines, so it is a bit boring. Maybe I can improve that command,
> too...
Some of these are internal errors that should never be presented to
an end-user, and some are for reflog entries. Here's a quick run
through of these:
D == internal error message (developer only)
R == reflog message
T == probably should be translated
D "Invalid arguments to git-version",
D "Last arm of $type $name must be default",
D "git-version >= x",
T "git-gui: fatal error",
T "Cannot move to top of working directory:\n\n$err",
D "error: no icon for $w state={$state} $path",
D "error: no desc for state={$state} $path",
T "Unstaging [short_path $path] from commit",
T "Adding [short_path $path]",
T "fatal: cannot stat path $path: No such file or directory",
T "Possible environment issues exist.[...]",
T "Loading$cur_s annotations...",
T "Loading annotation...",
T "Author:\t",
T "Committer:\t",
T "Original File:\t",
T "Originally By:\n",
T "In File: ",
T "Copied Or Moved Here By:\n",
T "fatal: Cannot resolve $l_trck",
R "branch: Created from $new_expr",
R "merge $new_expr: Fast-forward",
T "Updating working directory to '[_name $this]'...",
T "Checked out '$name'.",
D "class $class already declared",
D "wrong # args: field name value?",
D "class $class is sealed (cannot add new fields)",
D "field $name already declared",
D "wrong # args: method name args body (ifdeleted body)?",
D "make_toplevel topvar winvar {options}",
D "unsupported option $name",
T "Commit $PARENT appears to be corrupt",
T "warning: Tcl does not support encoding '$enc'.",
T "This repository currently has approximately [...]",
T "Loading diff of [escape_path $path]...",
T "Unable to display [escape_path $path]",
T "* Binary file (not showing content).",
T "Unable to display [escape_path $path]",
D "error: Unhandled 3 way diff marker: {$op}",
D "error: Unhandled 2 way diff marker: {$op}",
T "Unstaging [short_path $current_diff_path] from commit",
T "Adding [short_path $current_diff_path]", and
T "The following branches are not completely merged into [...]",
Messages that I marked as 'D' shouldn't ever be shown to an end-user
as they represent a Tcl error from incorrect usage of an internal
function. Translating these is fine but since it should never
appear unless there is a serious bug in git-gui its probably not
worth the translation effort.
Messages marked as 'R' appear in the reflog for the corresponding
branch, etc. These are not currently translated by core Git so I
am not sure if we should translate them in git-gui.
Messages marked as 'T' above are most definately shown to
the end-user and should be translated, or at least offered for
translation. I realize some terms have been kept in their English
form even after translation as there isn't a good way to translate
them into every language.
--
Shawn.
^ permalink raw reply
* Re: git-gui i18n status?
From: Junio C Hamano @ 2007-09-02 1:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Christian Stimming, Miklos Vajna,
Nanako Shiraishi, Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Irina Riesen, git
In-Reply-To: <Pine.LNX.4.64.0709020003480.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Then I'd like to prepare consolidated patches for the individual
> languages, attributed to the author where unique, and to Nanako for
> Japanese (mentioning help from Junio), and to Paolo (mentioning help from
> Michele).
>
> Junio, Michele, is that attribution enough for you?
I am just one of those with cheap talk -- no objection from me.
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Shawn O. Pearce @ 2007-09-02 0:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Robin Rosenberg, git
In-Reply-To: <Pine.LNX.4.64.0709020133540.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> > Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > I might be in the middle of resolving a conflicted "git am".
> >
> > And there's no way to tell the difference either.
>
> AFAICT git-am creates an "info" file in .dotest/.
But git-rebase without -m and -i is defined as format-patch|am.
So when rebasing it looks identical to git-am. Hence no way to
tell the difference between the two.
I think post 1.5.3 one of the things we should work on is trying
to better track our current operation state. Most of that would
be to refactor how we track state in things like rebase/am/merge.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Johannes Schindelin @ 2007-09-02 0:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Robin Rosenberg, git
In-Reply-To: <20070901222036.GH18160@spearce.org>
Hi,
On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> > >
> > > + local g="$(git rev-parse --git-dir 2>/dev/null)"
> > > + if [ -n "$g" ]; then
> > > + local r
> > > + local b
> > > + if [ -d "$g/../.dotest" ]
> > > + then
> > > + local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > > + r="|REBASEING"
> >
> > I might be in the middle of resolving a conflicted "git am".
>
> And there's no way to tell the difference either.
AFAICT git-am creates an "info" file in .dotest/.
And interactive rebase is detectable by the "interactive" file in
.git/.dotest-merge/.
Ciao,
Dscho
^ permalink raw reply
* Re: git: cannot rename foo to Foo on a case-insensitive filesystem (e.g. on Windows)
From: Nix @ 2007-09-02 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Reece Dunn, Andreas Ericsson, git
In-Reply-To: <alpine.LFD.0.999.0708281555580.25853@woody.linux-foundation.org>
On 29 Aug 2007, Linus Torvalds verbalised:
> And if you use that algorithm, them 'ß' and 'ss' are equal in a
> case-insensitive filesystem.
>
> Does anybody do that? I don't know. But I sure as hell wouldn't be
> surprised.
Oh yes, they do. Guess what I spent the last month fixing in a huge heap
of proprietary software. Of course the problem is not truly fixable
because of the potentially unbounded set of context-dependent stuff such
as `Masse'.
(I hear some people got a summer holiday...)
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Robin Rosenberg @ 2007-09-01 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: spearce, git
In-Reply-To: <7vir6us1ia.fsf@gitster.siamese.dyndns.org>
lördag 01 september 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 5ed1821..1fef857 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -64,12 +64,34 @@ __gitdir ()
> >
> > __git_ps1 ()
> > {
> > - local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > - if [ -n "$b" ]; then
> > + local g="$(git rev-parse --git-dir 2>/dev/null)"
> > + if [ -n "$g" ]; then
> > + local r
> > + local b
> > + if [ -d "$g/../.dotest" ]
> > + then
> > + local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > + r="|REBASEING"
>
> I might be in the middle of resolving a conflicted "git am".
>
> But I love the idea. We need to think about cleaning up our
> "state machine" mechanism to make this kind of thing easier to
> do. We've had a few suggestions on the list in the past but
> they never passed the suggestion/speculation stage.
I'd love to see that. The Eclipse plugin needs to know about such things
in order to prevent the user from making errors he wouldn't like to do. We do
commit and checkouts without looking for these states now. Not too good.
The downside of improving the state machine is that we'll have to detect
the old AND the new states.
Here's an ever better version which handles bisect and detached heads.
-- robin
From e5b2b9833786f13d729b7fead74297580b03f775 Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Sat, 1 Sep 2007 12:20:48 +0200
Subject: [PATCH] Improve bash prompt to detect various states like an unfinished merge
This patch makes the git prompt (when enabled) show if a merge or a
rebase is unfinished. It also detects if a bisect is being done as
well as detached checkouts.
An uncompleted git-am cannot be distinguised from a rebase (the
non-interactive version). Instead of having an even longer prompt
we simply ignore that and hope the power users that use git-am knows
the difference.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/completion/git-completion.bash | 37 ++++++++++++++++++++++++++++---
1 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5ed1821..048a715 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -64,12 +64,41 @@ __gitdir ()
__git_ps1 ()
{
- local b="$(git symbolic-ref HEAD 2>/dev/null)"
- if [ -n "$b" ]; then
+ local g="$(git rev-parse --git-dir 2>/dev/null)"
+ if [ -n "$g" ]; then
+ local r
+ local b
+ if [ -d "$g/../.dotest" ]
+ then
+ local b="$(git symbolic-ref HEAD 2>/dev/null)"
+ r="|REBASING"
+ else
+ if [ -d "$g/.dotest-merge" ]
+ then
+ r="|REBASING"
+ b="$(cat $g/.dotest-merge/head-name)"
+ else
+ if [ -f "$g/MERGE_HEAD" ]
+ then
+ r="|MERGING"
+ b="$(git symbolic-ref HEAD 2>/dev/null)"
+ else
+ if [ -f $g/BISECT_LOG ]
+ then
+ r="|BISECTING"
+ fi
+ if ! b="$(git symbolic-ref HEAD 2>/dev/null)"
+ then
+ b="$(cut -c1-7 $g/HEAD)..."
+ fi
+ fi
+ fi
+ fi
+
if [ -n "$1" ]; then
- printf "$1" "${b##refs/heads/}"
+ printf "$1" "${b##refs/heads/}$r"
else
- printf " (%s)" "${b##refs/heads/}"
+ printf " (%s)" "${b##refs/heads/}$r"
fi
fi
}
--
1.5.3.rc7.844.gfd3c5
^ permalink raw reply related
* Re: git-gui i18n status?
From: Johannes Schindelin @ 2007-09-01 23:42 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Christian Stimming, Miklos Vajna, Nanako Shiraishi,
Michele Ballabio, Paolo Ciarrocchi, Xudong Guan,
Harri Ilari Tapio Liusvaara, Junio C Hamano, Irina Riesen, git
In-Reply-To: <20070901042924.GE18160@spearce.org>
Hi,
[Cc'ed all contributors. I mean, the real contributors, not just those
with cheap talk ;-)]
On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> Now that git-gui 0.8.2 is out and git 1.5.3 is just around the corner I
> am starting to think about bringing the git-gui i18n work into the main
> git-gui tree, so we can start working from a common codebase.
Yes.
> Looking at the repository on repo.or.cz it looks like it needs to be
> merged/rebased onto 0.8.2. There is a trivial merge conflict, but there
> are some more subtle ones caused by the movement of the library
> directory initialization down lower in git-gui.sh. For example
> translations won't be initialized if we have an issue with the output of
> git-version and want to prompt the user.
Hmm. I am not enough involved in i18n stuff to form a proper opinion
here... Do you suggest to move the initialisation earlier?
> What is the current plan? Should I be looking at the master branch of
> git://repo.or.cz/git-gui/git-gui-i18n.git for pulling? Or are folks
> expecting that this series will be cleaned up before I pull it?
My plan is to put out a cleaned up patch series:
- Christian's patches, consolidated, to
- Makefile rules for translation
- Infrastructure in the source (basically adding [mc ...]
everywhere, and initialising msgcat)
- po/git-gui.pot
- glossary
Then I'd like to prepare consolidated patches for the individual
languages, attributed to the author where unique, and to Nanako for
Japanese (mentioning help from Junio), and to Paolo (mentioning help from
Michele).
Junio, Michele, is that attribution enough for you?
All these patches will go through the mailing list, so that people can
comment and suggest improvements.
I'll also try to bug Christian into looking through the output of
git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
to make sure that we did not forget a string. ATM the output consists of
300+ lines, so it is a bit boring. Maybe I can improve that command,
too...
(I see
"Invalid arguments to git-version",
"Last arm of $type $name must be default",
"git-version >= x", "git-gui: fatal error",
"Cannot move to top of working directory:\n\n$err",
"error: no icon for $w state={$state} $path",
"error: no desc for state={$state} $path",
"Unstaging [short_path $path] from commit",
"Adding [short_path $path]",
"fatal: cannot stat path $path: No such file or directory",
"Possible environment issues exist.[...]",
"Loading$cur_s annotations...",
"Loading annotation...",
"Author:\t",
"Committer:\t",
"Original File:\t",
"Originally By:\n",
"In File: ",
"Copied Or Moved Here By:\n",
"fatal: Cannot resolve $l_trck",
"branch: Created from $new_expr",
"merge $new_expr: Fast-forward",
"Updating working directory to '[_name $this]'...",
"Checked out '$name'.",
"class $class already declared",
"wrong # args: field name value?",
"class $class is sealed (cannot add new fields)",
"field $name already declared",
"wrong # args: method name args body (ifdeleted body)?",
"make_toplevel topvar winvar {options}",
"unsupported option $name",
"Commit $PARENT appears to be corrupt",
"warning: Tcl does not support encoding '$enc'.",
"This repository currently has approximately [...]",
"Loading diff of [escape_path $path]...",
"Unable to display [escape_path $path]",
"* Binary file (not showing content).",
"Unable to display [escape_path $path]",
"error: Unhandled 3 way diff marker: {$op}",
"error: Unhandled 2 way diff marker: {$op}",
"Unstaging [short_path $current_diff_path] from commit",
"Adding [short_path $current_diff_path]", and
"The following branches are not completely merged into [...]",
but I could have missed some, and it is possible some do not need [mc
...].)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Johannes Schindelin @ 2007-09-01 23:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, spearce, git
In-Reply-To: <7vir6us1ia.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 1 Sep 2007, Junio C Hamano wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > index 5ed1821..1fef857 100755
> > --- a/contrib/completion/git-completion.bash
> > +++ b/contrib/completion/git-completion.bash
> > @@ -64,12 +64,34 @@ __gitdir ()
> >
> > __git_ps1 ()
> > {
> > - local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > - if [ -n "$b" ]; then
> > + local g="$(git rev-parse --git-dir 2>/dev/null)"
> > + if [ -n "$g" ]; then
> > + local r
> > + local b
> > + if [ -d "$g/../.dotest" ]
> > + then
> > + local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > + r="|REBASEING"
>
> I might be in the middle of resolving a conflicted "git am".
>
> But I love the idea. We need to think about cleaning up our
> "state machine" mechanism to make this kind of thing easier to
> do. We've had a few suggestions on the list in the past but
> they never passed the suggestion/speculation stage.
Like your git-explain?
I actually liked the idea. Maybe we can get more people interested on
that thing post 1.5.3...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase--interactive: do not use one-or-more (\+) in sed.
From: Johannes Schindelin @ 2007-09-01 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vejhiu565.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Sat, 1 Sep 2007, Junio C Hamano wrote:
> This is a continuation of the other one to avoid one-or-more operator
> in sed. At the same time, it actually tightens error checking,
> because the numbers in the squash messages are not padded with
> leading zero and cannot begin with 0.
>
> With this, I think we do not have any more use of one-or-more
> (\+) in sed scripts.
>
> ---
>
> git-rebase--interactive.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index ec798a1..abc2b1c 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -190,7 +190,7 @@ nth_string () {
>
> make_squash_message () {
> if test -f "$SQUASH_MSG"; then
> - COUNT=$(($(sed -n "s/^# This is [^0-9]*\([0-9]\+\).*/\1/p" \
> + COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
Looks obviously correct to me... Ack.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improve bash prompt to detect merge / rebase in progress
From: Shawn O. Pearce @ 2007-09-01 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
In-Reply-To: <7vir6us1ia.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> >
> > + local g="$(git rev-parse --git-dir 2>/dev/null)"
> > + if [ -n "$g" ]; then
> > + local r
> > + local b
> > + if [ -d "$g/../.dotest" ]
> > + then
> > + local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > + r="|REBASEING"
>
> I might be in the middle of resolving a conflicted "git am".
And there's no way to tell the difference either. I just spent a
few minutes digging around git-am and git-rebase and realized there
really isn't a way to tell these two user level commands apart as
git-rebase (by default) calls git-am and there's no marker to say
it was started by rebase.
But more than that I have to wonder why git-am still uses .dotest
in the working directory for its state management. Why don't we
move it into $GIT_DIR like we do for `rebase -m`?
> But I love the idea. We need to think about cleaning up our
> "state machine" mechanism to make this kind of thing easier to
> do. We've had a few suggestions on the list in the past but
> they never passed the suggestion/speculation stage.
I love the idea too. I've actually walked away from a rebase -i and
come back the following day and forgotten that I was in the middle
of a rebase and just thought I was sitting on a detached checkout.
Really confused me for a few minutes when code I was looking for
wasn't found (it was still pending to be applied by rebase -i).
--
Shawn.
^ permalink raw reply
* Re: performance on repack
From: Jon Smirl @ 2007-09-01 21:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn O. Pearce, Martin Koegler, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0708300033540.16727@xanadu.home>
On 8/30/07, Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 30 Aug 2007, Nicolas Pitre wrote:
>
> > Well, here is a quick implementation of this idea for those who would
> > like to give it a try.
> [...]
Appears to be broken for a push.
jonsmirl@terra:~/mpc5200b$ git push dreamhost
updating 'refs/remotes/linus/master' using 'refs/heads/master'
from d1caeb02b17c6bc215a9a40a98a1beb92dcbd310
to 40ffbfad6bb79a99cc7627bdaca0ee22dec526f6
Generating pack...
Counting objects: 1
Done counting 3255 objects.
Result has 1997 objects.
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
Deltifying 398 objects...
0% (2/398) donee
1% (4/398) donee
11% (47/398) done
3% (12/398) done
2% (8/398) donee
12% (49/398) done
17% (69/398) done
1% (4/398) donee
25% (100/398) done
19% (77/398) donee
23% (94/398) done
21% (84/398) done
25% (100/398) done
2% (10/398) done
1% (6/398) done
error: pack-objects died with strange error
unpack eof before pack header was fully read
ng refs/remotes/linus/master n/a (unpacker error)
error: failed to push to 'ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git'
jonsmirl@terra:~/mpc5200b$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Jari Aalto @ 2007-09-01 20:40 UTC (permalink / raw)
To: git
In-Reply-To: <20070901150153.GD7422@mediacenter.austin.rr.com>
Shawn Bohrer <shawn.bohrer@gmail.com> writes:
> On Sat, Sep 01, 2007 at 02:40:22AM -0700, Junio C Hamano wrote:
>
>> Jari Aalto <jari.aalto@cante.net> writes:
>>
>> > Like:
>> >
>> > HEAD, HEAD~1, HEAD~2
>> >
>> > If the syntax is changed in the middle (as it was in manual page),
>> > that interrupts the kognitive flow of reading.
>> >
>> > HEAD, HEAD^, HEAD~2
>> >
>>
>> I still would prefer to teach people HEAD^ earlier. If you _REALLY_
>> insist, I can live with spelling the HEAD~2 as HEAD^^ for
>> consistency.
>
> Well I am a new user to git and I didn't find the mixed notation
> confusing at all. Perhaps this is because I read the tutorial first,
> then the git user manual which both explain this clearly.
Naturally one's learning path is naturally different. Did you come
from other SCM/VCS before intorduced to git?
> In either case I think eliminating either notation from the man pages is
> a bad idea.
That was not proposed. There a mnay pages that use and shoudl use the
^ notations. I was proposing that only (git-COMMAND) were dealt with.
After all, the ^ very differento to what other SCM/VCSs use.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ 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