* Re: [PATCH] ls-files: Don't require exclude files to end with a newline.
From: Petr Baudis @ 2006-03-19 21:29 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <8764mccaji.fsf@wine.dyndns.org>
Dear diary, on Sat, Mar 18, 2006 at 11:27:45AM CET, I got a letter
where Alexandre Julliard <julliard@winehq.org> said that...
> Without this patch, the last line of an exclude file is silently
> ignored if it doesn't end with a newline.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
$ echo -en "a\nb" | wc -l
1
In UNIX, a line is a string terminated by a newline, therefore the blob
past the last newline character is not really a line at all. ;-)
Perhaps a warning might be in order. Why don't you just add the trailing
newline to the file?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-19 19:47 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603190604ne4364f3o6a862d25267a2dce@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>>
>> How about getting an account on kernel.org?
>
> I don't think I have the credentials to ask for ;-)
Heh, it has a striking resemblance to the first thing I said
when Linus asked me if I want to take over git.git: "It would
be embarrassing to be the first person to have an account there
without having a single line of code in the kernel" ;-).
Well, you won't be the first (in fact it appears I wasn't
either), and it would never hurt to ask.
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Junio C Hamano @ 2006-03-19 19:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060319191243.GB18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Actually, I'm almost inclined to suggest making Git fail violently in
> case of an ambiguous name.
I am also inclined to suggest that or alternatively making it
warn, but having been almost burned by a bug or two coming from
the complexity of implementing it, I am not so enthused to start
hacking away again on this right now myself.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-19 19:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Paolo Ciarrocchi, git, junkio
In-Reply-To: <e5bfff550603190604ne4364f3o6a862d25267a2dce@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
>
> Git does not understand object is missing and thinks what site sends
> _is_ the requested
> object and then founds that is (of course) corrupted.
To be fair, the site is _not_ missing anything from HTTP
protocol perspective, because when git asks 8d/ea0351... file,
the server responds with a regular "HTTP/1.0 200 OK" response.
So it is _your_ repository that is corrupt -- instead of
correctly _lacking_ the file you should have removed with
prune-packed, it has a garbage file.
Having said that, I agree that it would be nicer if we support
such a site, in the same spirit that we already bend backwards
to support really dumb hosted http servers that do not give
directory index by using objects/info/packs and info/refs.
I think it wouldn't be too much a hassle to add logic to
http-fetch.c (perhaps with an additional "--no-404" option or
somesuch) to fall back on pack transfer upon seeing a corrupt
loose object. We do the falling back when getting 404 error to
a request for a loose object, so the new code would essentially
do the same and you might be OK.
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-03-19 19:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andreas Ericsson, Eric Wong, Martin Langhoff, git
In-Reply-To: <20060319191243.GB18185@pasky.or.cz>
On Sun, 19 Mar 2006, Petr Baudis wrote:
>
> (i) I _think_ that it would be less of a surprise if a branch would be
> checked first.
Yeah, I guess that's true.
> Actually, I'm almost inclined to suggest making Git fail violently in
> case of an ambiguous name.
Maybe not fail, but at least warn very loudly.
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Petr Baudis @ 2006-03-19 19:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Eric Wong, Linus Torvalds, Martin Langhoff, git
In-Reply-To: <44056BF1.6000109@op5.se>
Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> It already does. The search order is this, for a ref named 'foo':
> $GIT_DIR/foo
> $GIT_DIR/refs/foo
> $GIT_DIR/refs/tags/foo
> $GIT_DIR/refs/heads/foo
Actually, I've hit this recently when supporting an unhappy user on
#git, and I didn't manage to find anything in the archives (but perhaps
I missed it). Is there a particular reason why tags are checked first
than branches?
Why not:
(i) I _think_ that it would be less of a surprise if a branch would be
checked first.
(ii) E.g. Cogito output (cg-status -g) is very confusing when you have a
naming clash - cg-object-id foo will show tag commit ID, but cg-status -g
will say that the "foo" branch has a different commit ID (and it is
_right_).
(iii) Many operations will stop making sense (cg-merge foo, and even
cg-fetch foo will be confused), while in case of the opposite way I can't
think of any command still not making sense.
(iv) A security hole when you auto-fetch tags from remote repositories
- you could then be misled to merge something totally different when the
attacker will introduce a naming clash to your refs hierarchy.
Actually, I'm almost inclined to suggest making Git fail violently in
case of an ambiguous name.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [ANNOUNCE] qgit 1.1.1
From: Marco Costalba @ 2006-03-19 16:53 UTC (permalink / raw)
To: git; +Cc: proski
This is a maintenance release, mainly performance tweaks and small bug fixes.
To install use:
./configure
make
make install-strip
Or check the shipped README for detailed information.
To note are big speed-up in annotation and tree viewer browsing
See http://digilander.libero.it/mcostalba/ for download information.
Changelog
* add support for file annotations in multi-branch repos
* speed-up browsing with tree view open
* tree view: set in bold the names of modified files
* use a map instead of a list to speed-up path filtering
* add support for listing tags in a submenu in mainview context pop-up
* show StGIT patch names on the status bar (Pavel Roskin)
* use dark green pluses for applied StGIT patches (Pavel Roskin)
* more then double annotation speed
* add support for jumping to branches from pop-up menu
* remove setting 'Load file names in background'
* save cache file under ./git directory
* fix duplicate tags in the pop-up menu (Pavel Roskin)
Have fun
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 14:04 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git, junkio
In-Reply-To: <4d8e3fd30603190525o5a01fba8w5bcdedd064c213ec@mail.gmail.com>
On 3/19/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 3/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
> >
>
> How about getting an account on kernel.org?
>
I don't think I have the credentials to ask for ;-)
> Anyway, here is what I did:
> paolo@Italia:~$ cg-clone
> http://digilander.libero.it/mcostalba/scm/qgit.git qgit defaulting to
>
> Why am I getting this error?
> error: File 8dea03519e75f47da91108330dde3043defddd60
> (http://digilander.libero.i
> t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
> corr upt
>
Because http server of digilander.libero.it instead of responding with
404 code (page not
found) sends a not standard html page as answer. To see the page just point
your browser to:
http://digilander.libero.it /mcostalba/scm/qgit.git/objects/8d/ea03519e75f47d
Git does not understand object is missing and thinks what site sends
_is_ the requested
object and then founds that is (of course) corrupted.
Marco
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Paolo Ciarrocchi @ 2006-03-19 13:25 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, junkio
In-Reply-To: <e5bfff550603190252n7e3e1cbbp94e3f15c92f12d07@mail.gmail.com>
On 3/19/06, Marco Costalba <mcostalba@gmail.com> wrote:
> Hi all,
Ciao Marco,
> I have set a git repository on a hosted public site:
> http://digilander.libero.it/mcostalba/scm/qgit.git
>
> I cannot run any process (read git-daemon) on that site, so git-clone uses
> a 'dumb server' type protocol and this is what I got.
>
> $ git clone http://digilander.libero.it/mcostalba/scm/qgit.git
> error: File 8dea03519e75f47da91108330dde3043defddd60
> (http://digilander.libero.it/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
> corrupt
> Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
> Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
> Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
> which contains 8dea03519e75f47da91108330dde3043defddd60
> walk 8dea03519e75f47da91108330dde3043defddd60
> walk ec47dab590fb838ba2be7af5bf9aa46d9f2e502d
>
> -------------- cut ------------------------
>
> walk 907d47e836f4f174386d02d21e38aeafc1e79626
> walk 5d3454248bbb3aaba080057dc9666a3c3aaeca1f
> $
>
> The above mentioned error belongs to git requests a non existing object
> (8dea03519e75f47da91108330dde3043defddd60) _and_ the site answers with
> a pre-canned 'page not found' html page instead of reporting 404 error.
>
> After some research I found it is quite common for public hosting
> sites to use a pre-canned
> 'Sorry, no page here' html stuff instead of 404.
>
> So my request is if it is possible for git to _learn_ this and to
> avoid been fooled by
> these kind of public sites.
>
How about getting an account on kernel.org?
Anyway, here is what I did:
paolo@Italia:~$ cg-clone
http://digilander.libero.it/mcostalba/scm/qgit.git qgit defaulting to
local storage area
Fetching head...
Fetching objects...
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.i
t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corr upt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
which contains 8dea03519e75f47da91108330dde3043defddd60
Fetching tags...
Missing tag qgit-0.93... retrieved
Missing tag qgit-0.94... retrieved
Missing tag qgit-0.94.1... retrieved
Missing tag qgit-0.95.1... retrieved
Missing tag qgit-0.96... retrieved
Missing tag qgit-0.96.1... retrieved
Missing tag qgit-0.97... retrieved
Missing tag qgit-0.97.1... retrieved
Missing tag qgit-0.97.2... retrieved
Missing tag qgit-1.0... retrieved
Missing tag qgit-1.1rc1... retrieved
Missing tag qgit-1.1rc3... retrieved
New branch: 8dea03519e75f47da91108330dde3043defddd60
Cloned to qgit/ (origin
http://digilander.libero.it/mcostalba/scm/qgit.git available as branch
"origin")
Why am I getting this error?
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.i
t/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corr upt
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Cloning from sites with 404 overridden
From: Marco Costalba @ 2006-03-19 10:52 UTC (permalink / raw)
To: git; +Cc: junkio
Hi all,
I have set a git repository on a hosted public site:
http://digilander.libero.it/mcostalba/scm/qgit.git
I cannot run any process (read git-daemon) on that site, so git-clone uses
a 'dumb server' type protocol and this is what I got.
$ git clone http://digilander.libero.it/mcostalba/scm/qgit.git
error: File 8dea03519e75f47da91108330dde3043defddd60
(http://digilander.libero.it/mcostalba/scm/qgit.git/objects/8d/ea03519e75f47da91108330dde3043defddd60)
corrupt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
Getting index for pack fe1f3586b38e70e963de47f31379ef170adc5ca9
Getting pack fe1f3586b38e70e963de47f31379ef170adc5ca9
which contains 8dea03519e75f47da91108330dde3043defddd60
walk 8dea03519e75f47da91108330dde3043defddd60
walk ec47dab590fb838ba2be7af5bf9aa46d9f2e502d
-------------- cut ------------------------
walk 907d47e836f4f174386d02d21e38aeafc1e79626
walk 5d3454248bbb3aaba080057dc9666a3c3aaeca1f
$
The above mentioned error belongs to git requests a non existing object
(8dea03519e75f47da91108330dde3043defddd60) _and_ the site answers with
a pre-canned 'page not found' html page instead of reporting 404 error.
After some research I found it is quite common for public hosting
sites to use a pre-canned
'Sorry, no page here' html stuff instead of 404.
So my request is if it is possible for git to _learn_ this and to
avoid been fooled by
these kind of public sites.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Jan-Benedict Glaw @ 2006-03-19 10:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git, Jon Loeliger
In-Reply-To: <7vr74zqhhi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Sat, 2006-03-18 18:46:17 -0800, Junio C Hamano <junkio@cox.net> wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
> > [nice description of Git's packing heuristics]
> >
> > Junio, are there any specific reasons why this hasn't been applied
> > yet?
>
> Funny. I was just re-reading it last night.
>
> It _is_ amusing, but I am not sure if it should go to
> technical/. If properly digested and reorganized, I suspect
> that the document would become 1/3 of its current length.
But surely it should go somewhere, in its current form. It's *such* a
nice reading and really amusing, so it shouldn't get lost.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] git.el: Added a function to diff against the other heads in a merge.
From: Alexandre Julliard @ 2006-03-19 9:06 UTC (permalink / raw)
To: git
git-diff-file-merge-head generates a diff against the first merge
head, or with a prefix argument against the nth head. Bound to `d h'
by default.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
92478446cf5718ee76acaced75ff41416329a509
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5496a1b..ebd00ef 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -767,6 +767,16 @@ The default is to fall back to the git r
(git-setup-diff-buffer
(apply #'git-run-command-buffer "*git-diff*" "diff-index" "-p" "-M" "HEAD" "--" (git-get-filenames files)))))
+(defun git-diff-file-merge-head (arg)
+ "Diff the marked file(s) against the first merge head (or the nth one with a numeric prefix)."
+ (interactive "p")
+ (let ((files (git-marked-files))
+ (merge-heads (git-get-merge-heads)))
+ (unless merge-heads (error "No merge in progress"))
+ (git-setup-diff-buffer
+ (apply #'git-run-command-buffer "*git-diff*" "diff-index" "-p" "-M"
+ (or (nth (1- arg) merge-heads) "HEAD") "--" (git-get-filenames files)))))
+
(defun git-diff-unmerged-file (stage)
"Diff the marked unmerged file(s) against the specified stage."
(let ((files (git-marked-files)))
@@ -959,6 +969,7 @@ The default is to fall back to the git r
(define-key diff-map "=" 'git-diff-file)
(define-key diff-map "e" 'git-diff-file-idiff)
(define-key diff-map "E" 'git-find-file-imerge)
+ (define-key diff-map "h" 'git-diff-file-merge-head)
(define-key diff-map "m" 'git-diff-file-mine)
(define-key diff-map "o" 'git-diff-file-other)
(setq git-status-mode-map map)))
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/3] git.el: Get the default user name and email from the repository config.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
ac4b54cc4019abdb92cd0fbbf7c644976227fea0
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index cf650da..5496a1b 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -59,14 +59,14 @@
(defcustom git-committer-name nil
"User name to use for commits.
-The default is to fall back to `add-log-full-name' and then `user-full-name'."
+The default is to fall back to the repository config, then to `add-log-full-name' and then to `user-full-name'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Name")))
(defcustom git-committer-email nil
"Email address to use for commits.
-The default is to fall back to `add-log-mailing-address' and then `user-mail-address'."
+The default is to fall back to the git repository config, then to `add-log-mailing-address' and then to `user-mail-address'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Email")))
@@ -203,6 +203,7 @@ The default is to fall back to `add-log-
"Return the name to use as GIT_COMMITTER_NAME."
; copied from log-edit
(or git-committer-name
+ (git-repo-config "user.name")
(and (boundp 'add-log-full-name) add-log-full-name)
(and (fboundp 'user-full-name) (user-full-name))
(and (boundp 'user-full-name) user-full-name)))
@@ -211,6 +212,7 @@ The default is to fall back to `add-log-
"Return the email address to use as GIT_COMMITTER_EMAIL."
; copied from log-edit
(or git-committer-email
+ (git-repo-config "user.email")
(and (boundp 'add-log-mailing-address) add-log-mailing-address)
(and (fboundp 'user-mail-address) (user-mail-address))
(and (boundp 'user-mail-address) user-mail-address)))
@@ -268,6 +270,11 @@ The default is to fall back to `add-log-
(git-get-string-sha1
(git-call-process-env-string nil "rev-parse" rev)))
+(defun git-repo-config (key)
+ "Retrieve the value associated to KEY in the git repository config file."
+ (let ((str (git-call-process-env-string nil "repo-config" key)))
+ (and str (car (split-string str "\n")))))
+
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
(let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 1/3] git.el: More robust handling of subprocess errors when returning strings.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
66a8d3c3e63a2d4178c9917e0c172bdc2cbec3bb
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5135e36..cf650da 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -148,6 +148,12 @@ The default is to fall back to `add-log-
(append (git-get-env-strings env) (list "git") args))
(apply #'call-process "git" nil buffer nil args)))
+(defun git-call-process-env-string (env &rest args)
+ "Wrapper for call-process that sets environment strings, and returns the process output as a string."
+ (with-temp-buffer
+ (and (eq 0 (apply #' git-call-process-env t env args))
+ (buffer-string))))
+
(defun git-run-process-region (buffer start end program args)
"Run a git process with a buffer region as input."
(let ((output-buffer (current-buffer))
@@ -189,8 +195,9 @@ The default is to fall back to `add-log-
(defun git-get-string-sha1 (string)
"Read a SHA1 from the specified string."
- (let ((pos (string-match "[0-9a-f]\\{40\\}" string)))
- (and pos (substring string pos (match-end 0)))))
+ (and string
+ (string-match "[0-9a-f]\\{40\\}" string)
+ (match-string 0 string)))
(defun git-get-committer-name ()
"Return the name to use as GIT_COMMITTER_NAME."
@@ -259,18 +266,12 @@ The default is to fall back to `add-log-
(defun git-rev-parse (rev)
"Parse a revision name and return its SHA1."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "rev-parse" rev)))))
+ (git-call-process-env-string nil "rev-parse" rev)))
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
- (car
- (split-string
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "symbolic-ref" ref)))
- "\n")))
+ (let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
+ (and str (car (split-string str "\n")))))
(defun git-update-ref (ref val &optional oldval)
"Update a reference by calling git-update-ref."
@@ -285,11 +286,7 @@ The default is to fall back to `add-log-
(defun git-write-tree (&optional index-file)
"Call git-write-tree and return the resulting tree SHA1 as a string."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t
- (if index-file `(("GIT_INDEX_FILE" . ,index-file)) nil)
- "write-tree")))))
+ (git-call-process-env-string (and index-file `(("GIT_INDEX_FILE" . ,index-file))) "write-tree")))
(defun git-commit-tree (buffer tree head)
"Call git-commit-tree with buffer as input and return the resulting commit SHA1."
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Jon Loeliger @ 2006-03-19 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vr74zqhhi.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > [nice description of Git's packing heuristics]
> >
> > Junio, are there any specific reasons why this hasn't been applied
> > yet?
>
> Funny. I was just re-reading it last night.
>
> It _is_ amusing, but I am not sure if it should go to
> technical/.
You know, I don't know what to do with it either. :-)
I have half a notion to submit it to the OLS call for
"Linux Essay Contest" just to see what happens....
> If properly digested and reorganized, I suspect
> that the document would become 1/3 of its current length.
I suppose I could do a round of that, if you would like. :-)
I should either drink more or less, I can't tell which...
jdl
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Junio C Hamano @ 2006-03-19 2:46 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: junkio, git, Jon Loeliger
In-Reply-To: <20060319003255.GA17124@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> [nice description of Git's packing heuristics]
>
> Junio, are there any specific reasons why this hasn't been applied
> yet?
Funny. I was just re-reading it last night.
It _is_ amusing, but I am not sure if it should go to
technical/. If properly digested and reorganized, I suspect
that the document would become 1/3 of its current length.
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Fredrik Kuivinen @ 2006-03-19 0:32 UTC (permalink / raw)
To: junkio; +Cc: git, Jon Loeliger
In-Reply-To: <E1FEyx7-0007vo-Je@jdl.com>
On Thu, Mar 02, 2006 at 07:19:29PM -0600, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> ---
>
> Documentation/technical/pack-heuristics.txt | 466 +++++++++++++++++++++++++++
> 1 files changed, 466 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/pack-heuristics.txt
>
> 0cbbcac437be6f8a0249f6cf83b90a6fe9d2362e
> diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
> new file mode 100644
> index 0000000..eaab3ee
> --- /dev/null
> +++ b/Documentation/technical/pack-heuristics.txt
> @@ -0,0 +1,466 @@
> + Concerning Git's Packing Heuristics
> + ===================================
> +
[nice description of Git's packing heuristics]
Junio, are there any specific reasons why this hasn't been applied
yet?
- Fredrik
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-18 23:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqw51z5q.fsf@blue.stonehenge.com>
I tested the version in today's "next" branch, and it fixes the
problem for me in my tests that use my day-job CVS repository as
a guinea pig.
In case you are not brave enough to switch to "next" wholesale,
but are kind enough to try out the relevant cvsimport change for
us, here is a patch that applies on top of "master". It is a
roll-up of two commits on my jc/cvsimport branch.
-- >8 --
cvsimport: honor -i and non -i upon subsequent imports
Documentation says -i is "import only", so without it,
subsequent import should update the current branch and working
tree files in a sensible way.
"A sensible way" defined by this commit is "act as if it is a
git pull from foreign repository which happens to be CVS not
git". So:
- If importing into the current branch (note that cvsimport
requires the tracking branch is pristine -- you checked out
the tracking branch but it is your responsibility not to make
your own commits there), fast forward the branch head and
match the index and working tree using two-way merge, just
like "git pull" does.
- If importing into a separate tracking branch, update that
branch head, and merge it into your current branch, again,
just like "git pull" does.
Initial round of the updated code read the tip of the current
branch before and after the import runs, but forgot to chomp
what we read from the command. The read-tree command did not
them with the trailing LF. This has been fixed.
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..3728294 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -453,6 +453,7 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
my %branch_date;
+my $tip_at_start = undef;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
$git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;
@@ -487,6 +488,7 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
+ $tip_at_start = `git-rev-parse --verify HEAD`;
# populate index
system('git-read-tree', $last_branch);
@@ -873,7 +875,22 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE; you may need to merge manually.\n" if $opt_v;
+ print "DONE.\n" if $opt_v;
+ if ($opt_i) {
+ exit 0;
+ }
+ my $tip_at_end = `git-rev-parse --verify HEAD`;
+ if ($tip_at_start ne $tip_at_end) {
+ for ($tip_at_start, $tip_at_end) { chomp; }
+ print "Fetched into the current branch.\n" if $opt_v;
+ system(qw(git-read-tree -u -m),
+ $tip_at_start, $tip_at_end);
+ die "Fast-forward update failed: $?\n" if $?;
+ }
+ else {
+ system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ die "Could not merge $opt_o into the current branch.\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
^ permalink raw reply related
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 22:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <7vmzfns9c6.fsf@assigned-by-dhcp.cox.net>
>From nobody Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sat Mar 18 14:50:53 2006 -0800
Subject: [PATCH] git-merge knows some strategies want to skip trivial merges
Most notably "ours". Also this makes sure we do not record
duplicated parents on the parent list of the resulting commit.
This is based on Mark Wooding's work, but does not change the UI
nor introduce new flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* How about this instead? It looks larger than it really is
because strategy-defaulting code needed to get moved around.
git-merge.sh | 67 +++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 40 insertions(+), 27 deletions(-)
313093ea6d29bbce5977556645eb5946dbfb211e
diff --git a/git-merge.sh b/git-merge.sh
index cc0952a..78ab422 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -11,11 +11,15 @@ LF='
'
all_strategies='recursive octopus resolve stupid ours'
-default_strategies='recursive'
+default_twohead_strategies='recursive'
+default_octopus_strategies='octopus'
+no_trivial_merge_strategies='ours'
use_strategies=
+
+index_merge=t
if test "@@NO_PYTHON@@"; then
all_strategies='resolve octopus stupid ours'
- default_strategies='resolve'
+ default_twohead_strategies='resolve'
fi
dropsave() {
@@ -90,8 +94,6 @@ do
shift
done
-test "$#" -le 2 && usage ;# we need at least two heads.
-
merge_msg="$1"
shift
head_arg="$1"
@@ -99,6 +101,8 @@ head=$(git-rev-parse --verify "$1"^0) ||
shift
# All the rest are remote heads
+test "$#" = 0 && usage ;# we need at least one remote head.
+
remoteheads=
for remote
do
@@ -108,6 +112,27 @@ do
done
set x $remoteheads ; shift
+case "$use_strategies" in
+'')
+ case "$#" in
+ 1)
+ use_strategies="$default_twohead_strategies" ;;
+ *)
+ use_strategies="$default_octopus_strategies" ;;
+ esac
+ ;;
+esac
+
+for s in $use_strategies
+do
+ case " $s " in
+ *" $no_trivial_merge_strategies "*)
+ index_merge=f
+ break
+ ;;
+ esac
+done
+
case "$#" in
1)
common=$(git-merge-base --all $head "$@")
@@ -118,18 +143,21 @@ case "$#" in
esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common,$no_commit" in
-*,'',*)
+case "$index_merge,$#,$common,$no_commit" in
+f,*)
+ # We've been told not to try anything clever. Skip to real merge.
+ ;;
+?,*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1",*)
+?,1,"$1",*)
# If head can reach all the merge then we are up to date.
- # but first the most common case of merging one remote
+ # but first the most common case of merging one remote.
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head",*)
+?,1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
@@ -139,11 +167,11 @@ case "$#,$common,$no_commit" in
dropsave
exit 0
;;
-1,?*"$LF"?*,*)
+?,1,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*,)
+?,1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -188,17 +216,6 @@ esac
# We are going to make a new commit.
git var GIT_COMMITTER_IDENT >/dev/null || exit
-case "$use_strategies" in
-'')
- case "$#" in
- 1)
- use_strategies="$default_strategies" ;;
- *)
- use_strategies=octopus ;;
- esac
- ;;
-esac
-
# At this point, we need a real merge. No matter what strategy
# we use, it would operate on the index, possibly affecting the
# working tree, and when resolved cleanly, have the desired tree
@@ -270,11 +287,7 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents="-p $head"
- for remote
- do
- parents="$parents -p $remote"
- done
+ parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
dropsave
--
1.2.4.g2fc2
^ permalink raw reply related
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 21:59 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060318101941.8941.52615.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> These options disable some of git-merge's optimizations.
While there is no question about the part of the proposed change
to bypass "trivial merge", I do not necessarily agree with
"skipping fast forward" part.
It is a problem that "ours" strategy cannot be used as a way to
recover from the "accidentally rewound head" situation, because
it is prevented from running under certain conditions as you
described. But that does not necessarily mean we should make
"ours" to work in these situations.
You accidentally discarded B while somebody picked it up:
o---o
/ \
---o---o---A---o---o---B
^your head
Now you would want to recover. With your patch, it would create
this:
o---o
/ \
---o---o---A---o---o---B
\ \
------------M
^your updated head,
having the same tree as A
But recording A as a parent of M is not necessary. I think what
we want to have as the result is this instead:
o---o
/ \
---o---o---A---o---o---B---M
^your updated head,
having the same tree as A
This is something you cannot do within the current git-merge
framework; it is set up to either just fast forward or make a
multi-parent commit. You would want have a "revert to this
state" [*1*], something like this (assuming you have rewound to
A and currently your index matches A):
$ git reset --soft B
$ git commit -m 'Discard A..B and revert to A'
I did "ours" primarily as a demonstration of a funky thing
people could do with the consolidated driver "git-merge". I did
not have a useful use-case in mind back then, but it turned out
to be the ideal way to recover from "accidentally rewound head"
situation, except that making a merge commit between A and B is
not always the way to recover from it. If we wanted to, we
could have a special purpose command that does "git merge -s
ours" if there will be a new commit, otherwise the above two
commands sequence if it will be a fast forward, but the
"recovering from accidentally rewound head" _is_ really a
special purpose, so I do not know if it is worth it.
In your cover letter, you talked about using --no-fast-forward
to collapse your sole topic branch into your master branch. I
do not think smudging the development history with extra merge
commits for that is justfied either. There is no reason for you
to discard your topic branch heads after you merged them into
master. If they get in the way of your normal workflow, you can
stash them away as tags that you do not usually see in "git
branch" output [*2*].
Also I am already unhappy that git-merge knows about the
specifics of strategies [*3*], e.g. it knows octopus is
currently the only strategy that can do more than two heads.
Your patch gives more strategy specific knowledge to it, but I
do not know how to avoid it.
[Footnotes]
*1* As opposed to "git revert X" which means "revert the effect
of commit X", you would want "revert to the state X".
*2* I keep some of my old topic branch heads under
.git/tags/attic/.
*3* Another thing I am unhappy about is the list of available
strategies. I initially wanted to allow users to write their
own merge strategies and have them on their PATH (not even
necessarily in GIT_EXEC_PATH directory), so that you can do a
git-merge-mdw secretly, keep it in ~mdw/bin and cook it for a
while using yourself as a guinea pig, and then share that with
the community later, _without_ touching git-merge.
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Junio C Hamano @ 2006-03-18 19:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603181315060.4889@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
> has to be computed for every offset in the target buffer, increases
> accordingly. So you end up with both worse compression and more CPU
> usage.
Ah, I was not paying enough attention. I did not realize
destination scanning was done for every byte.
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Nicolas Pitre @ 2006-03-18 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtesxloi.fsf@assigned-by-dhcp.cox.net>
On Fri, 17 Mar 2006, Junio C Hamano wrote:
> Once you make it into a patch form, it is plainly obvious that
> this is a good optimization. Since our BLK_SIZE is 16 bytes,
> you are grabbing up to 15 more bytes (on average 8 more bytes or
> so) for every match after a partially modified block.
>
> Very nice. I wonder if a larger BLK_SIZE (say 32 bytes) would
> give us faster packing without losing much compression if we use
> this idea.
Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
has to be computed for every offset in the target buffer, increases
accordingly. So you end up with both worse compression and more CPU
usage.
Nicolas
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Fredrik Kuivinen @ 2006-03-18 16:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On Sat, Mar 18, 2006 at 04:25:04PM +0100, Nikolai Weibull wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
Oh, I didn't know about that.
<updates zsh>
Very nice! Much better than my crude cut-and-paste work.
Junio: Please don't apply the patch.
- Fredrik
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Nikolai Weibull @ 2006-03-18 16:14 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <4fb292fa0603180752r731c628eoa2b96fcd6ef43e0f@mail.gmail.com>
On 3/18/06, Bertrand Jacquin <beber.mailing@gmail.com> wrote:
> On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> > On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> > >
> > > Based on the completion code for quilt in the Zsh distribution.
> >
> > Actually, there's an almost-complete implementation in 4.3 already.
> > Written by me nonetheless. You can take a look and make suggestions
> > if you like :-). I have an updated version to deal with post
> > 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
> Any plan do to this for cogito ?
Sure, and stgit as well, but I haven't gotten around to it. The idea
was to reuse as much as possible of the stuff that the three have in
common (like tags, references, and so on), but as I haven't used
either of the two (cogito and stgit) I haven't had a compelling reason
to sit down and do it.
nikolai
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Bertrand Jacquin @ 2006-03-18 15:52 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
Any plan do to this for cogito ?
>
> nikolai
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Beber
#e.fr@freenode
^ 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