* Re: What's in git.git (stable)
From: Luben Tuikov @ 2006-12-27 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
In-Reply-To: <7vd566ciwq.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> >> I am not quite sure about that. An old timer would work in a
> >> newly cloned repository after all, and what this "newbie
> >> protection" is breaking is not existing repositories but
> >> expectation from existing users.
> >
> > Hmm, "newbie protection" doesn't sound good. It sounds like
> > "screw the old-timers and let's change well-established workflow".
>
> As far as I am concerned, this is a topic already closed four
> days ago with commit fb8696d9.
>
> Are you way too behind, are you rubbing it in, or am I
> hallucinating and fb8696d9 did not actually fix it?
I'm behind. I'll pull and take a look at that commit.
Luben
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-27 2:14 UTC (permalink / raw)
To: ltuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
In-Reply-To: <368927.59162.qm@web31804.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>> >> I am not quite sure about that. An old timer would work in a
>> >> newly cloned repository after all, and what this "newbie
>> >> protection" is breaking is not existing repositories but
>> >> expectation from existing users.
>> >
>> > Hmm, "newbie protection" doesn't sound good. It sounds like
>> > "screw the old-timers and let's change well-established workflow".
>>
>> As far as I am concerned, this is a topic already closed four
>> days ago with commit fb8696d9.
>>
>> Are you way too behind, are you rubbing it in, or am I
>> hallucinating and fb8696d9 did not actually fix it?
>
> I'm behind. I'll pull and take a look at that commit.
Thanks.
And sorry that I sounded harsher than necessary. Between the
two paragraphs, I meant to say "... with commit fb8696d9. It
was a mistake, I broke existing workflows, I apologized, and the
commit should have fixed it".
^ permalink raw reply
* Segfault in xdl_merge is back
From: Shawn Pearce @ 2006-12-27 4:16 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
So I've been able to reproduce the segfault that was earlier reported
in xdl_merge. Unfortunately its in the repo that I can't publish.
I plan to spend some time tomorrow evening to attempt to further
debug the problem. I would certainly appreciate any advice. :-)
I can say its *not* related to 1510fea7 (or its fix 5caf9232 for
that matter). Tonight I only had a few minutes to look at the issue
but reverting 1510fea7/5caf9232 does not fix the segfault on Cygwin,
even though 5caf9232 appears to have fixed the issue for the original
reporter on Linux.
If I recall it correctly we were segfaulting on line 197 of xmerge.c:
197 t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
according to my particular case m->i1 == 70, but it looks like
xdf2.recs isn't that large as index 70 is not a valid pointer.
I'm suspecting this is actually some sort of memory corruption in
the heap (due to a bad malloc/free) as the bug seems to rear its
head only based on the data we are allocating/have allocated.
If you look at what 1510fea7 would do on Linux the 1510fea7 bug
would send us into the else case of diff_populate_filespec where we
malloc the file data during decompression from the pack. Yet when
we fixed it with 5caf9232 we started to mmap the working tree file,
avoiding the malloc/free. This behavior, plus the fact that it
happens no matter what for a particular merge on Cygwin (but not
other merges), leads me to suspect heap corruption.
I may try to bisect this on Cygwin, but I may need to go all the way
back to pre-xdl_merge() to get a working merge-recursive, and I may
just find the bug pointing at the original merge-recursive code,
or just find it pointing at a random commit like what happened
with 1510fea7. So bisection may not really help out very much.
Has anyone run merge-recursive through Valgrind lately? I don't
have a setup handy to run it through and see if we have any obvious
errors.
--
Shawn.
^ permalink raw reply
* [PATCH] everyday: update for v1.5.0
From: Junio C Hamano @ 2006-12-27 6:42 UTC (permalink / raw)
To: git
Fix minor mark-up mistakes and adjust to v1.5.0 BCP, namely:
- use "git add" instead of "git update-index";
- use "git merge" instead of "git pull .";
- use separate remote layout;
- use config instead of remotes/origin file;
Also updates "My typical git day" example since now I have
'next' branch these days.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/everyday.txt | 89 +++++++++++++++++++++++--------------------
1 files changed, 48 insertions(+), 41 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 9677671..5d17ace 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -47,11 +47,11 @@ $ git repack <3>
$ git prune <4>
------------
+
-<1> running without "--full" is usually cheap and assures the
+<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
-<3> without "-a" repacks incrementally. repacking every 4-5MB
+<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> after repack, prune removes the duplicate loose objects.
@@ -80,8 +80,7 @@ following commands.
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
branches.
- * gitlink:git-add[1] and gitlink:git-update-index[1] to manage
- the index file.
+ * gitlink:git-add[1] to manage the index file.
* gitlink:git-diff[1] and gitlink:git-status[1] to see what
you are in the middle of doing.
@@ -91,8 +90,7 @@ following commands.
* gitlink:git-reset[1] and gitlink:git-checkout[1] (with
pathname parameters) to undo changes.
- * gitlink:git-pull[1] with "." as the remote to merge between
- local branches.
+ * gitlink:git-merge[1] to merge between local branches.
* gitlink:git-rebase[1] to maintain topic branches.
@@ -101,7 +99,7 @@ following commands.
Examples
~~~~~~~~
-Use a tarball as a starting point for a new repository:
+Use a tarball as a starting point for a new repository.::
+
------------
$ tar zxf frotz.tar.gz
@@ -123,7 +121,7 @@ $ edit/compile/test
$ git checkout -- curses/ux_audio_oss.c <2>
$ git add curses/ux_audio_alsa.c <3>
$ edit/compile/test
-$ git diff <4>
+$ git diff HEAD <4>
$ git commit -a -s <5>
$ edit/compile/test
$ git reset --soft HEAD^ <6>
@@ -131,15 +129,15 @@ $ edit/compile/test
$ git diff ORIG_HEAD <7>
$ git commit -a -c ORIG_HEAD <8>
$ git checkout master <9>
-$ git pull . alsa-audio <10>
+$ git merge alsa-audio <10>
$ git log --since='3 days ago' <11>
$ git log v2.43.. curses/ <12>
------------
+
<1> create a new topic branch.
-<2> revert your botched changes in "curses/ux_audio_oss.c".
+<2> revert your botched changes in `curses/ux_audio_oss.c`.
<3> you need to tell git if you added a new file; removal and
-modification will be caught if you do "commit -a" later.
+modification will be caught if you do `git commit -a` later.
<4> to see what changes you are committing.
<5> commit everything as you have tested, with your sign-off.
<6> take the last commit back, keeping what is in the working tree.
@@ -147,11 +145,13 @@ modification will be caught if you do "commit -a" later.
<8> redo the commit undone in the previous step, using the message
you originally wrote.
<9> switch to the master branch.
-<10> merge a topic branch into your master branch
+<10> merge a topic branch into your master branch. You can also use
+`git pull . alsa-audio`, i.e. pull from the local repository.
<11> review commit logs; other forms to limit output can be
-combined and include --max-count=10 (show 10 commits), --until='2005-12-10'.
-<12> view only the changes that touch what's in curses/
-directory, since v2.43 tag.
+combined and include `\--max-count=10` (show 10 commits),
+`\--until=2005-12-10`, etc.
+<12> view only the changes that touch what's in `curses/`
+directory, since `v2.43` tag.
Individual Developer (Participant)[[Individual Developer (Participant)]]
@@ -193,7 +193,7 @@ $ git fetch --tags <8>
+
<1> repeat as needed.
<2> extract patches from your branch for e-mail submission.
-<3> "pull" fetches from "origin" by default and merges into the
+<3> `git pull` fetches from `origin` by default and merges into the
current branch.
<4> immediately after pulling, look at the changes done upstream
since last time we checked, only in the
@@ -201,37 +201,41 @@ area we are interested in.
<5> fetch from a specific branch from a specific repository and merge.
<6> revert the pull.
<7> garbage collect leftover objects from reverted pull.
-<8> from time to time, obtain official tags from the "origin"
-and store them under .git/refs/tags/.
+<8> from time to time, obtain official tags from the `origin`
+and store them under `.git/refs/tags/`.
Push into another repository.::
+
------------
-satellite$ git clone mothership:frotz/.git frotz <1>
+satellite$ git clone mothership:frotz frotz <1>
satellite$ cd frotz
-satellite$ cat .git/remotes/origin <2>
-URL: mothership:frotz/.git
-Pull: master:origin
-satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <3>
+satellite$ git repo-config --get-regexp '^(remote|branch)\.' <2>
+remote.origin.url mothership:frotz
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*
+branch.master.remote origin
+branch.master.merge refs/heads/master
+satellite$ git repo-config remote.origin.push \
+ master:refs/remotes/satellite/master <3>
satellite$ edit/compile/test/commit
satellite$ git push origin <4>
mothership$ cd frotz
mothership$ git checkout master
-mothership$ git pull . satellite <5>
+mothership$ git merge satellite/master <5>
------------
+
<1> mothership machine has a frotz repository under your home
directory; clone from it to start a repository on the satellite
machine.
-<2> clone creates this file by default. It arranges "git pull"
-to fetch and store the master branch head of mothership machine
-to local "origin" branch.
-<3> arrange "git push" to push local "master" branch to
-"satellite" branch of the mothership machine.
-<4> push will stash our work away on "satellite" branch on the
-mothership machine. You could use this as a back-up method.
+<2> clone sets these configuration variables by default.
+It arranges `git pull` to fetch and store the branches of mothership
+machine to local `remotes/origin/*` tracking branches.
+<3> arrange `git push` to push local `master` branch to
+`remotes/satellite/master` branch of the mothership machine.
+<4> push will stash our work away on `remotes/satellite/master`
+tracking branch on the mothership machine. You could use this as
+a back-up method.
<5> on mothership machine, merge the work done on the satellite
machine into the master branch.
@@ -247,7 +251,7 @@ $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
+
<1> create a private branch based on a well known (but somewhat behind)
tag.
-<2> forward port all changes in private2.6.14 branch to master branch
+<2> forward port all changes in `private2.6.14` branch to `master` branch
without a formal "merging".
@@ -284,13 +288,13 @@ $ mailx <3>
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
-$ git checkout master
+$ git checkout -b topic/one master
$ git am -3 -i -s -u ./+to-apply <4>
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard master <7>
-$ git pull . topic/one topic/two && git pull . hold/linus <8>
+$ git checkout pu && git reset --hard next <7>
+$ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
@@ -307,29 +311,32 @@ they are.
that are not quite ready.
<4> apply them, interactively, with my sign-offs.
<5> create topic branch as needed and apply, again with my
-sign-offs.
+sign-offs.
<6> rebase internal topic branch that has not been merged to the
master, nor exposed as a part of a stable branch.
-<7> restart "pu" every time from the master.
+<7> restart `pu` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
<11> make sure I did not accidentally rewind master beyond what I
-already pushed out. "ko" shorthand points at the repository I have
+already pushed out. `ko` shorthand points at the repository I have
at kernel.org, and looks like this:
+
------------
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git
Pull: master:refs/tags/ko-master
+Pull: next:refs/tags/ko-next
Pull: maint:refs/tags/ko-maint
Push: master
+Push: next
Push: +pu
Push: maint
------------
+
-In the output from "git show-branch", "master" should have
-everything "ko-master" has.
+In the output from `git show-branch`, `master` should have
+everything `ko-master` has, and `next` should have
+everything `ko-next` has.
<12> push out the bleeding edge.
<13> push the tag out, too.
@@ -406,7 +413,7 @@ $ grep git /etc/shells <2>
------------
+
<1> log-in shell is set to /usr/bin/git-shell, which does not
-allow anything but "git push" and "git pull". The users should
+allow anything but `git push` and `git pull`. The users should
get an ssh access to the machine.
<2> in many distributions /etc/shells needs to list what is used
as the login shell.
--
1.5.0.rc0.g9c0d
^ permalink raw reply related
* Re: Segfault in xdl_merge is back
From: Linus Torvalds @ 2006-12-27 6:49 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20061227041644.GA22449@spearce.org>
On Tue, 26 Dec 2006, Shawn Pearce wrote:
>
> I'm suspecting this is actually some sort of memory corruption in
> the heap (due to a bad malloc/free) as the bug seems to rear its
> head only based on the data we are allocating/have allocated.
Can you try to reproduce it under Linux and use "valgrind" to run the
thing that SIGSEGV's? That tends to be a pretty good way to debug bad
allocations..
So instead of bisecting it on cygwin, try to use the build that broke on
Linux too (ie undo the 5caf9232 "fix") and when you can reproduce it under
Linux, compiel withour -O2 and with debug information, and gdb will be a
lot more useful, but also run it with valgrind..
Linus
^ permalink raw reply
* [PATCH] Create 'git gc' to perform common maintenance operations.
From: Shawn O. Pearce @ 2006-12-27 7:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio asked for a 'git gc' utility which users can execute on a
regular basis to perform basic repository actions such as:
* prune
* repack -a -d
* reflog expire
* rerere gc
* pack-refs --prune
So here is a command which does exactly that. The parameters fed
to reflog's expire subcommand can be chosen by the user by setting
configuration options in .git/config (or ~/.gitconfig), as users may
want different expiration windows for each repository but shouldn't
be bothered to remember what they are all of the time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.gitignore | 1 +
Documentation/git-gc.txt | 55 ++++++++++++++++++++++++++++++++++++++++++++++
Makefile | 2 +-
git-gc.sh | 30 +++++++++++++++++++++++++
4 files changed, 87 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 91e6966..f92e359 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,6 +41,7 @@ git-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck-objects
+git-gc
git-get-tar-commit-id
git-grep
git-hash-object
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
new file mode 100644
index 0000000..a494b1f
--- /dev/null
+++ b/Documentation/git-gc.txt
@@ -0,0 +1,55 @@
+git-gc(1)
+===========
+
+NAME
+----
+git-gc - Cleanup unnecessary files and optimize the local repository.
+
+
+SYNOPSIS
+--------
+'git-gc'
+
+DESCRIPTION
+-----------
+Runs a number of housekeeping tasks within the current repository,
+such as compressing file revisions (to reduce disk space and increase
+performance) and removing unreachable objects which may have been
+created from prior invocations of gitlink:git-add[1].
+
+Users are encouraged to run this task on a regular basis within
+each repository to maintain good disk space utilization and good
+operating performance.
+
+Configuration
+-------------
+
+The optional configuration variable 'gc.reflogExpire' can be
+set to indicate how long historical entries within each branch's
+reflog should remain available in this repository. The setting is
+expressed as a length of time, for example '90 days' or '3 months'.
+It defaults to '90 days'.
+
+The optional configuration variable 'gc.reflogExpireUnreachable'
+can be set to indicate how long historical reflog entries which
+are not part of the current branch should remain available in
+this repository. These types of entries are generally created as
+a result of using `git commit \--amend` or `git rebase` and are the
+commits prior to the amend or rebase occuring. Since these changes
+are not part of the current project most users will want to expire
+them sooner. This option defaults to '60 days'.
+
+See Also
+--------
+gitlink:git-prune[1]
+gitlink:git-repack[1]
+gitlink:git-rerere[1]
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index b8b746f..fb6ba27 100644
--- a/Makefile
+++ b/Makefile
@@ -157,7 +157,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
git-clean.sh git-clone.sh git-commit.sh \
- git-fetch.sh \
+ git-fetch.sh git-gc.sh \
git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
diff --git a/git-gc.sh b/git-gc.sh
new file mode 100644
index 0000000..cb70412
--- /dev/null
+++ b/git-gc.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+#
+# Copyright (c) 2006, Shawn O. Pearce
+#
+# Cleanup unreachable files and optimize the repository.
+
+USAGE=''
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+reflog_expire=$(git-repo-config gc.reflogExpire)
+if [ -z "$reflog_expire" ]
+then
+ reflog_expire="90 days"
+fi
+
+reflog_unreachable=$(git-repo-config gc.reflogExpireUnreachable)
+if [ -z "$reflog_unreachable" ]
+then
+ reflog_unreachable="60 days"
+fi
+
+git-pack-refs --prune &&
+git-reflog expire \
+ --expire="$reflog_expire" \
+ --expire-unreachable="$reflog_unreachable" \
+ --all &&
+git-prune &&
+git-repack -a -d &&
+git-rerere gc || exit
--
1.4.4.3.gd2e4
^ permalink raw reply related
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Linus Torvalds @ 2006-12-27 7:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061227070541.GA22982@spearce.org>
On Wed, 27 Dec 2006, Shawn O. Pearce wrote:
>
> Junio asked for a 'git gc' utility which users can execute on a
> regular basis to perform basic repository actions such as:
>
> * prune
> * repack -a -d
You should do "repack -a -d" _before_ pruning, because then pruning will
be much more efficient (thanks to a more efficient repo format).
Linus
^ permalink raw reply
* [PATCH] Create 'git gc' to perform common maintenance operations.
From: Shawn O. Pearce @ 2006-12-27 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio asked for a 'git gc' utility which users can execute on a
regular basis to perform basic repository actions such as:
* pack-refs --prune
* reflog expire
* repack -a -d
* prune
* rerere gc
So here is a command which does exactly that. The parameters fed
to reflog's expire subcommand can be chosen by the user by setting
configuration options in .git/config (or ~/.gitconfig), as users may
want different expiration windows for each repository but shouldn't
be bothered to remember what they are all of the time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is a resend, as Linus pointed out prune runs faster if
its done after the repack and not before. Thanks Linus!
.gitignore | 1 +
Documentation/git-gc.txt | 55 ++++++++++++++++++++++++++++++++++++++++++++++
Makefile | 2 +-
git-gc.sh | 30 +++++++++++++++++++++++++
4 files changed, 87 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 91e6966..f92e359 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,6 +41,7 @@ git-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck-objects
+git-gc
git-get-tar-commit-id
git-grep
git-hash-object
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
new file mode 100644
index 0000000..a494b1f
--- /dev/null
+++ b/Documentation/git-gc.txt
@@ -0,0 +1,55 @@
+git-gc(1)
+===========
+
+NAME
+----
+git-gc - Cleanup unnecessary files and optimize the local repository.
+
+
+SYNOPSIS
+--------
+'git-gc'
+
+DESCRIPTION
+-----------
+Runs a number of housekeeping tasks within the current repository,
+such as compressing file revisions (to reduce disk space and increase
+performance) and removing unreachable objects which may have been
+created from prior invocations of gitlink:git-add[1].
+
+Users are encouraged to run this task on a regular basis within
+each repository to maintain good disk space utilization and good
+operating performance.
+
+Configuration
+-------------
+
+The optional configuration variable 'gc.reflogExpire' can be
+set to indicate how long historical entries within each branch's
+reflog should remain available in this repository. The setting is
+expressed as a length of time, for example '90 days' or '3 months'.
+It defaults to '90 days'.
+
+The optional configuration variable 'gc.reflogExpireUnreachable'
+can be set to indicate how long historical reflog entries which
+are not part of the current branch should remain available in
+this repository. These types of entries are generally created as
+a result of using `git commit \--amend` or `git rebase` and are the
+commits prior to the amend or rebase occuring. Since these changes
+are not part of the current project most users will want to expire
+them sooner. This option defaults to '60 days'.
+
+See Also
+--------
+gitlink:git-prune[1]
+gitlink:git-repack[1]
+gitlink:git-rerere[1]
+
+Author
+------
+Written by Shawn O. Pearce <spearce@spearce.org>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index b8b746f..fb6ba27 100644
--- a/Makefile
+++ b/Makefile
@@ -157,7 +157,7 @@ BASIC_LDFLAGS =
SCRIPT_SH = \
git-bisect.sh git-checkout.sh \
git-clean.sh git-clone.sh git-commit.sh \
- git-fetch.sh \
+ git-fetch.sh git-gc.sh \
git-ls-remote.sh \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
diff --git a/git-gc.sh b/git-gc.sh
new file mode 100755
index 0000000..8b1172b
--- /dev/null
+++ b/git-gc.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+#
+# Copyright (c) 2006, Shawn O. Pearce
+#
+# Cleanup unreachable files and optimize the repository.
+
+USAGE=''
+SUBDIRECTORY_OK=Yes
+. git-sh-setup
+
+reflog_expire=$(git-repo-config gc.reflogExpire)
+if [ -z "$reflog_expire" ]
+then
+ reflog_expire="90 days"
+fi
+
+reflog_unreachable=$(git-repo-config gc.reflogExpireUnreachable)
+if [ -z "$reflog_unreachable" ]
+then
+ reflog_unreachable="60 days"
+fi
+
+git-pack-refs --prune &&
+git-reflog expire \
+ --expire="$reflog_expire" \
+ --expire-unreachable="$reflog_unreachable" \
+ --all &&
+git-repack -a -d &&
+git-prune &&
+git-rerere gc || exit
--
1.4.4.3.gd2e4
^ permalink raw reply related
* [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-27 7:39 UTC (permalink / raw)
To: git
This is still rough, but I think we have a pretty good idea what
will and what won't be in v1.5.0 by now, and end-of-year is a
good slow time to summarize what we have done.
One thing I am wondering is if delta from v1.4.4.3 is good
enough for the intended audience of this release notes. I am
reasonably sure that the name v1.5.0 will attract more people
than usual and there will be many people upgrading directly from
ancient versions such as v1.1.6 or v1.2.0, and there are a
handful "one-way-street upgrades" and quite a few user visible
changes that already have happened before v1.4.4. Namely:
- Pack-compatible loose object headers, introduced between
v1.4.1 and v1.4.2; repository cannot be read with ancient
version of git anymore -- this is a one-way street but
core.legacyheaders is still not enabled by default);
- delta-base-offset pack encoding, introduced between v1.4.2
and v1.4.3; this is also a one-way street.
- 'git -p' to paginate anything -- many commands do pagination
by default on a tty. Introduced between v1.4.1 and v1.4.2;
this may surprise old timer users.
- 'git archive' superseded 'git tar' in v1.4.3;
- 'git pack-refs' appeared in v1.4.4;
- 'git cvsserver' was new invention in v1.3.0;
- 'git repo-config', 'git grep', 'git rebase' and 'gitk' were
seriously enhanced during v1.4.0 timeperiod.
- 'gitweb' became part of git.git during v1.4.0 timeperiod and
seriously modified since then.
- reflog is v1.4.0 invention.
In the following, I am assuming that jc/utf8 and jc/fsck-reflog
topics currently in 'next' will be part of v1.5.0.
-- >8 --
Updates in v1.5.0 since v1.4.4 series
-------------------------------------
* Index manipulation
- git-add is to add contents to the index (aka "staging area"
for the next commit), whether the file the contents happen to
be is an existing one or a newly created one.
- git-add without any argument does not add everything
anymore. Say "git add ." if you want to.
- git-add tries to be more friendly to users by offering an
interactive mode.
- git-commit <path> used to refuse to commit if <path> was
different between HEAD and the index (i.e. update-index was
used on it earlier). This check was removed.
- git-rm is much saner and safer. It is used to remove paths
from both the index file and the working tree, and makes sure
you are not losing any local modification before doing so.
- git-reset <tree> <paths>... can be used to revert index
entries for selected paths.
- git-update-index is much less visible.
* Repository layout
- The data for origin repository is stored in the configuration
file $GIT_DIR/config, not in $GIT_DIR/remotes/, for newly
created clones (the latter is still supported).
- git-clone always uses what is known as "separate remote"
layout for a newly created repository with a working tree;
i.e. tracking branches in $GIT_DIR/refs/remotes/origin/ are
used to track branches from the origin. New branches that
appear on the origin side after a clone is made are also
tracked automatically.
- git-clone used to be buggy and copied refs outside refs/heads
and refs/tags; it doesn't anymore.
- git-branch and git-show-branch know remote tracking branches.
- git-push can now be used to delete a remote branch or a tag.
* Reflog
- Reflog records the history of where the tip of each branch
was at each moment. This facility is enabled by default for
repositories with working trees, and can be accessed with the
"branch@{time}" and "branch@{Nth}" notation.
- "git show-branch" learned showing the reflog data with the
new --reflog option.
- The commits referred to by reflog entries are now protected
against pruning. The new command "git reflog expire" can be
used to truncate older reflog entries and entries that refer
to commits that have been pruned away previously.
Existing repositories that have been using reflog may get
complaints from fsck-objects; please run "git reflog expire
--all" first to remove reflog entries that refer to commits
that are no longer in the repository before attempting to
repack it.
- git-branch knows how to rename branches and moves existing
reflog data from the old branch to the new one.
* Packed refs
- Repositories with hundreds of tags have been paying large
overhead, both in storage and in runtime. A new command,
git-pack-refs, can be used to "pack" them in more efficient
representation.
- Clones and fetches over dumb transports are now aware of
packed refs and can download from repositories that use
them.
* Configuration
- configuration related to colorize setting are consolidated
under color.* namespace (older diff.color.*, status.color.*
are still supported).
* Less external dependency
- We have been depended on "merge" program from RCS suite for
the file-level 3-way merge, but now we lost this dependency.
- The original implementation of git-merge-recursive which was
in Python has been removed; we have C implementation of it
now.
- git-shortlog is not in Perl anymore, and more importantly it
does not have to be piped output from git-log. It can
traverse the commit ancestry itself.
* I18n
- We have always encouraged the commit message to be encoded in
UTF-8, but the users are allowed to use legacy encoding as
appropriate for their projects (which will never change).
A non UTF-8 commit encoding however _must_ be explicitly set
with i18n.commitencoding in the repository configuration;
otherwise git-commit-tree will complain if the log message does
not look like a valid UTF-8 string.
- A commit object recorded in non UTF-8 encoding records the
encoding i18n.commitencoding specified in the originating
repository in a new "encoding" header. This information is
used by git-log and friends to reencode the message to UTF-8
when displaying.
* User support
- Quite a lot of documentation updates.
- Bash completion scripts have been updated heavily.
- Better error messages for often used Porcelainish commands.
----------------------------------------------------------------
(shortlog since v1.4.4.3 here)
^ permalink raw reply
* [PATCH] Fix random segfaults in pack-objects.
From: Shawn O. Pearce @ 2006-12-27 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio noticed that 'non-trivial' pushes were failing if executed
using the sliding window mmap changes. This was somewhat difficult
to track down as the failure was appearing randomly.
It turns out this was a failure caused by the delta base reference
(either ref or offset format) spanning over the end of a mmap window.
The error in pack-objects was we were not recalling use_pack
after the object header was unpacked, and therefore we did not
get the promise of at least 20 bytes in the buffer for the delta
base parsing. This would case later memcmp() calls to walk into
unassigned address space at the end of the window.
The reason Junio and I had hard time tracking this down in current
Git repositories is we were both probably packing with offset deltas,
which minimized the odds of the delta base reference spanning over
the end of the mmap window. Stepping back and repacking with
version 1.3.3 (which only supported reference deltas) increased
the likelyhood of seeing the bug.
The correct technique (as used in sha1_file.c) is to invoke
use_pack() after unpack_object_header_gently to ensure we have
enough data available for the delta base decoding.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Applies to the top of my sp/mmap topic.
builtin-pack-objects.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 93eefc4..31ebf5c 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -995,8 +995,6 @@ static void check_object(struct object_entry *entry)
*/
used = unpack_object_header_gently(buf, left,
&entry->in_pack_type, &size);
- if (!used || left - used <= 20)
- die("corrupt pack for %s", sha1_to_hex(entry->sha1));
/* Check if it is delta, and the base is also an object
* we are going to pack. If so we will reuse the existing
@@ -1008,10 +1006,13 @@ static void check_object(struct object_entry *entry)
/* there is at least 20 bytes left in the pack */
switch (entry->in_pack_type) {
case OBJ_REF_DELTA:
- base_name = buf + used;
+ base_name = use_pack(p, &w_curs,
+ entry->in_pack_offset + used, NULL);
used += 20;
break;
case OBJ_OFS_DELTA:
+ buf = use_pack(p, &w_curs,
+ entry->in_pack_offset + used, NULL);
c = buf[used++];
ofs = c & 127;
while (c & 128) {
--
1.4.4.3.gd2e4
^ permalink raw reply related
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Junio C Hamano @ 2006-12-27 7:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061227071759.GA23057@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> +The optional configuration variable 'gc.reflogExpireUnreachable'
> +can be set to indicate how long historical reflog entries which
> +are not part of the current branch should remain available in
> +this repository. These types of entries are generally created as
> +a result of using `git commit \--amend` or `git rebase` and are the
> +commits prior to the amend or rebase occuring. Since these changes
> +are not part of the current project most users will want to expire
> +them sooner. This option defaults to '60 days'.
Should I update the default expire-unreachable in builtin-reflog
to match 60 days?
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Shawn Pearce @ 2006-12-27 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6ul93wz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > +The optional configuration variable 'gc.reflogExpireUnreachable'
> > +can be set to indicate how long historical reflog entries which
> > +are not part of the current branch should remain available in
> > +this repository. These types of entries are generally created as
> > +a result of using `git commit \--amend` or `git rebase` and are the
> > +commits prior to the amend or rebase occuring. Since these changes
> > +are not part of the current project most users will want to expire
> > +them sooner. This option defaults to '60 days'.
>
> Should I update the default expire-unreachable in builtin-reflog
> to match 60 days?
Doh, I meant for git-gc to match the default in 'git-reflog expire'.
Whoops.
I don't care either way. 60 days may be too long for some users,
but for others it may be nice to have. I think the two defaults
should match just because. Feel free to edit my patch before
applying to be whatever 'git-reflog expire' uses if you want.
--
Shawn.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Shawn Pearce @ 2006-12-27 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
This is certainly a good idea. And your summary was pretty good
too, I enjoyed the read. This group has certainly accomplished
quite a bit lately!
Just a few comments:
> - Pack-compatible loose object headers, introduced between
> v1.4.1 and v1.4.2; repository cannot be read with ancient
> version of git anymore -- this is a one-way street but
> core.legacyheaders is still not enabled by default);
>
> - delta-base-offset pack encoding, introduced between v1.4.2
> and v1.4.3; this is also a one-way street.
Perhaps you can clarify that using these means the repository
cannot be used with an earlier version of Git? You may also want
to highlight why these features are good, answering the question
"Why should I enable them if it breaks backwards compatibility?".
Isn't the new packed-refs format also a one-way street? If you
use them for tags on a web server and the client is using a very
old http commit walker, what happens?
> - git-clone used to be buggy and copied refs outside refs/heads
> and refs/tags; it doesn't anymore.
I mentioned to you on #git this morning that I don't think this
is noteworthy for this release.
You missed talking about the mess of pack files created by git-push
now, especially with pushes over 100 objects. ;-)
> - git-push can now be used to delete a remote branch or a tag.
You should mention this requires server side support too. I read
that and assumed I could just upgrade my client and push to delete
- which isn't the case, and I know its not... but I still read it
that way.
> - "git show-branch" learned showing the reflog data with the
> new --reflog option.
I had hoped we could get 'git reflog show' into 1.5.0 but the
current discussion with Johannes seems like that's unlikely.
> - We have been depended on "merge" program from RCS suite for
> the file-level 3-way merge, but now we lost this dependency.
Perhaps just reword as:
We no longer require the "merge" program from the RCS suite.
All 3-way file-level merges are now done internally.
> - git-shortlog is not in Perl anymore, and more importantly it
> does not have to be piped output from git-log. It can
> traverse the commit ancestry itself.
The "traverse the commit ancestry itself" part is not very
readable for the average user. How about instead:
git-shortlog is no longer a Perl script. git-shortlog also
no longer requires output piped from git-log; it can accept
revision parameters directly on the command line.
--
Shawn.
^ permalink raw reply
* Re: Segfault in xdl_merge is back
From: Shawn Pearce @ 2006-12-27 8:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612262245250.4473@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 26 Dec 2006, Shawn Pearce wrote:
> >
> > I'm suspecting this is actually some sort of memory corruption in
> > the heap (due to a bad malloc/free) as the bug seems to rear its
> > head only based on the data we are allocating/have allocated.
>
> Can you try to reproduce it under Linux and use "valgrind" to run the
> thing that SIGSEGV's? That tends to be a pretty good way to debug bad
> allocations..
>
> So instead of bisecting it on cygwin, try to use the build that broke on
> Linux too (ie undo the 5caf9232 "fix") and when you can reproduce it under
> Linux, compiel withour -O2 and with debug information, and gdb will be a
> lot more useful, but also run it with valgrind..
Good advice. Unfortunately it may be difficult to get valgrind onto
a Linux system where I can also put that repository which is failing.
Junio suggested that I try running git-merge-file on the three
blobs that I'm segfaulting on. That's a pretty quick test.
Failing that I may have to find a way to get valgrind onto a Linux
system - but that could take a month or more. (The UNIX admins
are overworked and don't care much about Linux, and I don't have
my own Linux system there.)
I'd really like to get this segfault fixed before 1.5.0 ships. Its
a rather nasty bug and I suspect the culprit is already in 1.5.0-rc0.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Junio C Hamano @ 2006-12-27 8:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061227075330.GA23022@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I don't care either way. 60 days may be too long for some users,
> but for others it may be nice to have. I think the two defaults
> should match just because. Feel free to edit my patch before
> applying to be whatever 'git-reflog expire' uses if you want.
I think the built-in git-reflog should be updated to honor the
configuration in the absense of command line options; if we do
that git-gc.sh does not even have to call repo-config anymore.
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Shawn Pearce @ 2006-12-27 8:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvh922r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I don't care either way. 60 days may be too long for some users,
> > but for others it may be nice to have. I think the two defaults
> > should match just because. Feel free to edit my patch before
> > applying to be whatever 'git-reflog expire' uses if you want.
>
> I think the built-in git-reflog should be updated to honor the
> configuration in the absense of command line options; if we do
> that git-gc.sh does not even have to call repo-config anymore.
Sure, but then maybe the configuration options shouldn't be
'gc.reflog*' but instead 'reflog.*'.
git-gc.sh was a quick hack while I was waiting for that huge disk
IO to repack a git.git with 1.3.3. I was trying to avoid hacking
C code for it, but you are probably right, better to just make the
C code do the right thing from "day one".
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Create 'git gc' to perform common maintenance operations.
From: Junio C Hamano @ 2006-12-27 9:10 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061227083328.GD23022@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>> > I don't care either way. 60 days may be too long for some users,
>> > but for others it may be nice to have. I think the two defaults
>> > should match just because. Feel free to edit my patch before
>> > applying to be whatever 'git-reflog expire' uses if you want.
>>
>> I think the built-in git-reflog should be updated to honor the
>> configuration in the absense of command line options; if we do
>> that git-gc.sh does not even have to call repo-config anymore.
>
> Sure, but then maybe the configuration options shouldn't be
> 'gc.reflog*' but instead 'reflog.*'.
Actually I think gc.reflog, gc.rerere and friends make more
sense. In other words, I think it is better to match the
configuration group to what the end user primarily sees, which
is "gc"; "reflog expire" and "rerere gc" are implementation
details of it.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-27 10:12 UTC (permalink / raw)
To: git
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
Very nice idea! Perhaps those release notes can find it's way into
either v1.5.0 commit, or v1.5.0 tag comment?
Just a few comments:
> - git-add without any argument does not add everything
> anymore. Say "git add ." if you want to.
>
> - git-add tries to be more friendly to users by offering an
> interactive mode.
Perhaps information that git-add can be used to add ignored files
with -f option should be added? Or is it not important enough?
> - The commits referred to by reflog entries are now protected
> against pruning. The new command "git reflog expire" can be
> used to truncate older reflog entries and entries that refer
> to commits that have been pruned away previously.
>
> Existing repositories that have been using reflog may get
> complaints from fsck-objects; please run "git reflog expire
> --all" first to remove reflog entries that refer to commits
> that are no longer in the repository before attempting to
> repack it.
That's a bit bad, as it forces to lose some info... but that
info was not that useful anyway.
> - A commit object recorded in non UTF-8 encoding records the
> encoding i18n.commitencoding specified in the originating
> repository in a new "encoding" header. This information is
> used by git-log and friends to reencode the message to UTF-8
> when displaying.
I don't quite like it. Why if someone uses different encoding
that utf-8 because his terminal is not set to utf-8? Having suddenly
what looks like garbage on output, while input was in local encoding
(and specified in i18n.commitencoding) is a bit suprising...
> ----------------------------------------------------------------
> (shortlog since v1.4.4.3 here)
I'd rather have description a la "what's cooking" here...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-27 10:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emtgps$f1q$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> That's a bit bad, as it forces to lose some info... but that
> info was not that useful anyway.
I am tired of listening to this useless FUD of yours. You lost
the information when you pruned away the underlying objects; you
are not losing information when you expire the reflog entries
that became useless long time ago.
> I don't quite like it. Why if someone uses different encoding
> that utf-8 because his terminal is not set to utf-8? Having suddenly
> what looks like garbage on output, while input was in local encoding
> (and specified in i18n.commitencoding) is a bit suprising...
If Luben wants UTF-8 in his project, but somebody he pulled from
was mistakenly used latin-1, then the commit pulled record
latin-1 while Luben has i18n.commitencoding in his repository
set to UTF-8. Output will be done in UTF-8 for Luben. For the
originator of that latin-1 commit, i18n.commitencoding says
latin-1 (and that was the only reason he managed to create such
a commit) and git show of that commit would not involve
recoding.
At least that is the idea. Have you spotted a bug, perhaps?
>> (shortlog since v1.4.4.3 here)
>
> I'd rather have description a la "what's cooking" here...
Send the summary to the list and I'll append it to the release
notes.
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Junio C Hamano @ 2006-12-27 10:50 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <emtgps$f1q$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Just a few comments:
>
>> - git-add without any argument does not add everything
>> anymore. Say "git add ." if you want to.
>
> Perhaps information that git-add can be used to add ignored files
> with -f option should be added? Or is it not important enough?
Thanks. Will change the above bullet to this:
- git-add without any argument does not add everything
anymore. Use 'git-add .' instead. Also you can add
otherwise ignored files with an -f option.
^ permalink raw reply
* Re: Segfault in xdl_merge is back
From: Johannes Schindelin @ 2006-12-27 11:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061227041644.GA22449@spearce.org>
Hi,
On Tue, 26 Dec 2006, Shawn Pearce wrote:
> So I've been able to reproduce the segfault that was earlier reported in
> xdl_merge. Unfortunately its in the repo that I can't publish.
So here I am again, wanting to help, being unable to. *Sigh*. At least
this time it is due to legal reasons, not unknown ones.
As you said in another mail, Junio suggested using git-merge-file on the
blobs themselves. This is a little tricky, since git-merge-file does not
read blobs; only files. I'd do this:
- in merge-recursive.c just before line 658 I'd add an
fprintf(stderr, "xdl_merge: %s %s %s\n", sha1_to_hex(a->sha1),
sha1_to_hex(o->sha1), sha1_to_hex(b->sha1));
- run the merge until it segfaults
- get the blobs by using the last three SHA1's in the output by
$ git-show <sha1> > a # or "o" or "b"
- $ git merge-file -p a o b >/dev/null
This command line ensures that "a" is not edited, and you can repeat the
merge as often as needed.
If this still segfaults, I'd like to have the files privately (I will not
look at the contents, as they are irrelevant to this particular bug).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Johannes Schindelin @ 2006-12-27 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 27 Dec 2006, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > I don't quite like it. Why if someone uses different encoding
> > that utf-8 because his terminal is not set to utf-8? Having suddenly
> > what looks like garbage on output, while input was in local encoding
> > (and specified in i18n.commitencoding) is a bit suprising...
>
> If Luben wants UTF-8 in his project, but somebody he pulled from was
> mistakenly used latin-1, then the commit pulled record latin-1 while
> Luben has i18n.commitencoding in his repository set to UTF-8. Output
> will be done in UTF-8 for Luben. For the originator of that latin-1
> commit, i18n.commitencoding says latin-1 (and that was the only reason
> he managed to create such a commit) and git show of that commit would
> not involve recoding.
I think that this is a misunderstanding. Maybe the config variable is
misnamed. As is clearly visible from the commit messages, this whole stuff
is meant to reencode to whatever encoding the caller of git-log likes, not
just UTF-8. And it defaults to UTF-8, overridable by i18n.commitEncoding.
BTW I think that latin-1 is not a valid encoding name (at least in my
setup it isn't), so we should rather talk about iso-8859-1.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Horst H. von Brand @ 2006-12-27 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvejx948y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This is still rough, but I think we have a pretty good idea what
> will and what won't be in v1.5.0 by now, and end-of-year is a
> good slow time to summarize what we have done.
Could somebody please summarize how to "upgrade" a repository to the new
layout? This has got my head spinning... and I'm /not/ cloning the
various repos I've got here just to take advantage of the changes.
Thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-27 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wml8wmw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Junio C Hamano wrote:
>>>
>>> - The commits referred to by reflog entries are now protected
>>> against pruning. The new command "git reflog expire" can be
>>> used to truncate older reflog entries and entries that refer
>>> to commits that have been pruned away previously.
>>>
>>> Existing repositories that have been using reflog may get
>>> complaints from fsck-objects; please run "git reflog expire
>>> --all" first to remove reflog entries that refer to commits
>>> that are no longer in the repository before attempting to
>>> repack it.
>>
>> That's a bit bad, as it forces to lose some info... but that
>> info was not that useful anyway.
>
> I am tired of listening to this useless FUD of yours. You lost
> the information when you pruned away the underlying objects; you
> are not losing information when you expire the reflog entries
> that became useless long time ago.
Sorry, this is a bit of my inner packrat ;-) showing thru.
I'd rather use "git reflog expire --pruned" to remove reflog entries
which refer to commits which are no longer in the repository; I don't
know, perhaps "git reflog expire --all" does that: but there is no
Documentation/git-reflog.txt (and I'm not running 'next' nor 'master'
but 1.4.4.3). So most probably it is just the case of adding an alias
to reflog expire option.
>>> - A commit object recorded in non UTF-8 encoding records the
>>> encoding i18n.commitencoding specified in the originating
>>> repository in a new "encoding" header. This information is
>>> used by git-log and friends to reencode the message to UTF-8
>>> when displaying.
>>
>> I don't quite like it. Why if someone uses different encoding
>> that utf-8 because his terminal is not set to utf-8? Having suddenly
>> what looks like garbage on output, while input was in local encoding
>> (and specified in i18n.commitencoding) is a bit suprising...
>
> If Luben wants UTF-8 in his project, but somebody he pulled from
> was mistakenly used latin-1, then the commit pulled record
> latin-1 while Luben has i18n.commitencoding in his repository
> set to UTF-8. Output will be done in UTF-8 for Luben. For the
> originator of that latin-1 commit, i18n.commitencoding says
> latin-1 (and that was the only reason he managed to create such
> a commit) and git show of that commit would not involve
> recoding.
>
> At least that is the idea. Have you spotted a bug, perhaps?
Perhaps that is the idea, but that idea is not described in above
new feature announcement. "... to reencode the message to UTF-8
when displaying, if needed." would cover it, but perhaps better
would be to cover this in more detail: "reencode message to UTF-8
if i18n.commitencoding is not set to something other than UTF-8",
or "reencode ... to i18n.commitencoding ... if needed".
BTW. what happens for NO_ICONV? Just curious...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFH] An early draft of v1.5.0 release notes
From: Jakub Narebski @ 2006-12-27 12:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612271251060.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> BTW I think that latin-1 is not a valid encoding name (at least in my
> setup it isn't), so we should rather talk about iso-8859-1.
"iconv --list" include l1 and latin1 as aliases to the proper name
of encoding, i.e. iso-8859-1; but not latin-2.
--
Jakub Narebski
Poland
^ 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