[PATCH] Add "clone" support to lntree

[PATCH] Add "clone" support to lntree

[Daniel Barkalow]

I often want to take a base tree, which I keep tracking some remote head,
and make a local working tree that starts from it. This makes "git ln -c
<dest>" give you a tree that you can just start working in and then diff
against the head you'd started from and send off.

Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>

Index: gitlntree.sh
===================================================================
--- b068d3ec7c00cfe4a1f14a898f61c4807cd5bc8b/gitlntree.sh  (mode:100755 sha1:17c4966ea64aeced96ae4f1b00f3775c1904b0f1)
+++ 0877e1b9b70a4305959b7f65ace4044e4ae0afdb/gitlntree.sh  (mode:100755 sha1:84cbf0492996f1139b992147b4f53bc14342e3f2)
@@ -7,11 +7,14 @@
 # same objects database as the current one. It also shares the
 # branches and tags information.
 #
-# The new directory is completely pristine - there's not even
-# a directory cache there yet.
-#
 # Takes the new directory name.
 
+if [ "$1" = "-c" ]
+then
+    clone=yes
+    shift 1
+fi
+
 destdir=$1
 
 die () {
@@ -32,3 +35,12 @@
 ln -s $srcdir/.git/objects $dgitdir/objects
 ln -s $srcdir/.git/remotes $dgitdir/remotes
 ln -s $srcdir/.git/tags $dgitdir/tags
+
+if [ "$clone" != "" ]
+then
+    cp $srcdir/.git/HEAD $dgitdir/HEAD
+    cd $destdir
+    read-tree $(tree-id)
+    checkout-cache -a
+    update-cache --refresh
+fi

Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> I often want to take a base tree, which I keep tracking some remote head,
> and make a local working tree that starts from it. This makes "git ln -c
> <dest>" give you a tree that you can just start working in and then diff
> against the head you'd started from and send off.
> 
> Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>

I'm sorry but you are late, I added it about a hour and half ago or so.
:-) Check git fork. (I *want* separate command than git lntree. In fact,
I think I should make git lntree gitXlntree.sh instead, since it is
really internal command for git-tools and the user should probably never
need it for anything. git lntree is too lowlevel.)

Actually, I don't like the name at all, though. Some people may find
pondering about names pointless, but when I'm going to type them in
every day for the rest of my life, they better should not be stupid. ;-)

So, what are your clever ideas about git fork's proper name? Or should
we leave it as is?

Summary of current related git commands (yes, they are already around
and should be actually all working):

	git addremote --- registers a remote branch (name - URL pair)
	git branch --- creates a branch from a given commit
			(when passed empty commit, creates a branch
			from the current commit and sets the working
			tree to that branch)
	git clone --- creates a local GIT repository from a remote one
	git export --- checks out given commit to a separate directory
			(without any GIT information)
	git fork --- creates a new branch and working tree from
			the current working tree, sharing the same
			local GIT repository
	git lntree --- creates a "treeshell" sharing the same GIT
			repository with the current tree

If you think any other of those should be renamed, this is the time to
speak up. Oh well, I think I'll regret asking about this at all... ;-)

Note that there is a bug in current git update - it will allow you to
bring several of your trees to follow the same branch, or even a remote
branch. This is not even supposed to work, and will be fixed when I get
some sleep. You will be able to do git pull even on local branches, and
the proper solution for this will be just tracking the branch you want
to follow.

So, I'll fix that tomorrow, enable you to fork to an existing but unused
branch, fix git pull of remote branch by several local branches, and
write a lot of documentation.

Kind regards,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> 	git branch --- creates a branch from a given commit
> 			(when passed empty commit, creates a branch
> 			from the current commit and sets the working
> 			tree to that branch)
> Note that there is a bug in current git update - it will allow you to
> bring several of your trees to follow the same branch, or even a remote
> branch. This is not even supposed to work, and will be fixed when I get
> some sleep. You will be able to do git pull even on local branches, and
> the proper solution for this will be just tracking the branch you want
> to follow.

I must admit that I'm not entirely decided yet, so I'd love to hear your
opinion.

I'm wondering, whether each tree should be fixed to a certain branch.
That is, you decide a name when you do git fork, and then the tree
always follows that branch. (It always has to follow [be bound to]
*some* branch, and each branch can be followed by only a single tree at
a time.)

Currently, you can at anytime "mark" a new branch (by git branch) and
you can freely "rebranch" your tree (by git update). An alternative
approach would be to disallow git update to "rebranch" and remove the
git branch command (you'd always do git fork).

 From what I know, the alternative approach is nearer to what BK takes,
and it would be _slightly_ simpler (maybe). OTOH the current approach is
I believe more powerful, and could require less resources.

WWhat do you think,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Re: Add "clone" support to lntree

[Linus Torvalds]

On Sat, 16 Apr 2005, Petr Baudis wrote:
> 
> I'm wondering, whether each tree should be fixed to a certain branch.

I'm wondering why you talk about "branches" at all.

No such thing should exist. There are no branches. There are just 
repositories. You can track somebody elses repository, but you should 
track it by location, not by any "branch name".

And you track it by just merging it.

Yeah, we don't have really usable merges yet, but..

		Linus

Re: Re: Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sat, Apr 16, 2005 at 05:16:12AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> > 
> > I'm wondering, whether each tree should be fixed to a certain branch.
> 
> I'm wondering why you talk about "branches" at all.
> 
> No such thing should exist. There are no branches. There are just 
> repositories. You can track somebody elses repository, but you should 
> track it by location, not by any "branch name".
> 
> And you track it by just merging it.
> 
> Yeah, we don't have really usable merges yet, but..

First, this "level" of branches concerns multiple working directories
tied to a single repository. It seems like a sensible thing to do; and
you agreed with it too (IIRC). And when you do that, git-pasky just
saves some work for you. For git-pasky, branch is really just a symbolic
name for a commit ID, which gets updated every time you commit in some
repository. Nothing more.

So the whole point of this is to have a symbolic name for some other
working directory. When you want to merge, you don't need to go over to
the other directory, do commit-id, cut'n'paste, and feed that to git
merge. You just do

		git merge myotherbranch


Now, about remote repositories. When you pull a remote repository, that
does not mean it has to be immediately merged somewhere. It is very
useful to have another branch you do *not* want to merge, but you want
to do diffs to it, or even check it out / export it later to some
separate directory. Again, the "branch" is just a symbolic name for the
head commit ID of what you pulled, and the pointer gets updated every
time you pull again - that's the whole point of it.

The last concept are "tracking" working directories. If you pull the
tracked branch to this directory, it also automerges it. This is useful
when you have a single canonical branch for this directory, which it
should always mirror. That would be the case e.g. for the gazillions of
Linux users who would like to just have the latest bleeding kernel of
your, and they expect to use git just like a "different CVS". Basically,
they will just do

		git pull

instead of

		cvs update

:-).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Re: Add "clone" support to lntree

[Daniel Barkalow]

On Sat, 16 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> where Petr Baudis <pasky@ucw.cz> told me that...
> > 	git branch --- creates a branch from a given commit
> > 			(when passed empty commit, creates a branch
> > 			from the current commit and sets the working
> > 			tree to that branch)
> > Note that there is a bug in current git update - it will allow you to
> > bring several of your trees to follow the same branch, or even a remote
> > branch. This is not even supposed to work, and will be fixed when I get
> > some sleep. You will be able to do git pull even on local branches, and
> > the proper solution for this will be just tracking the branch you want
> > to follow.
> 
> I must admit that I'm not entirely decided yet, so I'd love to hear your
> opinion.
> 
> I'm wondering, whether each tree should be fixed to a certain branch.
> That is, you decide a name when you do git fork, and then the tree
> always follows that branch. (It always has to follow [be bound to]
> *some* branch, and each branch can be followed by only a single tree at
> a time.)

I don't think I'm following the use of branches. Currently, what I do is
have a git-pasky and a git-linus, and fork off a working directory from
one of these for each thing I want to work on. I do some work, commit as I
make progress, and then do a diff against the remote head to get a patch
to send off. If I want to do a series of patches which depend on each
other, I fork my next directory off of my previous one rather than off of
a remote base. I haven't done much rebasing, so I haven't worked out how I
would do that most effectively.

I think I can make this space efficient by hardlinking unmodified blobs to
a directory of cached expanded blobs.

	-Daniel
*This .sig left intentionally blank*

Re: Re: Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> 
> > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > where Petr Baudis <pasky@ucw.cz> told me that...
> > > 	git branch --- creates a branch from a given commit
> > > 			(when passed empty commit, creates a branch
> > > 			from the current commit and sets the working
> > > 			tree to that branch)
> > > Note that there is a bug in current git update - it will allow you to
> > > bring several of your trees to follow the same branch, or even a remote
> > > branch. This is not even supposed to work, and will be fixed when I get
> > > some sleep. You will be able to do git pull even on local branches, and
> > > the proper solution for this will be just tracking the branch you want
> > > to follow.
> > 
> > I must admit that I'm not entirely decided yet, so I'd love to hear your
> > opinion.
> > 
> > I'm wondering, whether each tree should be fixed to a certain branch.
> > That is, you decide a name when you do git fork, and then the tree
> > always follows that branch. (It always has to follow [be bound to]
> > *some* branch, and each branch can be followed by only a single tree at
> > a time.)
> 
> I don't think I'm following the use of branches. Currently, what I do is
> have a git-pasky and a git-linus, and fork off a working directory from
> one of these for each thing I want to work on. I do some work, commit as I
> make progress, and then do a diff against the remote head to get a patch
> to send off. If I want to do a series of patches which depend on each
> other, I fork my next directory off of my previous one rather than off of
> a remote base. I haven't done much rebasing, so I haven't worked out how I
> would do that most effectively.

Yes. And that's exactly what the branches allow you to do. You just do

	git fork myhttpclient ~/myhttpclientdir

then you do some hacking, and when you have something usable, you can
go back to your main working directory and do

	git merge -b when_you_started myhttpclient

Since you consider the code perfect, you can now just rm -rf
~/myhttpclient.

Suddenly, you get a mail from mj pointing out some bugs, and it looks
like there are more to come. What to do?

	git fork myhttpclient ~/myhttpclientdir

(Ok, this does not work, but that's a bug, will fix tomorrow.) This will
let you take off when you left in your work on the branch.

git update for seeking between commits is probably extremely important
for any kind of binary search when you are wondering when did this bug
appeared first, or when you are exploring how certain branch evolved
over time. Doing git fork for each successive iteration sounds horrible.


Now, what about git branch and git update for switching between
branches? I think this is the most controversial part; these are
basically just shortcuts for not having to do git fork, and I wouldn't
mind so much removing them, if you people really consider them too ugly
a wart for the soft clean git skin. I admit that they both come from a
hidden prejudice that git fork is going to be slow and eat a lot of
disk.

The idea for git branch is to mark a commit as "this is a branch but I
don't want to git fork" (because I'm lazy or short on disk space or
whatever). Let's say you are tracking a branch, do some local commits
and then want to untrack. This will get you back to HEAD.local, but you
want to keep a reference for your local commits, and possibly work on
them more later - so you mark them as a branch. But thinking about it, I
couldn't come up with another usage case than this, and I think that now
that we have git fork, I will modify git track behaviour heavily so that
tracking/untracking won't really switch you to the other branch
completely, but really only tell git pull that you want the pulled
updates applied. So git branch command will likely go.

The idea for git update for switching between branches is that
especially when you have two rather similar branches and mostly do stuff
on one of them, but sometimes you want to do something on the other one,
you can do just quick git update, do stuff, and git update back, without
any forking.


Note that this all is *absolutely* subject to change, provided you can
convince me about some better way. ;-) My mindset on this is pretty
open. This is just what seems to me as a pretty flexible and elegant to
do stuff, while giving you enough freedom to pick your own style.

> I think I can make this space efficient by hardlinking unmodified blobs to
> a directory of cached expanded blobs.

I don't know but I really feel *very* unsafe when doing that. What if
something screws up and corrupts my base... way too easy. And it gets
pretty inconvenient and even more dangerous when you get the idea to do
some modifications on your tree by something else than your favorite
editor (which you've already checked does the right thing).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Re: Re: Add "clone" support to lntree

[Daniel Barkalow]

On Sun, 17 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sat, Apr 16, 2005 at 05:17:00AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Sat, 16 Apr 2005, Petr Baudis wrote:
> > 
> > > Dear diary, on Sat, Apr 16, 2005 at 04:47:55AM CEST, I got a letter
> > > where Petr Baudis <pasky@ucw.cz> told me that...
> > > > 	git branch --- creates a branch from a given commit
> > > > 			(when passed empty commit, creates a branch
> > > > 			from the current commit and sets the working
> > > > 			tree to that branch)
> > > > Note that there is a bug in current git update - it will allow you to
> > > > bring several of your trees to follow the same branch, or even a remote
> > > > branch. This is not even supposed to work, and will be fixed when I get
> > > > some sleep. You will be able to do git pull even on local branches, and
> > > > the proper solution for this will be just tracking the branch you want
> > > > to follow.
> > > 
> > > I must admit that I'm not entirely decided yet, so I'd love to hear your
> > > opinion.
> > > 
> > > I'm wondering, whether each tree should be fixed to a certain branch.
> > > That is, you decide a name when you do git fork, and then the tree
> > > always follows that branch. (It always has to follow [be bound to]
> > > *some* branch, and each branch can be followed by only a single tree at
> > > a time.)
> > 
> > I don't think I'm following the use of branches. Currently, what I do is
> > have a git-pasky and a git-linus, and fork off a working directory from
> > one of these for each thing I want to work on. I do some work, commit as I
> > make progress, and then do a diff against the remote head to get a patch
> > to send off. If I want to do a series of patches which depend on each
> > other, I fork my next directory off of my previous one rather than off of
> > a remote base. I haven't done much rebasing, so I haven't worked out how I
> > would do that most effectively.
> 
> Yes. And that's exactly what the branches allow you to do. You just do
> 
> 	git fork myhttpclient ~/myhttpclientdir
> 
> then you do some hacking, and when you have something usable, you can
> go back to your main working directory and do
> 
> 	git merge -b when_you_started myhttpclient
> 
> Since you consider the code perfect, you can now just rm -rf
> ~/myhttpclient.
> 
> Suddenly, you get a mail from mj pointing out some bugs, and it looks
> like there are more to come. What to do?
> 
> 	git fork myhttpclient ~/myhttpclientdir
> 
> (Ok, this does not work, but that's a bug, will fix tomorrow.) This will
> let you take off when you left in your work on the branch.

Ah, I think that's what made me think I wasn't understanding branches; the
first thing I tried hit this big.

> git update for seeking between commits is probably extremely important
> for any kind of binary search when you are wondering when did this bug
> appeared first, or when you are exploring how certain branch evolved
> over time. Doing git fork for each successive iteration sounds horrible.

Even if there isn't a performance hit, it's semantically wrong, because
you're looking at different versions that were in the same place at
different times.

> Now, what about git branch and git update for switching between
> branches? I think this is the most controversial part; these are
> basically just shortcuts for not having to do git fork, and I wouldn't
> mind so much removing them, if you people really consider them too ugly
> a wart for the soft clean git skin. I admit that they both come from a
> hidden prejudice that git fork is going to be slow and eat a lot of
> disk.

I think that this just confuses matters.

> The idea for git update for switching between branches is that
> especially when you have two rather similar branches and mostly do stuff
> on one of them, but sometimes you want to do something on the other one,
> you can do just quick git update, do stuff, and git update back, without
> any forking.

I still think that fork should be quick enough, or you could leave the
extra tree around. I'm not against having such a command, but I think it
should be a separate command rather than a different use of update, since
it would be used by poeople working in different ways.

> > I think I can make this space efficient by hardlinking unmodified blobs to
> > a directory of cached expanded blobs.
> 
> I don't know but I really feel *very* unsafe when doing that. What if
> something screws up and corrupts my base... way too easy. And it gets
> pretty inconvenient and even more dangerous when you get the idea to do
> some modifications on your tree by something else than your favorite
> editor (which you've already checked does the right thing).

It should only be an option, not required and maybe not even
default. I think it should be possible to prevent stuff from screwing up,
since we really don't want anything to ever modify those inodes (as
opposed to some cases, where you want to modify inodes only in certain
ways). For that matter, relatively few programs actually support
modifying inodes rather than unlinking.

	-Daniel
*This .sig left intentionally blank*

Re: Re: Re: Add "clone" support to lntree

[Petr Baudis]

For the record, mostly... (this is how it already is in git-pasky-0.5)

Dear diary, on Sun, Apr 17, 2005 at 02:07:36AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > Now, what about git branch and git update for switching between
> > branches? I think this is the most controversial part; these are
> > basically just shortcuts for not having to do git fork, and I wouldn't
> > mind so much removing them, if you people really consider them too ugly
> > a wart for the soft clean git skin. I admit that they both come from a
> > hidden prejudice that git fork is going to be slow and eat a lot of
> > disk.
> 
> I think that this just confuses matters.

I killed them both for good.

> > The idea for git update for switching between branches is that
> > especially when you have two rather similar branches and mostly do stuff
> > on one of them, but sometimes you want to do something on the other one,
> > you can do just quick git update, do stuff, and git update back, without
> > any forking.
> 
> I still think that fork should be quick enough, or you could leave the
> extra tree around. I'm not against having such a command, but I think it
> should be a separate command rather than a different use of update, since
> it would be used by poeople working in different ways.

I've removed git branch, removed the possibility for git update to
switch branches and renamed git update to git seek. You can do

	git seek git-pasky-0.1

and examine stuff, but your tree is also blocked at the same time - git
won't let you commit, merge and such. By doing

	git seek
or
	git seek master

you return back to your branch (assuming its name is master).

I think git fork is after all good enough for branching and it is the
clean way. Shall there be a big demand for it, it should be minimal
hassle to implement 'git switch', which would do that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Change "pull" to _only_ download, and "git update"=pull+merge?

[David A. Wheeler]

This is a minor UI thing, but what the heck. I propose
changing "pull" to ONLY download, and "update" to pull AND merge.
Whenever you want to update, just say "git update", end of story.

Why? It seems oddly inconsistent that "pull" sometimes merges
in changes, but at other times it doesn't.  If I normally
track someone, but temporarily don't want to (I'm in the middle
of lots of changes but I _do_ want to see what's going on),
I have to "untrack", pull, and then "retrack" again (remembering who
I once tracked, which may be more of a trick over time).
Maybe more important, that is more annoying when you're
trying to "just pull data" from a script; I need to
do the untrack, pull, & retrack shuffle just to download data.

I propose that there be two subcommands, "pull" and "update"
(now that "update" isn't a reserved word again).
A "git pull" ONLY downloads; a "git update" pulls AND merges.
That means each command does exactly one thing, very simple &
clean to explain.  Also, some tools (such as subversion) already
use "update" as meaning this (auto download & merge from the
given repository), so the terminology would make sense for some.

I'd be happy to send in a patch to do that.  The coding is trivial,
but it means a UI change in one of the most common commands
(use "update" instead of "pull" in the typical case).
I could add a "reminder" message after pulling, to let people
adjust to the new commands for a little while.

--- David A. Wheeler

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[David Greaves]

David A. Wheeler wrote:
> I propose changing "pull" to ONLY download, and "update" to pull AND merge.

> Why? It seems oddly inconsistent that "pull" sometimes merges
> in changes, but at other times it doesn't.
true

> I propose that there be two subcommands, "pull" and "update"
> (now that "update" isn't a reserved word again).
> A "git pull" ONLY downloads; a "git update" pulls AND merges.

What's the most common thing to do? pull or update?
which is easier to type?
what are people used to?

I'm not sure but I suggest that pull and get would be better choices.

git pull
git get

is it rare enough to justify:
git --download-only pull


David

-- 

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Petr Baudis]

Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter
where David Greaves <david@dgreaves.com> told me that...
> What's the most common thing to do? pull or update?

update for normal users.

> which is easier to type?
> what are people used to?

I think 'git up' is easier to type than 'git pull'. It's the CVS/SVN
tradition, though, probably not the BK tradition.

> I'm not sure but I suggest that pull and get would be better choices.
> 
> git pull
> git get

I don't like git get; it is something completely new - not in CVS/SVN
and means something completely different in BK, apparently.

> is it rare enough to justify:
> git --download-only pull

Dunno. I do it personally all the time, with git at least.

What do others think? :-)

I start to like the pull/update distinction, and I think I'll go for it.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter
> where David Greaves <david@dgreaves.com> told me that...
>
> Dunno. I do it personally all the time, with git at least.
> 
> What do others think? :-)
> 

I think pull is pull.  If you are doing lots of local stuff and do not
want it overwritten, it should have been in a forked branch.

> I start to like the pull/update distinction, and I think I'll go for it.
> 

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Petr Baudis]

Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:
> > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter
> > where David Greaves <david@dgreaves.com> told me that...
> >
> > Dunno. I do it personally all the time, with git at least.
> > 
> > What do others think? :-)
> > 
> 
> I think pull is pull.  If you are doing lots of local stuff and do not
> want it overwritten, it should have been in a forked branch.

I disagree. This already forces you to have two branches (one to pull
from to get the data, mirroring the remote branch, one for your real
work) uselessly and needlessly.

I think there is just no good name for what pull is doing now, and
update seems like a great name for what pull-and-merge really is. Pull
really is pull - it _pulls_ the data, while update also updates the
given tree. No surprises.

(We should obviously have also update-without-pull but that is probably
not going to be so common so a parameter for update (like -n) should be
fine for that.)

These naming issues may appear silly but I think they matter big time
for usability, intuitiveness, and learning curve (I don't want git-pasky
become another GNU arch).

Kind regards,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Jon Seymour]

> I disagree. This already forces you to have two branches (one to pull
> from to get the data, mirroring the remote branch, one for your real
> work) uselessly and needlessly.
> 
> ...
> These naming issues may appear silly but I think they matter big time
> for usability, intuitiveness, and learning curve (I don't want git-pasky
> become another GNU arch).
> 


Not that it is worth that much, but my $0.02 is that Petr is right on
this one. I want something that allows me to get the objects into my
local repository without funking with my working directory.

As a long time CVS user, "git update" would do what I expect it to. I
don't have any pre-conceptions about what "pull" does, so it doesn't
phase me if pull is used for this purpose. However, perhaps pull means
something in some other SCM that would cause confusion for others?

Some alternatives to "pull" are offered: hoard, gather, make-local, download.

Regards,

jon.
-- 
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]

On Tue, 2005-04-19 at 12:50 +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> > On Tue, 2005-04-19 at 11:28 +0200, Petr Baudis wrote:
> > > Dear diary, on Tue, Apr 19, 2005 at 11:18:55AM CEST, I got a letter
> > > where David Greaves <david@dgreaves.com> told me that...
> > >
> > > Dunno. I do it personally all the time, with git at least.
> > > 
> > > What do others think? :-)
> > > 
> > 
> > I think pull is pull.  If you are doing lots of local stuff and do not
> > want it overwritten, it should have been in a forked branch.
> 
> I disagree. This already forces you to have two branches (one to pull
> from to get the data, mirroring the remote branch, one for your real
> work) uselessly and needlessly.
> 
> I think there is just no good name for what pull is doing now, and
> update seems like a great name for what pull-and-merge really is. Pull
> really is pull - it _pulls_ the data, while update also updates the
> given tree. No surprises.
> 
> (We should obviously have also update-without-pull but that is probably
> not going to be so common so a parameter for update (like -n) should be
> fine for that.)
> 
> These naming issues may appear silly but I think they matter big time
> for usability, intuitiveness, and learning curve (I don't want git-pasky
> become another GNU arch).
> 

Ok, so 'pull' do the bk thing, and 'update' do the cvs thing.  I think
however you should do either do one or the other.  Maybe drop the
'update', and rather add 'checkout' (or 'co' for short) which will
update the tree (or merge with local changes if needed).  Then you have
two distinct separate things (ok, so pretty much how bk do things).

This will also enable you to make 'fork', 'export', etc just do the
right thing with the database, but leave 'checkout' up to the user if he
wants to do so.


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Daniel Barkalow]

On Tue, 19 Apr 2005, Petr Baudis wrote:

> I disagree. This already forces you to have two branches (one to pull
> from to get the data, mirroring the remote branch, one for your real
> work) uselessly and needlessly.

If you pull in a non-tracked tree, it certainly won't apply the
changes, so you can just have your local tree and pull other people's
trees as desired.

> I think there is just no good name for what pull is doing now, and
> update seems like a great name for what pull-and-merge really is. Pull
> really is pull - it _pulls_ the data, while update also updates the
> given tree. No surprises.

I'm actually getting suspicious that the right thing is to hide "pull" in
the id scheme. That is, instead of saying "linus" to refer to the
"linus" head that you currently have, you say "+linus" to refer to the
head Linus has on his server currently, and this will cause you to
download anything necessary to perform the operation with the resulting
value.

See, I don't think you ever want to just pull. You want to
pull-and-do-something, but the something could be any operation that uses
a commit, not necessarily update. So you could do "git diff -r +linus" to
compare your head against current linus. You'd want "git update" to take a
working directory from "linus" to "+linus" (just because you know Linus's
more recent head doesn't mean you're automatically using it). You could
just "git merge +linus" in your working directory to sync with Linus. Even
"git log +linus" to see his recent changes.

I think the only reason not to just make any reference to a head pull it
is performance on looking up the head; you don't really want to hammer the
server getting these 40-byte files constantly or wait for a connection
every time (not to mention the possibility of not being able to
connect). But there's no reason to want to not have the latest data, since
the older data doesn't go away.

	-Daniel
*This .sig left intentionally blank*

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[David A. Wheeler]

Daniel Barkalow wrote:
 >See, I don't think you ever want to just pull. You want to
 >pull-and-do-something, but the something could be any operation...

In a _logical_ sense that's true; I'd only want to pull data if I intended
to (possibly) do something with it.  But as a _practical_ matter,
I can see lots of reasons for doing a pull as a separate operation.
One is disconnected operation; I may want to pull the data now, to
prepare for disconnectino, and then work later while disconnected.
Another is using lots of data compared to the pipesize; if I have a
dial-in modem, or I want the history of the linux kernel since 0.0.1,
I might want to "pull" & go away/go to sleep for the night. I might
use cron/at to automatically "pull" at 3am from some interesting branches.
The next day, I could then "pull" again to update just what changed,
and/or do the operation I intended to do if the operation auto-pulls the
missing data.

>I'm actually getting suspicious that the right thing is to hide "pull" in the id scheme. That is, instead of saying "linus" to refer to the
>"linus" head that you currently have, you say "+linus" to refer to the
>head Linus has on his server currently, and this will cause you to
>download anything necessary to perform the operation with the resulting value.
>  
>
That's an interesting idea.  I'll have to think about that.

What command would you suggest for the common case
of "update with current track?"  I've proposed "git update [NAME]".
"git merge" with update-from-current-track as default seems unclear, and
I worry that I might accidentally press RETURN too soon & merge with
the wrong thing.  And I like the idea of "git update" doing the same thing
(essentially) as "cvs update" and "svn update"; LOTS of people "know"
what update does, so using the same command name for one of the most
common operations smooths transition (GNU Arch's "tla update"
is almost, though not exactly, the same too.)

I still think it's important to have a very simple command that updates
your current branch with a tracked branch (because it's common to stay
in sync with a master branch), and a way to just download the data without
doing things with it YET (because you want to do things in stages).
The commands "update" and "pull" come to mind when thinking that way,
though as long as the commands are simple & clear that's a good thing
(I think it's a GOOD idea to use the same commands as CVS and
Subversion when the results are essentially the same, just because so many
people are already familiar with them, but only where it makes sense.)

--- David A. Wheeler

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Daniel Barkalow]

On Tue, 19 Apr 2005, David A. Wheeler wrote:

> In a _logical_ sense that's true; I'd only want to pull data if I intended
> to (possibly) do something with it.  But as a _practical_ matter,
> I can see lots of reasons for doing a pull as a separate operation.
> One is disconnected operation; (...)

That's true. I think I actually like "git pull" as the operation for "make
sure I have everything I need, so I can lose net".

> What command would you suggest for the common case
> of "update with current track?"  I've proposed "git update [NAME]".
> "git merge" with update-from-current-track as default seems unclear, and
> I worry that I might accidentally press RETURN too soon & merge with
> the wrong thing.  And I like the idea of "git update" doing the same thing
> (essentially) as "cvs update" and "svn update"; LOTS of people "know"
> what update does, so using the same command name for one of the most
> common operations smooths transition (GNU Arch's "tla update"
> is almost, though not exactly, the same too.)

I think that having "git update" update a tracked branch is best, if only as
an aid to discoverability. And "git merge" should require you to say what
you want to merge with, because it's too easy to pick a wrong default, and
the user had better know.

It seems to me like this makes "update" identical to "merge <tracked>", so
"update [NAME]" and "merge" don't make sense, since they'd do the other
command, but less intuitively.

	-Daniel
*This .sig left intentionally blank*

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Ingo Molnar]

* Petr Baudis <pasky@ucw.cz> wrote:

> > I think pull is pull.  If you are doing lots of local stuff and do not
> > want it overwritten, it should have been in a forked branch.
> 
> I disagree. This already forces you to have two branches (one to pull 
> from to get the data, mirroring the remote branch, one for your real 
> work) uselessly and needlessly.
> 
> I think there is just no good name for what pull is doing now, and 
> update seems like a great name for what pull-and-merge really is. Pull 
> really is pull - it _pulls_ the data, while update also updates the 
> given tree. No surprises.

yeah. In fact most of the times i did 'git pull pasky' in the past, the 
'merge' phase was unsuccessful, and i had to nuke the tree and recreate 
it.  All i did with the snapshots was to build them, so there were no 
local changes. Waiting a couple of days with doing a 'git pull pasky', 
or installing Linus' tree is a sure way to break the merging.

e.g. to reproduce the last such failure i had today, do:

 cd git-pasky-base
 echo 8568e1a88c086d1b72b0e84ab24fa6888b5861b9 > .git/HEAD
 read-tree $(tree-id $(cat .git/HEAD))
 checkout-cache -a -f
 make
 make install           # make sure to use the older tools
 rm -rf .git/objects
 git pull pasky

and i get:

 [...]
 fatal: unable to execute 'gitmerge-file.sh'
 fatal: merge program failed

        Conflicts during merge. Do git commit after resolving them.

note that with earlier versions of pasky, i had other merge conflicts.  
Sometimes there were .rej files, sometimes some sort of script failure.  
So it seems rather unrobust at the moment. Especially if i happen to 
install Linus' tree and try to sync the pasky tree with those tools.

another thing: it's confusing that during 'git pull', the rsync output 
is not visible. Especially during large rsyncs, it would be nice to see 
some progress. So i usually use a raw rsync not 'git pull', due to this.

yet another thing: what is the canonical 'pasky way' of simply nuking 
the current files and checking out the latest tree (according to 
.git/HEAD). Right now i'm using a script to:

  read-tree $(tree-id $(cat .git/HEAD))
  checkout-cache -a

(i first do an 'rm -f *' in the working directory)

i guess there's an existing command for this already?

	Ingo

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Petr Baudis]

Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
>  [...]
>  fatal: unable to execute 'gitmerge-file.sh'
>  fatal: merge program failed

Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of
scripts which get installed.

> another thing: it's confusing that during 'git pull', the rsync output 
> is not visible. Especially during large rsyncs, it would be nice to see 
> some progress. So i usually use a raw rsync not 'git pull', due to this.

Fixed. For further reference, you can also set RSYNC_FLAGS and put
whatever pleases you there.

> yet another thing: what is the canonical 'pasky way' of simply nuking 
> the current files and checking out the latest tree (according to 
> .git/HEAD). Right now i'm using a script to:
> 
>   read-tree $(tree-id $(cat .git/HEAD))
>   checkout-cache -a
> 
> (i first do an 'rm -f *' in the working directory)
> 
> i guess there's an existing command for this already?

git cancel

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Ingo Molnar]

* Petr Baudis <pasky@ucw.cz> wrote:

> > yet another thing: what is the canonical 'pasky way' of simply nuking 
> > the current files and checking out the latest tree (according to 
> > .git/HEAD). Right now i'm using a script to:
> > 
> >   read-tree $(tree-id $(cat .git/HEAD))
> >   checkout-cache -a
> > 
> > (i first do an 'rm -f *' in the working directory)
> > 
> > i guess there's an existing command for this already?
> 
> git cancel

hm, that's a pretty unintuitive name though. How about making it 'git 
checkout' and providing a 'git checkout -f' option to force the 
checkout? (or something like this)

	Ingo

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Ingo Molnar]

* Petr Baudis <pasky@ucw.cz> wrote:

> Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
> where Ingo Molnar <mingo@elte.hu> told me that...
> >  [...]
> >  fatal: unable to execute 'gitmerge-file.sh'
> >  fatal: merge program failed
> 
> Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of
> scripts which get installed.

another thing is this annoying message:

 rsync: link_stat "/linux/kernel/people/torvalds/git.git/tags" (in pub) 
 failed: No such file or directory (2)
 rsync error: some files could not be transferred (code 23) at 
 main.c(812)
 client: nothing to do: perhaps you need to specify some filenames or 
 the --recursive option?

you said before that it's "harmless", but it's annoying nevertheless as 
one doesnt know for sure whether the pull went fine.

	Ingo

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[Petr Baudis]

Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
> 
> * Petr Baudis <pasky@ucw.cz> wrote:
> 
> > > yet another thing: what is the canonical 'pasky way' of simply nuking 
> > > the current files and checking out the latest tree (according to 
> > > .git/HEAD). Right now i'm using a script to:
> > > 
> > >   read-tree $(tree-id $(cat .git/HEAD))
> > >   checkout-cache -a
> > > 
> > > (i first do an 'rm -f *' in the working directory)
> > > 
> > > i guess there's an existing command for this already?
> > 
> > git cancel
> 
> hm, that's a pretty unintuitive name though. How about making it 'git 
> checkout' and providing a 'git checkout -f' option to force the 
> checkout? (or something like this)

Since it does not really checkout. Ok, it does, but that's only small
part of it. It just cancels whatever local changes are you doing in the
tree and bring it to consistent state. When you have a merge in progress
and after you see the sheer number of conflicts you decide to get your
hands off, you type just git cancel. Doing basically anything with your
tree (not only local changes checkout would fix, but also various git
operations, including git add/rm and git seek) can be easily fixed by
git cancel.

Dear diary, on Wed, Apr 20, 2005 at 10:45:51PM CEST, I got a letter
where Ingo Molnar <mingo@elte.hu> told me that...
> 
> * Petr Baudis <pasky@ucw.cz> wrote:
> 
> > Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
> > where Ingo Molnar <mingo@elte.hu> told me that...
> > >  [...]
> > >  fatal: unable to execute 'gitmerge-file.sh'
> > >  fatal: merge program failed
> > 
> > Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of
> > scripts which get installed.
> 
> another thing is this annoying message:
> 
>  rsync: link_stat "/linux/kernel/people/torvalds/git.git/tags" (in pub) 
>  failed: No such file or directory (2)
>  rsync error: some files could not be transferred (code 23) at 
>  main.c(812)
>  client: nothing to do: perhaps you need to specify some filenames or 
>  the --recursive option?
> 
> you said before that it's "harmless", but it's annoying nevertheless as 
> one doesnt know for sure whether the pull went fine.

Already fixed. (Well, "fixed"... sent to /dev/null. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Change "pull" to _only_ download, and "git update"=pull+merge?

[David Mansfield]

Petr Baudis wrote:
> Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter
> where Ingo Molnar <mingo@elte.hu> told me that...
> 
>>* Petr Baudis <pasky@ucw.cz> wrote:
>>
>>
>>>>yet another thing: what is the canonical 'pasky way' of simply nuking 
>>>>the current files and checking out the latest tree (according to 
>>>>.git/HEAD). Right now i'm using a script to:
>>>>
>>>>  read-tree $(tree-id $(cat .git/HEAD))
>>>>  checkout-cache -a
>>>>
>>>>(i first do an 'rm -f *' in the working directory)
>>>>
>>>>i guess there's an existing command for this already?
>>>
>>>git cancel
>>
>>hm, that's a pretty unintuitive name though. How about making it 'git 
>>checkout' and providing a 'git checkout -f' option to force the 
>>checkout? (or something like this)
> 
> 
> Since it does not really checkout. Ok, it does, but that's only small
> part of it. It just cancels whatever local changes are you doing in the
> tree and bring it to consistent state. When you have a merge in progress
> and after you see the sheer number of conflicts you decide to get your
> hands off, you type just git cancel. Doing basically anything with your
> tree (not only local changes checkout would fix, but also various git
> operations, including git add/rm and git seek) can be easily fixed by
> git cancel.


How about 'git revert'?

Most editors and word processors use that idiom for revert to saved 
copy, with the obvious parallel here.

David

Re: Add "clone" support to lntree

[Daniel Barkalow]

On Sat, 16 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sat, Apr 16, 2005 at 03:56:03AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > I often want to take a base tree, which I keep tracking some remote head,
> > and make a local working tree that starts from it. This makes "git ln -c
> > <dest>" give you a tree that you can just start working in and then diff
> > against the head you'd started from and send off.
> > 
> > Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
> 
> I'm sorry but you are late, I added it about a hour and half ago or so.
> :-) Check git fork. (I *want* separate command than git lntree. In fact,
> I think I should make git lntree gitXlntree.sh instead, since it is
> really internal command for git-tools and the user should probably never
> need it for anything. git lntree is too lowlevel.)

Have you not pushed since? I don't see it.

I actually first made gitlntree.sh do the forking thing, because it didn't
seem useful as is, until I noticed that merge was already using it
internally.

> Actually, I don't like the name at all, though. Some people may find
> pondering about names pointless, but when I'm going to type them in
> every day for the rest of my life, they better should not be stupid. ;-)
> 
> So, what are your clever ideas about git fork's proper name? Or should
> we leave it as is?

I think "fork" is as good as anything for describing the operation. I had
thought about "clone" because it seemed to fill the role that "bk
clone" had (although I never used BK, so I'm not sure). It doesn't seem
useful to me to try cloning multiple remote repositories, since you'd get
a copy of anything common from each; you just want to suck everything into
the same .git/objects and split off working directories.

	-Daniel
*This .sig left intentionally blank*

Re: Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Sat, 16 Apr 2005, Petr Baudis wrote:
> > I'm sorry but you are late, I added it about a hour and half ago or so.
> > :-) Check git fork. (I *want* separate command than git lntree. In fact,
> > I think I should make git lntree gitXlntree.sh instead, since it is
> > really internal command for git-tools and the user should probably never
> > need it for anything. git lntree is too lowlevel.)
> 
> Have you not pushed since? I don't see it.

See my last mail. :-)

> I think "fork" is as good as anything for describing the operation. I had
> thought about "clone" because it seemed to fill the role that "bk
> clone" had (although I never used BK, so I'm not sure). It doesn't seem
> useful to me to try cloning multiple remote repositories, since you'd get
> a copy of anything common from each; you just want to suck everything into
> the same .git/objects and split off working directories.

Actually, what about if git pull outside of repository did what git
clone does now? I'd kinda like clone instead of fork too.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: Re: Add "clone" support to lntree

[Daniel Barkalow]

On Sun, 17 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sat, Apr 16, 2005 at 05:06:54AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
>
> > I think "fork" is as good as anything for describing the operation. I had
> > thought about "clone" because it seemed to fill the role that "bk
> > clone" had (although I never used BK, so I'm not sure). It doesn't seem
> > useful to me to try cloning multiple remote repositories, since you'd get
> > a copy of anything common from each; you just want to suck everything into
> > the same .git/objects and split off working directories.
> 
> Actually, what about if git pull outside of repository did what git
> clone does now? I'd kinda like clone instead of fork too.

This seems like the best solution to me, too. Although that would make
pull take a URL when making a new repository and not otherwise, which
might be confusing. "init-remote" perhaps, or maybe just have "init" do it
if given a URL?

	-Daniel
*This .sig left intentionally blank*

Re: Re: Re: Add "clone" support to lntree

[Petr Baudis]

Dear diary, on Sun, Apr 17, 2005 at 01:07:35AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > Actually, what about if git pull outside of repository did what git
> > clone does now? I'd kinda like clone instead of fork too.
> 
> This seems like the best solution to me, too. Although that would make
> pull take a URL when making a new repository and not otherwise, which
> might be confusing. "init-remote" perhaps, or maybe just have "init" do it
> if given a URL?

Yes, init taking URL optionally sounds ideal. Thanks.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor