Re: Change pull to _only_ download, and git update=pull+merge?
* Petr Baudis [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
* Petr Baudis [EMAIL PROTECTED] wrote: Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... * Petr Baudis [EMAIL PROTECTED] 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 [EMAIL PROTECTED] told me that... * Petr Baudis [EMAIL PROTECTED] wrote: Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Petr Baudis wrote: Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... * Petr Baudis [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
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 -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
Dear diary, on Tue, Apr 19, 2005 at 12:05:10PM CEST, I got a letter where Martin Schlemmer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
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/ - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part
Re: Change pull to _only_ download, and git update=pull+merge?
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* - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change pull to _only_ download, and git update=pull+merge?
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
