* [OT] ancestor branch in cvsps is wrong for branch-of-branch
From: Chris Shoemaker @ 2005-11-01 3:51 UTC (permalink / raw)
To: cvsps, David Mansfield; +Cc: git
[ Maybe the git list is interested in a problem with cvsps? ]
Summary: When creating a patchset for the first modification in a
branch-off-a-branch, cvsps (version 2.1) declares that the ancestor
branch is HEAD. Presumably this is because the file in the patchset
hadn't been modified since it was on HEAD. But this means that files
that are *added* to the first branch are never counted as added to the
branch-off-a-branch.
Figure:
-HEAD-(add file 'a')--+-------------------------
\
\-stable-(add file 'b')-+
\
\-dev-(change 'a')-->
In CVS, branch "dev" clearly contains both 'a' and 'b'. But cvsps
makes it look like this:
/-dev-(change 'a') ---->
/
-HEAD-(add file 'a')--+-------------------------
\
\-stable-(add file 'b')---->
So that in the imported git repository, the "dev" branch contains ONLY
'a'.
Below are: a script to reproduce this example, the cvs log output, and
cvsps output. It's clear from the cvs log that 'b' has the 'dev'
symbolic tag, so it seems like we should be able to recreate 'dev'.
Before I look into fixing this, I wanted to see if there were any
comments from the list. David?
-chris
#!/bin/sh
dirname=`date +"%Y%m%d%H%M%S"`
mkdir $dirname && cd $dirname
# create the repository
mkdir cvsroot && cd cvsroot
export CVSROOT=`pwd`
cd ..
cvs init
# import an empty project
mkdir project && cd project
cvs import -m "Create initial repo" project yoyo start
cd ..
rmdir project
# checkout the project
cvs co project && cd project
# create a new file on HEAD
echo 1 >a
cvs add a
cvs ci -m "added file a to HEAD" a
# create and switch to "stable" branch
cvs tag -b stable
cvs update -r stable
# add a new file to stable branch
echo 2 > b
cvs add b
cvs ci -m "added file b to 'stable' branch" b
# create and switch to "dev" branch from "stable"
cvs tag -b dev
cvs update -r dev
# modify file 'a' on "dev" branch
echo "change" >> a
cvs ci -m "changed file a on dev branch" a
# see what CVS thinks the "dev" branch looks like
cd ..
rm -rf project
cvs checkout -r dev project
ls project && echo "Note how b is PRESENT"
# check output of cvsps
cd project
cvs log > ../cvslog
cd ..
cvsps -A --test-log cvslog project > cvsps.out
# check behavior of git-cvsimport
git-cvsimport -i -d $CVSROOT -C project.git project
cd project.git
git-checkout -f dev
ls && echo "Note how b is ABSENT!"
#***********EOF*********************
cvsps output
---------------------
PatchSet 1
Date: 2005/10/31 22:30:46
Author: chris
Branch: HEAD
Tag: (none)
Log:
added file a to HEAD
Members:
a:INITIAL->1.1
---------------------
PatchSet 2
Date: 2005/10/31 22:30:47
Author: chris
Branch: stable
Ancestor branch: HEAD
Tag: (none)
Log:
added file b to 'stable' branch
Members:
b:1.1->1.1.2.1
---------------------
PatchSet 3
Date: 2005/10/31 22:30:48
Author: chris
Branch: dev
Ancestor branch: HEAD
Tag: (none)
Log:
changed file a on dev branch
Members:
a:1.1->1.1.4.1
******************EOF*********
cvs log output
RCS file: /home/chris/import/20051031223046/cvsroot/project/a,v
Working file: a
head: 1.1
branch:
locks: strict
access list:
symbolic names:
dev: 1.1.0.4
stable: 1.1.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.1
date: 2005/11/01 03:30:46; author: chris; state: Exp;
branches: 1.1.4;
added file a to HEAD
----------------------------
revision 1.1.4.1
date: 2005/11/01 03:30:48; author: chris; state: Exp; lines: +1 -0
changed file a on dev branch
=============================================================================
RCS file: /home/chris/import/20051031223046/cvsroot/project/Attic/b,v
Working file: b
head: 1.1
branch:
locks: strict
access list:
symbolic names:
dev: 1.1.2.1.0.2
stable: 1.1.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.1
date: 2005/11/01 03:30:47; author: chris; state: dead;
branches: 1.1.2;
file b was initially added on branch stable.
----------------------------
revision 1.1.2.1
date: 2005/11/01 03:30:47; author: chris; state: Exp; lines: +1 -0
added file b to 'stable' branch
=============================================================================
^ permalink raw reply
* [PATCH] Note that '.' is a useful value for <repository> in git-pull.
From: Daniel Barkalow @ 2005-11-01 3:28 UTC (permalink / raw)
To: git
Mention in the tutorial and in the documentation for git-pull that you can
merge local branches with all the bells and whistles with
"git pull . <branch>"
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
"git pull . <branch>" does, in fact, do exactly what I wanted, and, when
the tutorial mentioned that you could do this, it didn't mention why you
might want to.
Documentation/git-pull.txt | 3 ++-
Documentation/tutorial.txt | 12 ++++++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
applies-to: 8c8ace55eb085e930dcc9482f7cf66f9399374b4
0ba51e8c8298aff4256bd63289071f23b4d83db3
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index bae05de..fe0c18a 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -13,7 +13,8 @@ SYNOPSIS
DESCRIPTION
-----------
-Runs 'git-fetch' with the given parameters.
+Runs 'git-fetch' with the given parameters. This is effectively
+skipped if the repository is '.'
When only one ref is downloaded, runs 'git resolve' to merge it
into the local HEAD. Otherwise uses 'git octopus' to merge them
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index b9f737e..78443a9 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1027,8 +1027,16 @@ course, you will pay the price of more d
multiple working trees, but disk space is cheap these days.
[NOTE]
-You could even pull from your own repository by
-giving '.' as <remote-repository> parameter to `git pull`.
+
+One useful special case is
+
+ git pull . <branch-name>
+
+which does about the same thing as the `git resolve` calls for merging
+local branches, except that you don't have to type in the message or
+the side you're merging into (which is the branch that you have
+checked out).
+
It is likely that you will be pulling from the same remote
repository from time to time. As a short hand, you can store
---
0.99.8.GIT
^ permalink raw reply related
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-11-01 2:47 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Martin Langhoff, Joel Becker, Johannes Schindelin, walt, git
In-Reply-To: <86r7a1drji.fsf@blue.stonehenge.com>
On Mon, 31 Oct 2005, Randal L. Schwartz wrote:
>
> Linus> Start a new branch before the sequence you want to clean
> Linus> up. Then, move the cleaned-up history to that branch, and
> Linus> eventually you can just delete the old one.
>
> So if I toss something in git/refs, the objects pointed to by that are
> eventually reclaimed? Do I need to git-fsck-objects to do that? Or
> is there some cg command to do the whole thing?
You can do "git prune". It's pretty expensive, though, and the extra
objects don't _hurt_, so there's no reason to do pruning very
aggressively. I tend to prune immediately just because I run
git-fsck-objects all the time, and if you don't prune, it will nag you
about "dangling commit".
You may also decide to just rename the old broken branch. Keeping it
around for local historical reasons and never push it out.
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Junio C Hamano @ 2005-11-01 2:35 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0510311822080.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 31 Oct 2005, Randal L. Schwartz wrote:
>>
>> Martin> cg-diff -r from:to | patch -p1
>>
>> What's the easiest way then to toss all that intermediate history?
>> I'm thinking of the rcs "-o" switch that "outdates" any deltas in that
>> range.
>
> Start a new branch before the sequence you want to clean up. Then, move
> the cleaned-up history to that branch, and eventually you can just delete
> the old one.
Big caveat --- do that before you make that dirty tree available
to outside, otherwise you would be in hot water ;-)
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Randal L. Schwartz @ 2005-11-01 2:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Joel Becker, Johannes Schindelin, walt, git
In-Reply-To: <Pine.LNX.4.64.0510311822080.27915@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> Start a new branch before the sequence you want to clean
Linus> up. Then, move the cleaned-up history to that branch, and
Linus> eventually you can just delete the old one.
So if I toss something in git/refs, the objects pointed to by that are
eventually reclaimed? Do I need to git-fsck-objects to do that? Or
is there some cg command to do the whole thing?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-11-01 2:23 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Martin Langhoff, Joel Becker, Johannes Schindelin, walt, git
In-Reply-To: <86hdaxf6wq.fsf@blue.stonehenge.com>
On Mon, 31 Oct 2005, Randal L. Schwartz wrote:
>
> Martin> cg-diff -r from:to | patch -p1
>
> What's the easiest way then to toss all that intermediate history?
> I'm thinking of the rcs "-o" switch that "outdates" any deltas in that
> range.
Start a new branch before the sequence you want to clean up. Then, move
the cleaned-up history to that branch, and eventually you can just delete
the old one.
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Randal L. Schwartz @ 2005-11-01 2:17 UTC (permalink / raw)
To: Martin Langhoff
Cc: Joel Becker, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <46a038f90510311228v50743158q80d79e963bd503ce@mail.gmail.com>
>>>>> "Martin" == Martin Langhoff <martin.langhoff@gmail.com> writes:
Martin> You can do a diff that spans all the commits and apply it with a new
Martin> commit msg. With cogito:
Martin> cg-diff -r from:to | patch -p1
What's the easiest way then to toss all that intermediate history?
I'm thinking of the rcs "-o" switch that "outdates" any deltas in that
range.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* HTTP pushes
From: Nick Hengeveld @ 2005-11-01 2:02 UTC (permalink / raw)
To: git
HTTP is currently listed as a read-only/unsupported method for doing
pushes, is that due to inherent problems with HTTP or just because
it hasn't been written yet?
I've built a working prototype of an HTTP push implementation using DAV.
It locks the remote branch file during the push and PUTs to temp files to
insure nobody else reads objects while they're being pushed. It does
not validate remote objects - if they exist on the remote end as loose
objects or in a pack, local copies won't be pushed. It supports sparse
object directories, and verifies that the remote branch is an ancestor
of the local branch before doing anything.
I'm curious to know whether it would be useful to proceed further, and
to know what I haven't thought about yet...
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-11-01 1:48 UTC (permalink / raw)
To: Joel Becker; +Cc: Martin Langhoff, Junio C Hamano, git, Petr Baudis
In-Reply-To: <20051101012915.GR11488@ca-server1.us.oracle.com>
On Mon, 31 Oct 2005, Joel Becker wrote:
>
> But I'm not. I don't want patches in the first place. I want
> cg-pull but with a flattened history.
Well, that you've largely got in "git rebase". But if you wanrt to merge
commits, you'd have to do that logic yourself..
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-11-01 1:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com>
On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:
> I'm really surprised that Calalin hasn't chimed in. If you are into
> rewriting/merging/splitting your patches, StGIT is your friend. Check
> out: http://www.procode.org/stgit/
But I'm not. I don't want patches in the first place. I want
cg-pull but with a flattened history.
Joel
--
"Any man who is under 30, and is not a liberal, has not heart;
and any man who is over 30, and is not a conservative, has no brains."
- Sir Winston Churchill
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: git-cvsimport: $cvs->file() fails silently
From: Martin Langhoff @ 2005-11-01 1:22 UTC (permalink / raw)
To: Matthias Urlichs, Sven Verdoolaege, Git Mailing List
In-Reply-To: <46a038f90510262123y4f56cf7v5494b391394ac648@mail.gmail.com>
On 10/27/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> There _must_ be one place that we're missing but I just can't
> see it.
Got some more info on this. The output of cvsimport when this happens
looks like this:
Read from remote host cvs.sourceforge.net: Connection reset by peer
Read from remote host cvs.sourceforge.net: Connection reset by peer
Update course/enrol.php: bytes
Use of uninitialized value in split at
/home/martin/local/git/git-cvsimport line 362.
Update lang/en/moodle.php: 66792 bytes
Tree ID ef11ad5a0cf917e98bc477837de1b3f587e12027
Parent ID e972b3a28e1c4802fc5af6a996164c93fb4f3e53
Committed patch 20143 (MOODLE_15_STABLE 2005-10-31 20:31:57)
Commit ID 95a748b0d9cd6dc74e65497561514fa5858c149c
Around line 335 $res = $self->_line($fh); is returning '', which is
defined but otherwise empty. I've patched cvsimport thus to try and
catch this kind of error:
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index bbb83fb..f594df3 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -337,6 +337,10 @@ sub file {
}
close ($fh);
+ if ($res eq '') {
+ die "Looks like the server has gone away during the transaction!";
+ }
+
return ($name, $res);
}
@@ -764,6 +768,9 @@ while(<CVS>) {
my $rev = $3;
$fn =~ s#^/+##;
my ($tmpname, $size) = $cvs->file($fn,$rev);
+ if ($size eq '') {
+ die "Should not happen! Something went wrong
with the remote connection";
+ }
if($size == -1) {
push(@old,$fn);
print "Drop $fn\n" if $opt_v;
Now, I'm sure we can catch it in the "right" place, but I'm not sure
where that is.
cheers,
martin
^ permalink raw reply related
* Re: git versus CVS (versus bk)
From: Martin Langhoff @ 2005-11-01 1:02 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <20051101004255.GQ11488@ca-server1.us.oracle.com>
On 11/1/05, Joel Becker <Joel.Becker@oracle.com> wrote:
> > is possible) offhand. Sometimes, when you want truly logical
> > steps, you would end up needing intermediate steps that never
> > existed in your true history (i.e. "in the hindsight, my
> > development should have progressed in these steps.")
>
> Yes, I always do. But I'm not talking about that sort of large
> feature add or whatever. I'm talking about merely doing something on a
> small scale, but in a temporary repository.
I'm really surprised that Calalin hasn't chimed in. If you are into
rewriting/merging/splitting your patches, StGIT is your friend. Check
out: http://www.procode.org/stgit/
cheers,
martin
^ permalink raw reply
* Re: Date-based limits
From: Daniel Barkalow @ 2005-11-01 0:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x21b3v6.fsf@assigned-by-dhcp.cox.net>
On Mon, 31 Oct 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > At some point, we might want to have a series of refs tracking changes to
> > the user's heads over time.
>
> Hmph. If you really want something like that, I think you could
> add a hook support for git-fetch to implement this as
> automatically created lightweight tags...
Probably; I think this should also trigger on commits and such, and it
would need a way for rev-list (or rev-parse?) to find the last one before
a user-specified date, so that you don't have to figure out when the last
change was that contributed to you seeing a particular tree on a given
date.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-11-01 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vbr15b4m4.fsf@assigned-by-dhcp.cox.net>
On Mon, Oct 31, 2005 at 04:20:51PM -0800, Junio C Hamano wrote:
> After extracting a sequence of the dirty commits using
> git-format-patch, I would say:
> for i in 0*.txt; do git-apply --index $i; done
> to bring my tree up to date, and then just say "git commit".
Yeah, but this is a lot of by-hand (as you note below).
> Typically when I do this, I have one "significant" commit among
> them, usually early in the series, which is followed by smaller
> "fix this, fix that, oops fix that too" commits. So I edit the
> log message using the log of the significant commit, and add
> some missing bits.
When I work, regardless of SCM, I generally have many
checkpoints along the way. It might be a particular subfeature is
complete (and probably deserves a split-out patch of its own when I do
the "clean" merge), but it could also just be "I changed a lot today,
and I'd really like to save that off." So, while somtimes it looks just
like your "significant commit + fixes" model, it might also be "1/4 the
work", "compile fix on other platform, "1/2 the work", "fix", "the rest
of the work", all over the course of two days.
> $ git-read-tree -m -u master mytopic
> $ git-commit -c <that-significant-commit-in-mytopic-branch>
Replace <that-...> with <overall-concept-of-the-change> and you
have the workflow I'm talking about.
You know, this is a simpler command set than I am using. I've
been using Cogito, because it makes many of the 5-step git operations a
single step, more like some other tools. But I know no way to tell
Cogito to merge all the changes of the branch into the master without
also pulling in the commit history. That's the thing here. Petr, do
you have a way of doing this that I don't know about?
What I mean is, for the "naive" Cogito workflow:
cg-clone repo working
cd working
hack hack hack, commit commit commit
cd mainline
cg-pull working
the cg-pull command merges the changes back, but it also includes the
full commit history. Not what we want. Compare the "identical"
workflow:
cg-clone repo working
cd working
hack hack hack, commit commit commit
cg-diff mainline working > patch
cd mainline
cg-apply < patch
cg-commit
My basic premise is that I shouldn't have to deal with diff/patch as an
external step, especially since git knows more about the tree than
diff/patch do. It's a useless hoop to jump through.
Maybe Cogito contains something like what you describe above, a
way to get all the file changes without actually pulling in the commit
history. I don't care that the read-tree and the commit are separate
stages. I just have to type them.
> is possible) offhand. Sometimes, when you want truly logical
> steps, you would end up needing intermediate steps that never
> existed in your true history (i.e. "in the hindsight, my
> development should have progressed in these steps.")
Yes, I always do. But I'm not talking about that sort of large
feature add or whatever. I'm talking about merely doing something on a
small scale, but in a temporary repository.
Joel
--
Life's Little Instruction Book #510
"Count your blessings."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Date-based limits
From: Junio C Hamano @ 2005-11-01 0:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510311820060.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> At some point, we might want to have a series of refs tracking changes to
> the user's heads over time.
Hmph. If you really want something like that, I think you could
add a hook support for git-fetch to implement this as
automatically created lightweight tags, stashed in
$GIT_DIR/fetch-history/, deriving their names from the time of
the fetch; clone would grab everything below refs/ but this is
deliberately placed outside that hierarchy and won't get copied.
By definition, these point at commits reachable from some of
your heads (unless the remote repository maintainer is stupid
enough to rewind public trees ;-), so fsck-object would not see
them but it should not be a problem.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Daniel Barkalow @ 2005-11-01 0:31 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git
In-Reply-To: <20051031224246.GP11488@ca-server1.us.oracle.com>
On Mon, 31 Oct 2005, Joel Becker wrote:
> So, I have a git repository that is my For-Linus repository.
> It's got a clean history. What's my workflow?
>
> 1) Clone the repo to a Work tree.
> 2) Create and test fix X, with perhaps some >1 number of commits.
> 3) Bring that fix back to the For-Linus repository.
>
> This is a small change. It's not something that needs stepS, as
> you put them. But my history in the Work tree is "dirty," so I cannot
> just pull from Work to For-Linus.
> As the tools currently stand, I need to hand-diff and patch my
> commits. Neither git nor cogito have a command to do this first-class
> "the way you should do it" common operation.
I actually have a set of scripts that I use for this, which I've been too
lame to clean up properly and send in. The basic idea is:
(1) "git branch clean mainline"
(2) "git checkout clean"
(now I'm looking at the clean history, which doesn't have anything
yet)
(3) "git refine dirty"
(this says I'm trying to match the content of the head with the
dirty history)
(4) editor window pops up with the diff between the working tree and
dirty
(5) edit the patch, removing hunks which go later in the series, or which
I don't want to do at all and forgot to revert.
(6) it applies the patch; if there are rejects, it goes back to (4)
(7) normal thing for committing happens
(8) if there is any difference between the working tree and dirty, it
goes back to (4) for the next in the series
I still need to correct the flow control and make it invoke the editor
automatically and such, and provide some way out of the middle if you want
to give up or stop without reaching the end, and I have to detect the done
condition. But the general method does work, provided you're at least
somewhat comfortable editing patches (with the safety net that nobody else
will ever see the patch, so it doesn't matter too much if you screw it
up).
If somebody else wants to clean this up, I can post my version; dunno when
I'll get around to making it really right.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Theodore Ts'o @ 2005-11-01 0:25 UTC (permalink / raw)
To: Joel Becker; +Cc: Junio C Hamano, git
In-Reply-To: <20051031224246.GP11488@ca-server1.us.oracle.com>
On Mon, Oct 31, 2005 at 02:42:46PM -0800, Joel Becker wrote:
> As the tools currently stand, I need to hand-diff and patch my
> commits. Neither git nor cogito have a command to do this first-class
> "the way you should do it" common operation. It is, in my experience, a
> pain. Not as large a pain as some things, but certainly second class to
> much of the workflow git/cogito provide. If it is supposed to be a
> regular part of my workflow, what's wrong with making it a first-class
> operation?
For an example of how to make it a first-class operation, it might be
worthwhile to look at Chris Mason's "Mercurial Queues" extention to
Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
I've used it once or twice, and hg mq is definitely very nice and
convenient, and it makes commits a first-class operation. On the
other hand, I've found that the combination of quilt and
Mercurial/BK/git works just fine, even for my own internal development
of (for example) the e2fsprogs tree.
- Ted
^ permalink raw reply
* Re: Question on GIT usage.
From: Junio C Hamano @ 2005-11-01 0:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510311540300.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I _think_ you should be able to just do
>
> git pull <repodir> <branchname>
>
> where <repodir> can even be just "." for the very same repository.
>
> I've not tested it, but dammit, it should work. If it doesn't, it's a bug.
I know it works. 'git pull . somebranch' is the command I use
the second most often in the git suite (the first being
git-show-branch).
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Linus Torvalds @ 2005-11-01 0:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Randal L. Schwartz, wa1ter, git
In-Reply-To: <Pine.LNX.4.64.0510311905120.25300@iabervon.org>
On Mon, 31 Oct 2005, Daniel Barkalow wrote:
>
> Being married is great, but it just doesn't scale past a dozen people who
> trust each other and have rules on how they do things.
This thread is getting a big psychedelic.
People, take your meds, please,
Linus
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Junio C Hamano @ 2005-11-01 0:20 UTC (permalink / raw)
To: git
In-Reply-To: <20051031224246.GP11488@ca-server1.us.oracle.com>
Joel Becker <Joel.Becker@oracle.com> writes:
> No, you're reading me wrong, but I wasn't clear enough either.
> At the end of my message, I'm noting that I'm considering smaller
> changes here, not huge features.
OK. Consolidating two or more patches into one is something I
have done too, but I never felt need for tool support, so that's
probably why I misunderstood you.
After extracting a sequence of the dirty commits using
git-format-patch, I would say:
for i in 0*.txt; do git-apply --index $i; done
to bring my tree up to date, and then just say "git commit".
Typically when I do this, I have one "significant" commit among
them, usually early in the series, which is followed by smaller
"fix this, fix that, oops fix that too" commits. So I edit the
log message using the log of the significant commit, and add
some missing bits.
I guess another way to do it without even first extracting them
as patches would be:
$ git checkout -b mytopic master
$ work work work, commit commit commit.
$ git checkout master
$ git-read-tree -m -u master mytopic
$ git-commit -c <that-significant-commit-in-mytopic-branch>
If you want a tool support for this workflow, probably the last
two could be somewhat automated. But what would the user input
for that be? You need to tell what tree shape you want the
after-commit tree to be in, and where you would want the bulk of
your commit message to come from.
One possibility.
$ git-squash-pick mytopic
would be something like this:
#!/bin/sh
#
git-read-tree -m -u HEAD "$1"
git log HEAD.."$1" >.tmp-commit
git-commit -F .tmp-commit -e
Your commit-log edit buffer would start with the concatenation
of all the commit logs in that throwaway history, and hopefully
you would mostly need to delete lines and move some parts around
before committing. I do not know how useful this kind of
specialized tool would be, though...
Splitting and merging patches into logical steps is something I
dream of to be automated, but I do not know how (nor even if it
is possible) offhand. Sometimes, when you want truly logical
steps, you would end up needing intermediate steps that never
existed in your true history (i.e. "in the hindsight, my
development should have progressed in these steps.")
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Daniel Barkalow @ 2005-11-01 0:15 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: wa1ter, git
In-Reply-To: <867jbtii85.fsf@blue.stonehenge.com>
On Mon, 31 Oct 2005, Randal L. Schwartz wrote:
> >>>>> "wa1ter" == wa1ter <wa1ter@myrealbox.com> writes:
>
> wa1ter> Ahh -- the lightbulb just lit up. Using CVS is just like
> wa1ter> being married. No wonder you hate it...
>
> Now, hey hey. I've met Tove. She's very nice. I doubt that Linus
> would compare his marriage to her with CVS. :)
He did say that CVS worked reasonably at Transmeta. He's probably just as
glad she's not married to the entire Linux development community...
Being married is great, but it just doesn't scale past a dozen people who
trust each other and have rules on how they do things.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Question on GIT usage.
From: Daniel Barkalow @ 2005-10-31 23:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Greear, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510311540300.27915@g5.osdl.org>
On Mon, 31 Oct 2005, Linus Torvalds wrote:
> On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> >
> > Oh, that reminds me: is there a simple way to merge a branch with another
> > local branch or remote branch that's already up-to-date? E.g., I've
> > already fetched the latest git from kernel.org, built it, and installed
> > it. Now I want to merge my development branch with that. Last time I was
> > looking, I had to write the message for the merge myself, unlike "pull",
> > which takes care of that.
>
> Umm.. Why don't you just use "pull"?
>
> I _think_ you should be able to just do
>
> git pull <repodir> <branchname>
>
> where <repodir> can even be just "." for the very same repository.
>
> I've not tested it, but dammit, it should work. If it doesn't, it's a bug.
That does follow logically, but it really ought to be an example in the
documentation, because "fetch what you have from yourself and merge it"
isn't the first thing that comes to mind for me. :)
I'll make sure that works and comes out nicely, and then send in a
Documentation patch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Date-based limits (Was Re: GIT 0.99.9)
From: Daniel Barkalow @ 2005-10-31 23:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510301838110.27915@g5.osdl.org>
On Sun, 30 Oct 2005, Linus Torvalds wrote:
> (The danger with date-based things is that something may be 4 months old,
> but it only got _merged_ yesterday, so it may be new to _you_. And the
> --since="2 weeks ago" will not show it, which can be surprising to people
> who expect things that are new to _them_ to be shown).
At some point, we might want to have a series of refs tracking changes to
the user's heads over time. Then the right set of arguments could actually
handle "what would I have seen on Thursday, when I hadn't pulled since
Tuesday, and upstream got some changes on Wednesday that I got on Friday,
and it's Saturday now." (That is, Wednesday's commits hadn't hit the local
repository yet; the commit that we got to is dated Friday for local
purposes, and the latest as of Thursday is dated Tuesday, which is the
last time the ref file was modified.)
And we probably don't want to fetch or clone this stuff; I doubt most
people want to know the history from somebody else's point of view. At
least, I can't think of a use for it that wouldn't be better served by
asking whoever for the hash out of their history.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: walt @ 2005-10-31 23:41 UTC (permalink / raw)
To: git
In-Reply-To: <867jbtii85.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
> ...I doubt that Linus
> would compare his marriage...with CVS. :)
I dunno why not. If my wife knew CVS she would probably agree
with me (for a change).
I've learned a great deal from reading this thread -- as I hope
others have. I did learn one important thing while reading about
old Al Einstein: you can get some astonishing insights by asking
really dumb questions of really smart people.
I've had many such astonishing insights from reading Linus's posts
over the years (and I look forward to many more). I've been amazed
by Linus's understanding of both machines and people -- this combo
is rare indeed!
Linus, have you considered a career in marriage counseling?
^ permalink raw reply
* Re: Question on GIT usage.
From: Linus Torvalds @ 2005-10-31 23:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Ben Greear, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510311821410.25300@iabervon.org>
On Mon, 31 Oct 2005, Daniel Barkalow wrote:
>
> Oh, that reminds me: is there a simple way to merge a branch with another
> local branch or remote branch that's already up-to-date? E.g., I've
> already fetched the latest git from kernel.org, built it, and installed
> it. Now I want to merge my development branch with that. Last time I was
> looking, I had to write the message for the merge myself, unlike "pull",
> which takes care of that.
Umm.. Why don't you just use "pull"?
I _think_ you should be able to just do
git pull <repodir> <branchname>
where <repodir> can even be just "." for the very same repository.
I've not tested it, but dammit, it should work. If it doesn't, it's a bug.
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