* Re: [ANNOUCNE] GIT 1.1.0
From: Andreas Ericsson @ 2006-01-09 22:22 UTC (permalink / raw)
To: lamikr; +Cc: Junio C Hamano, git
In-Reply-To: <43C2CAED.8030304@cc.jyu.fi>
lamikr wrote:
>>- "git --version" from an interim snapshot gives a more
>> descriptive version name than "1.0-GIT" (Linus).
>>
>>
>
> I installed 1.1.0 today and it shows me
>
> $ git --version
> git version 1.0.GIT
>
You did not have git-describe installed prior to building 1.1.0. If you
re-install right on top the one you did today the version-file will be
generated correctly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: lamikr @ 2006-01-09 20:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q4eurgu.fsf@assigned-by-dhcp.cox.net>
> - "git --version" from an interim snapshot gives a more
> descriptive version name than "1.0-GIT" (Linus).
>
>
I installed 1.1.0 today and it shows me
$ git --version
git version 1.0.GIT
Mika
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Junio C Hamano @ 2006-01-09 20:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brown, Len, Luck, Tony, Martin Langhoff, David S. Miller,
linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601090835580.3169@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> One thing we could do is to make it easier to apply a patch to a
> _non_current_ branch.
>...
> And one way to do that might be to teach "git-apply" to apply patches to a
> non-active branch,...
>
> git diff | git-apply -b development
>
> or something similar..)
>
> Then you could always do "git pull . development" to pull in the
> development stuff into your working branch - keeping the development
> branch clean all the time.
I had to do something like that last night, when I hacked on
gitweb. gitweb as shipped does not work for anybody but kay
(e.g. it has /home/kay hardcoded in it). So I did:
$ git clone git://git.kernel.org/pub/scm/git/gitweb gitweb
$ cd gitweb
$ git checkout -b custom
$ edit gitweb.cgi ;# adjust /home/kay -> somewhere else etc.
$ git commit -a -m "customization for junio's home"
Then I started preparing a proposed fix for Kay:
$ git checkout -b symref master
$ edit gitweb.cgi
$ git commit -a -s -m "make it work on symref repository"
Now the thing is that I cannot test symref branch as is. I
deliberately omitted the change necessary to make the upstream
work on my local machine from that branch, because I want to
keep my home-machine customization separate from what I will
eventually feed Kay. So I do a throwaway test branch:
$ git checkout -b test master
$ git pull . custom symref ;# an octopus ;-)
# I could have done two separate pulls, custom then symref.
The interesting part starts here. Inevitably, I find bugs and
bugs and bugs in the test branch, and I fix them in the working
tree, without committing. Eventually things starts working.
I did not commit here in the test branch, because the symref
branch is where I intend to keep this set of changes. So
instead, I did this:
$ git diff HEAD >P.diff
$ git checkout -f symref
$ git reset --soft HEAD^
$ git apply P.diff
$ git commit -a -C ORIG_HEAD
Usually I strongly discourage people to use "checkout -f"
because it will leave files that are in the current branch but
not in the new branch behind in the working tree. Here I used
"checkout -f symref" because I knew this is a one-file project.
Instead of fixing the symref commit in place like this, I could
have committed P.diff as a separate "fixup" commit on top of the
symref branch, in which case the above sequence would have been:
$ git diff HEAD >P.diff
$ git checkout -f symref
$ git apply P.diff
$ git commit -a -m 'fixup bugs in the previous.'
but I did not --- it would have been more disgusting than
honest.
And after that, the usual format-patch:
$ git format-patch origin..symref
In either case, this *was* cumbersome. And I did it twice for
two independent topics. Admittedly, these topic branches were
both single-commit topics, and in real life your subsystem
maintainers must be facing bigger mess than this toy experience
of mine, but the principle is the same.
I think there are a couple of ways to improve what I had to do.
I'll think aloud here. The fictitious transcripts all start
after I got things working in the test branch working tree, with
a clean index file (i.e. changes are in the working tree only).
1. Make a commit in the "test" branch, and then cherry-pick the
commit back to the topic branch:
$ git commit -a -m "Fix symref fix"
$ git checkout symref
$ git cherry-pick -r test
2. Fix "git checkout <branch>" so that it does a reasonable thing
even when a dirty path is different in current HEAD and
destination branch. Then I could:
$ git checkout symref ;# this would not work in the current git
# it would die like this:
# $ git checkout symref
# fatal: Entry 'gitweb.cgi' not uptodate. Cannot merge.
$ git diff ;# just to make sure inevitable automated merge
# did the right thing
$ git commit -a -m "Fix symref fix"
# I could collapse them into one instead, like this:
# $ git reset --soft HEAD^
# $ git commit -a -C ORIG_HEAD
To retest (possibly with latest from Kay), we can rebuild the
test branch from scratch since it is by definition a throwaway
branch and never is exposed to public:
$ git fetch origin
$ git checkout test
$ git reset --head origin
$ git pull . custom symref
Obviously I prefer to have #2 work well, but #1 would work today.
I am not sure if making "git-apply" to take different branch is
a sane approach. It might make sense to teach git-applymbox and
git-am about branches, though. So is teaching git-merge about
merging into different branch.
^ permalink raw reply
* Re: [PATCH 2/3] ls-files --others --directory: give trailing slash
From: Darrin Thompson @ 2006-01-09 15:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy81racv7.fsf@assigned-by-dhcp.cox.net>
On Sat, 2006-01-07 at 14:31 -0800, Junio C Hamano wrote:
> * Likes, dislikes? This suits better for *my* purpose of
> calling this from git-status, but it might be undesirable for
> your Porcelain.
>
+1 likes.
--
Darrin
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Johannes Schindelin @ 2006-01-09 12:31 UTC (permalink / raw)
To: Martin Langhoff
Cc: Brown, Len, David S. Miller, torvalds, linux-acpi, linux-kernel,
akpm, git
In-Reply-To: <46a038f90601090211j33479764q13c74df60033a061@mail.gmail.com>
Hi,
On Mon, 9 Jan 2006, Martin Langhoff wrote:
> In a sense we are still exploring possible/desirable workflows and what
> the missing pieces are. And yes, some thing don't quite make sense from
> the outside, perhaps because they just don't or because we arent'
> explaining them very well.
Maybe what is needed here is this:
T1 - T2 .. Tn .. Tp
\ \ \
\ M1 M2
\ / /
B1 .. Bm .. Bo
where T1..Tp are the upstream commits, B1..Bo are the local commits, and
M1.. are the test merges just to make sure nothing breaks?
As long as the Mx commits resolve automatically, no need for an explicit
merge in the Bx commits, since a pull from B into T will just recreate an
Mx as next commit in T.
Kind of "throw away merge".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: allow working in repositories with textual symref HEAD
From: Kay Sievers @ 2006-01-09 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j99ssfy.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 09, 2006 at 12:42:41AM -0800, Junio C Hamano wrote:
> There is a change to git-core, proposed by Pavel and cooking for
> the last 6 weeks, to use textual symref to represent HEAD even
> on filesystems that support symbolic links. It would break
> gitweb without this even on UNIX.
Applied and installed on kernel.org.
Thanks,
Kay
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Martin Langhoff @ 2006-01-09 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Coywolf Qi Hunt, git
In-Reply-To: <7vbqylpty1.fsf@assigned-by-dhcp.cox.net>
On 1/9/06, Junio C Hamano <junkio@cox.net> wrote:
> > I think that was discussed already this year, so look in the
> > list archive for the past 10 days or so please before asking.
Like, yesterday ;-)
Anyway, I have to report that I'm now a happy backports.org user for
all the git-core packages on my production servers. And sid has your
git-core fix too, if you happen to be feeling unstable.
Many thanks to Gerrit and whoever's done the backports.org one.
martin
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-09 10:38 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: git
In-Reply-To: <7vr77hpwla.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Coywolf Qi Hunt <qiyong@fc-cn.com> writes:
>
>> Why not support debian? I see the debian directory is outdated.
>
> I think that was discussed already this year, so look in the
> list archive for the past 10 days or so please before asking.
Especially, please see this thread:
http://marc.theaimsgroup.com/?l=git&m=113576889301331
I haven't received any patches to re-add debian/ directory from
Gerrit since I removed it, and I do not expect nor wish to get
one. I respect Gerrit's request not to ship debian/ directory
myself.
If you want to see deb packages at kernel.org built by me, you
need to convince both Gerrit and me with a workable workflow
that does not add extra burden on us and avoids confusion.
A starting point might be for me to slave debian/ part from
Gerrit, updating debian/changelog with only X.Y.Z-0 entries by
me, and publish X.Y.Z-0 packages at kernel.org.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-09 10:11 UTC (permalink / raw)
To: Brown, Len
Cc: David S. Miller, torvalds-3NddpPZAyC0,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A136FE-N2PTB0HCzHKkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
On 1/9/06, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> I appologize for using the phrase "completely insane".
> The rebase proposal caught me somewhat off-guard and
> I was expressing surprise -- hopefully not taken as insult.
>
> Further, I thank you for your thoughful follow-up.
No worries... and no offence taken! In a sense we are still exploring
possible/desirable workflows and what the missing pieces are. And yes,
some thing don't quite make sense from the outside, perhaps because
they just don't or because we arent' explaining them very well.
In a sense, we do have a bit of a challenge explaining what how all
the parts fit together, even to bk old timers it seems.
> While I don't expect it to become a routine occurnece for me,
> I do see that rebase has utility in some situations.
As long as you've got enough tools to use a workflow that fits you,
it's all good.
cheers,
martin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-09 9:41 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: git
In-Reply-To: <20060109084930.GA560@localhost.localdomain>
Coywolf Qi Hunt <qiyong@fc-cn.com> writes:
> Why not support debian? I see the debian directory is outdated.
I think that was discussed already this year, so look in the
list archive for the past 10 days or so please before asking.
^ permalink raw reply
* Re: git-rename
From: Junio C Hamano @ 2006-01-09 9:37 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20060109.010625.15399855.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> I couldn't find it in my git installation, but found it ready
> to execute in the GIT sources :-)
I do not ship git-rename anymore. Doesn't your 'git status' say
it is "untracked"?
^ permalink raw reply
* gitweb sometimes shows branch heads sometimes doesn't
From: Junio C Hamano @ 2006-01-09 9:35 UTC (permalink / raw)
To: git
Has anybody wondered why some repositories at kernel.org have
yellowish (#ffffaa) <master> at the latest commit in the
shortlog on the summary page, and some do not have it at all
or have it at a wrong place, i.e. not at the top?
http://www.kernel.org/git/?p=git/git.git;a=summary
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
This is because gitweb looks at info/refs as a shortcut to find
out which commits branch heads and tags are pointing at, in
order to place these markers. The repositories that do not have
the marker at the right place in gitweb have this file out-of-date.
In fact, most of the repositories at kernel.org seem to either
not have info/refs at all, or have them out-of-date.
This file is updated when git-update-server-info is run on the
repository, along with another file objects/info/packs. It also
is used by dumb http transfer, so the corollary is that you may
have trouble fetching via http from any repository that does not
show the branch head marker at the latest commit in gitweb.
Attached is a patch to gitweb that I do _not_ really want Kay to
apply, because I think helping people to acquire a good habit to
help others is a good thing, and I would like to encourage
repository owners to do this, so update-server-info is run every
time the repository is pushed into:
mkdir -p hooks
cat >hooks/post-update <<\EOF
#!/bin/sh
exec git-update-server-info
EOF
chmod +x hooks/post-update
The first 5 lines are unneeded for people who initialized the
repository with recent git (later than v0.99.3-g8d5a on Aug 2nd,
2005), because they are likely to have the necessary file from
the templates.
HOWEVER.
If enough repository owners forget to do so, and I suspect some
of them deliberately forget to do so in order to discourage use
of dumb http transfers -- you know whom I mean ;-), at least
gitweb can be helped with this patch.
-- >8 --
[PATCH] Do not rely on info/refs
I personally consider this change is backwards, but many
repositories at kernel.org have obsolete info/refs (i.e. the
owners do not run git-update-server-info in them), so the
information kept there is unfortunately unreliable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitweb.cgi | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
f22fb181cb315bfa14261d81fcaba25154224384
diff --git a/gitweb.cgi b/gitweb.cgi
index 1814f7f..a97859e 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -914,7 +914,9 @@ sub read_info_ref {
my %refs;
# 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
# c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
- open my $fd, "$projectroot/$project/info/refs" or return;
+
+ open my $fd, "-|", "$gitbin/git", "ls-remote", "$projectroot/$project"
+ or return;
while (my $line = <$fd>) {
chomp($line);
if ($line =~ m/^([0-9a-fA-F]{40})\t.*$type\/([^\^]+)/) {
--
1.1.0
^ permalink raw reply related
* Re: git-rename
From: David S. Miller @ 2006-01-09 9:06 UTC (permalink / raw)
To: ae; +Cc: git
In-Reply-To: <43C21EA1.9020504@op5.se>
From: Andreas Ericsson <ae@op5.se>
Date: Mon, 09 Jan 2006 09:28:17 +0100
> It's obsoleted by git-mv. If you have git-rename at all you most likely
> have built the pu branch some time past and not done "make clean".
Someone who submitted a patch to me asked me to run a series
of git-rename invocations as part of installing the change.
I couldn't find it in my git installation, but found it ready
to execute in the GIT sources :-)
^ permalink raw reply
* Re: [ANNOUCNE] GIT 1.1.0
From: Coywolf Qi Hunt @ 2006-01-09 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v4q4eurgu.fsf@assigned-by-dhcp.cox.net>
On Sun, Jan 08, 2006 at 05:20:49PM -0800, Junio C Hamano wrote:
> The latest feature release GIT 1.1.0 is available at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.1.0.tar.{gz,bz2} (tarball)
> RPMS/$arch/git-*-1.1.0-1.$arch.rpm (RPM)
Why not support debian? I see the debian directory is outdated.
--
Coywolf Qi Hunt
^ permalink raw reply
* [PATCH] gitweb: allow working in repositories with textual symref HEAD
From: Junio C Hamano @ 2006-01-09 8:42 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <7vslrytcw7.fsf@assigned-by-dhcp.cox.net>
There is a change to git-core, proposed by Pavel and cooking for
the last 6 weeks, to use textual symref to represent HEAD even
on filesystems that support symbolic links. It would break
gitweb without this even on UNIX.
The current code is already broken on filesystems that do not
handle symbolic links. With this change, gitweb keeps working
with repositories whose HEADs are symbolic links.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Junio C Hamano <junkio@cox.net> writes:
> Waiting in the proposed updates branch are two backward
> incompatible changes.
> ...
> - Use textual symbolic refs to represent .git/HEAD everywhere,
> not just on filesystems without symbolic link supports. This
> was proposed by Pavel mid November 2005, but is known to
> break Porcelains that read(2) from .git/HEAD and expect to
> read an object name for the current branch head (use "git
> rev-parse --verify HEAD" instead), and write(2) into
> .git/HEAD and expect to update the current branch head (use
> "git update-ref HEAD $commit [$old]" instead). Last time I
> checked, gitweb would break with this change.
Here is a proposed fix. It was not clear to me what your
$ENV{'GIT_DIR'} policy was, so git_read_head tries to play
safer, but please feel free to drop that part if the rest of
the code is safe without them.
gitweb.cgi | 49 +++++++++++++++++++++++++++++++++----------------
1 files changed, 33 insertions(+), 16 deletions(-)
c903862d1c5d77fe5a1633eb7a40171d98a8dd73
diff --git a/gitweb.cgi b/gitweb.cgi
index 1814f7f..26c7395 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -396,6 +396,23 @@ sub git_get_type {
return $type;
}
+sub git_read_head {
+ my $project = shift;
+ my $oENV = $ENV{'GIT_DIR'};
+ my $retval = undef;
+ $ENV{'GIT_DIR'} = "$projectroot/$project";
+ if (open my $fd, "-|", "$gitbin/git-rev-parse", "--verify", "HEAD") {
+ my $head = <$fd>;
+ close $fd;
+ chomp $head;
+ if ($head =~ m/^[0-9a-fA-F]{40}$/) {
+ $retval = $head;
+ }
+ }
+ $ENV{'GIT_DIR'} = $oENV;
+ return $retval;
+}
+
sub git_read_hash {
my $path = shift;
@@ -823,7 +840,7 @@ sub git_project_list {
die_error(undef, "No project found.");
}
foreach my $pr (@list) {
- my $head = git_read_hash("$pr->{'path'}/HEAD");
+ my $head = git_read_head($pr->{'path'});
if (!defined $head) {
next;
}
@@ -994,7 +1011,7 @@ sub git_read_refs {
sub git_summary {
my $descr = git_read_description($project) || "none";
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
my %co = git_read_commit($head);
my %cd = date_str($co{'committer_epoch'}, $co{'committer_tz'});
@@ -1034,7 +1051,7 @@ sub git_summary {
"<tr><td>owner</td><td>$owner</td></tr>\n" .
"<tr><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n" .
"</table>\n";
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_hash("$project/HEAD") or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$gitbin/git-rev-list --max-count=17 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd;
print "<div>\n" .
@@ -1172,7 +1189,7 @@ sub git_summary {
}
sub git_tag {
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
git_header_html();
print "<div class=\"page_nav\">\n" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=summary")}, "summary") .
@@ -1211,7 +1228,7 @@ sub git_tag {
}
sub git_tags {
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
git_header_html();
print "<div class=\"page_nav\">\n" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=summary")}, "summary") .
@@ -1270,7 +1287,7 @@ sub git_tags {
}
sub git_heads {
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
git_header_html();
print "<div class=\"page_nav\">\n" .
$cgi->a({-href => "$my_uri?" . esc_param("p=$project;a=summary")}, "summary") .
@@ -1343,7 +1360,7 @@ sub git_get_hash_by_path {
sub git_blob {
if (!defined $hash && defined $file_name) {
- my $base = $hash_base || git_read_hash("$project/HEAD");
+ my $base = $hash_base || git_read_head($project);
$hash = git_get_hash_by_path($base, $file_name, "blob") || die_error(undef, "Error lookup file.");
}
open my $fd, "-|", "$gitbin/git-cat-file blob $hash" or die_error(undef, "Open failed.");
@@ -1407,13 +1424,13 @@ sub git_blob_plain {
sub git_tree {
if (!defined $hash) {
- $hash = git_read_hash("$project/HEAD");
+ $hash = git_read_head($project);
if (defined $file_name) {
- my $base = $hash_base || git_read_hash("$project/HEAD");
+ my $base = $hash_base || $hash;
$hash = git_get_hash_by_path($base, $file_name, "tree");
}
if (!defined $hash_base) {
- $hash_base = git_read_hash("$project/HEAD");
+ $hash_base = $hash;
}
}
$/ = "\0";
@@ -1497,7 +1514,7 @@ sub git_tree {
sub git_rss {
# http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
- open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_hash("$project/HEAD") or die_error(undef, "Open failed.");
+ open my $fd, "-|", "$gitbin/git-rev-list --max-count=150 " . git_read_head($project) or die_error(undef, "Open failed.");
my (@revlist) = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading rev-list failed.");
print $cgi->header(-type => 'text/xml', -charset => 'utf-8');
@@ -1566,7 +1583,7 @@ sub git_opml {
foreach my $pr (@list) {
my %proj = %$pr;
- my $head = git_read_hash("$proj{'path'}/HEAD");
+ my $head = git_read_head($proj{'path'});
if (!defined $head) {
next;
}
@@ -1587,7 +1604,7 @@ sub git_opml {
}
sub git_log {
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
if (!defined $hash) {
$hash = $head;
}
@@ -2083,7 +2100,7 @@ sub git_commitdiff_plain {
sub git_history {
if (!defined $hash) {
- $hash = git_read_hash("$project/HEAD");
+ $hash = git_read_head($project);
}
my %co = git_read_commit($hash);
if (!%co) {
@@ -2159,7 +2176,7 @@ sub git_search {
die_error("", "Text field empty.");
}
if (!defined $hash) {
- $hash = git_read_hash("$project/HEAD");
+ $hash = git_read_head($project);
}
my %co = git_read_commit($hash);
if (!%co) {
@@ -2300,7 +2317,7 @@ sub git_search {
}
sub git_shortlog {
- my $head = git_read_hash("$project/HEAD");
+ my $head = git_read_head($project);
if (!defined $hash) {
$hash = $head;
}
--
1.1.0
^ permalink raw reply related
* Re: git-rename
From: Andreas Ericsson @ 2006-01-09 8:28 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20060108.222045.21927554.davem@davemloft.net>
David S. Miller wrote:
> Any particular reason why that little tool doesn't get installed by
> "make install"? Is it deprecated?
>
It's obsoleted by git-mv. If you have git-rename at all you most likely
have built the pu branch some time past and not done "make clean".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-09 8:05 UTC (permalink / raw)
To: Luck, Tony, Linus Torvalds
Cc: Junio C Hamano, Martin Langhoff, David S. Miller, linux-acpi,
linux-kernel, akpm, git
Linus,
I think Tony has articulated the work-flow problem that
originally started this thread, as well as the fix.
>I'll try to update the using-topic-branches document to capture this.
>Some of the problem is that it doesn't quite capture what I'm doing
>with my test/release branches.
>
>My release branch really is just used as a transfer point to Linus.
>I usually[1] don't leave patches sitting in "release" for long enough
>that I'll be tempted to merge in from Linus ... once I decide that
>some patches are ready to go to Linus I'll update "release" from Linus
>(which will be a fast-forward, so no history) merge in the topic
>branches, do one final sanity build, push to kernel.org and send
>the "please pull" e-mail.
>
>The huge majority of my "automatic update from upstream" merges
>go into my test branch ... which never becomes part of the real
>history as I never ask Linus to pull from it.
>
>-Tony
>
>[1] Sometimes I goof on this because I forget that I've applied
>a trivial patch directly to the release branch without going through
>a topic branch. I think I'll fix my update script to check
>for this case.
I figured that checking some trivial patches directly into "release"
would be a convenient way to make sure I didn't forget to push them --
as they didn't depend on anything else in my tree. Okay.
To make sure that my test branch (where I generate my consolidated
plain patch, and what Andrew pulls) includes everything, I then pull
"release" into "test". Still good.
But then I decide I need to update my test tree from upstream.
I did this by pulling "linus" into "release", and then pulling
"release" into "test". This creates the book-keeping merge
in "release" that irritates gitk users.
This "flow", BTW, is a habit I picked up from the
"two-phase release strategy" that we used in bk days.
There I'd pull from upstream down into my to-linus tree and then pull
from the to-linus tree into the to-andrew tree.
I expect BK also created a merge cset, but apparently
nobody was looking at the history like they do with gitk today.
So if I simply don't pull from "linus" into a modified
"release" branch then the cluttered history issue goes away.
I should fetch "linus" into "release" right before I merge
the topic branches into "release" and push upstream.
The fetch is a clean fast-forward, and the merges all have
real content.
This will work as long as "release" doesn't get too old
to be pulled upstream without conflicts. Based on past
experience with low latency pulls upstream, I think this will be rare.
Andrew will still get cluttered history in the test tree,
but as he's focused on the content and not the (throw-away) history,
this is surely a non-issue.
So problem #1 is solved, yes?
Going forward...
I'm hopeful that gitk users will not be irritated also
by the liberal use of topic branches. I'm starting to like using
them quite a bit. Yes, it is true that I could cherry-pick
the topics out of their original context to re-manufacture linear
history. But that is extra work. Also, as you poined out,
there is real value in the real history because the context is accurate.
Further, I find that sometimes I need to augment a topic branch
with a follow-up patch. I can checkout the topic branch an plop
the follow-up right on the tip where it logically should live,
and (Tony's) scripts will remind me when the branch is not fully
pulled into test or release -- so it will never get misplaced.
In the case where a topic branch is a single commit, gitk users
will see both the original commit, as well as the merge commit
back into "release".
-Len
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-09 7:34 UTC (permalink / raw)
To: Martin Langhoff
Cc: David S. Miller, torvalds-3NddpPZAyC0,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
Martin,
I appologize for using the phrase "completely insane".
The rebase proposal caught me somewhat off-guard and
I was expressing surprise -- hopefully not taken as insult.
Further, I thank you for your thoughful follow-up.
While I don't expect it to become a routine occurnece for me,
I do see that rebase has utility in some situations.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Junio C Hamano @ 2006-01-09 6:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601082212420.3169@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> To be fair, backtracking a "git-rebase" isn't obvious. One of the
> downsides of rebasing.
I thought "git reset --hard ORIG_HEAD" as usual would do.
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-09 6:27 UTC (permalink / raw)
To: David S. Miller, torvalds-3NddpPZAyC0
Cc: martin.langhoff-Re5JQEeQqe8AvxtiuMwx3w,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
>From: David S. Miller
>I think merges with conflicts that need to get resolved by hand create
>a lot of noise and useless information and therefore to me they are
>pointless. But this is just my opinion. It simply works easier to me
>to shuffle the patches in by hand and deal with the rejects one by
>one. It's very much akin to how Andrew's -mm tree works.
I guess in this model you can do all your development with quilt,
and the value of git is a high-bandwidth bransport medium to
replace e-mail.
>I think a clean history is worth an extra few minutes of someone's
>time. And note that subsystem development is largely linear anyways.
Maybe true in your neck of the woods, but not true here.
I have more than a dozen topic branches in my tree, and they mature
at different rates.
When a topic branch is in the test tree and and a follow-up patch
is needed, I check out that topic branch and put the patch
exactly in non-linear 3D history where it is meant to live.
When the topic seems fully baked, I can pull the top of the
branch into the release tree.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-rename
From: David S. Miller @ 2006-01-09 6:20 UTC (permalink / raw)
To: git
Any particular reason why that little tool doesn't get installed by
"make install"? Is it deprecated?
Thanks.
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-09 6:13 UTC (permalink / raw)
To: Linus Torvalds, Martin Langhoff
Cc: David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
>Which just means that a commit that was tested and found to be working
>might suddenly not work any more, which can be very surprising ("But I
>didn't change anything!").
This is why I try to follow the top of tree as closely as possible.
While parts of ACPI are well contained, other parts get stomped on constantly.
My two updates in 10 hours were not becaudse of what I did,
it was in response to seeing the flood gates in 2.6.16 open.
Also, it isn't accurate that nothing changed at my end.
I put some trivial patches into my release branch,
udpated the release branch with upstream,
and then pulled the release branch into my test branch
where there are other patches you haven't seen yet.
I pushed the release branch just to 'clear the deck' of
the trivial patches there since there was no reason to delay
them behind all the stuff still on the test branch.
>So trying out git-rebase and git-cherry-pick just in case you
>decide to want to use them might be worthwhile. Making it part of your
>daily routine like David has done? Somewhat questionable, but hey,
>it seems to be working for David, and it does make some things much easier, so..
In the past I have use git-cherry-pick to recover from when a "good" patch
was checked in on top of a "bad" patch, and I wanted to push
the good without the bad.
But the linearization model will not work for me in general.
Branches enable parallel lines of development in git. If that
is thrown out, then we're basically back at quilt.
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-09 6:13 UTC (permalink / raw)
To: Martin Langhoff
Cc: Brown, Len, David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <46a038f90601082208i95cd19fmda542da0da8cc9ef@mail.gmail.com>
On Mon, 9 Jan 2006, Martin Langhoff wrote:
>
> and if it does anything but a very trivial merge, backtrack and do a merge.
To be fair, backtracking a "git-rebase" isn't obvious. One of the
downsides of rebasing.
Linus
^ permalink raw reply
* Re: git-format-patch Date header
From: Linus Torvalds @ 2006-01-09 6:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Timo Hirvonen, git
In-Reply-To: <43C12DE9.8010906@op5.se>
On Sun, 8 Jan 2006, Andreas Ericsson wrote:
>
> Actually, that's what's printed in the commit message, so any change
> would have to be put there and that would break backwards compatibility
> for new tools that might want to use it.
No, git should always take the date in any of a million different formats,
and always turn it into "seconds + timezone" internally.
The fact that git-format-patch also prints it out in the internal format
is unambiguous (nice) but human-unreadable (bad).
There are other unambiguous formats it could use, notably standard rfc2822
format ("date -R").
The git "show_date()" function hopefully does exactly that rfc2822 format,
but you'd have to make a helper program to do the conversion in
git-format-patch.sh.
Linus
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-09 6:08 UTC (permalink / raw)
To: Brown, Len; +Cc: David S. Miller, torvalds, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com>
On 1/9/06, Brown, Len <len.brown@intel.com> wrote:
> This is completely insane.
> Do you have any idea what "sometimes has problems merging" means
> in practice? It means the tools are really nifty in the trivial
> case but worse than worthless when you need them the most.
Len,
all I meant was that you will sometimes see conflicts. And in that
case, you are far better off cancelling the rebase and doing a merge,
where you will have to resolve the conflicts by hand.
git-rebase is for when the potential merge is clearly trivial. In any
other case, you do want a proper merge. But in any case, it is easy to
do
git-fetch <upstream> && git-rebase <upstream>
and if it does anything but a very trivial merge, backtrack and do a merge.
In any case, if I have any suspicion that the merge may not be trivial, I do
git-fetch <upstream> && gitk --since=" 1 month ago" upstream master
before deciding on a course of action. Of course, you can merge all
the time. It's whether people care about a readable/useful history
afterwards.
cheers,
martin
^ 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