* Re: git-blame.el: does not show one-line summary in echo area
From: Jakub Narebski @ 2011-02-04 10:03 UTC (permalink / raw)
To: David Kågedal
Cc: Jonathan Nieder, Xavier Maillard, Alexandre Julliard,
Martin Nordholts, Kevin Ryde, git, Andreas Schwab, Sergei Organov
In-Reply-To: <87tygkm8h7.fsf@krank.kagedal.org>
Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
> 3) Showing when you move to a different blame chunk, by showing a
> one-line summary in the echo area.
There is even some prior art for this to borrow from, namely cperl-mode
shows information about syntax at given point in echo area (minibuffer
area) after some delay. Just FYI.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-blame.el: does not show one-line summary in echo area
From: David Kågedal @ 2011-02-04 9:53 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jakub Narebski, Xavier Maillard, Alexandre Julliard,
Martin Nordholts, Kevin Ryde, git, Andreas Schwab, Sergei Organov
In-Reply-To: <20110204014315.GB28525@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Hi David et al,
>
> David Kågedal wrote:
>> Sergei Organov <osv@javad.com> writes:
>
>>> Now, I've evaluated (require 'format-spec) in my Emacs 22 (yes, 22, not
>>> 23), and now git-blame almost works there. The problem I see is that it
>>> doesn't output anything in the echo area. It color-codes the buffer, it
>>> does show correct pop-up when mouse is over a region, but it doesn't
>>> print anything in the echo area when I move cursor through the regions.
>>> Any idea how to debug/fix this?
>>
>> Well, it appears I removed the output to the echo area. I didn't think
>> it worked very well, and the new output format mostly replaces it by
>> showing the hash.
>>
>> There are also technical reasons for removing it (it couldn't be
>> implemented very cleanly).
>
> I don't use git-blame.el ("git blame", "git gui blame", and "git log
> -S/-G" take care of my needs already) but it seems to me that this
> change was a regression. The emacs support before v1.6.6-rc0~120^2
> had a simple way to find out the purpose of each line of code, while
> after that there is no simple way. And it is what the README
> promises:
>
> * git-blame.el:
>
> Emacs implementation of incremental git-blame. When you turn it on
> while viewing a file, the editor buffer will be updated by setting
> the background of individual lines to a color that reflects which
> commit it comes from. And when you move around the buffer, a
> one-line summary will be shown in the echo area.
>
> Any advice for people who want to fix that? Is anyone interested in
> doing so? (It is quite likely I am guessing incorrectly about what is
> useful, but I would imagine that at least the documentation could use
> updating.)
Let's try to figure out how we would like it to work. I agree that the
mouseover information is not good enough. There are several things we
can do:
1) Use some command to request information about the current line.
When the command is invoked (bound to some convenient key?), it pops
up a buffer with the result of "git show <commit>" or similar.
2) Have a separate buffer always showing information about the line
under the cursor. This should at least be the info in the commit
object, but going to the diff should be accessible.
3) Showing when you move to a different blame chunk, by showing a
one-line summary in the echo area.
There are variations and combinations. I think that 1+3 or 2 are the
best options.
--
David Kågedal
^ permalink raw reply
* Re: git-blame.el: does not show one-line summary in echo area
From: David Kågedal @ 2011-02-04 10:15 UTC (permalink / raw)
To: Jakub Narebski
Cc: Sergei Organov, Andreas Schwab, git, Kevin Ryde, Martin Nordholts,
Alexandre Julliard, Xavier Maillard, Jonathan Nieder
In-Reply-To: <201102041103.10770.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
>
>> 3) Showing when you move to a different blame chunk, by showing a
>> one-line summary in the echo area.
>
> There is even some prior art for this to borrow from, namely cperl-mode
> shows information about syntax at given point in echo area (minibuffer
> area) after some delay. Just FYI.
Sure, there are a number of those (eldoc comes to mind). I think the
hardest part is figuring out what to show. A 40-charater hash is
probably not very useful. The problem is that the committer information,
date, and commit message first line takes up a lot of space. But we can
of course let the echo area grow to two lines, or even three.
I don't think I'll have time to cook something up right now, though.
--
David Kågedal
^ permalink raw reply
* Re: git-p4 - workflow suggestions
From: Tor Arvid Lund @ 2011-02-04 10:26 UTC (permalink / raw)
To: Kaizer H. Sogiawala; +Cc: git
In-Reply-To: <AANLkTik3iFXZE6KSvSSgka3rJyCQbPXpUrTWRGyonfT=@mail.gmail.com>
On Fri, Feb 4, 2011 at 1:23 AM, Kaizer H. Sogiawala <kaizers@gmail.com> wrote:
> Hi,
>
> We are primarily a Perforce shop. I am looking for a git-p4 workflow
> that will alllow a sub-team (2-20 developers) to use git as their
> primary source control repository. This sub-team is tasked with
> refactoring and will need heavy-duty branch/merge support. The
> main/central source code repository (and branch) is in Perforce.
>
> I am looking at approaches that will allow me to "git-p4 clone" from
> Perforce (a branch in perforce, say trunk) into a bare/shared git
> repository. This repository is then cloned by each developer of the
> git-sub-team to perform regular development/push/pull/merge/rebase
> activities.
Hey! Yes, this should be possible - at least to some extent. What I
did personally, was to keep things as simple as possible, and decide
early on that I wouldn't hope to be able to do *everything* with
git-p4/perforce that I *could* do in git. [branch/merge tradeoff
details will follow]
> Periodically, a gatekeeper would pull changes from Perforce to git and
> push changes from git to Perforce. Can this be done?
I think I did kind of what you describe... I had one "blessed" git-p4
repo. That repo would be setup by:
git p4 clone --import-local //depot/path@all myproject
(The "--import-local" makes sure that the p4 branch is placed in
refs/heads/ instead of refs/remotes. Better when the actual users
clone the git repo later...)
Then I made a simple script that would loop through all my git-p4
projects... basically just 'cd' into the dir and do 'git p4 sync'.
This script would be run by a cron job every <whatever> minutes so it
would always be reasonably up-to-date.
> So far, I have looked at the:
> - git-p4 documentation
> - Version Control with Git book By: Jon Loeliger (particularly the
> git-svn section)
> - Mailing list (particularly following thread answered by Tor Arvid Lund)
> - googl'n around this topic
>
> Most discussion is around how to use git-p4 as a sync mechanism for a
> single user. When I attempt to git-p4 clone (import) and then create a
> shared/bare repository out of it and emulating multiple user, the
> git-p4 sync mechanism breaks down after couple of merges. The git-p4
> sync/rebase/submit will try to reapply duplicate changes and trip
> pretty early in the cycle.
>
> If you have a working model of making available a p4 branch for a
> sub-team using git-p4, I would really appreciate a writeup or blog.
> Thanks in advance.
Ok, so to make things practical, I made some simple 'rules' for myself:
* The blessed git repo would be "pull-only" for the git users. That is
- no one pushes to that repo. It reads from p4, and the users do 'git
fetch/pull' from that. Nothing more, nothing less...
* When preparing commits for upload to perforce, *always* rebase them
on top of the latest git-p4 tip.
I never tried to do merges in git, and then try to turn that into
'integrates' in perforce. So I always kept the perforce-things
'linear' so that the communication between git and perforce should be
easy. IOW I always did the "official" branching and integrate'ing
using the perforce client.
We did 'git p4 submit' directly from the users' git repos (which would
be synced by the blessed git repo, and from there to the other git
users). If you want another layer in-between [we use gerrit
code-review... You may have something else, or an integration manager
etc], you could push to another <some-project-manager-repo> and do all
git-p4 submits from there, I guess...
Of course, these branch/merge limitations only apply to my git history
at the point where I want to push to perforce. In all my daily work, I
create topic branches, rebase, reorder commits... all of the git
goodness. I simply "linearize" things when I want to push...
In your use-case, if you are going to do work that will result in many
perforce integrates, you may have a harder time with git-p4 than I
did, but it should be worth a try so that you can delight in daily git
usage instead of cursing the awfulness that is perforce.
And yes, git-p4 does rewrite every commit after you submit it. This is
because of the quite simple design that was used to help git-p4 "know"
what had been synced from perforce to git. Commit messages get the
appended "[git-p4: depot-paths = ... change = 12345]" line. If git-p4
had been written today, this could have maybe been solved using
git-notes instead of rewriting commit msgs. I'm just saying... :)
Otherwise, you will have to get around the fact that it rewrites
everything. For me, I have used git rebase a *lot* :)
Good luck!
-- Tor Arvid
^ permalink raw reply
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-04 10:49 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTikfGapDfZtD9H10797Ted_Av78WD8M7XrACOCpW@mail.gmail.com>
Hi All,
Thanks for the replies.
2011/2/4 Tor Arvid Lund <torarvid@gmail.com>:
> On Fri, Feb 4, 2011 at 1:03 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
>> git remote add remotename myprojectrepo
> Endre, you should start like you already have; by git-p4 cloning your
> project from perforce. (You maybe want to have a dummy file checked in
> to your <projectdir> in perforce, so that the 'git-p4 clone' command
> produces at least one commit in your git repo)...
>
> Then, do 'git remote add tempremote <path-to-your-existing-git-repo>'
> like Vitor suggests.
>
> At this point I would do:
>
> $ git checkout -b tempbranch tempremote/master
At this point I got an error message:
fatal: git checkout: updating paths is incompatible with switching branches.
So I fetched my tempremote first:
$ git fetch tempremote
$ git checkout -b tempbranch tempremote/master
(I got a warning from fetch, that there are no common commits, but I
supposed that it is right. :) )
> $ git rebase master
It applied all my commits.
> $ git-p4 submit
Synchronizing p4 checkout...
... - file(s) up-to-date.
Applying 1##############################9 Initial commit
error: ***: already exists in working directory
[...]
Unfortunately applying the change failed!
It said this error for all my files. :(
But I think we are almost there. :)
Regards,
Endre
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Jakub Narebski @ 2011-02-04 10:49 UTC (permalink / raw)
To: Tor Arntsen
Cc: Miles Bader, Hilco Wijbenga, git, Nicolas Pitre, George Spelvin,
Eugene Sajine
In-Reply-To: <AANLkTinQ13b9c1=SmMSC5ThjXcsSuMO2irwW04E+K=xY@mail.gmail.com>
Tor Arntsen <tor@spacetec.no> writes:
> On Fri, Feb 4, 2011 at 03:06, Miles Bader <miles@gnu.org> wrote:
> > Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>>>
>>> Quite frankly, I'm surprised there are (presumably experienced)
>>> developers who do not immediately see the value of a little
>>> organization. Surely, given the use of code conventions, formatting
>>> rules, etcetera, the obvious one step further is to also organize
>>> where the files go?
>>
>> I think one of the problems is that what's been suggested seems like
>> window-dressing. Moving everything into src/ and calling it "organized"
>> doesn't actually accomplish much other than perhaps making the README
>> file more visible to newbs; things are _still_ a mess, just a mess with
>> four more letters...
>
> What Miles says is my feeling as well. And having a 'bin/' as was suggested
> in one post doesn't make much sense to me either - if you want your compiled
> output to go elsewhere than the source directory then the normal way of doing
> that is to do and out-of-tree build (so if that's not working - I have
> not checked - then that's something which would be worth looking into.)
It is about supporting 'srcdir', isn't it?
BTW. what about using 'lib/' directory?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Erik Faye-Lund @ 2011-02-04 11:17 UTC (permalink / raw)
To: Miles Bader
Cc: Hilco Wijbenga, git, Nicolas Pitre, George Spelvin, Eugene Sajine
In-Reply-To: <87bp2sy2mf.fsf@catnip.gol.com>
On Fri, Feb 4, 2011 at 3:06 AM, Miles Bader <miles@gnu.org> wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>> Quite frankly, I'm surprised there are (presumably experienced)
>> developers who do not immediately see the value of a little
>> organization. Surely, given the use of code conventions, formatting
>> rules, etcetera, the obvious one step further is to also organize
>> where the files go?
>
> I think one of the problems is that what's been suggested seems like
> window-dressing. Moving everything into src/ and calling it "organized"
> doesn't actually accomplish much other than perhaps making the README
> file more visible to newbs; things are _still_ a mess, just a mess with
> four more letters...
FWIW, I don't quite see what's wrong with "window dressing" here.
Making those files more visible is a good thing, IMO.
But I'm not so sure I agree that the rest of the source tree is such a
mess that everyone makes it out to be. OK, there's a lot of
source-files on the top-level (which would be the src-level with this
change), but why is that such a bad thing? And if this is a big deal,
perhaps moving libgit-sources to a separate folder would help?
^ permalink raw reply
* Re: [PATCH maint] start_command: flush buffers in the WIN32 code path as well
From: Pat Thoyts @ 2011-02-04 11:23 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, msysgit, Git Mailing List, Junio C Hamano
In-Reply-To: <4D4BBBD6.7010100@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>From: Johannes Sixt <j6t@kdbg.org>
>
>The POSIX code path did The Right Thing already, but we have to do the same
>on Windows.
>
>This bug caused failures in t5526-fetch-submodules, where the output of
>'git fetch --recurse-submodules' was in the wrong order.
>
>Debugged-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>---
>Am 2/3/2011 21:26, schrieb Johannes Schindelin:
>> Have you seen my response where I proved that it is a fflush() issue, most
>> likely with mingw_spawn()?
>
>I think this is the correct fix.
>
> run-command.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/run-command.c b/run-command.c
>index 2a1041e..f91e446 100644
>--- a/run-command.c
>+++ b/run-command.c
>@@ -194,6 +194,7 @@ fail_pipe:
> }
>
> trace_argv_printf(cmd->argv, "trace: run_command:");
>+ fflush(NULL);
>
> #ifndef WIN32
> {
>@@ -201,7 +202,6 @@ fail_pipe:
> if (pipe(notify_pipe))
> notify_pipe[0] = notify_pipe[1] = -1;
>
>- fflush(NULL);
> cmd->pid = fork();
> if (!cmd->pid) {
> /*
This fixes the issue for me on msysGit. Thanks.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [BUG?] git.el: M-x git-commit-file produces error if font lock is disabled
From: Lawrence Mitchell @ 2011-02-04 11:40 UTC (permalink / raw)
To: git; +Cc: Kevin Ryde, David Kågedal, Jonathan Nieder,
Alexandre Julliard
In-Reply-To: <20110204001016.GC16688@elie>
Jonathan Nieder wrote:
> Hi,
> Kevin Ryde reports[1]:
[...] bug in git.el
> and suggests a patch[2]. Does it make sense?
font-lock-add-keywords isn't supported in the stable Xemacs
version (21.4). But really, we don't want to /add/ keywords, but
set up our own, so we should define a major mode appropriately
and use that in log-edit. Something like the patch below, I think.
>From 6333cd09f1a921757680f1376eeb0a6389d75449 Mon Sep 17 00:00:00 2001
From: Lawrence Mitchell <wence@gmx.li>
Date: Fri, 4 Feb 2011 10:59:18 +0000
Subject: [PATCH] git.el: Don't use font-lock-compile-keywords
If font-lock is disabled, font-lock-compile-keywords complains.
Really what we want to do is to replace log-edit's font-lock
definitions with our own, so define a major mode deriving from
log-edit and set up font-lock-defaults there. We then use the option
MODE argument to log-edit to set up the major mode of the commit
buffer appropriately.
Signed-Off-By: Lawrence Mitchell <wence@gmx.li>
---
contrib/emacs/git.el | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 214930a..65c95d9 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1310,6 +1310,13 @@ The FILES list must be sorted."
(when sign-off (git-append-sign-off committer-name committer-email)))
buffer))
+(define-derived-mode git-log-edit-mode log-edit-mode "Git-Log-Edit"
+ "Major mode for editing git log messages.
+
+Set up git-specific `font-lock-keywords' for `log-edit-mode'."
+ (set (make-local-variable 'font-lock-defaults)
+ '(git-log-edit-font-lock-keywords t t)))
+
(defun git-commit-file ()
"Commit the marked file(s), asking for a commit message."
(interactive)
@@ -1335,9 +1342,9 @@ The FILES list must be sorted."
(git-setup-log-buffer buffer (git-get-merge-heads) author-name author-email subject date))
(if (boundp 'log-edit-diff-function)
(log-edit 'git-do-commit nil '((log-edit-listfun . git-log-edit-files)
- (log-edit-diff-function . git-log-edit-diff)) buffer)
- (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
- (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
+ (log-edit-diff-function . git-log-edit-diff)) buffer 'git-log-edit-mode)
+ (log-edit 'git-do-commit nil 'git-log-edit-files buffer
+ 'git-log-edit-mode))
(setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
(setq buffer-file-coding-system coding-system)
(re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
--
1.7.4.rc2.18.gb20e9
^ permalink raw reply related
* Re: git-blame.el: does not show one-line summary in echo area
From: David Kågedal @ 2011-02-04 12:26 UTC (permalink / raw)
To: Jakub Narebski
Cc: Jonathan Nieder, Xavier Maillard, Alexandre Julliard,
Martin Nordholts, Kevin Ryde, git, Andreas Schwab, Sergei Organov
In-Reply-To: <87r5bom7g3.fsf@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Dnia piątek 4. lutego 2011 10:53, David Kågedal napisał:
>>
>>> 3) Showing when you move to a different blame chunk, by showing a
>>> one-line summary in the echo area.
>>
>> There is even some prior art for this to borrow from, namely cperl-mode
>> shows information about syntax at given point in echo area (minibuffer
>> area) after some delay. Just FYI.
>
> Sure, there are a number of those (eldoc comes to mind). I think the
> hardest part is figuring out what to show. A 40-charater hash is
> probably not very useful. The problem is that the committer information,
> date, and commit message first line takes up a lot of space. But we can
> of course let the echo area grow to two lines, or even three.
>
> I don't think I'll have time to cook something up right now, though.
I whipped up a patch anyway. This adds an echo area message shown after
0.5 seconds of idleness, using the git-blame-echo-format format string.
Try it and see if makes sense. I can clean it up (and split it up)
later.
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index d351cfb..9f60a6f 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -104,34 +104,53 @@
(defcustom git-blame-prefix-format
"%h %20A:"
"The format of the prefix added to each line in `git-blame'
-mode. The format is passed to `format-spec' with the following format keys:
-
- %h - the abbreviated hash
- %H - the full hash
- %a - the author name
- %A - the author email
- %c - the committer name
- %C - the committer email
- %s - the commit summary
+mode. See `git-blame-format' for more information.
"
:group 'git-blame)
(defcustom git-blame-mouseover-format
"%h %a %A: %s"
"The format of the description shown when pointing at a line in
-`git-blame' mode. The format string is passed to `format-spec'
-with the following format keys:
+`git-blame' mode. See `git-blame-format' for more information
+"
+ :group 'git-blame)
+
+(defcustom git-blame-echo-format
+ "%H\n%a %A %t\n%s"
+ "The format of the description shown in the echo area when moving around in
+`git-blame' mode. See `git-blame-format' for more information."
+ :group 'git-blame)
+
+(defun git-blame-format (info format)
+ "Use format-spec to format the blame info in INFO with the following keys:
%h - the abbreviated hash
%H - the full hash
%a - the author name
%A - the author email
+ %t - the author time
%c - the committer name
%C - the committer email
+ %T - the commtter time
%s - the commit summary
"
- :group 'git-blame)
-
+ (let ((hash (car info))
+ (author-time (let ((time (string-to-number
+ (git-blame-get-info info 'author-time))))
+ (list (/ time 65536) (% time 65536) 0)))
+ (committer-time (let ((time (string-to-number
+ (git-blame-get-info info 'committer-time))))
+ (list (/ time 65536) (% time 65536) 0))))
+ (format-spec format
+ `((?h . ,(substring (car info) 0 6))
+ (?H . ,(car info))
+ (?a . ,(git-blame-get-info info 'author))
+ (?A . ,(git-blame-get-info info 'author-mail))
+ (?t . ,(format-time-string "%c" author-time))
+ (?c . ,(git-blame-get-info info 'committer))
+ (?C . ,(git-blame-get-info info 'committer-mail))
+ (?T . ,(format-time-string "%c" committer-time))
+ (?s . ,(git-blame-get-info info 'summary))))))
(defun git-blame-color-scale (&rest elements)
"Given a list, returns a list of triples formed with each
@@ -198,10 +217,13 @@ minor mode.")
"A cache of git-blame information for the current buffer")
(make-variable-buffer-local 'git-blame-cache)
-(defvar git-blame-idle-timer nil
+(defvar git-blame-update-timer nil
"An idle timer that updates the blame")
(make-variable-buffer-local 'git-blame-cache)
+(defvar git-blame-show-timer nil
+ "An idle timer that show the current blame info.")
+
(defvar git-blame-update-queue nil
"A queue of update requests")
(make-variable-buffer-local 'git-blame-update-queue)
@@ -246,6 +268,10 @@ See also function `git-blame-mode'."
(setq git-blame-colors git-blame-dark-colors)
(setq git-blame-colors git-blame-light-colors)))
(setq git-blame-cache (make-hash-table :test 'equal))
+ (unless (and git-blame-show-timer
+ (memq git-blame-show-timer timer-idle-list))
+ (setq git-blame-show-timer
+ (run-with-idle-timer 0.5 t 'git-blame-echo-current)))
(setq git-blame-mode t)
(git-blame-run))
@@ -254,7 +280,7 @@ See also function `git-blame-mode'."
See also function `git-blame-mode'."
(git-blame-cleanup)
- (if git-blame-idle-timer (cancel-timer git-blame-idle-timer))
+ (if git-blame-update-timer (cancel-timer git-blame-update-timer))
(setq git-blame-mode nil))
;;;###autoload
@@ -392,34 +418,33 @@ See also function `git-blame-mode'."
(goto-line start-line)
(let* ((start (point))
(end (progn (forward-line num-lines) (point)))
- (ovl (make-overlay start end))
- (hash (car info))
- (spec `((?h . ,(substring hash 0 6))
- (?H . ,hash)
- (?a . ,(git-blame-get-info info 'author))
- (?A . ,(git-blame-get-info info 'author-mail))
- (?c . ,(git-blame-get-info info 'committer))
- (?C . ,(git-blame-get-info info 'committer-mail))
- (?s . ,(git-blame-get-info info 'summary)))))
+ (ovl (make-overlay start end)))
(push ovl git-blame-overlays)
(overlay-put ovl 'git-blame info)
(overlay-put ovl 'help-echo
- (format-spec git-blame-mouseover-format spec))
+ (git-blame-format info git-blame-mouseover-format))
(if git-blame-use-colors
(overlay-put ovl 'face (list :background
(cdr (assq 'color (cdr info))))))
(overlay-put ovl 'line-prefix
- (propertize (format-spec git-blame-prefix-format spec)
+ (propertize (git-blame-format info git-blame-prefix-format)
'face 'git-blame-prefix-face))))))
(defun git-blame-add-info (info key value)
- (nconc info (list (cons (intern key) value))))
+ (let* ((keysym (intern key))
+ (a (assq keysym (cdr info))))
+ (if a
+ (setcdr a value)
+ (nconc info (list (cons (intern key) value))))))
(defun git-blame-get-info (info key)
(cdr (assq key (cdr info))))
+(defun git-blame-current-info ()
+ (get-char-property (point) 'git-blame))
+
(defun git-blame-current-commit ()
- (let ((info (get-char-property (point) 'git-blame)))
+ (let ((info (git-blame-current-info)))
(if info
(car info)
(error "No commit info"))))
@@ -467,17 +492,22 @@ See also function `git-blame-mode'."
(setq git-blame-last-update (cons start end))
(setq git-blame-update-queue (nconc git-blame-update-queue
(list git-blame-last-update)))))
- (unless (or git-blame-proc git-blame-idle-timer)
- (setq git-blame-idle-timer
+ (unless (or git-blame-proc git-blame-update-timer)
+ (setq git-blame-update-timer
(run-with-idle-timer 0.5 nil 'git-blame-delayed-update))))
(defun git-blame-delayed-update ()
- (setq git-blame-idle-timer nil)
+ (setq git-blame-update-timer nil)
(if git-blame-update-queue
(let ((first (pop git-blame-update-queue))
(inhibit-point-motion-hooks t))
(git-blame-update-region (car first) (cdr first)))))
+(defun git-blame-echo-current ()
+ (let ((info (git-blame-current-info)))
+ (when info
+ (message "%s" (git-blame-format info git-blame-echo-format)))))
+
(provide 'git-blame)
;;; git-blame.el ends here
--
David Kågedal
^ permalink raw reply related
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Nguyen Thai Ngoc Duy @ 2011-02-04 13:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Joshua Jensen
In-Reply-To: <201102032117.32745.j6t@kdbg.org>
2011/2/4 Johannes Sixt <j6t@kdbg.org>:
> On Donnerstag, 3. Februar 2011, Nguyễn Thái Ngọc Duy wrote:
>> Commit 21444f1 (Add case insensitivity support when using git ls-files
>> - 2010-10-03) teaches match_pathspec() to ignore case when
>> core.ignorecase=true.
>>
>> match_pathspec_depth() is developed independently and does not have
>> this feature. Teach it.
>
> Is match_pathspec_depth() used to match names of files on the filesystem, or
> names of files in the index or in the repository?
>
> core.ignorecase should be honored only when files on the filesystem are
> matched, IMO.
Names in index, just as same as match_pathspec().
--
Duy
^ permalink raw reply
* Re: [1.8.0] Support quoting in .gitattributes, .gitignore
From: Nguyen Thai Ngoc Duy @ 2011-02-04 13:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vbp2t0wld.fsf@alter.siamese.dyndns.org>
On Fri, Feb 4, 2011 at 2:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> Migration plan:
>>
>> I think a release note mentioning this is enough. No migration needed.
>>
>> But to be safe, we can make post-1.7.5 warn users about patterns with
>> leading double quote. By 1.8.0, the new behavior will be used.
>
> That's obviously not a migration plan, and it is worse than not having the
> warning at all. People with paths that begin with dq (which I suspect
> would be an empty set) will get wraning every time they do anything with
> git, and until 1.8.0 there is no way to turn that warnings off without
> breaking their pattern (like removing the entry from the attributes file),
> and when 1.8.0 comes their patterns will break.
Actually they can turn "<dq>abc" pattern to "[<dq>]abc". The tip
should be included in the warning. The warning would then be gone and
their patterns are 1.8.0-safe.
> How about introducing a new feature in .gitattributes file so that the
> parser can tell if the file is (1) written pre-1.7.5 that depends on the
> old behaviour, (2) written post-1.7.5 by a person who is aware of the dq
> convention, but still relying on the old behaviour, (3) written post-1.7.5
> to take advantage of the new behaviour? E.g., you can explicitly mark
> your .gitattributes file by putting "# feature: no-cq-pattern" as the
> first line that the patterns in the file relies on the traditional
> behaviour, or "# feature: cq-pattern" to cause the parser to interpret
> cquoted patterns, and the last 1.7.x will warn if a file does not have
> this explicit marking, but has a pattern that would change the behaviour.
> Then 1.8.0 would flip the default.
Nice. Chances of having a pattern with leading dq are small enough
that I'd rarely need to add "#feature: cq-pattern" in new
.gitattributes (i.e it does not bother the majority of users).
So the syntax of this line would be:
# feature: <feature>[,<feature>]*
where features in lowercase are mandatory, Git will abort if it does
not understand such a feature. Features start with an uppercase letter
is optional. Hmm?
--
Duy
^ permalink raw reply
* Re: git to p4 conversion
From: Tor Arvid Lund @ 2011-02-04 14:01 UTC (permalink / raw)
To: Endre Czirbesz; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTimrwUxNOAnfxgvReGN+-h4_0jhZ731y22TB6u1K@mail.gmail.com>
On Fri, Feb 4, 2011 at 11:49 AM, Endre Czirbesz <endre@czirbesz.hu> wrote:
> Hi All,
>
> Thanks for the replies.
>
> 2011/2/4 Tor Arvid Lund <torarvid@gmail.com>:
>> On Fri, Feb 4, 2011 at 1:03 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
>>> git remote add remotename myprojectrepo
>
>> Endre, you should start like you already have; by git-p4 cloning your
>> project from perforce. (You maybe want to have a dummy file checked in
>> to your <projectdir> in perforce, so that the 'git-p4 clone' command
>> produces at least one commit in your git repo)...
>>
>> Then, do 'git remote add tempremote <path-to-your-existing-git-repo>'
>> like Vitor suggests.
>>
>> At this point I would do:
>>
>> $ git checkout -b tempbranch tempremote/master
> At this point I got an error message:
> fatal: git checkout: updating paths is incompatible with switching branches.
>
> So I fetched my tempremote first:
> $ git fetch tempremote
> $ git checkout -b tempbranch tempremote/master
See, this is what happens when I write a "how-to" and not actually try
it out before sending it... Obviously, you are correct in that you
have to fetch it before being able to check it out :-)
> (I got a warning from fetch, that there are no common commits, but I
> supposed that it is right. :) )
That is correct.
>> $ git rebase master
> It applied all my commits.
>
>> $ git-p4 submit
> Synchronizing p4 checkout...
> ... - file(s) up-to-date.
> Applying 1##############################9 Initial commit
> error: ***: already exists in working directory
> [...]
> Unfortunately applying the change failed!
>
> It said this error for all my files. :(
> But I think we are almost there. :)
Again, if only I'd tried it myself first! ;)
Well, I can get it to work if I do:
$ git p4 sync
before the 'git p4 submit'.
Try that, and see if it works for you. (BTW, when committing
half-works, and then fails, oftentimes you need to do a bit of cleanup
in perforce... Revert files, manually remove files created by git
inside your p4 clientspec root directory, that sort of thing...)
-- Tor Arvid
^ permalink raw reply
* [ANNOUNCE] Git for Windows 1.7.4
From: Pat Thoyts @ 2011-02-04 14:14 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <7vaaihacj6.fsf@alter.siamese.dyndns.org>
Announcing Git for Windows 1.7.4.
This now is available for download at http://msysgit.googlecode.com/
Git for Windows Release Notes (Git-1.7.4-preview20110204)
Last update: 4 February 2011
Introduction
These release notes describe issues specific to the Git for Windows
release.
General release notes covering the history of the core git commands are
included in the subdirectory doc/git/html of the installation
directory. Look for files starting with RelNotes.
Known issues
- Some commands are not yet supported on Windows and excluded from the
installation; namely: git archimport, git cvsexportcommit, git
cvsimport, git cvsserver, git instaweb, git shell.
- The Logitec QuickCam software can cause spurious crashes. See "Why
does make often crash creating a sh.exe.stackdump file when I try to
compile my source code?" on the MinGW Wiki
(http://www.mingw.org/wiki/Environment_issues)
- The Quick Launch icon will only be installed for the user running
setup (typically the Administrator). This is a technical restriction
and will not change.
- curl uses $HOME/_netrc instead of $HOME/.netrc.
- If you want to specify a different location for --upload-pack, you
have to start the absolute path with two slashes. Otherwise MSys will
mangle the path.
- git and bash have serious problems with non-ASCII file names (Issue
80, 159).
- If configured to use plink, you will have to connect with putty first
and accept the host key.
- As merge tools are executed using the MSys bash, options starting with
"/" need to be handled specially: MSys would interpret that as a POSIX
path, so you need to double the slash (Issue 226). Example: instead
of "/base", say "//base". Also, extra care has to be paid to pass
Windows programs Windows paths, as they have no clue about MSys style
POSIX paths -- You can use something like $(cmd //c echo
"$POSIXPATH").
Changes since Git-1.7.3.2-preview20101025
Comes with Git 1.7.4 plus patches.
Includes antiword to enable viewing diffs of .doc files
Includes poppler to enable viewing diffs of .pdf files
Removes cygwin paths from the bash shell PATH
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Joey Hess @ 2011-02-04 14:34 UTC (permalink / raw)
To: git
In-Reply-To: <20110203174518.GA14871@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
Jeff King wrote:
> If it sounds like I'm handwaving away scalability problems, I am. I'd be
> curious to see some performance numbers for gollum or ikiwiki versus
> more traditional wiki formats.
Ikiwiki builds static pages, this tends to mean it doesn't have
performance, because there is little more to perform than
httpd < file > network :)
So I've routinely had ikiwiki sites slashdotted, and not noticed.
Ikiwiki is not enormously fast in the rare cases when it does have to
run as a CGI, but little of that has to do with git. About the worst
case is that saving a page edit leads to a git commit -- if git
decides to gc the repository right then, it could make the save stall
for a while. There are easy ways to avoid that. (ie, git gc in cron job)
In general, though ikiwiki as a CGI is fast enough to not be annoying --
although it won't scale to a site the size of wikipedia.
Since I'm lazy, ikiwiki does not include a history or diff viewer. It
just points off to gitweb or a similar tool. As you say, gitweb can be
fast enough, and really most wiki users do read their current content,
or maybe make an edit; digging in the history is comparatively rare.
And once users realize the wiki is in git, they can use gitk to dig in
the history without using any server resources. :)
The feature I like best with using git for a wiki (besides ease of
branching) is that it can actually make a legitimate use of the
woefully underused git push over git:// feature. Ikiwiki can be
configured to check such pushes, running via the pre-receive hook. This
allows it to limit the changes that can be pushed anonymously to changes
that could be made using the web interface. So if you've chosen to lock
some pages, or virus filter attachments, or whatever, in the web side of
the wiki, that all applies to the anonymous git pushes too. Details at
<http://ikiwiki.info/tips/untrusted_git_push/>
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-04 16:08 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTi=_spLE-KMnou-2LLQjwq4FUZxNr9pk7D9C=4PK@mail.gmail.com>
2011/2/4 Tor Arvid Lund <torarvid@gmail.com>:
> Well, I can get it to work if I do:
> $ git p4 sync
>
> before the 'git p4 submit'.
Same result. :(
My current workflow is:
$ rm -rf projdir
$ git-p4 clone //depot/projdir/...@all
$ cd projdir
$ git remote add gitremote endre@gitserver/gitrepo.git
$ git fetch -q gitremote
$ git checkout -b tempbranch gitremote/master
$ git rebase -q master
$ git-p4 sync
$ git-p4 submit
The result is still tons of file already exists in working directory messages.
> Try that, and see if it works for you. (BTW, when committing
> half-works, and then fails, oftentimes you need to do a bit of cleanup
> in perforce... Revert files, manually remove files created by git
> inside your p4 clientspec root directory, that sort of thing...)
I dropped the whole directory, and then recreated it, I do not know
any better 'cleanup'. :)
Rgds,
Endre
^ permalink raw reply
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-04 16:52 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Ian Wienand, Tor Arvid Lund
In-Reply-To: <AANLkTimGaPQ=hRp+2pvw-hAOg+wp50nvc_sv9jNTay=n@mail.gmail.com>
Hi Vitor,
2011/2/4 Vitor Antunes <vitor.hda@gmail.com>:
>> I dropped the whole directory, and then recreated it, I do not know
>> any better 'cleanup'. :)
>
> Which directory did you drop? Was is the git repository or the P4 workspace?
> You need to clean up the later. Basically, a "rm -rf
> path/to/p4_workspace" and a "p4 sync -f" should do the trick :)
It is almost the same in my case. :)
My p4 client root is ~/work/, my project dir is ~/work/projdir (and at
the moment this is the only directory within ~/work/), and I dropped
the latter.
And then it was created again by git-p4 clone.
I can drop the workspace root, but I do not think it would help.
Regards,
Endre
^ permalink raw reply
* Re: git-p4 - workflow suggestions
From: Kaizer H. Sogiawala @ 2011-02-04 17:41 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: git
In-Reply-To: <AANLkTik7Gv6vOgYNyuz-TCD6SAPV5G8f7RujEpfEYU3Q@mail.gmail.com>
Thanks a bunch Tor. It seems you are using a non-bare repo as the
"blessed" repository and mitigating the risk or getting the workspace
messed up by always "pulling" changes that need to go in Perforce. I
will give it a try and post back.
Thanks for the post.
On Fri, Feb 4, 2011 at 2:26 AM, Tor Arvid Lund <torarvid@gmail.com> wrote:
> On Fri, Feb 4, 2011 at 1:23 AM, Kaizer H. Sogiawala <kaizers@gmail.com> wrote:
>> Hi,
>>
>> We are primarily a Perforce shop. I am looking for a git-p4 workflow
>> that will alllow a sub-team (2-20 developers) to use git as their
>> primary source control repository. This sub-team is tasked with
>> refactoring and will need heavy-duty branch/merge support. The
>> main/central source code repository (and branch) is in Perforce.
>>
>> I am looking at approaches that will allow me to "git-p4 clone" from
>> Perforce (a branch in perforce, say trunk) into a bare/shared git
>> repository. This repository is then cloned by each developer of the
>> git-sub-team to perform regular development/push/pull/merge/rebase
>> activities.
>
> Hey! Yes, this should be possible - at least to some extent. What I
> did personally, was to keep things as simple as possible, and decide
> early on that I wouldn't hope to be able to do *everything* with
> git-p4/perforce that I *could* do in git. [branch/merge tradeoff
> details will follow]
>
>> Periodically, a gatekeeper would pull changes from Perforce to git and
>> push changes from git to Perforce. Can this be done?
>
> I think I did kind of what you describe... I had one "blessed" git-p4
> repo. That repo would be setup by:
>
> git p4 clone --import-local //depot/path@all myproject
>
> (The "--import-local" makes sure that the p4 branch is placed in
> refs/heads/ instead of refs/remotes. Better when the actual users
> clone the git repo later...)
>
> Then I made a simple script that would loop through all my git-p4
> projects... basically just 'cd' into the dir and do 'git p4 sync'.
> This script would be run by a cron job every <whatever> minutes so it
> would always be reasonably up-to-date.
>
>> So far, I have looked at the:
>> - git-p4 documentation
>> - Version Control with Git book By: Jon Loeliger (particularly the
>> git-svn section)
>> - Mailing list (particularly following thread answered by Tor Arvid Lund)
>> - googl'n around this topic
>>
>> Most discussion is around how to use git-p4 as a sync mechanism for a
>> single user. When I attempt to git-p4 clone (import) and then create a
>> shared/bare repository out of it and emulating multiple user, the
>> git-p4 sync mechanism breaks down after couple of merges. The git-p4
>> sync/rebase/submit will try to reapply duplicate changes and trip
>> pretty early in the cycle.
>>
>> If you have a working model of making available a p4 branch for a
>> sub-team using git-p4, I would really appreciate a writeup or blog.
>> Thanks in advance.
>
> Ok, so to make things practical, I made some simple 'rules' for myself:
>
> * The blessed git repo would be "pull-only" for the git users. That is
> - no one pushes to that repo. It reads from p4, and the users do 'git
> fetch/pull' from that. Nothing more, nothing less...
>
> * When preparing commits for upload to perforce, *always* rebase them
> on top of the latest git-p4 tip.
>
> I never tried to do merges in git, and then try to turn that into
> 'integrates' in perforce. So I always kept the perforce-things
> 'linear' so that the communication between git and perforce should be
> easy. IOW I always did the "official" branching and integrate'ing
> using the perforce client.
>
> We did 'git p4 submit' directly from the users' git repos (which would
> be synced by the blessed git repo, and from there to the other git
> users). If you want another layer in-between [we use gerrit
> code-review... You may have something else, or an integration manager
> etc], you could push to another <some-project-manager-repo> and do all
> git-p4 submits from there, I guess...
>
>
> Of course, these branch/merge limitations only apply to my git history
> at the point where I want to push to perforce. In all my daily work, I
> create topic branches, rebase, reorder commits... all of the git
> goodness. I simply "linearize" things when I want to push...
>
>
> In your use-case, if you are going to do work that will result in many
> perforce integrates, you may have a harder time with git-p4 than I
> did, but it should be worth a try so that you can delight in daily git
> usage instead of cursing the awfulness that is perforce.
>
> And yes, git-p4 does rewrite every commit after you submit it. This is
> because of the quite simple design that was used to help git-p4 "know"
> what had been synced from perforce to git. Commit messages get the
> appended "[git-p4: depot-paths = ... change = 12345]" line. If git-p4
> had been written today, this could have maybe been solved using
> git-notes instead of rewriting commit msgs. I'm just saying... :)
>
> Otherwise, you will have to get around the fact that it rewrites
> everything. For me, I have used git rebase a *lot* :)
>
> Good luck!
>
> -- Tor Arvid
>
--
Kaizer H. Sogiawala
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Felipe Contreras @ 2011-02-04 17:50 UTC (permalink / raw)
To: Jeff King
Cc: J.H., Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano,
git
In-Reply-To: <20110204061622.GB2455@sigill.intra.peff.net>
On Fri, Feb 4, 2011 at 8:16 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Feb 03, 2011 at 10:34:38PM +0200, Felipe Contreras wrote:
>
>> > Forget about a git-backed wiki for a moment, and imagine a regular old
>> > Mediawiki. What are the operations you can perform? You can look at
>> > the current or any past version of a page, you can do diffs between
>> > versions of pages, and you can create a new version of a page. All
>> > through some CGI forms.
>>
>> Howe about these?
>
> I've never really used a wiki in any in-depth way, so be gentle if my
> utter cluelessness about these features shows through.
>
>> 1) Support for discussion; since changes can be controversial.
>
> Doesn't this just happen on special Talk: pages? Couldn't these just be
> pages with special names?
Could be.
>> 2) Support for article move; so everything is kept organized.
>
> Isn't that even simpler in a git-backed wiki? You just move the files.
> Obviously you would want to update links, too, and presumably the wiki
> software helps with that. But that is outside the scope of data storage.
> In a git-backed wiki, you would get one atomic commit with the move and
> link updating.
Yeah.
>> 3) Support for "who is linking here". Also helps reorganization.
>
> Again, is that a fundamental storage issue? It seems like you could
> implement that easily on top of basic storage with a grep (and some
> caching if you are going to let people do it a lot via the web).
I doubt that. That's where you need an SQL database, to make it fast.
>> 4) Support for categories. Ditto.
>
> I have no idea how categories work. Special page naming and/or
> directories?
Each page has a tag [[Category::Tips]], and then the the
Category::Tips page gets a new link automatically. Again, SQL helps.
>> 5) Support for watchlist, e-mail notifications. So that you are
>> up-to-date with the changes.
>
> Post-receive hook?
Yeah, but you need to store the watchers, and their preferences. Again, SQL.
>> 6) Support for contribution backtracking. So that it's easy to know who's who.
>
> git log? git blame? :)
Sure, 'git log' would do it... Very inefficiently.
>> 7) Personal wiki pages (with discussion). So you can put information
>> about yourself, and general notes.
>
> Specially named pages for people?
Right.
> Obviously I'm just filling in these features off the top of my head.
> MediaWiki is a mature system, and I doubt that either ikiwiki or gollum
> has nearly the same featureset. But that was never my point. In the bit
> you quoted, my point was that a git-interface to a wiki was useful and
> feasible. And I stand by that.
It might be possible to implement some functionality of a full blown
wiki such as MediaWiki on a git backed wiki, but my point is that it's
not there _now_, and more likely would never be.
> Even with just the basic functionality of fetch/diff/push, that still
> makes it a useful interface into an existing wiki for a large number of
> users who just want to do simple stuff (or power users who happen to be
> doing simple stuff at the moment).
>
> I also happen to think you could put all of those features into a
> git-backed wiki, and build the web features on _top_ of git access. But
> I'm not volunteering to work on that.
Exactly, and nobody is volunteering for that. MediaWiki is the best,
it has all the features, and it's already there.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [1.8.0] Re: reorganize the mess that the source tree has become
From: Nicolas Sebrecht @ 2011-02-04 18:15 UTC (permalink / raw)
To: Miles Bader
Cc: Hilco Wijbenga, git, Nicolas Pitre, George Spelvin, Eugene Sajine,
Nicolas Sebrecht
In-Reply-To: <87bp2sy2mf.fsf@catnip.gol.com>
The 04/02/11, Miles Bader wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> > Quite frankly, I'm surprised there are (presumably experienced)
> > developers who do not immediately see the value of a little
> > organization. Surely, given the use of code conventions, formatting
> > rules, etcetera, the obvious one step further is to also organize
> > where the files go?
>
> I think one of the problems is that what's been suggested seems like
> window-dressing. Moving everything into src/ and calling it "organized"
> doesn't actually accomplish much other than perhaps making the README
> file more visible to newbs; things are _still_ a mess, just a mess with
> four more letters...
So it would be an ordered mess, at least. The current amount of files in
the root directory do make things harder for people not already familiar
with the content. FMHO, moving the source files into a subdirectory
could be only a first step to the good direction.
--
Nicolas Sebrecht
^ permalink raw reply
* Potential problems with rebasing branch foo onto master, if master was previously merged into foo?
From: Dun Peal @ 2011-02-04 18:28 UTC (permalink / raw)
To: Git ML
I'm designing a workflow for a long-lived feature branch `foo`. This
branch will have `master` merged into about once day. About once a
week, we rebase `foo` back into `master`.
Are there any problems to be expected in this workflow? I have a
hunch the rebase back into `master` might be subject to potential
problems that I can't foresee.
I should mention that over 70 developers will be collaborating on
`foo`, spread across multiple, widely diverging timezones; any state
that requires all of these developers to coordinate / synchronize will
be prohibitively expensive for us.
Thanks, D
^ permalink raw reply
* Re: git log --summary outputs extra newlines inconsistently
From: Anders Kaseorg @ 2011-02-04 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <AANLkTinX6igafGkEv+k97Tm+V-8kEJK0rZs-K0iUGyes@mail.gmail.com>
On Fri, 4 Feb 2011, Junio C Hamano wrote:
> > ‘git log --summary’ seems to output a newline after every non-merge
> > commit.
>
> I suspect you want tformat.
Same problem.
$ git log --summary --pretty=tformat:'%h %s'
3c0eee3 Linux 2.6.37
65f4288 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
9fc3bbb ipv4/route.c: respect prefsrc for local routes
8a87694 remove trim_fs method from Documentation/filesystems/Locking
989d873 Merge master.kernel.org:/home/rmk/linux-2.6-arm
d9a1abe arch/mn10300/kernel/irq.c: fix build
867c202 ima: fix add LSM rule bug
Also, tformat doesn’t seem to work at all with -z (it gives identical
results with and without -z).
Anders
^ permalink raw reply
* [PATCH] git pull: Remove option handling done by fetch
From: Jens Lehmann @ 2011-02-04 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options
"--[no-]recurse-submodules" had been added to git-pull.sh. This was not
necessary because all options to "git fetch" are passed to it and handled
there, so lets remove them.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I noticed this while implementing the on-demand recursive fetch.
git-pull.sh | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index eb87f49..20a3bbe 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -38,7 +38,7 @@ test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress=
merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
@@ -105,12 +105,6 @@ do
--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
rebase=false
;;
- --recurse-submodules)
- recurse_submodules=--recurse-submodules
- ;;
- --no-recurse-submodules)
- recurse_submodules=--no-recurse-submodules
- ;;
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
@@ -223,7 +217,7 @@ test true = "$rebase" && {
done
}
orig_head=$(git rev-parse -q --verify HEAD)
-git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
+git fetch $verbosity $progress $dry_run --update-head-ok "$@" || exit 1
test -z "$dry_run" || exit 0
curr_head=$(git rev-parse -q --verify HEAD)
--
1.7.4.31.g5ae186
^ permalink raw reply related
* Re: Performance issue exposed by git-filter-branch
From: Ken Brownfield @ 2011-02-04 21:17 UTC (permalink / raw)
To: git, Elijah Newren
In-Reply-To: <AANLkTi=-0Sj9c5b778jchn+pgw26xCbioQ2K4tNgtm_G@mail.gmail.com>
Thanks for the feedback on git_fast_filter. It takes 11.5 hours on our repository instead of 6.5 days, so that's a significant improvement. :-) I have a couple of observations:
1) You said that your repo would have taken 2-3 months to filter with git-filter-branch, and the time was reduced to ~1hr. I'm surprised our reduction was not quite as dramatic, although I presume the variability of repo contents are the explanation.
2) The resulting repository pack files are actually much larger. A garbage collection reduces the size below the original, but only slightly. I'm concerned that the recreated repository has redundant or inefficiently stored information, but I'm not sure how to verify what objects are taking up what space.
3) git_fast_filter doesn't currently support remote submodules. When it tries to parse a submodule line, the regex fails and the code aborts:
Expected:
M 100644 :433236 foo/bar/bletch
Received, something like:
M 100644 cd821b4c0ea8e9493069ff43712a0b09 foo/bar/bletch
To correct the issue, I modified git_fast_filter to simply skip these. While we no longer utilize remote submodules, I would prefer not to have them removed.
Any feedback on what the proper behavior would be in the submodule case? Perhaps this is covered in your internal version?
Thanks,
--
Ken
On Dec 16, 2010, at 9:39 PM, Elijah Newren wrote:
> On Thu, Dec 16, 2010 at 8:08 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Ken Brownfield wrote:
>>
>>> I had considered this approach (and the one mentioned by Jonathan)
>>> but there are no git tools to actually perform the filter I wanted
>>> on the export in this form.
>>
>> Keep in mind that the two suggestions were subtly different from one
>> another.
>>
>> For the "filter fast-import stream" technique, apparently there is a
>> tool called reposurgeon[1] to do that. git_fast_filter[2] has the
>> same purpose, too, if I remember correctly.
>
> Yes, git_fast_filter was written precisely because git-filter-branch
> took waaaaaay too long. IIRC, git-filter-branch would have taken
> about 2-3 months for our use case (there's no way we could have shut
> down the repositories for that long), whereas git_fast_filter (serving
> along with fast-export and fast-import) allowed us to drop that to
> about an hour (we couldn't use --index-filter with filter-branch as we
> needed to do a number of operations on the actual file contents as
> well).
>
> All git_fast_filter really does is parse the fast-export output into
> some basic python data structures, making it easy for you to modify
> those structures as necessary (assuming basic python skills, though if
> you only need to do what one of the examples shows then you could even
> get away without that), and then pipes the results back out in the
> format fast-import expects. It has a few examples with it; removing
> existing files is one of the simple examples.
>
> I haven't really bothered keeping the public repository up-to-date
> since there hasn't been any prior external interest in it, but we
> haven't modified it much internally either, and most of those
> modifications are likely for niche stuff that you wouldn't need.
>
> Elijah
> --
> 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
^ permalink raw reply
* in the news with Delta Cooling Towers...
From: Tom Ryder @ 2011-02-04 21:45 UTC (permalink / raw)
To: git
Hi,
Delta Cooling Towers is in the news again!
Below is an on-line published article generated for Delta Cooling Towers.
The magazine is Construction Week Online.
http://www.constructionweekonline.com/article-10384-maintenance-for-cooling-towers/
Here is another on-line published article generated.
The magazine is HVAC News Online.
http://news.hvacnews.com/2011/01/new-engineered-plastic-cooling-tower-helps-keep-tenants-fresh-in-broiling-la-heat-wave.html
Thanks,
Tom Ryder
Customer Support and Business Development
Delta Cooling Towers, Inc.
41 Pine Street, PO Box 315
Rockaway, NJ 07866
Tel: 973-586-2201 x204
FAX: 973-586-2243 / 973-586-9156
Toll-Free: 1-800-BUY-DELTA
tryder@deltacooling.com
www.deltacooling.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you would like to be removed from this list, please reply with the word 'remove' as the subject.
^ 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