The latest maintenance release GIT 1.5.0.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.0.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.2.tar.{gz,bz2}
: it is i18n.commitencoding not core.commitencoding
Junio C Hamano (15):
Documentation: Drop full-stop from git-fast-import title.
cmd-list: add git-remote
Makefile: update check-docs target
Clarify two backward incompatible repository options.
Still updating 1.5.0
: it is i18n.commitencoding not core.commitencoding
Junio C Hamano (15):
Documentation: Drop full-stop from git-fast-import title.
cmd-list: add git-remote
Makefile: update check-docs target
Clarify two backward incompatible repository options.
Still updating 1.5.0
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Andy Parkins <[EMAIL PROTECTED]> writes:
>
>> On Wednesday 2007 February 14 03:14, Junio C Hamano wrote:
>>
>>> - There is a configuration variable core.legacyheaders that
>>
>>> The above
Andy Parkins <[EMAIL PROTECTED]> writes:
> On Wednesday 2007 February 14 03:14, Junio C Hamano wrote:
>
>> - There is a configuration variable core.legacyheaders that
>
>> The above two are not enabled by default and you explicitly have
>> to ask for them
Andy Parkins [EMAIL PROTECTED] writes:
On Wednesday 2007 February 14 03:14, Junio C Hamano wrote:
- There is a configuration variable core.legacyheaders that
The above two are not enabled by default and you explicitly have
to ask for them, because these two features make repositories
Junio C Hamano [EMAIL PROTECTED] writes:
Andy Parkins [EMAIL PROTECTED] writes:
On Wednesday 2007 February 14 03:14, Junio C Hamano wrote:
- There is a configuration variable core.legacyheaders that
The above two are not enabled by default and you explicitly have
to ask for them, because
The latest feature release GIT 1.5.0 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.0.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.tar.{gz,bz2}
The latest feature release GIT 1.5.0 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.0.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.0.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.0.tar.{gz,bz2}
Jeff Garzik <[EMAIL PROTECTED]> writes:
> mode change 100644 => 100755 drivers/net/qla3xxx.c
> mode change 100644 => 100755 drivers/net/qla3xxx.h
Did you mean to have these? Commit bd36b0ac appears to have
brought the mode bits change in.
Not trying to nitpick --- I am trying to find out if
Jeff Garzik [EMAIL PROTECTED] writes:
mode change 100644 = 100755 drivers/net/qla3xxx.c
mode change 100644 = 100755 drivers/net/qla3xxx.h
Did you mean to have these? Commit bd36b0ac appears to have
brought the mode bits change in.
Not trying to nitpick --- I am trying to find out if this
annes Schindelin (2):
annotate: use pager
reflog inspection: introduce shortcut "-g"
Johannes Sixt (1):
Add a missing fork() error check.
Junio C Hamano (43):
User manual: fix typos in examples
Documentation/tutorial-2: Fix interesting typo in an example.
Revert "prune: --gra
: introduce shortcut -g
Johannes Sixt (1):
Add a missing fork() error check.
Junio C Hamano (43):
User manual: fix typos in examples
Documentation/tutorial-2: Fix interesting typo in an example.
Revert prune: --grace=time
Make sure git_connect() always give two file descriptors
Thanks for your comments; the attached probably needs
proofreading.
The changes in response to the remainder of your comments are
quite straightforward and I do not think needs proofreading, so
I'll incorporate them and push the result out in 'todo'.
diff --git a/v1.5.0.txt b/v1.5.0.txt
index
Thanks for your comments; the attached probably needs
proofreading.
The changes in response to the remainder of your comments are
quite straightforward and I do not think needs proofreading, so
I'll incorporate them and push the result out in 'todo'.
diff --git a/v1.5.0.txt b/v1.5.0.txt
index
"Horst H. von Brand" <[EMAIL PROTECTED]> writes:
> Junio C Hamano <[EMAIL PROTECTED]> wrote:
>> Willy Tarreau <[EMAIL PROTECTED]> writes:
>> > Anything you can do to make tester's life easier will always slightly
>> > increase the numbe
Willy Tarreau <[EMAIL PROTECTED]> writes:
> Anything you can do to make tester's life easier will always slightly
> increase the number of testers.
> ...
> Pre-release tar.gz and rpms coupled with a freshmeat announcement should
> get you a bunch of testers and newcomers. This will give the new
BTW, as the upcoming v1.5.0 release will introduce quite a bit of
surface changes (although at the really core it still is the old
git and old ways should continue to work), I am wondering if it
would help people to try out and find wrinkles before the real
thing for me to cut a tarball and a set
--walk-reflogs: actually find the right commit by date.
--walk-reflogs: do not crash with cyclic reflog ancestry
Junio C Hamano (69):
reflog-expire: brown paper bag fix.
merge-recursive: do not report the resulting tree object name
Explain "Not a git repository: '.git'&q
: actually find the right commit by date.
--walk-reflogs: do not crash with cyclic reflog ancestry
Junio C Hamano (69):
reflog-expire: brown paper bag fix.
merge-recursive: do not report the resulting tree object name
Explain Not a git repository: '.git'.
glossary
BTW, as the upcoming v1.5.0 release will introduce quite a bit of
surface changes (although at the really core it still is the old
git and old ways should continue to work), I am wondering if it
would help people to try out and find wrinkles before the real
thing for me to cut a tarball and a set
Willy Tarreau [EMAIL PROTECTED] writes:
Anything you can do to make tester's life easier will always slightly
increase the number of testers.
...
Pre-release tar.gz and rpms coupled with a freshmeat announcement should
get you a bunch of testers and newcomers. This will give the new doc a
Horst H. von Brand [EMAIL PROTECTED] writes:
Junio C Hamano [EMAIL PROTECTED] wrote:
Willy Tarreau [EMAIL PROTECTED] writes:
Anything you can do to make tester's life easier will always slightly
increase the number of testers.
...
Pre-release tar.gz and rpms coupled with a freshmeat
):
Speed-up recursive by flushing index only once for all entries
Eric Wong (1):
Avoid errors and warnings when attempting to do I/O on zero bytes
Johannes Schindelin (2):
Sanitize for_each_reflog_ent()
Fix t1410 for core.filemode==false
Junio C Hamano (20
):
Speed-up recursive by flushing index only once for all entries
Eric Wong (1):
Avoid errors and warnings when attempting to do I/O on zero bytes
Johannes Schindelin (2):
Sanitize for_each_reflog_ent()
Fix t1410 for core.filemode==false
Junio C Hamano (20
are as follows:
Johannes Schindelin (1):
diff --check: fix off by one error
Junio C Hamano (3):
spurious .sp in manpages
Fix infinite loop when deleting multiple packed refs.
pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
-
To unsubscribe from
are as follows:
Johannes Schindelin (1):
diff --check: fix off by one error
Junio C Hamano (3):
spurious .sp in manpages
Fix infinite loop when deleting multiple packed refs.
pack-check.c::verify_packfile(): don't run SHA-1 update on huge data
-
To unsubscribe from
test for git-rerere
Make git-rerere a builtin
commit-tree: encourage UTF-8 commit messages.
Junio C Hamano (19):
git-add --interactive
git-add --interactive: hunk splitting
revision: --skip=
merge and reset: adjust for "reset --hard" messages
Make git-rerere a builtin
commit-tree: encourage UTF-8 commit messages.
Junio C Hamano (19):
git-add --interactive
git-add --interactive: hunk splitting
revision: --skip=n
merge and reset: adjust for reset --hard messages
default pull: forget about newbie
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
> curses.h. However, I don't see how that's relevant to strings.h
> or the others I need. There's no "config" for "compatibility".
> Welcome to Linux vs Unix. :)
>
> What I do
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Lemme see if it breaks on OpenBSD as well.
>
> Oddly enough - it didn't. :)
Of course it didn't. I was a bit more careful than usual with
this and fired up an OpenBSD bochs on my wife's machine to test
it before pushing out.
> running "git
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Nope... can't compile:
> ...
> daemon.c:970: warning: implicit declaration of function 'initgroups'
> make: *** [daemon.o] Error 1
>
> This smells like we've seen this before. Regression introduced with
> some of the cleanup?
Most
ic Wong (2):
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
Jim Meyering (1):
Don't use memcpy when source and dest. buffers may overlap
Junio C Hamano (1):
GIT 1.4.4.3
Martin Langhoff (1):
cvsserver: Avoid miscoun
):
git-svn: exit with status 1 for test failures
git-svn: correctly display fatal() error messages
Jim Meyering (1):
Don't use memcpy when source and dest. buffers may overlap
Junio C Hamano (1):
GIT 1.4.4.3
Martin Langhoff (1):
cvsserver: Avoid miscounting bytes
merlyn@stonehenge.com (Randal L. Schwartz) writes:
Nope... can't compile:
...
daemon.c:970: warning: implicit declaration of function 'initgroups'
make: *** [daemon.o] Error 1
This smells like we've seen this before. Regression introduced with
some of the cleanup?
Most likely.
merlyn@stonehenge.com (Randal L. Schwartz) writes:
Lemme see if it breaks on OpenBSD as well.
Oddly enough - it didn't. :)
Of course it didn't. I was a bit more careful than usual with
this and fired up an OpenBSD bochs on my wife's machine to test
it before pushing out.
running git
merlyn@stonehenge.com (Randal L. Schwartz) writes:
But yes, _XOPEN_SOURCE_EXTENDED definitely does some damage to
curses.h. However, I don't see how that's relevant to strings.h
or the others I need. There's no config for compatibility.
Welcome to Linux vs Unix. :)
What I do know is (a)
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Linus Torvalds writes:
>
>> Why do people think that using "ln" is _any_ different from using
>> "mkisofs". Both create one file that contains multiple pieces. What's the
>> difference - really?
>
> The difference - really - at least for static
Paul Mackerras [EMAIL PROTECTED] writes:
Linus Torvalds writes:
Why do people think that using ln is _any_ different from using
mkisofs. Both create one file that contains multiple pieces. What's the
difference - really?
The difference - really - at least for static linking - is that ln
obvious
Add builtin merge-file, a minimal replacement for RCS merge
merge-file: support -p and -q; fix compile warnings
Get rid of the dependency on RCS' merge program
merge-recursive: add/add really is modify/modify with an empty base
Josef Weidendorfer (1):
compile warnings
Get rid of the dependency on RCS' merge program
merge-recursive: add/add really is modify/modify with an empty base
Josef Weidendorfer (1):
Add branch.*.merge warning and documentation update
Junio C Hamano (45):
Store peeled refs in packed-refs file
git-svn: correctly handle revision 0 in SVN repositories
git-svn: preserve uncommitted changes after dcommit
git-svn: avoid fetching files twice in the same revision
Johannes Schindelin (1):
git-mv: search more precisely for source directory in index
Junio C Hamano (5
git-svn: correctly handle revision 0 in SVN repositories
git-svn: preserve uncommitted changes after dcommit
git-svn: avoid fetching files twice in the same revision
Johannes Schindelin (1):
git-mv: search more precisely for source directory in index
Junio C Hamano (5
er
sha1_object_info(): be consistent with read_sha1_file()
git-mv: search more precisely for source directory in index
diff -b: ignore whitespace at end of line
cvs-migration document: make the need for "push" more obvious
Junio C Hamano (24):
Store peeled refs in p
directory in index
diff -b: ignore whitespace at end of line
cvs-migration document: make the need for push more obvious
Junio C Hamano (24):
Store peeled refs in packed-refs file.
remove merge-recursive-old
git-merge: make it usable as the first class UI
merge
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> I'm wondering if doing
PB> if [ "$(show-diff)" ]; then
PB> git diff | git apply
PB> else
PB> checkout-cache -f -a
PB> fi
PB> would actually buy us some time; or, how common is it for people to have
PB> no local changes
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB I'm wondering if doing
PB if [ $(show-diff) ]; then
PB git diff | git apply
PB else
PB checkout-cache -f -a
PB fi
PB would actually buy us some time; or, how common is it for people to have
PB no local changes whatsoever, and whether
> "DL" == David Lang <[EMAIL PROTECTED]> writes:
DL> just wanted to point out that recent news shows that sha1 isn't as
DL> good as it was thought to be (far easier to deliberatly create
DL> collisions then it should be)
I suspect there is no need to do so...
Message-ID: <[EMAIL
>>>>> "CL" == Christopher Li <[EMAIL PROTECTED]> writes:
CL> On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
>>
>> But I am wondering what your plans are to handle renames---or
>> does git already represent them?
>>
CL&g
Listing the file paths and their sigs included in a tree to make
a snapshot of a tree state sounds fine, and diffing two trees by
looking at the sigs between two such files sounds fine as well.
But I am wondering what your plans are to handle renames---or
does git already represent them?
-
To
Listing the file paths and their sigs included in a tree to make
a snapshot of a tree state sounds fine, and diffing two trees by
looking at the sigs between two such files sounds fine as well.
But I am wondering what your plans are to handle renames---or
does git already represent them?
-
To
CL == Christopher Li [EMAIL PROTECTED] writes:
CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
But I am wondering what your plans are to handle renames---or
does git already represent them?
CL Rename should just work. It will create a new tree object and you
CL
DL == David Lang [EMAIL PROTECTED] writes:
DL just wanted to point out that recent news shows that sha1 isn't as
DL good as it was thought to be (far easier to deliberatly create
DL collisions then it should be)
I suspect there is no need to do so...
Message-ID: [EMAIL PROTECTED]
From:
> "PJ" == Paul Jackson <[EMAIL PROTECTED]> writes:
PJ> There is not a concensus (nor a King Penguin dictate) between the
PJ> "while(1)" and "for(;;)" style to document.
FWIW, linux-0.01 has four uses of "while (1)" and two uses of
"for (;;)" ;-).
./fs/inode.c: while (1) {
./fs/namei.c:
PJ == Paul Jackson [EMAIL PROTECTED] writes:
PJ There is not a concensus (nor a King Penguin dictate) between the
PJ while(1) and for(;;) style to document.
FWIW, linux-0.01 has four uses of while (1) and two uses of
for (;;) ;-).
./fs/inode.c: while (1) {
./fs/namei.c: while (1) {
> "AG" == Andreas Gruenbacher <[EMAIL PROTECTED]> writes:
AG> On Wed, 2005-02-02 at 11:50, Herbert Xu wrote:
>> What if a/b aren't aligned?
AG> If people sort arrays that are unaligned even though the
AG> element size is a multiple of sizeof(long) (or sizeof(u32)
AG> as Matt proposes), they
AG == Andreas Gruenbacher [EMAIL PROTECTED] writes:
AG On Wed, 2005-02-02 at 11:50, Herbert Xu wrote:
What if a/b aren't aligned?
AG If people sort arrays that are unaligned even though the
AG element size is a multiple of sizeof(long) (or sizeof(u32)
AG as Matt proposes), they are just
801 - 857 of 857 matches
Mail list logo
