* [PATCH 0/2] gitweb: blame: make cut-and-paste legible
From: Luben Tuikov @ 2006-10-05 0:57 UTC (permalink / raw)
To: git
The following set of patches makes cut-and-paste from blame
legible in the destination buffer. E.g.:
cae1862a 3033 if (defined $co{'parent'}) {
3034 push @views_nav,
3035 $cgi->a({-href => href(action=>"shortlog", hash=>$hash)}, "shortlog"),
3036 $cgi->a({-href => href(action=>"log", hash=>$hash)}, "log");
3037 }
It also adds "title" to all rows of data.
Luben
^ permalink raw reply
* [PATCH 1/2] gitweb: blame: Print just a single new line char per table row
From: Luben Tuikov @ 2006-10-05 0:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
This makes cut-and-paste from blame legible, else after
pasting it is broken into too many lines.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 996 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cba0840..451bf5d 100644
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2509,7 +2509,7 @@ HTML
$current_color = ++$current_color % $num_colors;
$print_c8 = 1;
}
- print "<tr class=\"$rev_color[$current_color]\">\n";
+ print "<tr class=\"$rev_color[$current_color]\">";
print "<td class=\"sha1\"";
if ($print_c8 == 1) {
print " title=\"$author, $date\"";
@@ -2519,10 +2519,10 @@ HTML
print $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev));
}
- print "</td>\n";
+ print "</td>";
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
- esc_html($lineno) . "</a></td>\n";
- print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
+ esc_html($lineno) . "</a></td>";
+ print "<td class=\"pre\">" . esc_html($data) . "</td>";
print "</tr>\n";
}
print "</table>\n";
--
1.4.2.3.g7d77
^ permalink raw reply related
* [PATCH 2/2] gitweb: blame: All rows have title; print 8 SP when no leading commit-8
From: Luben Tuikov @ 2006-10-05 1:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Print eight spaces when no leading commit is being printed.
I.e. on all rows of a commit-block, but the first. This fixes
alignment in the destination buffer when blame data lines
are cut and pasted.
Also, now all rows have title.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
[-- Attachment #2: 1908141687-p2.txt --]
[-- Type: text/plain, Size: 898 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 451bf5d..2949fa4 100644
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2510,15 +2510,12 @@ HTML
$print_c8 = 1;
}
print "<tr class=\"$rev_color[$current_color]\">";
- print "<td class=\"sha1\"";
- if ($print_c8 == 1) {
- print " title=\"$author, $date\"";
- }
- print ">";
- if ($print_c8 == 1) {
- print $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
- esc_html($rev));
+ print "<td class=\"sha1\" title=\"$author, $date\">";
+ if ($print_c8 == 0) {
+ $rev = " ";
}
+ print $cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
+ esc_html($rev));
print "</td>";
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
esc_html($lineno) . "</a></td>";
--
1.4.2.3.g7d77
^ permalink raw reply related
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Junio C Hamano @ 2006-10-05 1:03 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061004155928.57310.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Yes, I completely understand the problem you're describing
> here and have seen even more extreme examples of it.
I agree with your conclusion. More than one commit-8 placed in
a large group end up visually suggesting that they are
separating the group into multiple pieces that have some
meaning, which is not, because the contrast of zebra shading
between groups is very subtle and is much weaker than commit-8
"clickable handles".
I am not suggesting to make the contrast of shading stronger;
that would make things harder to read, and readability matters
more on that page.
Will revert mine from "next" (along with the mistakenly dropped
executable bit) and replace with your patch 1 and 2.
^ permalink raw reply
* Re: [PATCH] gitweb: make leftmost column of blame less cluttered.
From: Luben Tuikov @ 2006-10-05 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpnk20p.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Yes, I completely understand the problem you're describing
> > here and have seen even more extreme examples of it.
>
> I agree with your conclusion. More than one commit-8 placed in
> a large group end up visually suggesting that they are
> separating the group into multiple pieces that have some
> meaning, which is not, because the contrast of zebra shading
> between groups is very subtle and is much weaker than commit-8
> "clickable handles".
>
> I am not suggesting to make the contrast of shading stronger;
> that would make things harder to read, and readability matters
> more on that page.
>
> Will revert mine from "next" (along with the mistakenly dropped
> executable bit) and replace with your patch 1 and 2.
Sounds great -- thanks!
Luben
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: blame: All rows have title; print 8 SP when no leading commit-8
From: Junio C Hamano @ 2006-10-05 1:24 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061005010215.63402.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Print eight spaces when no leading commit is being printed.
> I.e. on all rows of a commit-block, but the first. This fixes
> alignment in the destination buffer when blame data lines
> are cut and pasted.
>
> Also, now all rows have title.
Its visuals might be Ok (I haven't had chance to try it), but I
am a bit worried about the output size bloat. What kind of
bloat factor are we talking about with this patch?
- compared to the ancient original, which used to have commit-8
on all lines, title * N lines for a file that is N lines
long. A title ("$author, $date") is about say 30 bytes or so
so for a file that is on average 25 bytes per line (this is
from "wc *.c" in git.git repository ) we are now spewing out
roughly twice the bytes back to the browser (25+8 vs 25+8+30)
- compared to "only first in the block" version, assuming an
average group size is 10 lines or so (this is a totally made
up number) we are adding 72 extra bytes per 10 lines for
commit-8 on top of the title bloat which would be 270 bytes
per 10 lines. Again assuming 25-byte per line average, that
is 250+8+30 vs 250+80+300 per 10 lines. Again, roughly
twice.
I am not sure what the numbers of the chunked one I just
reverted from "next" compared to the original. For the same
group size assumption, it added 8 bytes for commit-8 and 30
bytes for title per the N lines, but we are assuming 10-line
blocks, so 38 byte overhead per 10 lines, which is 250+80 vs
250+38, so it might have been actually slimmer than the
original.
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: blame: All rows have title; print 8 SP when no leading commit-8
From: Luben Tuikov @ 2006-10-05 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt7fimgs.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Its visuals might be Ok (I haven't had chance to try it), but I
> am a bit worried about the output size bloat. What kind of
> bloat factor are we talking about with this patch?
>
> - compared to the ancient original, which used to have commit-8
> on all lines, title * N lines for a file that is N lines
> long. A title ("$author, $date") is about say 30 bytes or so
> so for a file that is on average 25 bytes per line (this is
> from "wc *.c" in git.git repository ) we are now spewing out
> roughly twice the bytes back to the browser (25+8 vs 25+8+30)
>
> - compared to "only first in the block" version, assuming an
> average group size is 10 lines or so (this is a totally made
> up number) we are adding 72 extra bytes per 10 lines for
> commit-8 on top of the title bloat which would be 270 bytes
> per 10 lines. Again assuming 25-byte per line average, that
> is 250+8+30 vs 250+80+300 per 10 lines. Again, roughly
> twice.
>
> I am not sure what the numbers of the chunked one I just
> reverted from "next" compared to the original. For the same
> group size assumption, it added 8 bytes for commit-8 and 30
> bytes for title per the N lines, but we are assuming 10-line
> blocks, so 38 byte overhead per 10 lines, which is 250+80 vs
> 250+38, so it might have been actually slimmer than the
> original.
Yes, I agree with you. That patch adds bloat. I agree with
you, we can print the "title=" only for the leading commit-8,
as we currently do, and dispense with 8 SP. In effect this
patch 2/2 can be dropped.
Thanks,
Luben
^ permalink raw reply
* (unknown),
From: JOSEPH KULIG @ 2006-10-05 1:54 UTC (permalink / raw)
To: majordomo
unsubscribe jkulig@everstream.com
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: blame: Print just a single new line char per table row
From: Junio C Hamano @ 2006-10-05 2:35 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061005005926.57010.qmail@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> This makes cut-and-paste from blame legible, else after
> pasting it is broken into too many lines.
>
> Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
I have to say the browser is seriously broken if whitespaces
between <tr> and <td>, </td> and next <td>, </td> and </tr>
makes a difference to its behaviour. Aren't there a way to tell
the browser to cut "visually"? E.g. "The area I want to cut is
from this data column, and lines from here to there. I do not
want the leftmost two columns (commit-8 and lineno)".
I do not mind applying this, but that is only because it does
not make its source any less readable. It does make things
harder to debug if somebody is debugging its output by reading
the generated raw HTML, so it is not like there is no downside.
You might want to run links (or lynx) in screen ;-). Screen
supports left- (or right-, or both-sides) bounded cut which I
find extremely useful.
^ permalink raw reply
* Re: [PATCH] pack-refs: use lockfile as everybody else does.
From: Linus Torvalds @ 2006-10-05 2:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7izhrc2v.fsf@assigned-by-dhcp.cox.net>
On Tue, 3 Oct 2006, Junio C Hamano wrote:
>
> Also I am not sure about the "fsync(fd); fclose(refs_file)"
> sequence I did not touch with this patch. Doesn't stdio still
> have stuff buffered when you run fsync()? Would adding fflush()
> in between help?
Yes, there should be a fflush() there before the fsync.
Linus
^ permalink raw reply
* Re: [PATCH] pack-refs: use lockfile as everybody else does.
From: Junio C Hamano @ 2006-10-05 6:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610041954480.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Yes, there should be a fflush() there before the fsync.
While I have your attention... The code that follows the
committing of packed-refs file by calling rename() to move the
lock file to its final name prunes already packed refs, and we
should really make sure the effect of rename() survives before
starting to remove loose refs from the filesystem.
How would one ensure the effect of rename(2) hits the disk
platter before proceeding to do something else? We seem to do
sync(1) in git-repack.sh for similar reasons, and I wonder if we
should do a sync(2) there. I doubt it would be worth it though;
the function can return before the actual writing is done.
If the write-out of metainfo is ordered enough that if we rename
the packed-refs lock file to its final destination and then we
unlink loose refs, it might be reasonably safe to assume that
rename(2)'s effect has already hit the disk when the effect of
unlink(2) does, of the machine crashes in the meantime, as long
as none of the later unlink hits the disk before rename does it
is Ok.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: blame: Print just a single new line char per table row
From: Luben Tuikov @ 2006-10-05 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejtnij5n.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> I have to say the browser is seriously broken if whitespaces
> between <tr> and <td>, </td> and next <td>, </td> and </tr>
> makes a difference to its behaviour. Aren't there a way to tell
> the browser to cut "visually"? E.g. "The area I want to cut is
I'm not sure, I'm using latest Firefox.
> from this data column, and lines from here to there. I do not
> want the leftmost two columns (commit-8 and lineno)".
>
> I do not mind applying this, but that is only because it does
> not make its source any less readable. It does make things
> harder to debug if somebody is debugging its output by reading
> the generated raw HTML, so it is not like there is no downside.
If you think that this could be a problem or affects negatively,
please don't apply. cut-paste-edit is a small price to pay
as opposed to messing up the code and output.
> You might want to run links (or lynx) in screen ;-). Screen
> supports left- (or right-, or both-sides) bounded cut which I
> find extremely useful.
Ok, I'll try that.
Luben
^ permalink raw reply
* perhaps time to remove git_blame from gitweb, and git-annotate?
From: Junio C Hamano @ 2006-10-05 8:13 UTC (permalink / raw)
To: git
Cc: Luben Tuikov, Petr Baudis, Jakub Narebski, Ryan Anderson,
Johannes Schindelin, Martin Langhoff, Martyn Smith,
Fredrik Kuivinen, Linus Torvalds
In-Reply-To: <20061005064817.21552.qmail@web31804.mail.mud.yahoo.com>
It's been a while since we lost git_blame from %actions list. I
am wondering maybe it's time to remove it, after 1.4.3 happens.
While I was looking at it, I noticed that it would make
git-cvsserver the last in-tree user of git-annotate. As I
understand it, "git-blame -c" should produce compatible output
to the command, so it might also be a good time to consider
removal of git-annotate as well while updating git-cvsserver to
use git-blame instead of it.
Do people have reason to favor annotate over blame? To keep
existing people's scripts working I think we should add a small
amount of code to blame.c to default to compatibility mode when
the command is called as git-annotate at least for a while, but
other than that I do not see much issue against scheduling for
annotate's removal.
I am not going to do anything about this right now (the "master"
branch is in freeze-and-stabilize phase), but if people have
issues I overlooked, raise hands now please?
^ permalink raw reply
* [PATCH] Add git-upload-archive to the main git man page
From: Franck Bui-Huu @ 2006-10-05 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Franck Bui-Huu <fbuihuu@gmail.com>
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
Documentation/git.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 2135b65..3af6fc6 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -243,6 +243,9 @@ gitlink:git-update-server-info[1]::
Updates auxiliary information on a dumb server to help
clients discover references and packs on it.
+gitlink:git-upload-archive[1]::
+ Invoked by 'git-archive' to send a generated archive.
+
gitlink:git-upload-pack[1]::
Invoked by 'git-fetch-pack' to push
what are asked for.
--
1.4.2.3
^ permalink raw reply related
* Re: [PATCH] Add git-upload-archive to the main git man page
From: Junio C Hamano @ 2006-10-05 8:57 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <4524C568.2050507@innova-card.com>
Thanks.
I should run "make check-docs" more often.
^ permalink raw reply
* [PATCH] git.el: Fixed inverted "renamed from/to" message.
From: Alexandre Julliard @ 2006-10-05 9:29 UTC (permalink / raw)
To: git
The deleted file should be labeled "renamed to" and the added file
"renamed from", not the other way around (duh!)
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 68de9be..5354cd6 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -422,8 +422,8 @@ (defun git-rename-as-string (info)
(propertize
(concat " ("
(if (eq state 'copy) "copied from "
- (if (eq (git-fileinfo->state info) 'added) "renamed to "
- "renamed from "))
+ (if (eq (git-fileinfo->state info) 'added) "renamed from "
+ "renamed to "))
(git-escape-file-name (git-fileinfo->orig-name info))
")") 'face 'git-status-face)
"")))
--
1.4.2.3.g1723
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] vc-git.el: Switch to using git-blame instead of git-annotate.
From: Alexandre Julliard @ 2006-10-05 9:30 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/vc-git.el | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 4a8f790..4189c4c 100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -119,10 +119,10 @@ (defun vc-git-checkout (file &optional e
(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)))
+ (call-process "git" nil buf nil "blame" 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)
+ (and (re-search-forward "[0-9a-f]+ (.* \\([0-9]+\\)-\\([0-9]+\\)-\\([0-9]+\\) \\([0-9]+\\):\\([0-9]+\\):\\([0-9]+\\) \\([-+0-9]+\\) +[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))))))
--
1.4.2.3.g1723
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH] vc-git.el: Switch to using git-blame instead of git-annotate.
From: Junio C Hamano @ 2006-10-05 9:34 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87k63f9kjf.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
> ---
> contrib/emacs/vc-git.el | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
> index 4a8f790..4189c4c 100644
> --- a/contrib/emacs/vc-git.el
> +++ b/contrib/emacs/vc-git.el
> @@ -119,10 +119,10 @@ (defun vc-git-checkout (file &optional e
> (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)))
> + (call-process "git" nil buf nil "blame" name)))
"blame -c" is advertised to give the same format as "annotate",
so I think you would not need other hunk if you did.
> (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)
> + (and (re-search-forward "[0-9a-f]+ (.* \\([0-9]+\\)-\\([0-9]+\\)-\\([0-9]+\\) \\([0-9]+\\):\\([0-9]+\\):\\([0-9]+\\) \\([-+0-9]+\\) +[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 that I am preferring the annotate output format over blame's
native output format. I just wanted to know if the reason you
did not do -c was because you tried and "blame -c" was not
compatible as advertised (in which case we have one more thing
to fix).
^ permalink raw reply
* Re: [PATCH] vc-git.el: Switch to using git-blame instead of git-annotate.
From: Alexandre Julliard @ 2006-10-05 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pujf6mx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Not that I am preferring the annotate output format over blame's
> native output format. I just wanted to know if the reason you
> did not do -c was because you tried and "blame -c" was not
> compatible as advertised (in which case we have one more thing
> to fix).
As far as I can tell, "blame -c" works fine. I switched because I find
the default blame output nicer, it wastes less horizontal space and
the file contents are properly aligned.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* How to checkout a tag?
From: Jeff Garzik @ 2006-10-05 10:47 UTC (permalink / raw)
To: Git Mailing List
Sometimes I receive a kernel patch based off an older version of the
kernel, for example a 2.6.18 patch when the current kernel is 2.6.19-rc1.
I would like to create a branch starting at 2.6.18, merge the patch, and
then merge up to the current kernel.
How does one check out a tag, or create a branch based on a tag's
starting point?
Jeff
^ permalink raw reply
* Re: How to checkout a tag?
From: Andy Whitcroft @ 2006-10-05 11:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4524E2D5.3030907@garzik.org>
Jeff Garzik wrote:
>
> Sometimes I receive a kernel patch based off an older version of the
> kernel, for example a 2.6.18 patch when the current kernel is 2.6.19-rc1.
>
> I would like to create a branch starting at 2.6.18, merge the patch, and
> then merge up to the current kernel.
>
> How does one check out a tag, or create a branch based on a tag's
> starting point?
A tag is a ref like any other:
git checkout -b branchname tag
-apw
^ permalink raw reply
* Re: How to checkout a tag?
From: Jeff Garzik @ 2006-10-05 11:13 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Git Mailing List
In-Reply-To: <4524E72D.9030101@shadowen.org>
Andy Whitcroft wrote:
> Jeff Garzik wrote:
>> Sometimes I receive a kernel patch based off an older version of the
>> kernel, for example a 2.6.18 patch when the current kernel is 2.6.19-rc1.
>>
>> I would like to create a branch starting at 2.6.18, merge the patch, and
>> then merge up to the current kernel.
>>
>> How does one check out a tag, or create a branch based on a tag's
>> starting point?
>
> A tag is a ref like any other:
>
> git checkout -b branchname tag
Weird. No idea why that didn't work before, for me.
Thanks for the clue-hammer.
Jeff
^ permalink raw reply
* Re: How to checkout a tag?
From: Andy Whitcroft @ 2006-10-05 11:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <4524E8C2.3060404@garzik.org>
Jeff Garzik wrote:
> Andy Whitcroft wrote:
>> Jeff Garzik wrote:
>>> Sometimes I receive a kernel patch based off an older version of the
>>> kernel, for example a 2.6.18 patch when the current kernel is
>>> 2.6.19-rc1.
>>>
>>> I would like to create a branch starting at 2.6.18, merge the patch, and
>>> then merge up to the current kernel.
>>>
>>> How does one check out a tag, or create a branch based on a tag's
>>> starting point?
>>
>> A tag is a ref like any other:
>>
>> git checkout -b branchname tag
>
> Weird. No idea why that didn't work before, for me.
>
> Thanks for the clue-hammer.
I think I've been in a place where I git fetched a tag and I ended up
with the objects, but not with an actual local tag for it. Perhaps that
happened to you.
-apw
^ permalink raw reply
* Re: How to checkout a tag?
From: linux @ 2006-10-05 12:00 UTC (permalink / raw)
To: git; +Cc: linux
> A tag is a ref like any other:
>
> git checkout -b branchname tag
For some operations, "git pull" in particular, I need
to include a "tags/" prefix. E.g.
$ git fetch
remote: Generating pack...
remote: Done counting 27780 objects.
remote: Result has 22237 objects.
remote: Deltifying 22237 objects.
remote: 100% (22237/22237) done
Unpacking 22237 objects
remote: Total 22237, written 22237 (delta 18295), reused 17624 (delta 14183)
100% (22237/22237) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
from a77c64c1a641950626181b4857abb701d8f38ccc to d223a60106891bfe46febfacf46b20cd8509aaad
Auto-following refs/tags/v2.6.19-rc1
remote: Generating pack...
remote: Done counting 1 objects.
remote: Deltifying 1 objects.
remote: 100% (1/1) done
remote: Total 1, written 1 (delta 0), reused 1 (delta 0)
Unpacking 1 objects
100% (1/1) done
* refs/tags/v2.6.19-rc1: storing tag 'v2.6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
$ git pull . v2.6.19-rc1
error: no such remote ref refs/heads/v2.6.19-rc1
Fetch failure: .
$ git pull -n . tags/v2.6.19-rc1
Updating from e478bec0ba0a83a48a0f6982934b6de079e7e6b3 to d223a60106891bfe46febfacf46b20cd8509aaad
Checking files out...
Checking files out...
100% (6590/6590) done
Fast forward
^ permalink raw reply
* Re: [PATCH] pack-refs: use lockfile as everybody else does.
From: Linus Torvalds @ 2006-10-05 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodsrguej.fsf@assigned-by-dhcp.cox.net>
On Wed, 4 Oct 2006, Junio C Hamano wrote:
>
> How would one ensure the effect of rename(2) hits the disk
> platter before proceeding to do something else? We seem to do
> sync(1) in git-repack.sh for similar reasons, and I wonder if we
> should do a sync(2) there. I doubt it would be worth it though;
> the function can return before the actual writing is done.
sync() is supposed to wait until the data is on the disk, anything else is
likely to be a bad implementation (even if POSIX may not _guarantee_ it).
Also, most filesystems (for various reasons, not the least of which is
"speed of fsck") will journal metadata, but not file contents. Which means
that if a crash happens and one of the loose refs has already been
removed, then (thanks to journaling) that means that on most filesystems
the rename would already have been guaranteed to hit the disk - even
regardless of any sync().
So in practice, it's much more important to guarantee the file contents
(the fsync) part, because the OS already tends to guarantee metadata
ordering.
Linus
^ 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