* [PATCH 2/5] git.el: Set default directory before running the status mode setup hooks.
From: Alexandre Julliard @ 2006-03-04 16:38 UTC (permalink / raw)
To: git
Also set the list-buffers-directory variable for nicer buffer list
display.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
437d990348e13e6a4460cc445ec5d2b2077cf2fb
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5828d4c..2363e48 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -943,6 +943,7 @@ Commands:
(erase-buffer)
(let ((status (ewoc-create 'git-fileinfo-prettyprint "" "")))
(set (make-local-variable 'git-status) status))
+ (set (make-local-variable 'list-buffers-directory) default-directory)
(run-hooks 'git-status-mode-hook)))
(defun git-status (dir)
@@ -952,8 +953,8 @@ Commands:
(if (file-directory-p (concat (file-name-as-directory dir) ".git"))
(let ((buffer (create-file-buffer (expand-file-name "*git-status*" dir))))
(switch-to-buffer buffer)
- (git-status-mode)
(cd dir)
+ (git-status-mode)
(git-refresh-status)
(goto-char (point-min)))
(message "%s is not a git working tree." dir)))
--
1.2.4.g0040-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 1/5] git.el: Portability fixes for XEmacs and Emacs CVS.
From: Alexandre Julliard @ 2006-03-04 16:37 UTC (permalink / raw)
To: git
Fixed octal constants for XEmacs.
Added highlighting support in log-edit buffer for Emacs CVS.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
7c95060616dd2f596d2f0bc0d707c584002913db
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8f23477..5828d4c 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -388,9 +388,9 @@ If not set, fall back to `add-log-mailin
(propertize
(if (or (not old-perm)
(not new-perm)
- (eq 0 (logand #O111 (logxor old-perm new-perm))))
+ (eq 0 (logand ?\111 (logxor old-perm new-perm))))
" "
- (if (eq 0 (logand #O111 old-perm)) "+x" "-x"))
+ (if (eq 0 (logand ?\111 old-perm)) "+x" "-x"))
'face 'git-permission-face))
(defun git-fileinfo-prettyprint (info)
@@ -806,7 +806,13 @@ If not set, fall back to `add-log-mailin
"\n")
(when (and merge-heads (file-readable-p ".git/MERGE_MSG"))
(insert-file-contents ".git/MERGE_MSG"))))
- (log-edit #'git-do-commit nil #'git-log-edit-files buffer)))
+ (let ((log-edit-font-lock-keywords
+ `(("^\\(Author:\\|Date:\\|Parent:\\)\\(.*\\)"
+ (1 font-lock-keyword-face)
+ (2 font-lock-function-name-face))
+ (,(concat "^\\(" (regexp-quote git-log-msg-separator) "\\)$")
+ (1 font-lock-comment-face)))))
+ (log-edit #'git-do-commit nil #'git-log-edit-files buffer))))
(defun git-find-file ()
"Visit the current file in its own buffer."
@@ -891,7 +897,7 @@ If not set, fall back to `add-log-mailin
(define-key map "d" diff-map)
(define-key map "=" 'git-diff-file)
(define-key map "f" 'git-find-file)
- (define-key map [RET] 'git-find-file)
+ (define-key map "\r" 'git-find-file)
(define-key map "g" 'git-refresh-status)
(define-key map "i" 'git-ignore-file)
(define-key map "l" 'git-log-file)
--
1.2.4.g0040-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Emacs git interface
From: Jakub Narebski @ 2006-03-04 15:10 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
Thank you for creating Emacs git interface.
You might want to take a look at other Emacs version control interfaces
http://www.emacswiki.org/cgi-bin/wiki/CategoryVersionControl
especially for distributed SCMs similar to Git: Mercurial and Monotone:
http://hg.serpentine.com/mercurial/bos?f=794a337fb657;file=contrib/mercurial.el;style=gitweb
http://viewmtn.angrygoats.net/getfile.py?id=file&path=contrib/monotone.el
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] contrib/emacs: Add an Emacs VC backend.
From: Alexandre Julliard @ 2006-03-04 14:32 UTC (permalink / raw)
To: git
Add a basic Emacs VC backend. It currently supports the following
commands: checkin, checkout, diff, log, revert, and annotate. There is
only limited support for working with revisions other than HEAD.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/vc-git.el | 135 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 contrib/emacs/vc-git.el
b0c7984b6da71ab875c40a661b9a743370c41dfb
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
new file mode 100644
index 0000000..2453cdc
--- /dev/null
+++ b/contrib/emacs/vc-git.el
@@ -0,0 +1,135 @@
+;;; vc-git.el --- VC backend for the git version control system
+
+;; Copyright (C) 2006 Alexandre Julliard
+
+;; This program is free software; you can redistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; published by the Free Software Foundation; either version 2 of
+;; the License, or (at your option) any later version.
+;;
+;; This program is distributed in the hope that it will be
+;; useful, but WITHOUT ANY WARRANTY; without even the implied
+;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+;; PURPOSE. See the GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public
+;; License along with this program; if not, write to the Free
+;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+;; MA 02111-1307 USA
+
+;;; Commentary:
+
+;; This file contains a VC backend for the git version control
+;; system.
+;;
+;; To install: put this file on the load-path and add GIT to the list
+;; of supported backends in `vc-handled-backends'.
+;;
+;; TODO
+;; - changelog generation
+;; - working with revisions other than HEAD
+;;
+
+(defvar git-commits-coding-system 'utf-8
+ "Default coding system for git commits.")
+
+(defun vc-git--run-command-string (file &rest args)
+ "Run a git command on FILE and return its output as string."
+ (let* ((ok t)
+ (str (with-output-to-string
+ (with-current-buffer standard-output
+ (unless (eq 0 (apply #'call-process "git" nil '(t nil) nil
+ (append args (list (file-relative-name file)))))
+ (setq ok nil))))))
+ (and ok str)))
+
+(defun vc-git--run-command (file &rest args)
+ "Run a git command on FILE, discarding any output."
+ (let ((name (file-relative-name file)))
+ (eq 0 (apply #'call-process "git" nil (get-buffer "*Messages") nil (append args (list name))))))
+
+(defun vc-git-registered (file)
+ "Check whether FILE is registered with git."
+ (with-temp-buffer
+ (let* ((dir (file-name-directory file))
+ (name (file-relative-name file dir)))
+ (when dir (cd dir))
+ (and (eq 0 (call-process "git" nil '(t nil) nil "ls-files" "-c" "-z" "--" name))
+ (let ((str (buffer-string)))
+ (and (> (length str) (length name))
+ (string= (substring str 0 (1+ (length name))) (concat name "\0"))))))))
+
+(defun vc-git-state (file)
+ "git-specific version of `vc-state'."
+ (let ((diff (vc-git--run-command-string file "diff-index" "-z" "HEAD" "--")))
+ (if (and diff (string-match ":[0-7]\\{6\\} [0-7]\\{6\\} [0-9a-f]\\{40\\} [0-9a-f]\\{40\\} [ADMU]\0[^\0]+\0" diff))
+ 'edited
+ 'up-to-date)))
+
+(defun vc-git-workfile-version (file)
+ "git-specific version of `vc-workfile-version'."
+ (let ((str (with-output-to-string
+ (with-current-buffer standard-output
+ (call-process "git" nil '(t nil) nil "symbolic-ref" "HEAD")))))
+ (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str)
+ (match-string 2 str)
+ str)))
+
+(defun vc-git-revert (file &optional contents-done)
+ "Revert FILE to the version stored in the git repository."
+ (if contents-done
+ (vc-git--run-command file "update-index" "--")
+ (vc-git--run-command file "checkout" "HEAD")))
+
+(defun vc-git-checkout-model (file)
+ 'implicit)
+
+(defun vc-git-workfile-unchanged-p (file)
+ (let ((sha1 (vc-git--run-command-string file "hash-object" "--"))
+ (head (vc-git--run-command-string file "ls-tree" "-z" "HEAD" "--")))
+ (and head
+ (string-match "[0-7]\\{6\\} blob \\([0-9a-f]\\{40\\}\\)\t[^\0]+\0" head)
+ (string= (car (split-string sha1 "\n")) (match-string 1 head)))))
+
+(defun vc-git-register (file &optional rev comment)
+ "Register FILE into the git version-control system."
+ (vc-git--run-command file "update-index" "--add" "--"))
+
+(defun vc-git-print-log (file)
+ (let ((name (file-relative-name file))
+ (coding-system-for-read git-commits-coding-system))
+ (vc-do-command nil 'async "git" name "rev-list" "--pretty" "HEAD" "--")))
+
+(defun vc-git-diff (file &optional rev1 rev2)
+ (let ((name (file-relative-name file)))
+ (if (and rev1 rev2)
+ (vc-do-command "*vc-diff*" 0 "git" name "diff-tree" "-p" rev1 rev2 "--")
+ (vc-do-command "*vc-diff*" 0 "git" name "diff-index" "-p" (or rev1 "HEAD") "--"))
+ ; git-diff-index doesn't set exit status like diff does
+ (if (vc-git-workfile-unchanged-p file) 0 1)))
+
+(defun vc-git-checkin (file rev comment)
+ (let ((coding-system-for-write git-commits-coding-system))
+ (vc-git--run-command file "commit" "-m" comment "--only" "--")))
+
+(defun vc-git-checkout (file &optional editable rev destfile)
+ (vc-git--run-command file "checkout" (or rev "HEAD")))
+
+(defun vc-git-annotate-command (file buf &optional rev)
+ ; FIXME: rev is ignored
+ (let ((name (file-relative-name file)))
+ (call-process "git" nil buf nil "annotate" name)))
+
+(defun vc-git-annotate-time ()
+ (and (re-search-forward "[0-9a-f]+\t(.*\t\\([0-9]+\\)-\\([0-9]+\\)-\\([0-9]+\\) \\([0-9]+\\):\\([0-9]+\\):\\([0-9]+\\) \\([-+0-9]+\\)\t[0-9]+)" nil t)
+ (vc-annotate-convert-time
+ (apply #'encode-time (mapcar (lambda (match) (string-to-number (match-string match))) '(6 5 4 3 2 1 7))))))
+
+;; Not really useful since we can't do anything with the revision yet
+;;(defun vc-annotate-extract-revision-at-line ()
+;; (save-excursion
+;; (move-beginning-of-line 1)
+;; (and (looking-at "[0-9a-f]+")
+;; (buffer-substring (match-beginning 0) (match-end 0)))))
+
+(provide 'vc-git)
--
1.2.4.g0040-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: On recording renames
From: Junio C Hamano @ 2006-03-04 13:19 UTC (permalink / raw)
To: git; +Cc: paul
In-Reply-To: <7v64muvin9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> A bit more on merges and renames...
> The whole thread is worth reading, but the punch line is:
>
> The transition happened over time with multiple commits.
> You cannot record "this is the rename" by attributing that
> information to one particular commit.
After re-reading that thread, and especially the analysis of the
history of that part of the kernel source I did back then, I am
again convinced that Linus was right when he said "file renames
do not matter". That real-life example shows how inadequate
file boundaries are when dealing with content changes.
An ideal merge strategy would handle the case where pieces of
code gradually moves around across file boundaries. I do not
think this is something you can sensibly do by recording file
rename history. It would not help the situation a bit even if
you gave each file (or content or object or whatever you want to
call it) a persistent ID.
One way (now, it is my turn to handwave) to do such a merge
might be to take the whole tree as if it were a flat single file
(think of it as a concatenation of all files in the tree) with
each line tagged with the pathname. You and your friend would
start from something like this. A single file that describe
topics of interest to both of you:
notes.txt:Kernel Topics
notes.txt: - filesystem
notes.txt: - scheduler
notes.txt: - devices
notes.txt:Cool Git Topics
notes.txt: - git-cvsserver
notes.txt: - Cogito
And your friend splits this into two files and starts editing,
while you edit the original file:
your friend you
linux.txt:Kernel Topics notes.txt:Kernel Topics
linux.txt: - filesystem notes.txt: - filesystem
linux.txt: - scheduler notes.txt: - scheduler
linux.txt: - devices notes.txt: - devices
linux.txt: - stable driver API notes.txt: - mm
git.txt:Cool Git Topics notes.txt:Cool Git Topics
git.txt: - git-cvsserver notes.txt: - git-cvsserver
git.txt: - Cogito notes.txt: - gitview
notes.txt: - Cogito
notes.txt: - StGIT
notes.txt: - diff --cc
Now you would want to compare notes and merge them. When
comparing these two "trees", the clever merge algorithm would
treat this two-column thingy and merge both labels
(i.e. pathnames) and contents:
linux.txt:Kernel Topics
linux.txt: - filesystem
linux.txt: - scheduler
linux.txt: - devices
linux.txt: - mm
linux.txt: - stable driver API
git.txt:Cool Git Topics
git.txt: - git-cvsserver
git.txt: - gitview
git.txt: - Cogito
git.txt: - StGIT
git.txt: - diff --cc
It could even guess that the line you touched are related to the
hunk your friend moved to another file (iow, your friend gave a
new label to the region you touched), and label your new line
with the same pathname as surrounding lines.
I suspect this is weave merge taken to its extreme, but I am
handwaving so please do not ask me how I would propose to
implement it ;-). The point really is that file is a poor unit
of operation when dealing with changes.
^ permalink raw reply
* Re: Problems with using git
From: Mark Wooding @ 2006-03-04 10:56 UTC (permalink / raw)
To: git
In-Reply-To: <20060302235824.GA13436@kroah.com>
Greg KH <greg@kroah.com> wrote:
> The latest development tree, and the latest public betas contain
> 1.1.3. If you think this should be newer, I can easily go poke the
> proper people...
Given that there's a security issue which got fixed in 1.1.5, I think
this is really a bit poor.
I notice, by contrast, that Debian had managed to repackage and release
a new GIT the day after Junio fixed the bug in the first place. That
was more than a month ago.
-- [mdw]
^ permalink raw reply
* cvsimport woes
From: Rajkumar S @ 2006-03-04 7:47 UTC (permalink / raw)
To: git
Hi,
I am trying to track a cvs project using git. The idea is to use cvsimport to update my
local git copy and make my changes in a separate branch. But for some reason after
cvsimport the last update of cvs repository is not reflected in git. I have made a small
script to test this behavior and am able to reproduce is consistently. I am working on
FreeBSD 6.0-RELEASE, git version 1.2.4 and cvsps version 2.1
The first script is to init a cvs repository, add 3 files and cvsimport it into git
repository, before which I remove the all directories and .cvsps
raj@beastie:~$ cat git_init.sh
export CVSROOT=/home/raj/cvsroot
rm -rf cvsroot/ git/ src/ /home/raj/.cvsps
mkdir cvsroot git src
cvs init
cd src/
echo "Line one" > file.txt
echo "Line one" > file1.txt
echo "Line one" > file2.txt
cvs import -m "Imported sources" src start realstart
cd ..
rm -rf src/
cvs co src
git cvsimport -v -d /home/raj/cvsroot -C git/ src
on executing:
N src/file.txt
N src/file1.txt
N src/file2.txt
No conflicts created by this import
cvs checkout: Updating src
U src/file.txt
U src/file1.txt
U src/file2.txt
cvs_direct initialized to CVSROOT /home/raj/cvsroot
cvs rlog: Logging src
Fetching file.txt v 1.1
New file.txt: 9 bytes
Fetching file1.txt v 1.1
New file1.txt: 9 bytes
Fetching file2.txt v 1.1
New file2.txt: 9 bytes
Tree ID b75643d0deaa77018b4dbaa2ff81756c4c1bebc1
Committed patch 1 (origin 2006-03-04 07:37:59)
Committing initial tree b75643d0deaa77018b4dbaa2ff81756c4c1bebc1
Commit ID e800fd633e319b9a0b4c351f2964a03abf96b6e2
Fetching file.txt v 1.1.1.1
Update file.txt: 9 bytes
Fetching file1.txt v 1.1.1.1
Update file1.txt: 9 bytes
Fetching file2.txt v 1.1.1.1
Update file2.txt: 9 bytes
Tree ID b75643d0deaa77018b4dbaa2ff81756c4c1bebc1
Parent ID e800fd633e319b9a0b4c351f2964a03abf96b6e2
Committed patch 2 (start 2006-03-04 07:37:59)
Commit ID 21bd067b19310d11790e99ad421de6611b942fbd
Created tag 'realstart' on 'start'
DONE; creating master branch
Now edit two files, commit cvs and cvsupdate again.
raj@beastie:~$ cat git_test.sh
export CVSROOT=/home/raj/cvsroot
cd src/
echo "Line two" >> file.txt
echo "Line two" >> file1.txt
cvs commit -m "v2.0"
cd ..
git cvsimport -v -d /home/raj/cvsroot -C git/ src
cd git
git status
cd ..
echo cat git/file.txt
cat git/file.txt
echo cat src/file.txt
cat src/file.txt
on executing:
cvs commit: Examining .
Checking in file.txt;
/home/raj/cvsroot/src/file.txt,v <-- file.txt
new revision: 1.2; previous revision: 1.1
done
Checking in file1.txt;
/home/raj/cvsroot/src/file1.txt,v <-- file1.txt
new revision: 1.2; previous revision: 1.1
done
cvs_direct initialized to CVSROOT /home/raj/cvsroot
cvs rlog: Logging src
skip patchset 1: 1141457879 before 1141457879
skip patchset 2: 1141457879 before 1141457879
Switching from master to origin
Fetching file.txt v 1.2
Update file.txt: 18 bytes
Fetching file1.txt v 1.2
Update file1.txt: 18 bytes
Tree ID 18d855d5b825ef1c0ecb9d26591e654cbe5c21df
Parent ID e800fd633e319b9a0b4c351f2964a03abf96b6e2
Committed patch 3 (origin 2006-03-04 07:39:35)
Commit ID 6e7129d186834d5b2941e78c1c67c5255f868e12
DONE
#
# Updated but not checked in:
# (will commit)
#
# modified: file.txt
# modified: file1.txt
#
cat git/file.txt
Line one
cat src/file.txt
Line one
Line two
As you can see the git/file.txt and src/file.txt are different. I have tried my best to
read all documentation and follow them faithfully and I hope I am not making any obviously
stupid mistake.
raj
^ permalink raw reply
* [PATCH] cvsserver: anonymous cvs via pserver support
From: Martin Langhoff @ 2006-03-04 7:30 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
git-cvsserver now knows how to do the pserver auth chat when the user
is anonymous. To get it to work, add a line to your inetd.conf like
cvspserver stream tcp nowait nobody git-cvsserver pserver
(On some inetd implementations you may have to put the pserver parameter twice.)
Commits are blocked. Naively, git-cvsserver assumes non-malicious users. Please
review the code before setting this up on an internet-accessible server.
NOTE: the <nobody> user above will need write access to the .git directory
to maintain the sqlite database. Updating of the sqlite database should be
put in an update hook to avoid this problem, so that it is maintained by
users with write access.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-cvsserver.perl | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
91a6bf468230d63c414a21adeef94f1242eaaaab
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index b450792..7d3f78e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -87,6 +87,31 @@ $log->info("--------------- STARTING ---
my $TEMP_DIR = tempdir( CLEANUP => 1 );
$log->debug("Temporary directory is '$TEMP_DIR'");
+# if we are called with a pserver argument,
+# deal with the authentication cat before entereing the
+# main loop
+if (@ARGV && $ARGV[0] eq 'pserver') {
+ my $line = <STDIN>; chomp $line;
+ unless( $line eq 'BEGIN AUTH REQUEST') {
+ die "E Do not understand $line - expecting BEGIN AUTH REQUEST\n";
+ }
+ $line = <STDIN>; chomp $line;
+ req_Root('root', $line) # reuse Root
+ or die "E Invalid root $line \n";
+ $line = <STDIN>; chomp $line;
+ unless ($line eq 'anonymous') {
+ print "E Only anonymous user allowed via pserver\n";
+ print "I HATE YOU\n";
+ }
+ $line = <STDIN>; chomp $line; # validate the password?
+ $line = <STDIN>; chomp $line;
+ unless ($line eq 'END AUTH REQUEST') {
+ die "E Do not understand $line -- expecting END AUTH REQUEST\n";
+ }
+ print "I LOVE YOU\n";
+ # and now back to our regular programme...
+}
+
# Keep going until the client closes the connection
while (<STDIN>)
{
@@ -165,6 +190,7 @@ sub req_Root
print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
print "E \n";
print "error 1 GITCVS emulation disabled\n";
+ return 0;
}
if ( defined ( $cfg->{gitcvs}{logfile} ) )
@@ -173,6 +199,8 @@ sub req_Root
} else {
$log->nofile();
}
+
+ return 1;
}
# Global_option option \n
@@ -914,6 +942,12 @@ sub req_ci
$log->info("req_ci : " . ( defined($data) ? $data : "[NULL]" ));
+ if ( @ARGV && $ARGV[0] eq 'pserver')
+ {
+ print "error 1 pserver access cannot commit\n";
+ exit;
+ }
+
if ( -e $state->{CVSROOT} . "/index" )
{
print "error 1 Index already exists in git repo\n";
--
1.2.4.g09a27-dirty
^ permalink raw reply related
* Re: [PATCH] Add a Documentation/git-tools.txt
From: Marco Costalba @ 2006-03-04 6:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Julliard, git
In-Reply-To: <87psl9i4as.fsf@wine.dyndns.org>
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
Documentation/git-tools.txt | 97 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-tools.txt
5e8c2ec9d08dce7f333b0963d7911c3096ab6588
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
new file mode 100644
index 0000000..00e57a6
--- /dev/null
+++ b/Documentation/git-tools.txt
@@ -0,0 +1,97 @@
+A short git tools survey
+========================
+
+
+Introduction
+------------
+
+Apart from git contrib/ area there are some others third-party tools
+you may want to look.
+
+This document presents a brief summary of each tool and the corresponding
+link.
+
+
+Alternative/Augmentative Procelains
+-----------------------------------
+
+ - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
+
+ Cogito is a version control system layered on top of the git tree history
+ storage system. It aims at seamless user interface and ease of use,
+ providing generally smoother user experience than the "raw" Core GIT
+ itself and indeed many other version control systems.
+
+
+ - *pg* (http://www.spearce.org/category/projects/scm/pg/)
+
+ pg is a shell script wrapper around GIT to help the user manage a set of
+ patches to files. pg is somewhat like quilt or StGIT, but it does have a
+ slightly different feature set.
+
+
+ - *StGit* (http://www.procode.org/stgit/)
+
+ Stacked GIT provides a quilt-like patch management functionality in the
+ GIT environment. You can easily manage your patches in the scope of GIT
+ until they get merged upstream.
+
+
+History Viewers
+---------------
+
+ - *gitk* (shipped with git-core)
+
+ gitk is a simple TK GUI for browsing history of GIT repositories easily.
+
+
+ - *gitview* (contrib/)
+
+ gitview is a GTK based repository browser for git
+
+
+ - *gitweb* (ftp://ftp.kernel.org/pub/software/scm/gitweb/)
+
+ GITweb provides full-fledged web interface for GIT repositories.
+
+
+ - *qgit* (http://digilander.libero.it/mcostalba/)
+
+ QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ to browse history and directory tree, view annotated files, commit
+ changes cherry picking single files or applying patches.
+ Currently it is the fastest and most feature rich among the git
+ viewers and commit tools.
+
+
+
+Foreign SCM interface
+---------------------
+
+ - *git-svn* (contrib/)
+
+ git-svn is a simple conduit for changesets between a single Subversion
+ branch and git.
+
+
+ - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)
+
+ These utilities convert patch series in a quilt repository and commit
+ series in git back and forth.
+
+
+Others
+------
+
+ - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)
+
+ Commit Tool or (h)gct is a GUI enabled commit tool for git and
+ Mercurial (hg). It allows the user to view diffs, select which files
+ to committed (or ignored / reverted) write commit messages and
+ perform the commit itself.
+
+ - *git.el* (contrib/)
+
+ This is an Emacs interface for git. The user interface is modeled on
+ pcl-cvs. It has been developed on Emacs 21 and will probably need some
+ tweaking to work on XEmacs.
--
1.2.2.gce4c
^ permalink raw reply related
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Linus Torvalds @ 2006-03-04 6:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vfylzx7t3.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Mar 2006, Junio C Hamano wrote:
>
> The first round. The set of objects packed were from
> today's Linus tip (everything down to epoch v2.6.12-rc2), 193309
> objects in total, on my Duron 750 with slow disks.
>
> real user sys bytes savings
> master 11m17.121s 10m23.280s 0m47.290s 109045599 N/A
> nico 25m37.058s 23m0.770s 2m20.460s 104401392 4.25%
> jc 24m12.072s 21m45.120s 2m16.400s 104409761 4.25%
Ouch.
Btw, it's often worth using /usr/bin/time instead of the bash built-in
time. Why? Because /usr/bin/time reports one absolutely _hugely_ important
number (maybe more important than almost any of the other numbers in
there).
Which one? It's the "minor pagefaults". That's a very good approximation
of memory usage overhead.
We've already had one person report that they ran out of memory when
packing. So memory usage is actually a problem.
Anyway, it looks like the 16-byte window is the way to go, even regardless
of any memory use issue.
Linus
^ permalink raw reply
* Re: On recording renames
From: Junio C Hamano @ 2006-03-04 6:16 UTC (permalink / raw)
To: git; +Cc: paul
In-Reply-To: <7vfylyx3e3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>
> a1--a2--a3--a4--a5--A
> / \
> ---O---b1--b2--b3--b4--B---*
>
> O has hello.c
> a1 renames file hello.c to world.c and a2-a5-A modifies world.c
> b1-b4-B modifies hello.c
> we are about to merge A and B
>
> comparing O and A may not notice O's hello.c and A's world.c
> are similar!
>
> But you are allowed to write a new merge strategy that is more
> careful about renames. There is no reason you can only look at
> three trees. Such a merge strategy, when given commit A and B,
> would walk the history back, running "diff-tree -M" for each
> commit along the way, and difference between O's hello.c and
> a1's world.c would be hopefully *much* smaller than O's hello.c
> and A's world.c -- even the current similarity estimator may
> recognize it is a rename.
A bit more on merges and renames. The thread that started on
Dec 16 2005 by Don Zickus is about a case that anybody
interested in renaming merge should think about. Unfortunately
gmane web interface says it is "down for maintenance" so I
cannot give an URL, but the message IDs of key messages are:
<68948ca0512161205x3d5921bfm3bfcaa64f988eb99@mail.gmail.com>
<7vbqzgbcyv.fsf@assigned-by-dhcp.cox.net>
The whole thread is worth reading, but the punch line is:
The transition happened over time with multiple commits.
You cannot record "this is the rename" by attributing that
information to one particular commit.
^ permalink raw reply
* [PATCH] tar-tree: file/dirmode fix.
From: Junio C Hamano @ 2006-03-04 5:35 UTC (permalink / raw)
To: git; +Cc: Matt McCutchen
In-Reply-To: <1141446331.3171.4.camel@mattlaptop>
This fixes two bugs introduced when we switched to generic tree
traversal code.
(1) directory mode recorded silently became 0755, not 0777
(2) if passed a tree object (not a commit), it emitted an
alarming error message (but proceeded anyway).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
tar-tree.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
815afaf1bd0ddf419231d2d9f129260ce1ddbecc
diff --git a/tar-tree.c b/tar-tree.c
index e85a1ed..e478e13 100644
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -304,9 +304,11 @@ static void write_header(const unsigned
}
if (S_ISDIR(mode))
- mode |= 0755; /* GIT doesn't store permissions of dirs */
- if (S_ISLNK(mode))
- mode |= 0777; /* ... nor of symlinks */
+ mode |= 0777;
+ else if (S_ISREG(mode))
+ mode |= (mode & 0100) ? 0777 : 0666;
+ else if (S_ISLNK(mode))
+ mode |= 0777;
sprintf(&header[100], "%07o", mode & 07777);
/* XXX: should we provide more meaningful info here? */
@@ -391,7 +393,7 @@ int main(int argc, char **argv)
usage(tar_tree_usage);
}
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference_gently(sha1, 1);
if (commit) {
write_global_extended_header(commit->object.sha1);
archive_time = commit->date;
--
1.2.4.gfe04
^ permalink raw reply related
* Re: Producing tar file with 666/777 permissions
From: Junio C Hamano @ 2006-03-04 5:03 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1141446331.3171.4.camel@mattlaptop>
Matt McCutchen <hashproduct@verizon.net> writes:
> Dear GIT people,
>
> How do I package a git repository in a tar file with 666 and 777
> embedded permissions? There's evidently some way to do it because the
> Linux kernel source packages have 666 and 777 embedded permissions, but
> git-tar-tree gives me a tar file with 644 and 755 permissions and
> there's no obvious way to tell it to do otherwise.
Ouch, thanks for reporting this. You have spotted a recent
regression.
^ permalink raw reply
* [PATCH] cvsserver: nested directory creation fixups for Eclipse clients
From: Martin Langhoff @ 2006-03-04 4:47 UTC (permalink / raw)
To: git, junkio; +Cc: Martin Langhoff
To create nested directories without (or before) sending file entries
is rather tricky. Most clients just work. Eclipse, however, expects
a very specific sequence of events. With this patch, cvsserver meets
those expectations.
Note: we may want to reuse prepdir() in req_update -- should move it
outside of req_co. Right now prepdir() is tied to how req_co() works.
---
git-cvsserver.perl | 73 ++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 56 insertions(+), 17 deletions(-)
701168bf1ddad1dbc3788e58181589dc082ce536
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ab32d3e..b450792 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -592,6 +592,11 @@ sub req_co
print $state->{CVSROOT} . "/$module/\n";
print "Clear-static-directory $checkout_path/\n";
print $state->{CVSROOT} . "/$module/\n";
+ print "Clear-sticky $checkout_path/\n"; # yes, twice
+ print $state->{CVSROOT} . "/$module/\n";
+ print "Template $checkout_path/\n";
+ print $state->{CVSROOT} . "/$module/\n";
+ print "0\n";
# instruct the client that we're checking out to $checkout_path
print "E cvs checkout: Updating $checkout_path\n";
@@ -599,6 +604,43 @@ sub req_co
my %seendirs = ();
my $lastdir ='';
+ # recursive
+ sub prepdir {
+ my ($dir, $repodir, $remotedir, $seendirs) = @_;
+ my $parent = dirname($dir);
+ $dir =~ s|/+$||;
+ $repodir =~ s|/+$||;
+ $remotedir =~ s|/+$||;
+ $parent =~ s|/+$||;
+ $log->debug("announcedir $dir, $repodir, $remotedir" );
+
+ if ($parent eq '.' || $parent eq './') {
+ $parent = '';
+ }
+ # recurse to announce unseen parents first
+ if (length($parent) && !exists($seendirs->{$parent})) {
+ prepdir($parent, $repodir, $remotedir, $seendirs);
+ }
+ # Announce that we are going to modify at the parent level
+ if ($parent) {
+ print "E cvs checkout: Updating $remotedir/$parent\n";
+ } else {
+ print "E cvs checkout: Updating $remotedir\n";
+ }
+ print "Clear-sticky $remotedir/$parent/\n";
+ print "$repodir/$parent/\n";
+
+ print "Clear-static-directory $remotedir/$dir/\n";
+ print "$repodir/$dir/\n";
+ print "Clear-sticky $remotedir/$parent/\n"; # yes, twice
+ print "$repodir/$parent/\n";
+ print "Template $remotedir/$dir/\n";
+ print "$repodir/$dir/\n";
+ print "0\n";
+
+ $seendirs->{$dir} = 1;
+ }
+
foreach my $git ( @{$updater->gethead} )
{
# Don't want to check out deleted files
@@ -606,6 +648,17 @@ sub req_co
( $git->{name}, $git->{dir} ) = filenamesplit($git->{name});
+ if (length($git->{dir}) && $git->{dir} ne './'
+ && $git->{dir} ne $lastdir ) {
+ unless (exists($seendirs{$git->{dir}})) {
+ prepdir($git->{dir}, $state->{CVSROOT} . "/$module/",
+ $checkout_path, \%seendirs);
+ $lastdir = $git->{dir};
+ $seendirs{$git->{dir}} = 1;
+ }
+ print "E cvs checkout: Updating /$checkout_path/$git->{dir}\n";
+ }
+
# modification time of this file
print "Mod-time $git->{modified}\n";
@@ -617,24 +670,10 @@ sub req_co
print "M U $checkout_path/$git->{name}\n";
}
- if (length($git->{dir}) && $git->{dir} ne './'
- && $git->{dir} ne $lastdir && !exists($seendirs{$git->{dir}})) {
-
- # Eclipse seems to need the Clear-sticky command
- # to prepare the 'Entries' file for the new directory.
- print "Clear-sticky $checkout_path/$git->{dir}\n";
- print $state->{CVSROOT} . "/$module/$git->{dir}\n";
- print "Clear-static-directory $checkout_path/$git->{dir}\n";
- print $state->{CVSROOT} . "/$module/$git->{dir}\n";
- print "E cvs checkout: Updating /$checkout_path/$git->{dir}\n";
- $lastdir = $git->{dir};
- $seendirs{$git->{dir}} = 1;
- }
-
- # instruct client we're sending a file to put in this path
- print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
+ # instruct client we're sending a file to put in this path
+ print "Created $checkout_path/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "\n";
- print $state->{CVSROOT} . "/$module/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "$git->{name}\n";
+ print $state->{CVSROOT} . "/$module/" . ( defined ( $git->{dir} ) and $git->{dir} ne "./" ? $git->{dir} . "/" : "" ) . "$git->{name}\n";
# this is an "entries" line
print "/$git->{name}/1.$git->{revision}///\n";
--
1.2.4.g09a27-dirty
^ permalink raw reply related
* Producing tar file with 666/777 permissions
From: Matt McCutchen @ 2006-03-04 4:25 UTC (permalink / raw)
To: git
Dear GIT people,
How do I package a git repository in a tar file with 666 and 777
embedded permissions? There's evidently some way to do it because the
Linux kernel source packages have 666 and 777 embedded permissions, but
git-tar-tree gives me a tar file with 644 and 755 permissions and
there's no obvious way to tell it to do otherwise.
There was lots of discussion on the mailing list about what permissions
to preserve when copying in and out of repositories (I obviously side
with those who want a single execute bit), but I could not find any
mention of permission issues in reference to git-tar-tree.
Please reply to me as I am off-list.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: On recording renames
From: Paul Jakma @ 2006-03-04 4:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylyx3e3.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
On Fri, 3 Mar 2006, Junio C Hamano wrote:
> Recently some people said "I want to tell git that I renamed fileA
> to fileB" on the list and #git channel,
> *1* This is by design, and I am not going to debate if that is a
> good design or not here.
Thanks for your detailed email. Before I continue digesting it, I'd
like to revise my original proposal (having now read the
more of the 'design philosophy'):
- I want to tell git that object A is related to object B between two
trees.
I think at this stage a proof-of-concept would be an idea. I'll try
get back with that before end of the month.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
we just switched to Sprint.
^ permalink raw reply
* On recording renames
From: Junio C Hamano @ 2006-03-04 4:03 UTC (permalink / raw)
To: git; +Cc: paul
Recently some people said "I want to tell git that I renamed
fileA to fileB" on the list and #git channel, and I made some
vague comments on the issue that might have confused people.
This message is to clarify where I stand.
First of all, I understand some people "want to tell git", but
at the same time, I know very well that "git does not even want
to hear". It does not care about names -- it only tracks
contents [*1*].
Having said that, there are at least two cases that renamed
files matter in practice from the end user's point of view.
Diff and merge.
For diff, it is often __very__ frustrating when you know you
renamed hello.c to world.c and then edited just a bit and "git
diff -M hello.c world.c" does not notice. You can do one of two
things to help:
(1) figure out why git (diffcore-rename) does not think they
are similar enough, and improve its similarity estimator.
Some of you who are paying attention to what is in my
"next" branch might have noticed that I have been working
in this area recently.
(2) add a way to tell git-diff-files to compare hello.c in the
index with working tree file world.c:
$ git-diff-files -p 'hello.c->world.c'
And people who "want to tell git" are after the second way.
Although this can probably be implemented as an extension to
diffcore-rename [*2*], I have to say that is kludging around the
real problem. Only as a workaround for pathological cases it
may be OK, but I am really reluctant to accept such a change
without trying avenue (1) first.
About merge. Currently recursive merge strategy claims to
handle renames and I've seen it handle renames well in some
cases. However, it only uses three trees. The rename between
merge base and one head, and the rename between merge base and
the other head are computed, compared and usual three-way merge
rules are applied (e.g. if you kept it there while she moved it
to somewhere else, result is to move it to somewhere else). If
two development tracks forked long time ago are being merged,
and corresponding files deviated from each other beyond
recognition, there is no way for any heuristics to figure out
one is a rename-edit of the other only by looking at these three
trees:
a1--a2--a3--a4--a5--A
/ \
---O---b1--b2--b3--b4--B---*
O has hello.c
a1 renames file hello.c to world.c and a2-a5-A modifies world.c
b1-b4-B modifies hello.c
we are about to merge A and B
comparing O and A may not notice O's hello.c and A's world.c
are similar!
But you are allowed to write a new merge strategy that is more
careful about renames. There is no reason you can only look at
three trees. Such a merge strategy, when given commit A and B,
would walk the history back, running "diff-tree -M" for each
commit along the way, and difference between O's hello.c and
a1's world.c would be hopefully *much* smaller than O's hello.c
and A's world.c -- even the current similarity estimator may
recognize it is a rename.
That is the first thing I'd like to see. I do not want to even
think about recording renames in commit objects before anybody
explores that avenue.
Even with that, if O's hello.c and a1's world.c are _so_
different that if the changes are beyond recognition, you
_might_ want to "tell git" about the rename, or even record such
a rename in the commit object a1. But I personally doubt it
would help anything in practice. After such a huge rewrite
between O->a1, merging between A and B will be very hard anyway,
and you would need some off-line method to extract the intention
of the developer who originally did a1 commit while merging A
and B. And when you inspect that change yourself, you may
decide O's hello.c correspond to a1's world.c yourself. At that
point you will be hand merging the mess, so your being able to tell
git about it would not help you much.
[Footnotes]
*1* This is by design, and I am not going to debate if that is a
good design or not here. There is a "Linus once said 'you say
users know better but users cannot be trusted -- trust me'"
factor involved. I am a trusting kind and somebody needs to
convince me not to trust Linus.
*2* You would supply "in what you are comparing, the source path
hello.c and destination path world.c are similar with similarity
index 80% -- do not bother to estimate yourself, I am telling
you their similarity index so trust me".
$ git-diff-files -p -M --similarity='hello.c world.c 80%'
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Nicolas Pitre @ 2006-03-04 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylzx7t3.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Mar 2006, Junio C Hamano wrote:
> In short, I'd love to get a tighter packing, but as it
> currently stands, I do not think 5% resulting packsize reduction
> warrants making 100% slower operation the default.
Agreed. Please just drop that one patch for now.
I'll rework the hash limiting patch so the 16-byte block version behaves
better with the large 20MB files.
Nicolas
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Junio C Hamano @ 2006-03-04 2:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vfylzx7t3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The first round. The set of objects packed were from
> today's Linus tip (everything down to epoch v2.6.12-rc2), 193309
> objects in total, on my Duron 750 with slow disks.
>
> real user sys bytes savings
> master 11m17.121s 10m23.280s 0m47.290s 109045599 N/A
> nico 25m37.058s 23m0.770s 2m20.460s 104401392 4.25%
> jc 24m12.072s 21m45.120s 2m16.400s 104409761 4.25%
Minor correction in numbers. The size for nico and jc are
swapped. jc variant created the smallest pack in this
experiment.
Which puzzles me even more...
^ permalink raw reply
* Re: [PATCH] diff-delta: bound hash list length to avoid O(m*n) behavior
From: Junio C Hamano @ 2006-03-04 2:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <7vbqwrq4yi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> These numbers are misleading.
>>
>> The 36K objects pack I used in my previous tests gives 9971223
>> (from "next" branch) vs 9664546 (this patch) final pack size.
>> The wallclock time on my machine is 1m35 vs 3m30. I doubt many
>> people are willing to pay 100% more waiting time for 3% tighter
>> pack.
I started to suspect that the above benchmark was
unreliable, because I do not know how the original linux-2.6
repository I used for my testing were packed, and I was letting
the delta reusing to do its thing, so the times were probably
off (the 3-byte finer grained deltifier would have spent a lot
more time during the initial packing) and the result size were
too (the finer grained one would have packed things a lot more
tightly if the delta it was allowed to reuse was made by itself,
not by the old one).
So I tried a fresh packing without reusing delta at all,
with three variants: the original 16-byte one (master), 3-byte
finer grained one with your hash limit (nico), and 3-byte finer
grained one with my more aggressive hash limit (jc). The
benchmark is not meant to be scientific, but to see how well it
serves the kernel community ;-).
The first round. The set of objects packed were from
today's Linus tip (everything down to epoch v2.6.12-rc2), 193309
objects in total, on my Duron 750 with slow disks.
real user sys bytes savings
master 11m17.121s 10m23.280s 0m47.290s 109045599 N/A
nico 25m37.058s 23m0.770s 2m20.460s 104401392 4.25%
jc 24m12.072s 21m45.120s 2m16.400s 104409761 4.25%
My hack does not change things much in the overall picture
compared to yours, although it does cut down runtime by about
5%. We can immediately see that finer grained ones are
significantly more expensive than the original loose one either
way.
The next round of test is to place the "full pack"
generated in the previous experiment in .git/objects/pack and
generate packs by reusing delta. When testing the "master"
version, I move the pack produced above with "master" under
.git/objects/pack, and run this to emulate pack generation for
downloader who has v2.6.14 and wants v2.6.15-rc1 (the same 36K
objects test I did previously):
git rev-list --objects-edge v2.6.14..v2.6.15-rc1 |
time git-pack-objects --stdout | wc -c
When switching to test "nico" deltifier implementation, I start
with the full pack generated by "nico" in .git/object/pack to
make comparison fair. Here is the result:
real user sys bytes savings
master 1m37.703s 1m28.970s 0m5.860s 9968386 N/A
nico 3m39.982s 3m24.420s 0m14.380s 9182761 7.88%
jc 3m0.434s 2m35.940s 0m13.730s 9139460 8.31%
In thin transfer, base object is omitted, so the generated pack
has higher delta to non-delta ratio than usual -- and that is
the reason we see much more savings. Still, we are paying quite
a lot of overhead by finer grained delta code.
The last test is not to do a thin pack but still reusing
delta. This is to emulate "git repack" performance. Again, I
had the matching pack in .git/objects/pack to make the
compararison fair:
git rev-list --objects v2.6.14..v2.6.15-rc1 |
time git-pack-objects --stdout | wc -c
And here is the result:
real user sys bytes savings
master 1m0.866s 0m57.590s 0m2.810s 34601417 N/A
nico 2m8.059s 2m0.360s 0m6.350s 33888419 2.06%
jc 1m49.894s 1m42.250s 0m6.780s 33838262 2.20%
This one is not getting much savings compared to the full pack
case, but still spending about twice the time.
In short, I'd love to get a tighter packing, but as it
currently stands, I do not think 5% resulting packsize reduction
warrants making 100% slower operation the default. And the
experiment I did does not account for the memory pressure the
new delitifier imposes us (two pointers per every byte of source
material -- it could be reduced to one pointer though), so when
we start talking about huge files I am not sure we can manage to
keep the runtime reasonably low.
It maybe is an option to have a flag to tell "I want a
lot tighter pack made; you can spend all the time while I am
sleeping" and switch between two deltifiers, but otherwise...
One thing I do not understand is why my patch improves
the compressed result size. The patch was primarily to brutally
pessimize the selection of "copied from source" to avoid the
corner case performance problems, so I would understand why it
is faster than yours, but I expected it to *always* create a
looser pack. I am puzzled.
Swapping window scan order is orthogonal to this, so
maybe we could do it first and make it work, then start reusing
the refindex to see how well things improve. But we should be
reminded of the recent report that pack-object ran out of space
even with the current code that does not reuse the refindex when
packing 8 huge objects X-<.
^ permalink raw reply
* [PATCH] Use Cogito when possible in the "tutorial" test.
From: Pavel Roskin @ 2006-03-04 1:23 UTC (permalink / raw)
To: git, Petr Baudis
In particular, use Cogito branch support. Document why git has to be
used in some places.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
Documentation/tutorial-script/script.sh | 29 +++++++++++++++++------------
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/tutorial-script/script.sh b/Documentation/tutorial-script/script.sh
index edcebda..4d6b732 100755
--- a/Documentation/tutorial-script/script.sh
+++ b/Documentation/tutorial-script/script.sh
@@ -1,8 +1,9 @@
#!/bin/bash
#
-# FIXME: This script has many GITisms. Some of them are unnecessary, while
-# some stem from missing Cogito features (especially no support for pushing
-# tags, and consequently no support for remotes/).
+# FIXME: This script has some GITisms. They stem from missing Cogito
+# features, such as exporting patches to mbox format, applying patches
+# from e-mail, merging multiple tags at once, verifying signed tags and
+# repacking the repository.
# This function is appended as "&& should_fail" to commands which should
@@ -34,7 +35,7 @@ cd $ALICE
tar xf $TOP/0001-alice.tar
cd rpn
-# Being a tidy girl, she places it under git
+# Being a tidy girl, she places it under Cogito
echo "Alice's first version" | cg-init
cg-tag -d "First ever version of RPN" rpn-0.1
@@ -108,8 +109,8 @@ cg-export ../rpn-0.3.tar.bz2
### Bob tells Alice of his changes, Alice prepares to get them.
cd $ALICE/rpn
-git checkout -b bob
-git branch
+cg-switch -r master bob
+cg-status -g
# Alice needs to register his remote branch
cg-branch-add bobswork $BOB/rpn
@@ -163,14 +164,16 @@ cg-commit -m "Add proper header file for
-m "Update dependencies in Makefile"
# Charlie emails the patch to Alice:
+# cg-mkpatch -d .. -r rpn-0.3..master
git format-patch -o .. --mbox --signoff -r rpn-0.3
- # Result is in $TOP/0014-charlie-email
+# Only git can create mbox formatted output
+# Compare the result to 0014-charlie-email
### Alice is busy meanwhile...
cd $ALICE/rpn
-git checkout master
+cg-switch master
patch -p1 -i $TOP/0015-alice-mod.patch
@@ -189,21 +192,23 @@ cg-push public
### Alice gets Charlie's fix, creates a new branch for his changes
cd $ALICE/rpn
-git checkout master
-git checkout -b charlie rpn-0.3
-git branch
+cg-switch -r rpn-0.3 charlie
+cg-status -g
+# Check what's inside the patch. There is no Cogito equivalent yet.
git apply --stat $TOP/0014-charlie-email
git apply --summary $TOP/0014-charlie-email
git apply --check $TOP/0014-charlie-email
# Everything looks OK
git applymbox $TOP/0014-charlie-email
+# This doesn't work well yet
+# cg-patch < $TOP/0014-charlie-email
### Alice integrates the changes in the branches for the next release
cd $ALICE/rpn
-git checkout master
+cg-switch master
# Alice tries "git merge" instead of "cg-merge" since she wanted to
# merge both branches at once, which "cg-merge" cannot do.
git merge "Integrate changes from Bob and Charlie" master bob charlie \
^ permalink raw reply related
* Re: git-repack && git-prune-packed isn't doing it's job anymore?
From: Martin Langhoff @ 2006-03-04 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64mv2for.fsf@assigned-by-dhcp.cox.net>
On 3/4/06, Junio C Hamano <junkio@cox.net> wrote:
> If that is the case, "git prune" would be the right tool to use.
Spot on. Thanks!
> And this is not something that changed recently.
Of course, my bad. I had not seen this before. I guess it was because
I hadn't actually paid much attention at leftover objects in
oft-rebased repositories. I used to look at the .git/objects directory
a lot in my early git days, when I didn't do any rebasing.
thanks again!
martin
^ permalink raw reply
* Re: git-repack && git-prune-packed isn't doing it's job anymore?
From: Junio C Hamano @ 2006-03-04 0:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90603031629qbbb287ckd8da1ef56a831dba@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> $ find .git/objects -type f | grep -v pack | wc -l
> 3297
> $ git-repack && git-prune-packed
> Generating pack...
> Done counting 664 objects.
> Deltifying 664 objects.
> 100% (664/664) done
> Writing 664 objects.
> 100% (664/664) done
> Total 664, written 664 (delta 384), reused 0 (delta 0)
> Pack pack-f38c51a5d5194d6a2f6e711586b9a51980c8d524 created.
> $ find .git/objects -type f | grep -v pack | wc -l
> 2583
The last one would be "git count-objects", but repack packs
things that are reachable from your refs and prune-packed
removes what are in packs, so perhaps these are unreachable
objects? I'd imagine fsck-objects would say they are dangling.
If that is the case, "git prune" would be the right tool to use.
And this is not something that changed recently.
^ permalink raw reply
* git-repack && git-prune-packed isn't doing it's job anymore?
From: Martin Langhoff @ 2006-03-04 0:29 UTC (permalink / raw)
To: Git Mailing List
$ find .git/objects -type f | grep -v pack | wc -l
3297
$ git-repack && git-prune-packed
Generating pack...
Done counting 664 objects.
Deltifying 664 objects.
100% (664/664) done
Writing 664 objects.
100% (664/664) done
Total 664, written 664 (delta 384), reused 0 (delta 0)
Pack pack-f38c51a5d5194d6a2f6e711586b9a51980c8d524 created.
$ find .git/objects -type f | grep -v pack | wc -l
2583
Strange! This is from todays master,
$ git --version
git version 1.2.4.g0a60
cheers,
martin
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-03-03 22:07 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060303142413.GB16456@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:
>>I attached another patch that should work properly. It also pushes
>>empty patches on the stack if they were merged upstream (a 'stg
>>clean' is required to remove them). This is useful for the push
>>--undo command if you are not happy with the result.
>
> It appears to work for me. I still had to fix things up manually when
> pulling the uncommit patch though, since you had made a minor change
> in "uncommit.py":
>
> Pushing patch "uncommit"...Error: File "stgit/commands/uncommit.py" added in branches but different
Yes, I made some minor modifications (one of them was the copyright).
> Is there a way to make stgit not fall on its face when faced with this
> situation? Surely it ought to be possible to create a merged file with
> conflict markers? (I realize this is harder when there is no common
> ancestor, but these files are 95% identical!)
I've been thinking about this but it's not straight-forward. I tried
using /dev/null as the common ancestor but both diff3 and wiggle put the
whole file text in the conflict regions. These tools are not smart
enough to compare the conflict regions and reduce them.
Another approach would be to have a script that creates the common
ancestor only with the common lines between the two files and pass this
file as an argument to diff3. This wouldn't probably be that difficult,
maybe some combination of diff and sed and apply the result to one of
the files to remove the diff'ed lines.
Catalin
^ 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