* [PATCH 0] A few improvements to Emacs interface to Git
From: Jakub Narebski @ 2006-07-13 20:15 UTC (permalink / raw)
To: git
This series of patches introduces a few minor improvements to
Emacs interface to Git.
--
Jakub Narebski
^ permalink raw reply
* Re: As long as you're hacking on git-daemon...
From: Matthias Lederhofer @ 2006-07-13 20:19 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060713201248.25353.qmail@science.horizon.com>
linux@horizon.com <linux@horizon.com> wrote:
> Is it possible to make it capable of running from /etc/inetd.conf?
It is, see man git-daemon, --inetd :)
^ permalink raw reply
* [PATCH 2] Display help for Git mode after pressing `h' or `?' in *git-status*
From: Jakub Narebski @ 2006-07-13 20:22 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11528217463561-git-send-email-jnareb@gmail.com>
Add bindings for "h" and "?" in git-status-mode to display help about the mode,
including keymap via (describe-function 'git-status-mode), like in PCL-CVS.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/emacs/git.el | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 83a845d..34c9950 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -943,6 +943,8 @@ (unless git-status-mode-map
(let ((map (make-keymap))
(diff-map (make-sparse-keymap)))
(suppress-keymap map)
+ (define-key map "?" 'git-help)
+ (define-key map "h" 'git-help)
(define-key map " " 'git-next-file)
(define-key map "a" 'git-add-file)
(define-key map "c" 'git-commit-file)
@@ -1012,5 +1014,10 @@ (defun git-status (dir)
(goto-char (point-min)))
(message "%s is not a git working tree." dir)))
+(defun git-help ()
+ "Display help for Git mode."
+ (interactive)
+ (describe-function 'git-status-mode))
+
(provide 'git)
;;; git.el ends here
--
1.4.0
^ permalink raw reply related
* [PATCH 1] Wrap long lines in docstrings in contrib/emacs/git.el
From: Jakub Narebski @ 2006-07-13 20:22 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <11528217463561-git-send-email-jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
contrib/emacs/git.el | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index ebd00ef..83a845d 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -59,14 +59,16 @@ (defgroup git nil
(defcustom git-committer-name nil
"User name to use for commits.
-The default is to fall back to the repository config, then to `add-log-full-name' and then to `user-full-name'."
+The default is to fall back to the repository config,
+then to `add-log-full-name' and then to `user-full-name'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Name")))
(defcustom git-committer-email nil
"Email address to use for commits.
-The default is to fall back to the git repository config, then to `add-log-mailing-address' and then to `user-mail-address'."
+The default is to fall back to the git repository config,
+then to `add-log-mailing-address' and then to `user-mail-address'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Email")))
@@ -86,6 +88,7 @@ (defcustom git-per-dir-ignore-file ".git
:group 'git
:type 'string)
+
(defface git-status-face
'((((class color) (background light)) (:foreground "purple")))
"Git mode face used to highlight added and modified files."
@@ -149,7 +152,8 @@ (defun git-call-process-env (buffer env
(apply #'call-process "git" nil buffer nil args)))
(defun git-call-process-env-string (env &rest args)
- "Wrapper for call-process that sets environment strings, and returns the process output as a string."
+ "Wrapper for call-process that sets environment strings,
+and returns the process output as a string."
(with-temp-buffer
(and (eq 0 (apply #' git-call-process-env t env args))
(buffer-string))))
--
1.4.0
^ permalink raw reply related
* when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:21 UTC (permalink / raw)
To: git
I assume the -C and -M, -c, and -cc options all result in diff output
that can't be correctly applied by "patch" any more? (Would a patch to
the git-diff-files documentation warning about this be helpful?)
Someone I'm working with is having trouble applying patches that they
created with a simple "git diff". The patches in question have some
"copy from/copy to" headers. Should that every happen with just a plain
"git diff"? Is this a bug in their version of git? (They're on 1.2.4).
--b.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: Junio C Hamano @ 2006-07-13 21:27 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060713212127.GA30770@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> I assume the -C and -M, -c, and -cc options all result in diff output
> that can't be correctly applied by "patch" any more? (Would a patch to
> the git-diff-files documentation warning about this be helpful?)
May not be bad to have, except that I do not know if
"git-diff-files" documentation is the right place to talk about
it.
> Someone I'm working with is having trouble applying patches that they
> created with a simple "git diff". The patches in question have some
> "copy from/copy to" headers. Should that every happen with just a plain
> "git diff"? Is this a bug in their version of git? (They're on 1.2.4).
As far as I recall "git diff" never defaulted to -M. These days
you can have diff.renames = true in the configuration to make it
so, but and I do not think there was any way to do that back in
1.2.4.
If _they_ created the diff with git, and if that is the same
_they_ who are having trouble applying, maybe you can suggest to
use "git apply" instead of "patch -p1"?
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Junio C Hamano @ 2006-07-13 21:31 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <44B6369D.6070602@codeweavers.com>
Robert Shearman <rob@codeweavers.com> writes:
> This patch inserts a newline in two places - once in the loop to
> separate the subject part of the commit message from the body part of
> the commit message and another after the loop to counteract the eating
> of whitespace at the end of the message.
Thanks.
* Please sign your patch.
* This breaks a handful t4013 tests, but all in a good way (in
other words, the expected output files were wrong).
I'll fix up the t/t4013/diff.* files myself.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd1lurei.fsf@assigned-by-dhcp.cox.net>
On Thu, Jul 13, 2006 at 02:27:33PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > I assume the -C and -M, -c, and -cc options all result in diff output
> > that can't be correctly applied by "patch" any more? (Would a patch to
> > the git-diff-files documentation warning about this be helpful?)
>
> May not be bad to have, except that I do not know if
> "git-diff-files" documentation is the right place to talk about
> it.
OK.
> > Someone I'm working with is having trouble applying patches that they
> > created with a simple "git diff". The patches in question have some
> > "copy from/copy to" headers. Should that every happen with just a plain
> > "git diff"? Is this a bug in their version of git? (They're on 1.2.4).
>
> As far as I recall "git diff" never defaulted to -M.
Hm. Is this related?:
commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
Author: Junio C Hamano <junkio@cox.net>
Date: Sat Mar 11 17:44:10 2006 -0800
git-diff: -p disables rename detection.
--b.
^ permalink raw reply
* Re: As long as you're hacking on git-daemon...
From: linux @ 2006-07-13 21:38 UTC (permalink / raw)
To: linux, matled; +Cc: git
In-Reply-To: <E1G17eZ-0006qh-PV@moooo.ath.cx>
> It is, see man git-daemon, --inetd :)
*Blush*. I remember looking for that a while ago and not finding it,
but it appears that it's been there for a year
(since e64e1b79d7c50a234e97d59aadc7a4911de91efe)
I don't think it was that long ago that I looked, so I must have somehow
been utterly blind.
Sorry.
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Junio C Hamano @ 2006-07-13 21:48 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <7vbqrtur8q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Robert Shearman <rob@codeweavers.com> writes:
>
>> This patch inserts a newline in two places - once in the loop to
>> separate the subject part of the commit message from the body part of
>> the commit message and another after the loop to counteract the eating
>> of whitespace at the end of the message.
>
> Thanks.
>
> * Please sign your patch.
>
> * This breaks a handful t4013 tests, but all in a good way (in
> other words, the expected output files were wrong).
>
> I'll fix up the t/t4013/diff.* files myself.
Actually, I take that back. This breaks normal commit log
messages by adding extra blank lines. The extra LF is needed
when the commit log does not have any message (just title).
I'll be tweaking a few tests in t4013 to catch future breakage
of this kind.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: Junio C Hamano @ 2006-07-13 21:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060713213116.GK19366@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> As far as I recall "git diff" never defaulted to -M.
>
> Hm. Is this related?:
>
> commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
> Author: Junio C Hamano <junkio@cox.net>
> Date: Sat Mar 11 17:44:10 2006 -0800
>
> git-diff: -p disables rename detection.
Ah, sorry, it _did_ default to -M; it was in such an ancient
past and the shell wrapper wasn't initially done by me, so I
misremembered.
^ permalink raw reply
* Re: when is "git diff" output suitable for patch?
From: J. Bruce Fields @ 2006-07-13 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bd5uqav.fsf@assigned-by-dhcp.cox.net>
On Thu, Jul 13, 2006 at 02:51:20PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> >> As far as I recall "git diff" never defaulted to -M.
> >
> > Hm. Is this related?:
> >
> > commit 42efbf6d8a5b4902c55a2f6e96034625c056ba1f
> > Author: Junio C Hamano <junkio@cox.net>
> > Date: Sat Mar 11 17:44:10 2006 -0800
> >
> > git-diff: -p disables rename detection.
>
> Ah, sorry, it _did_ default to -M; it was in such an ancient
> past and the shell wrapper wasn't initially done by me, so I
> misremembered.
Perfectly understandable; thanks for the help.--b.
^ permalink raw reply
* Re: [PATCH] format-patch: Generate a newline between the subject header and the message body.
From: Robert Shearman @ 2006-07-13 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2huqfj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Junio C Hamano <junkio@cox.net> writes:
>
>
>
>>Robert Shearman <rob@codeweavers.com> writes:
>>
>>
>>
>>>This patch inserts a newline in two places - once in the loop to
>>>separate the subject part of the commit message from the body part of
>>>the commit message and another after the loop to counteract the eating
>>>of whitespace at the end of the message.
>>>
>>>
>>Thanks.
>>
>> * Please sign your patch.
>>
>> * This breaks a handful t4013 tests, but all in a good way (in
>> other words, the expected output files were wrong).
>>
>>I'll fix up the t/t4013/diff.* files myself.
>>
>>
>
>Actually, I take that back. This breaks normal commit log
>messages by adding extra blank lines. The extra LF is needed
>when the commit log does not have any message (just title).
>
>
Ok, I'll resend with that fixed.
>I'll be tweaking a few tests in t4013 to catch future breakage
>of this kind.
>
Thanks.
--
Rob Shearman
^ permalink raw reply
* [PATCH] format-patch: Generate a newline between the subject header and the message body
From: Robert Shearman @ 2006-07-13 22:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]
format-patch previously didn't generate a newline after a subject. This
caused the diffstat to not be displayed in messages with only one line
for the commit message.
This patch fixes this by adding a newline after the headers if a body
hasn't been added.
Signed-off-by: Robert Shearman <rob@codeweavers.com>
---
commit.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
[-- Attachment #2: e4ec67def0af32e4a1704ce5ad941c81136b34e8.diff --]
[-- Type: text/x-patch, Size: 884 bytes --]
diff --git a/commit.c b/commit.c
index 522a6f3..6ac3bf7 100644
--- a/commit.c
+++ b/commit.c
@@ -655,6 +655,9 @@ unsigned long pretty_print_commit(enum c
continue;
}
+ if (!subject)
+ body = 1;
+
if (is_empty_line(line, &linelen)) {
if (!body)
continue;
@@ -662,8 +665,6 @@ unsigned long pretty_print_commit(enum c
continue;
if (fmt == CMIT_FMT_SHORT)
break;
- } else {
- body = 1;
}
if (subject) {
@@ -702,6 +703,12 @@ unsigned long pretty_print_commit(enum c
/* Make sure there is an EOLN for the non-oneline case */
if (fmt != CMIT_FMT_ONELINE)
buf[offset++] = '\n';
+ /*
+ * make sure there is another EOLN to separate the headers from whatever
+ * body the caller appends if we haven't already written a body
+ */
+ if (fmt == CMIT_FMT_EMAIL && !body)
+ buf[offset++] = '\n';
buf[offset] = '\0';
return offset;
}
^ permalink raw reply related
* Kernel headers git tree
From: David Woodhouse @ 2006-07-13 23:59 UTC (permalink / raw)
To: linux-kernel; +Cc: git
At http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
there's a git tree which contains the sanitised exported headers for all
architectures -- basically the result of 'make headers_install'.
It tracks Linus' kernel tree, by means of some evil scripts.¹
Only commits in Linus' tree which actually affect the exported result
should have an equivalent commit in the above tree, which means that any
changes which affect userspace should be clearly visible for review.
--
dwmw2
¹ http://david.woodhou.se/extract-khdrs-git.sh and
http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 0:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1152835150.31372.23.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> ¹ http://david.woodhou.se/extract-khdrs-git.sh and
> http://david.woodhou.se/extract-khdrs-stage2.sh for the stout of stomach
With modern enough git, you can rewrite
KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
with
KBUILDSHA1=`git rev-parse $TREE:Kbuild`
I am not sure what function incparent() is trying to do with
this:
git rev-list --max-count=1 --topo-order $1 -- .
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:
> With modern enough git, you can rewrite
> KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
> with
> KBUILDSHA1=`git rev-parse $TREE:Kbuild`
Aha. Thanks.
> I am not sure what function incparent() is trying to do with
> this:
>
> git rev-list --max-count=1 --topo-order $1 -- .
Find the latest ancestor commit which actually changed any files. The
first script has a similar line, except that it finds the latest
ancestor which changed anything in include/
Consider a kernel tree with commits A-->B-->C-->D, of which only A and C
change anything in include/ and in fact only C actually changes the
_exported_ headers after the unifdef and sed bits.
The first script (extract-khdrs-git.sh) creates a 'stage1' branch which
only contains commits A'-->C', with the _exported_ header tree for each.
The second script (extract-khdrs-stage2.sh) then creates the master
branch with the same tree objects, but omitting the commits which don't
change anything. So it contains only commit C''
For an example of this, compare
http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
with
http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git;a=shortlog;h=stage1
Btw, git-rev-list is _very_ slow at this. Even when the output is
actually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:
pmac /pmac/git/linux-2.6 $ git-rev-parse HEAD
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
pmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m18.840s
Is there a better way to do that step?
--
dwmw2
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Woodhouse, git
In-Reply-To: <7v4pxlt3xg.fsf@assigned-by-dhcp.cox.net>
On Thu, 13 Jul 2006, Junio C Hamano wrote:
>
> I am not sure what function incparent() is trying to do with
> this:
>
> git rev-list --max-count=1 --topo-order $1 -- .
Yeah, that looks strange.
The "--topo-order" in particular looks pointless, and just slows things
down.
The default ordering from git-rev-list (and all other revision listing
things, ie "git log" etc) _does_ guarantee that we never show a child
before _one_ of its parents has been shown (although "parent" in this case
may be the command line).
As such, "--max-count=1 --topo-order" is pointless if you only give one
revision, because whether you use --topo-order or not, the first commit
will always be the parent of all subsequent commits.
So --topo-order just makes things MUCH MUCH slower with no upsides.
But that thing is doubly strange, because it uses "." as a path specifier.
If this is done in the top-most directory, that should mean "all changes",
which in turn means that the whole thing should be equivalent to
git rev-parse "$1^0"
since all commits should make _some_ change, and thus the first revision
in the list should always be the top commit - the one you passed in as an
argument.
Linus
^ permalink raw reply
* Re: Kernel headers git tree
From: Linus Torvalds @ 2006-07-14 1:08 UTC (permalink / raw)
To: David Woodhouse; +Cc: Junio C Hamano, git
In-Reply-To: <1152838562.31372.58.camel@shinybook.infradead.org>
On Fri, 14 Jul 2006, David Woodhouse wrote:
>
> Btw, git-rev-list is _very_ slow at this. Even when the output is
> actually HEAD, it takes my 2.3GHz G5 a _long_ time to give a result:
>
> pmac /pmac/git/linux-2.6 $ git-rev-parse HEAD
> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
> pmac /pmac/git/linux-2.6 $ time git-rev-list --max-count=1 --topo-order HEAD -- include
> ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
>
> real 0m18.840s
>
> Is there a better way to do that step?
Umm.. On my poor little 1.6GHz laptop:
[torvalds@evo linux]$ time git-rev-list --max-count=1 HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m0.014s
user 0m0.004s
sys 0m0.012s
that's 0.014 sec. Not exactly slow.
Now, the --topo-order you have there does slow it down a lot:
[torvalds@evo linux]$ time git-rev-list --max-count=1 --topo-order HEAD -- include
ab6cf0d0cb96417ef65cc2c2120c0e879edf7a4a
real 0m24.016s
user 0m23.973s
sys 0m0.016s
so now it takes 24 seconds, and gives the same result.
Linus
^ permalink raw reply
* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 1:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607131800520.5623@g5.osdl.org>
On Thu, 2006-07-13 at 18:05 -0700, Linus Torvalds wrote:
>
> On Thu, 13 Jul 2006, Junio C Hamano wrote:
> >
> > I am not sure what function incparent() is trying to do with
> > this:
> >
> > git rev-list --max-count=1 --topo-order $1 -- .
>
> Yeah, that looks strange.
>
> The "--topo-order" in particular looks pointless, and just slows things
> down.
>
> The default ordering from git-rev-list (and all other revision listing
> things, ie "git log" etc) _does_ guarantee that we never show a child
> before _one_ of its parents has been shown (although "parent" in this case
> may be the command line).
Does it? I thought at one point it sorted on some random criterion like
alphabetically by author, or some other cosmetic information which isn't
really part of the git structure -- like the timestamp or something?
We still don't enforce monotonicity, do we? The timestamps are still
just fluff?
> But that thing is doubly strange, because it uses "." as a path specifier.
> If this is done in the top-most directory, that should mean "all changes",
> which in turn means that the whole thing should be equivalent to
>
> git rev-parse "$1^0"
>
> since all commits should make _some_ change, and thus the first revision
> in the list should always be the top commit - the one you passed in as an
> argument.
In this case, I really do have commits in the intermediate tree which
don't actually change anything, and I want to filter them out -- I
couldn't see a simple way to do it all in one pass.
--
dwmw2
^ permalink raw reply
* Most quality products for anyone who wants to become a champion in bed
From: Olive @ 2006-07-14 2:19 UTC (permalink / raw)
To: godard
Good Day!
Impress your girl with prolonged hardness, plentiful explosions and increased duration
Masculine performance has never been so easy to increase with these products
http://www.icicledid.com
To keep thee from the evil woman, from the flattery of the tongue of a strange woman. Little Strokes Fell Great Oaks There is always some madness in love But there is also always some reason in madness
The West Wind Always Brings Wet Weather, The East Wind Wet and Cold Together, the South Wind Surely Brings Us Rain, the North Wind Blows It Back Again All good things come to those who wait.
^ permalink raw reply
* Re: Kernel headers git tree
From: Junio C Hamano @ 2006-07-14 2:37 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1152838562.31372.58.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> On Thu, 2006-07-13 at 17:39 -0700, Junio C Hamano wrote:
>> With modern enough git, you can rewrite
>> KBUILDSHA=`git ls-tree $TREE -- Kbuild | cut -f3 -d\ | cut -f1`
>> with
>> KBUILDSHA1=`git rev-parse $TREE:Kbuild`
>
>
> Aha. Thanks.
>
>> I am not sure what function incparent() is trying to do with
>> this:
>>
>> git rev-list --max-count=1 --topo-order $1 -- .
>
> Find the latest ancestor commit which actually changed any files. The
> first script has a similar line, except that it finds the latest
> ancestor which changed anything in include/
>
> Consider a kernel tree with commits A-->B-->C-->D, of which only A and C
> change anything in include/ and in fact only C actually changes the
> _exported_ headers after the unifdef and sed bits.
>
> The first script (extract-khdrs-git.sh) creates a 'stage1' branch which
> only contains commits A'-->C', with the _exported_ header tree for each.
>
> The second script (extract-khdrs-stage2.sh) then creates the master
> branch with the same tree objects, but omitting the commits which don't
> change anything. So it contains only commit C''
I guess what I was getting at was if you can avoid creating
commits that do not change anything from previous in stage1
branch, you do not have to do this, but I haven't studied stage1
script deeply enough.
^ permalink raw reply
* Re: Error writing loose object on Cygwin
From: Shawn Pearce @ 2006-07-14 3:34 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060713055127.GA15960@trixie.casa.cgf.cx>
Christopher Faylor <me@cgf.cx> wrote:
> On Tue, Jul 11, 2006 at 09:15:38PM -0700, Junio C Hamano wrote:
> >Shawn Pearce <spearce@spearce.org> writes:
> >
> >> Has anyone else seen this type of behavior before? Any suggestions
> >> on debugging this issue?
> >
> >I would suggest raising this (politely) to Cygwin people.
>
> I lost the thread here but wasn't this referring to a samba mount? If so,
> it would be samba that's returning the wrong "errno".
I thought about that but Windows 2000 talking to the same samba
server issues back the correct errno. Running the exact same Cygwin
and GIT binaries (we've at least standardized on that). So it
seems weird that a samba server is issuing the correct error code
to a Windows 2000 client but the wrong one to a Windows XP client.
(In both cases the clients are accessing directories on the same
filesystem on the UNIX server.)
--
Shawn.
^ permalink raw reply
* [PATCH 1/2] Avoid using the git wrapper in git-rebase.sh.
From: Shawn Pearce @ 2006-07-14 4:46 UTC (permalink / raw)
To: git
Ideally 'shipped' commands (e.g. git-rebase) should avoid calling
the git wrapper when executing other commands to prevent the user
from shadowing those commands with aliases and causing the shipped
command behavior to differ unexpectedly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 1b9e986..6d06665 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -131,7 +131,7 @@ do
finish_rb_merge
exit
fi
- git am --resolved --3way --resolvemsg="$RESOLVEMSG"
+ git-am --resolved --3way --resolvemsg="$RESOLVEMSG"
exit
;;
--skip)
@@ -150,7 +150,7 @@ do
finish_rb_merge
exit
fi
- git am -3 --skip --resolvemsg="$RESOLVEMSG"
+ git-am -3 --skip --resolvemsg="$RESOLVEMSG"
exit
;;
--abort)
@@ -163,7 +163,7 @@ do
else
die "No rebase in progress?"
fi
- git reset --hard ORIG_HEAD
+ git-reset --hard ORIG_HEAD
exit
;;
--onto)
@@ -231,7 +231,7 @@ esac
# The upstream head must be given. Make sure it is valid.
upstream_name="$1"
-upstream=`git rev-parse --verify "${upstream_name}^0"` ||
+upstream=`git-rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
# If a hook exists, give it a chance to interrupt
@@ -250,7 +250,7 @@ case "$#" in
git-checkout "$2" || usage
;;
*)
- branch_name=`git symbolic-ref HEAD` || die "No current branch"
+ branch_name=`git-symbolic-ref HEAD` || die "No current branch"
branch_name=`expr "z$branch_name" : 'zrefs/heads/\(.*\)'`
;;
esac
@@ -288,7 +288,7 @@ fi
if test -z "$do_merge"
then
git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
- git am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+ git-am --binary -3 -k --resolvemsg="$RESOLVEMSG"
exit $?
fi
--
1.4.1.gd3d5
^ permalink raw reply related
* [PATCH 2/2] Record rebase changes as 'rebase' in the reflog.
From: Shawn Pearce @ 2006-07-14 4:47 UTC (permalink / raw)
To: git
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-am.sh | 6 +++++-
git-rebase.sh | 9 ++++++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index db9a20a..3a129e0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -91,6 +91,7 @@ fall_back_3way () {
}
prec=4
+rloga=am
dotest=.dotest sign= utf8= keep= skip= interactive= resolved= binary= ws= resolvemsg=
while case "$#" in 0) break;; esac
@@ -130,6 +131,9 @@ do
--resolvemsg=*)
resolvemsg=$(echo "$1" | sed -e "s/^--resolvemsg=//"); shift ;;
+ --reflog-action=*)
+ rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`; shift ;;
+
--)
shift; break ;;
-*)
@@ -413,7 +417,7 @@ do
parent=$(git-rev-parse --verify HEAD) &&
commit=$(git-commit-tree $tree -p $parent <"$dotest/final-commit") &&
echo Committed: $commit &&
- git-update-ref -m "am: $SUBJECT" HEAD $commit $parent ||
+ git-update-ref -m "$rloga: $SUBJECT" HEAD $commit $parent ||
stop_here $this
if test -x "$GIT_DIR"/hooks/post-applypatch
diff --git a/git-rebase.sh b/git-rebase.sh
index 6d06665..14d7ed9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -131,7 +131,8 @@ do
finish_rb_merge
exit
fi
- git-am --resolved --3way --resolvemsg="$RESOLVEMSG"
+ git-am --resolved --3way --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit
;;
--skip)
@@ -150,7 +151,8 @@ do
finish_rb_merge
exit
fi
- git-am -3 --skip --resolvemsg="$RESOLVEMSG"
+ git-am -3 --skip --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit
;;
--abort)
@@ -288,7 +290,8 @@ fi
if test -z "$do_merge"
then
git-format-patch -k --stdout --full-index "$upstream"..ORIG_HEAD |
- git-am --binary -3 -k --resolvemsg="$RESOLVEMSG"
+ git-am --binary -3 -k --resolvemsg="$RESOLVEMSG" \
+ --reflog-action=rebase
exit $?
fi
--
1.4.1.gd3d5
^ permalink raw reply related
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