* Re: [PATCH] Add SubmittingPatches
From: Junio C Hamano @ 2005-08-16 0:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508160147560.26580@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> BTW, I don't know how many people still use pine, but for those poor souls
> it may be good to mention that the quell-flowed-text is needed for recent
> versions.
Contributions from pine users are very much appreciated. Among
the patches I either receive or pick up from the list, 15-20%
have WS corruption one way or another, which is starting to
annoy me. What annoys me more are MIME quoted printable,
though, but that is partly my fault.
I haven't counted what percentage of those WS corrupted ones are
from Pine, so please do not take the above 15-20% number to have
anything to do with Pine.
^ permalink raw reply
* [PATCH] Make git-format-patch's signoff option more consistent
From: Johannes Schindelin @ 2005-08-16 0:20 UTC (permalink / raw)
To: Junio C Hamano, git
Since git-commit-script has a "--signoff" option, use that in
git-format-patch-script, too (and since partial option names are
supported,"--sign" is still valid).
Also, if the message already contains the S-O-B line, silently ignore the
"--signoff" request.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-format-patch-script | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
36d8f8116e677848da231e3d33da379bd4546505
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -6,7 +6,7 @@
. git-sh-setup-script || die "Not a git archive."
usage () {
- echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--sign] [-<diff options>...] upstream [ our-head ]
+ echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--signoff] [-<diff options>...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -46,7 +46,7 @@ do
date=t author=t mbox=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
- -s|--s|--si|--sig|--sign)
+ -s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
--output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\
@@ -179,9 +179,12 @@ Date: '"$ad"
test "$signoff" = "t" && {
offsigner=`git-var GIT_COMMITTER_IDENT | sed -e 's/>.*/>/'`
- echo
- echo "Signed-off-by: $offsigner"
- echo
+ line="Signed-off-by: $offsigner"
+ grep -q "^$line\$" $commsg || {
+ echo
+ echo "$line"
+ echo
+ }
}
echo '---'
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Junio C Hamano @ 2005-08-16 0:18 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050815162519.GB9719@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> Somewhere in the thread something was mentioned about maintaining
> <local branch>:<remote branch> pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
> branch of a different name.
If you are referring to what I said about the user having some
control over both ends hence it should be possible to arrange to
use the same name on both ends to reduce mental burden, Pasky
and others convinced me otherwise during later discussions, and
the current core knows how to do renaming pushes.
One proposal which has not been pursued yet, due to lack of time
on my end if anything else, is to have a set of files that is an
extension of current $GIT_DIR/branches/* file (which can record
the URL and optionally one filename under refs/heads/ over there
to mean "which branch to pull from by default"). Instead, the
proposal introduces $GIT_DIR/remotes/* files, whose contents
would look like this:
$ cat .git/remotes/ko
URL: master.kernel.org:/pub/scm/git/git.git/
Push: master pu rc
Pull: master:ko-master pu:ko-pu rc:ko-rc
The expected workflow with the above example "remotes" file is
for me to be able to do this:
(1) fetch from master.kernel.org (that is the source of the
mirroring for everybody to see on {www,rsync}.kernel.org)
before starting my day. The current "git fetch" does not
do this, but make it:
$ git fetch ko
to mean "fetch from those three branches on the 'Pull:'
line, fast-forward local ko-master, ko-pu and ko-rc with
these heads".
Then I can see where my private heads and publicly visibile
ones stand to make sure things are in good order. E.g. I
can do "git show-branches ko ko-master rc rc-master".
(2) after doing work in my private repository, push to
master.kernel.org with:
$ git push ko
This does not happen to involve renaming push, because both
ends are owned and controlled by me, but you could put
renaming refspec on "Push:" line in the .git/remotes line
to make it rename.
Note that I am _not_ expecting for "git push/pull/fetch"
commands to dynamically update .git/remotes/ file whenever it
gets a new set of heads and renaming refspecs on the command
line. Explicit refspecs on the command line will just override
what is recorded in .git/remotes/* files instead. So:
$ git push ko pu:refs/heads/testing
would not push usual "master pu rc" but create a new "testing"
branch there, starting at the commit which is the head commit of
the local "pu" branch. This is a one-shot override, so next
time around, "git push ko" will do the usual three heads that is
recorded in the .git/remotes/ko file.
^ permalink raw reply
* Re: [PATCH] Add --signoff and --verify option to git commit.
From: Junio C Hamano @ 2005-08-16 0:13 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508152321.17075.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> These verification scripts should be used per default, and git-commit should
> have an option to force bypassing verification.
I agree that it would be a good place to do a hook. Also it may
not be a bad idea, if you volunteer to come up with a patch, to
look at an earlier thread that talks about commit message
templates and think about how these things should mesh together.
Bypassing can already be done by not giving '-v', so I do not
think you need to make things more complicated than necessary.
You can first try with a '-v', examine what it complains about,
fix only what are applicable to your change, try with '-v' again
to make sure the only complaints are from false positives, and
then you commit without '-v', bypassing the check.
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Junio C Hamano @ 2005-08-16 0:12 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f9050815042036616b08@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> So this patch is obsolete too.
I take it to mean that it should be dropped and replaced with
the one you sent today with -kk change.
However, the -kk change one is a corrupted patch and does not
apply. Your MUA ate leading whitespaces, perhaps.
I have already slurped in other two patches to cvsimport in the
proposed updates branch, so could you kindly proofread them (I
am no expert on cvs networking protocol issues) and rebase the
-kk patch, and send it without whitespace corruption this time
around please?
-jc
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-08-15 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git
In-Reply-To: <7vacjmqnu7.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 13 Aug 2005, Junio C Hamano wrote:
> Johannes posted a script on the list a couple of days ago, which
> should work well, except that it was written before the
> git-fetch-pack command was updated to natively download from
> multiple refs, so it does not know how to fetch multiple refs at
> a one go.
Actually, my script usually only calls fetch once. It checks if the commit
object is already local before trying to fetch it, and it turns out that a
single fetch is often (always?) sufficient to slurp the other commits,
too. I did not have time to find out if that is a true bug in git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add SubmittingPatches
From: Johannes Schindelin @ 2005-08-15 23:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslxep5jq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 13 Aug 2005, Junio C Hamano wrote:
> +Note that your maintainer does not subscribe to the git mailing
> +list (he reads it via mail-to-news gateway).
Wow. I didn't even read a newsgroup in decades...
BTW, I don't know how many people still use pine, but for those poor souls
it may be good to mention that the quell-flowed-text is needed for recent
versions.
Ciao,
Dscho
^ permalink raw reply
* Screwed up AUTHOR field for two commits.
From: Junio C Hamano @ 2005-08-15 23:07 UTC (permalink / raw)
To: Amos Waterland, Ryan Anderson; +Cc: git
The topmost couple of commits in the "master" branch made from
your patches are incorrectly attributed to me.
What happened was that I stumbled upon a merge conflict during
git-rebase, and ended up hand committing these two without
carrying the authorship information forward from the original
commits. This usually does not happen because I always use JIT
tools for rebasing, but this time I was trying to stay within
the set of core GIT barebone Porcelain.
I apologize for the screwup.
^ permalink raw reply
* Re: git reveals a bug in (some versions) BSD diff
From: Johannes Schindelin @ 2005-08-15 23:02 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0508130335300.2136-100000@bellevue.puremagic.com>
Hi,
On Sat, 13 Aug 2005, Brad Roberts wrote:
> I'm seeing this on a standard os/x 10.3.9 install which seems to have an
> old, but still GNU based, diff.
>
> $ which diff
> /usr/bin/diff
>
> $ diff --version
> diff - GNU diffutils version 2.7
That is exactly the same as with 10.2.8.
> [...]
> * FAIL 9: apply diff between 2 and 3
> git-apply <diff.2-3 && diff frotz.3 frotz
> * FAIL 12: apply diff between 3 and 2
> git-apply <diff.3-2 && diff frotz.2 frotz
Yes, that is what I saw, too. Actually, I found the bug in diff-v2.7
annoying enough that I updated (just diff) to version 2.8.1. That works
fine.
Ciao,
Dscho
^ permalink raw reply
* Re: Some tutorial text
From: Junio C Hamano @ 2005-08-15 23:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508160043140.25894@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Here's something that I've been putting together on how I'm using
>> GIT as a Linux subsystem maintainer.
>
> This is perfect material for the newly introduced howto/ directory! How
> about Documentation/howto/how-tony-luck-does-it.txt :-)
I already have done that pushed it out. Tony is clearly a
winner with this one.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Johannes Schindelin @ 2005-08-15 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, Wolfgang Denk, GIT
In-Reply-To: <Pine.LNX.4.58.0508151535130.3553@g5.osdl.org>
Hi,
On Mon, 15 Aug 2005, Linus Torvalds wrote:
> I was seriously considering just breaking the "remote cvs" support
> entirely (you can always just use cvsup or something to download it to
> make it local), and just taking the RCS parsing code from GNU rcs/cvs and
> making a C language CVS importer. That would speed things up by an order
> of magnitude or more, as far as I can tell.
That may be true for many "cvs import" tasks, but not _at all_ for "cvs
update" tasks. I, for one, keep track of _lots_ of CVS projects via
git-cvsimport. I would hate it if I could no longer do that.
Ciao,
Dscho
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Johannes Schindelin @ 2005-08-15 22:49 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050815162519.GB9719@hpsvcnb.fc.hp.com>
Hi,
On Mon, 15 Aug 2005, Carl Baldwin wrote:
> Somewhere in the thread something was mentioned about maintaining
> <local branch>:<remote branch> pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
> branch of a different name.
I think the loudest voice was mine :-)
Actually, I was not against *keeping* the information, but against
*pulling* in such strange ways. If "cross-pulling" is allowed, I am all
for keeping track of that.
In the meantime, I did not think about the issue at all :-) However, as is
often the case in an open discussion, I think I was wrong after all. There
may be cases you want that, and in the end, nobody forces me to use that
feature.
Anyway, Junio decided to enhance the fetch mechanism to support the
cross-pulling (and also multi-pulling).
Ciao,
Dscho
^ permalink raw reply
* Re: Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
From: Johannes Schindelin @ 2005-08-15 22:44 UTC (permalink / raw)
To: tony.luck; +Cc: Linus Torvalds, Martin Langhoff, GIT
In-Reply-To: <200508151917.j7FJHfFv009367@agluck-lia64.sc.intel.com>
Hi,
On Mon, 15 Aug 2005, tony.luck@intel.com wrote:
> Linus Torvalds wrote:
> > I'll happily help anybody who wants to try to write some nice
> > documentation (answer questions etc), but I'm just not very good at doing
> > it myself.
>
> Here's something that I've been putting together on how I'm using
> GIT as a Linux subsystem maintainer.
This is perfect material for the newly introduced howto/ directory! How
about Documentation/howto/how-tony-luck-does-it.txt :-)
Ciao,
Dscho
^ permalink raw reply
* Re: gitweb - option to disable rename detection
From: Linus Torvalds @ 2005-08-15 22:43 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87br3zorjk.wl@mail2.atmark-techno.com>
On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
>
> > Instead of disabling it entirely, how about just having some limit on it?
>
> ah, that's a good idea. here is a quick and dirty patch.
This makes it somewhat more expensive - I was thinking about disabling it
in git-diff-tree, since the rename logic already knows how many
new/deleted files there are.
Linus
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Linus Torvalds @ 2005-08-15 22:37 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Wolfgang Denk, GIT
In-Reply-To: <46a038f90508151309269ffc04@mail.gmail.com>
On Tue, 16 Aug 2005, Martin Langhoff wrote:
>
> If I find the time, I'll add some sort of pattern-match parameters to
> be tried against the commitmsg to extract likely head/branch names
> where we are merging from. My problem right now is that the only cvs
> repo with interesting branches and merges I have is huge, and takes an
> hour to import. That puts a damper on things, unfortunately.
I was seriously considering just breaking the "remote cvs" support
entirely (you can always just use cvsup or something to download it to
make it local), and just taking the RCS parsing code from GNU rcs/cvs and
making a C language CVS importer. That would speed things up by an order
of magnitude or more, as far as I can tell.
Linus
^ permalink raw reply
* Re: Cloning speed comparison
From: Daniel Barkalow @ 2005-08-15 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacjjx70u.fsf@assigned-by-dhcp.cox.net>
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I should be able to get http-pull down to the neighborhood of
> > (current) ssh-pull; http-pull is that slow (when the source repository
> > isn't packed) because it's entirely sequential, rather than overlapping
> > requests like ssh-pull now does.
>
> I like those prefetch() and process() code in pull.c very much.
>
> I have been wondering if increasing parallelism more by
> prefetching beyond the immediate parents of the current commit,
> in "if (get_history)" part of process_commit(). Maybe it is not
> worth it because doing a commit, its associated tree(s) and its
> parents would already give us enough parallelism already.
It is actually already maxing out the parallelism; it has a FIFO of
objects which it needs, and calls prefetch() when it enqueues an object
and fetch() when it dequeues it. It only cares about the dependancies for
this purpose, not the types.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add --signoff and --verify option to git commit.
From: Josef Weidendorfer @ 2005-08-15 21:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmrmp5kw.fsf@assigned-by-dhcp.cox.net>
On Saturday 13 August 2005 11:08, Junio C Hamano wrote:
> Also add --verify to make sure the lines you introduced are
> clean, which is more useful in commit but not very much in
> format-patch as it was originally implemented, because finding
> botches at format-patch time is too late.
I think that verification of/commenting on commits at/before commit time is a
perfect place for another hook script (or collection of verification
scripts).
People probably want to check a new commit on identation/coding style on a
per-project manner. The hook also should be able to give warnings/hints by
adding text to the commit message (e.g. "please do not use 'fgetc'" /
"doublecheck quoting in system()", ...) without rejecting the commit as a
whole. It could even be allowed to edit the code before commit.
These verification scripts should be used per default, and git-commit should
have an option to force bypassing verification.
If I get some time, I can come up with a patch.
Josef
^ permalink raw reply
* Mergeback patch - (was: Switching heads and head vs branch after CVS import)
From: Martin Langhoff @ 2005-08-15 20:50 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050815204511.B6D793300AD@ng.eduforge.org>
Just a work-in-progress sample. I've done a pretty successful import
of a small tree with this patch. It is showing the merges /almost/ in
the right place. The almost is due to bad cvs practices, and not this
code.
Definitely doable, though it'll never be "nice" -- CVS doesn't have
the right data for this. I want to make the regexes configurable, and
have a more decent way of extracting the parent sha. B
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -542,6 +542,24 @@ my $commit = sub {
my @par = ();
@par = ("-p",$parent) if $parent;
+
+ # detect additional branches
+ my @rx = ( qr/Merged from (\w+)/i , qr/merge of (\w+)/i );
+ foreach my $rx (@rx) {
+ if ($logmsg =~ $rx) {
+ my $parent = $1;
+ if ($parent eq 'HEAD') { $parent = 'origin'};
+ if ( -e "$git_dir/refs/heads/$parent") {
+ warn "grabbing $parent";
+ $parent = `cat $git_dir/refs/heads/$parent`;
+ chomp $parent;
+ warn "grabbed $parent";
+ push @par, '-p', $parent;
+ }
+ }
+ }
+ # %seen_branches
+
exec("env",
"GIT_AUTHOR_NAME=$author",
"GIT_AUTHOR_EMAIL=$author",
^ permalink raw reply
* Re: gitweb - option to disable rename detection
From: Yasushi SHOJI @ 2005-08-15 20:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508151140050.3553@g5.osdl.org>
At Mon, 15 Aug 2005 11:53:20 -0700 (PDT),
Linus Torvalds wrote:
>
> On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
> >
> > It seems to me that git-diff-tree needs huge memory if you try to diff
> > on big change with rename detection enabled.
> >
> > This isn't problem for sane project but if you create a repo with only
> > major releases imports, git-diff-tree run by git_commit() eats system
> > memory and die ;P
>
> Instead of disabling it entirely, how about just having some limit on it?
ah, that's a good idea. here is a quick and dirty patch.
--
yashi
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -40,6 +40,9 @@ my $home_text = "indextext.html";
#my $projects_list = $projectroot;
my $projects_list = "index/index.aux";
+# max number of changes to use rename detection on git-diff-tree
+my $rename_detection_threshold = 1000;
+
# input validation and dispatch
my $action = $cgi->param('a');
if (defined $action) {
@@ -1587,7 +1590,18 @@ sub git_commit {
$root = " --root";
$parent = "";
}
- open my $fd, "-|", "$gitbin/git-diff-tree -r -M $root $parent $hash" or die_error(undef, "Open failed.");
+ my $nr_files;
+ my $opts = "";
+ my $disabled_notice;
+ open my $fd, "-|", "$gitbin/git-diff-tree -r $root $parent $hash" or die_error(undef, "Open failed.");
+ $nr_files++ while <$fd>;
+ close $fd or die_error(undef, "Counting diff-tree failed.");
+ if ($nr_files < $rename_detection_threshold) {
+ $opts .= " -M";
+ } else {
+ $disabled_notice = "(Rename detection disabled)";
+ }
+ open my $fd, "-|", "$gitbin/git-diff-tree -r $opts $root $parent $hash" or die_error(undef, "Open failed.");
@difftree = map { chomp; $_ } <$fd>;
close $fd or die_error(undef, "Reading diff-tree failed.");
git_header_html();
@@ -1671,7 +1685,7 @@ sub git_commit {
print "</div>\n";
print "<div class=\"list_head\">\n";
if ($#difftree > 10) {
- print(($#difftree + 1) . " files changed:\n");
+ print(($#difftree + 1) . " files changed" . $disabled_notice . ":\n");
}
print "</div>\n";
print "<table cellspacing=\"0\">\n";
^ permalink raw reply
* [PATCH] Add git-branches-script
From: Amos Waterland @ 2005-08-15 20:44 UTC (permalink / raw)
To: junkio; +Cc: git
For people whose workflow involves switching back and forth between a
lot of branches, it can be really helpful to be able to quickly tell
which branch you are on and which ones are available. This patch
introduces a small script that when invoked as `git branches' prints a
list of available branches with a star in front of the one you are on:
$ cd linux-2.6/
$ git checkout -b ppc64-cleanups
$ git checkout -b ppc64-new-devel
$ git checkout -b ppc64-all-merge
$ git branches
master
* ppc64-all-merge
ppc64-cleanups
ppc64-new-devel
Signed-off-by: Amos Waterland <apw@rossby.metr.ou.edu>
---
git-branches-script | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
create mode 100755 git-branches-script
12ab86f36137c4ffd1fb9b878479b9befe4cf2d4
diff --git a/git-branches-script b/git-branches-script
new file mode 100755
--- /dev/null
+++ b/git-branches-script
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+. git-sh-setup-script || die "Not a git archive"
+
+current=$(basename $(readlink $GIT_DIR/HEAD))
+
+cd $GIT_DIR/refs/heads &&
+ls | sed -e "s/^/ /" -e "s/ $current/* $current/"
^ permalink raw reply
* Re: Cloning speed comparison
From: Junio C Hamano @ 2005-08-15 20:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508151321270.12816@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I should be able to get http-pull down to the neighborhood of
> (current) ssh-pull; http-pull is that slow (when the source repository
> isn't packed) because it's entirely sequential, rather than overlapping
> requests like ssh-pull now does.
I like those prefetch() and process() code in pull.c very much.
I have been wondering if increasing parallelism more by
prefetching beyond the immediate parents of the current commit,
in "if (get_history)" part of process_commit(). Maybe it is not
worth it because doing a commit, its associated tree(s) and its
parents would already give us enough parallelism already.
> (I've written an untested patch for local-pull, which I'll be testing,
> cleaning, and submitting tonight, assuming my newly-arrived monitor
> actually works)
That is a great news. Thank you for doing this; looking forward
to see it, but no rush. Enjoy your new monitor.
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Wolfgang Denk @ 2005-08-15 20:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, GIT
In-Reply-To: <46a038f90508151309269ffc04@mail.gmail.com>
In message <46a038f90508151309269ffc04@mail.gmail.com> you wrote:
>
> If I find the time, I'll add some sort of pattern-match parameters to
> be tried against the commitmsg to extract likely head/branch names
> where we are merging from. My problem right now is that the only cvs
> repo with interesting branches and merges I have is huge, and takes an
> hour to import. That puts a damper on things, unfortunately.
In a first step, and to try things out, it might be sufficient if one
could feed in this information manually, like by providing a list of
PatchSet ID's which are known to be merges ?
At least in my case where the number of branches and merges is small
this would be completely satisfactory.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* Re: Switching heads and head vs branch after CVS import
From: Martin Langhoff @ 2005-08-15 20:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Wolfgang Denk, GIT
In-Reply-To: <Pine.LNX.4.58.0508150930020.3553@g5.osdl.org>
On 8/16/05, Linus Torvalds <torvalds@osdl.org> wrote:
> The good news is that if you guess wrong, and you claim a merge where none
> exists, it doesn't really do any real damage.
I had figured out what part of the code I wanted to hack, but was
concerned that marking things that were merges in cvs-speak but not in
git-speak would leave me with broken import and problems going
forward.
If I find the time, I'll add some sort of pattern-match parameters to
be tried against the commitmsg to extract likely head/branch names
where we are merging from. My problem right now is that the only cvs
repo with interesting branches and merges I have is huge, and takes an
hour to import. That puts a damper on things, unfortunately.
cheers,
martin
^ permalink raw reply
* Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
From: tony.luck @ 2005-08-15 19:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, GIT
In-Reply-To: <Pine.LNX.4.58.0508131625010.3553@g5.osdl.org>
Linus Torvalds wrote:
> I'll happily help anybody who wants to try to write some nice
> documentation (answer questions etc), but I'm just not very good at doing
> it myself.
Here's something that I've been putting together on how I'm using
GIT as a Linux subsystem maintainer.
I suspect that I'm a bit slap-happy with the "git checkout" commands in
the examples below, and perhaps missing some of the _true-git_ ways of
doing things.
-Tony
Linux subsystem maintenance using GIT
-------------------------------------
My requirements here are to be able to create two public trees:
1) A "test" tree into which patches are initially placed so that they
can get some exposure when integrated with other ongoing development.
This tree is available to Andrew for pulling into -mm whenever he wants.
2) A "release" tree into which tested patches are moved for final
sanity checking, and as a vehicle to send them upstream to Linus
(by sending him a "please pull" request.)
Note that the period of time that each patch spends in the "test" tree
is dependent on the complexity of the change. Since GIT does not support
cherry picking, it is not practical to simply apply all patches to the
test tree and then pull to the release tree as that would leave trivial
patches blocked in the test tree waiting for complex changes to accumulate
enough test time to graduate.
Back in the BitKeeper days I achieved this my creating small forests of
temporary trees, one tree for each logical grouping of patches, and then
pulling changes from these trees first to the test tree, and then to the
release tree. At first I replicated this in GIT, but then I realised
that I could so this far more efficiently using branches inside a single
GIT repository.
So here is the step-by-step guide how this all works for me.
First create your work tree by cloning Linus's public tree:
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
Change directory into the cloned tree you just created
$ cd work
Make a GIT branch named "linus", and rename the "origin" branch as linus too:
$ git checkout -b linus
$ mv .git/branches/origin .git/branches/linus
The "linus" branch will be used to track the upstream kernel. To update it,
you simply run:
$ git checkout linus && git pull linus
you can do this frequently (as long as you don't have any uncommited work
in your tree).
If you need to keep track of other public trees, you can add branches for
them too:
$ git checkout -b another linus
$ echo URL-for-another-public-tree > .git/branches/another
Now create the branches in which you are going to work, these start
out at the current tip of the linus branch.
$ git checkout -b test linus
$ git checkout -b release linus
These can be easily kept up to date by merging from the "linus" branch:
$ git checkout test && git resolve test linus "Auto-update from upstream"
$ git checkout release && git resolve release linus "Auto-update from upstream"
Set up so that you can push upstream to your public tree:
$ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin
and then push each of the test and release branches using:
$ git push origin test
and
$ git push origin release
Now to apply some patches from the community. Think of a short
snappy name for a branch to hold this patch (or related group of
patches), and create a new branch from the current tip of the
linus branch:
$ git checkout -b speed-up-spinlocks linus
Now you apply the patch(es), run some tests, and commit the change(s). If
the patch is a multi-part series, then you should apply each as a separate
commit to this branch.
$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
When you are happy with the state of this change, you can pull it into the
"test" branch in preparation to make it public:
$ git checkout test && git resolve test speed-up-spinlocks "Pull speed-up-spinlock changes"
It is unlikely that you would have any conflicts here ... but you might if you
spent a while on this step and had also pulled new versions from upstream.
Some time later when enough time has passed and testing done, you can pull the
same branch into the "release" tree ready to go upstream. This is where you
see the value of keeping each patch (or patch series) in its own branch. It
means that the patches can be moved into the "release" tree in any order.
$ git checkout release && git resolve release speed-up-spinlocks "Pull speed-up-spinlock changes"
After a while, you will have a number of branches, and despite the
well chosen names you picked for each of them, you may forget what
they are for, or what status they are in. To get a reminder of what
changes are in a specific branch, use:
$ git-whatchanged branchname ^linus | git-shortlog
To see whether it has already been merged into the test or release branches
use:
$ git-rev-list branchname ^test
or
$ git-rev-list branchname ^release
[If this branch has not yet been merged you will see a set of SHA1 values
for the commits, if it has been merged, then there will be no output]
Once a patch completes the great cycle (moving from test to release, then
pulled by Linus, and finally coming back into your local "linus" branch)
the branch for this change is no longer needed. You detect this when the
output from:
$ git-rev-list branchname ^linus
is empty. At this point the branch can be deleted:
$ rm .git/refs/heads/branchname
To create diffstat and shortlog summaries of changes to include in a "please
pull" request to Linus you can use:
$ git-whatchanged -p release ^linus | diffstat -p1
and
$ git-whatchanged release ^linus | git-shortlog
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Daniel Barkalow @ 2005-08-15 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7vhddr397g.fsf@assigned-by-dhcp.cox.net>
On Mon, 15 Aug 2005, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > I was waiting until you said, "Ok, 1.00 tomorrow morning"
>
> Makes sense. There would be some weeks until that happens I am
> afraid.
It might be worth putting the list of things left to do before 1.0 in the
tree (since they clearly covary), and it would be useful to know what
you're thinking of as preventing the release at any particular stage.
-Daniel
*This .sig left intentionally blank*
^ 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