Re: [racket-dev] git rebase/squash my commits before submitting a pull request?
I regularly rebase and force-update pull request commits. GitHub even notices when a commit is out of date and hides the comments, if they're made there. So I encourage you to do this. Sam On Sat, Oct 19, 2013 at 10:56 PM, David T. Pierson d...@mindstory.com wrote: Thank you to everyone who provided feedback on my Guide chapter on concurrency. I think I've addressed everyone's suggestions in my latest version [1]. My question at this point is whether to rebase before submitting a pull request. If the initial commit had not been made public I would obviously want to rebase and squash. But since it was publicized here and people commented, should I leave it as is? Since this is a relatively minor patch, perhaps it doesn't matter so much for this time. But it would be good to know whether there is a general rule for when not to rebase/squash. David [1] https://github.com/davidtpierson/racket/tree/concurrency-docs _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
A report from the junior varsity squad: I just tried this on OS X and it worked AOK. FWIW I've been strictly doing `git pull --ff-only upstream master` to keep my fork's master 100% in sync with PLT's. Any experimentation or feature requests done solely on topic branches. (Like I wrote about here: http://www.greghendershott.com/2013/04/a-guide-for-infrequent-contributors-to-racket.html ) I don't yet know enough about Git submodules to understand the analog of that workflow for submodules, if any. I suspect it will be moot because I'll probably never doink around with the kind of stuff in native-pkgs. However if submodules start to get used more extensively I guess I may need to learn more about submodules. On Sat, Jul 27, 2013 at 9:10 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Nothing has been split out of the current git repository, but there is now a native-pkgs git submodule for the native-library packages. If you build on Mac OS X or Windows or if you run a snapshot build, then you'll need to use git pull git submodule init git submodule update once on each repository checkout from now on, and git pull git submodule update for updates after the first checkout. If you just `git pull' without the submodule commands, then you'll have an empty native-pkgs directory. That's fine if you're building on, say, Linux. If you're on Mac OS X or Windows, then the makefile should give you a good error message and suggest using `git submodule init' and `git submodule update'. If you use `git submodule update' today and forget to use it in the future, probably things will be fine for a long time, because native-pkgs doesn't change often. If native-pkgs does change and you forget `git submodule update', then (as I understand things) `git status' will tell you that there's a mismatch. The mismatch report might take a form that's not entirely clear, but it should be enough to remind you to run `git submodule update'. I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. I'm much more confident that a submodule will work for the native-library packages in the current build structure. The native libraries are already kept in a separate repository, they change infrequently, and almost no one has to change them. Also, the native-pkgs git submodule replaces two things that I think were just bad forms of `git submodule update': * A makefile target that fires on Mac OS X and uses `git pull', which is bad if you happen to be working offline. * A note in INSTALL.txt that tells Windows users to manually clone a particular git repository. If a git submodule does not work out for native-library packages after all, then should be easy to roll back, since there was no split to rewind. Meanwhile, we get a little experience with git submodules. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote: I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. Perhaps it would be worth considering using the git subtree feature instead of submodules for the rest of the repository (just to clarify, I'm not saying we should reconsider submodules for native-pkgs). Description here: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt In particular, this aspect seems useful for us: you can also extract the entire history of a subdirectory from your project and make it into a standalone project From what I understand (not having used them yet), subtrees also enable end users of our main repo to just do a clone without any special consideration for the subtrees. Only package maintainers would have to occasionally update the subtrees in the main repo to pull in changes from their own package repos. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
I looked into git-subtree, and as I recall it, nothing in the setup recalls what subtree is used for what. Every git-subtree command you enter has to be fully explicit, which is a big hassle. Whereas git-submodule saves its state in the repository, so it knows what it's being used for and you only need to do it once. Hopefully I misunderstood git-subtree, but if I didn't, I found its interface disappointing. Carl Eastlund On Tue, Jul 30, 2013 at 5:41 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote: I'm still unsure that submodules are going to be useful for managing a kind of main-distribution repository with references to package repositories. Perhaps it would be worth considering using the git subtree feature instead of submodules for the rest of the repository (just to clarify, I'm not saying we should reconsider submodules for native-pkgs). Description here: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt In particular, this aspect seems useful for us: you can also extract the entire history of a subdirectory from your project and make it into a standalone project From what I understand (not having used them yet), subtrees also enable end users of our main repo to just do a clone without any special consideration for the subtrees. Only package maintainers would have to occasionally update the subtrees in the main repo to pull in changes from their own package repos. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-30 17:44:37 -0400, Carl Eastlund wrote: I looked into git-subtree, and as I recall it, nothing in the setup recalls what subtree is used for what. Every git-subtree command you enter has to be fully explicit, which is a big hassle. AFAIK, you are correct. OTOH, I imagine that using subtree commands is actually going to be relatively rare. Here is my reasoning: * You are a developer on a Racket main distribution package: - Most of your commits will be local to that package while you work on it. Let's assume this is in a separate repo (otherwise the subtree thing is moot) - You'll work on a working copy of that package installed instead of the core package that ships with release Racket (using `raco pkg` to set up the links) - Assuming the last two points, you are unlikely to use any subtree commands until the changes need to be merged for a release or for wider use/testing. * You are a power user of Racket: - You'll just clone the whole Racket git repo and automatically get all of the subtrees. No additional effort necessary unless you want to make changes. * You are a developer responsible for the release: - You will probably end up pulling all subtrees (which is pretty manual work) and then cherry-pick all relevant commits. In comparison, I think submodules are supposed to make it less convenient for the power user who is just cloning the repo. That said, this isn't informed by a lot of experience with either feature, so please take with a salt mine. Maybe I will try this with Typed Racket somewhere and see what happens. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git submodule for native-library packages
On 2013-07-31 00:04:20 -0400, Asumu Takikawa wrote: Maybe I will try this with Typed Racket somewhere and see what happens. One downside I discovered immediately after trying to set this up: the subtree command is only available in git 1.7.11 and newer and it's only available if the contrib tools are packaged in your git install (it's not in Debian). I tried using the subtree command to split out the main Typed Racket package into a separate repo. The result is here: https://github.com/takikawa/typed-racket-lib One issue is that the new repo only has history going back until the package split. This makes sense, given that the old paths are nonsense in the new repo. Maybe this is ok if the main Racket repo still has the history though. Unfortunately, this experiment didn't work very well. Doing a `git subtree pull` with just one simple new commit caused a spurious merge conflict, due to the fact that the new repo's SHA1s are different. Splitting out the package will require more clever git hackery. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git head setup displays problems and warnings:
I've just pushed a fix for the runtime error at the beginning there, but I'll note that this part: raco setup: WARNING: undefined tag in teachpack/teachpack.scrbl: raco setup: (tech worldstate) raco setup: (tech s expression) raco setup: (tech package) has been on your list for more than a few weeks. Robby On Fri, Feb 15, 2013 at 9:18 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: context...: /Users/matthias/plt/collects/unstable/2d/private/lexer.rkt:31:2: 2dcond-lexer /Users/matthias/plt/collects/syntax-color/module-lexer.rkt:25:0: module-lexer /Users/matthias/plt/collects/scribble/private/manual-code.rkt:68:12: loop /Users/matthias/plt/collects/scribble/private/manual-code.rkt:68:12: loop /Users/matthias/plt/collects/scribble/private/manual-code.rkt:68:12: loop /Users/matthias/plt/collects/scribble/private/manual-code.rkt:68:12: loop /Users/matthias/plt/collects/scribble/private/manual-code.rkt:68:12: loop /Users/matthias/plt/collects/scribble/private/manual-code.rkt:55:0: typeset-code15 /Users/matthias/plt/collects/unstable/scribblings/2d.scrbl: [running body] /Users/matthias/plt/collects/unstable/scribblings/unstable.scrbl: [traversing imports] /Users/matthias/plt/collects/setup/scribble.rkt:586:0: load-doc/ensure-prefix /Users/matthias/plt/collects/setup/scribble.rkt:776:13 /Users/matthias/plt/collects/setup/parallel-do.rkt:418:20: loop raco setup: 0 running: web-server/scribblings/web-server-internal.scrbl raco setup: 1 running: web-server/scribblings/tutorial/continue.scrbl raco setup: 0 running: xml/xml.scrbl raco setup: 1 running: xrepl/xrepl.scrbl raco setup: WARNING: undefined tag in plot/scribblings/plot.scrbl: raco setup: ((lib plot/scribblings/common.rkt) sequence/c) raco setup: ((lib plot/scribblings/common.rkt) treeof) raco setup: WARNING: undefined tag in net/scribblings/net.scrbl: raco setup: ((lib unstable/contract.rkt) tcp-listen-port?) raco setup: WARNING: undefined tag in teachpack/teachpack.scrbl: raco setup: (tech worldstate) raco setup: (tech s expression) raco setup: (tech package) raco setup: WARNING: undefined tag in web-server/scribblings/web-server.scrbl: raco setup: ((lib web-server/private/util.rkt) read/bytes) raco setup: ((lib web-server/private/util.rkt) tcp-listen-port?) raco setup: ((lib web-server/private/util.rkt) write/bytes) raco setup: WARNING: undefined tag in web-server/scribblings/web-server-internal.scrbl: raco setup: ((lib unstable/contract.rkt) path-piece?) raco setup: ((lib unstable/contract.rkt) tcp-listen-port?) raco setup: ((lib web-server/private/util.rkt) path-piece?) raco setup: ((lib web-server/private/util.rkt) port-number?) _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git head problem
Sorry! I've pushed a change. On Thu, Nov 15, 2012 at 12:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: Looks like the latest git head i smissing a file: raco setup: --- installing collections --- raco setup: --- post-installing collections --- raco setup: post-installing: help raco setup: post-installing: mred raco setup: post-installing: mzcom raco setup: post-installing: mzscheme raco setup: post-installing: racket/gui raco setup: raco setup: error: during making for framework/private raco setup: default-load-handler: cannot open input file raco setup: path: /Users/robby/git/plt/collects/tests/drracket/private/drracket-test-util.rkt raco setup: system error: No such file or directory; errno=2 raco setup: context...: raco setup: standard-module-name-resolver raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:353:0: compile-zo* raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:560:26 raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:553:42 raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:518:0: maybe-compile-zo raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:631:2: do-check raco setup: /Users/matthias/plt/collects/compiler/cm.rkt:712:4 raco setup: /Users/matthias/plt/collects/setup/parallel-do.rkt:419:20: loop raco setup: make[1]: *** [install-3m] Error 1 make: *** [install] Error 2 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] git error help?
On 04/25/2011 10:32 AM, Robby Findler wrote: Anyone recognize this? (git up is git pull --ff-only --stat --all) C:\Users\Administrator\git\exp\pltgit up Fetching origin error: unable to resolve reference refs/remotes/origin/master: No error From git:plt ! [new branch] master - origin/master (unable to update local ref) error: Could not fetch origin For the future, try 'git fetch -v origin'. A pull is a fetch plus a merge, this error indicates the fetch was failing, and the verbose fetch might give more diagnostics. The following commands show the settings used by fetch. # git config remote.origin.url # git config remote.origin.fetch Maybe one of them was broken? - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] git error help?
Thanks! (I don't know why, but I'm just getting this message now.) Robby On Sun, May 1, 2011 at 2:04 AM, D Herring dherr...@tentpost.com wrote: On 04/25/2011 10:32 AM, Robby Findler wrote: Anyone recognize this? (git up is git pull --ff-only --stat --all) C:\Users\Administrator\git\exp\pltgit up Fetching origin error: unable to resolve reference refs/remotes/origin/master: No error From git:plt ! [new branch] master - origin/master (unable to update local ref) error: Could not fetch origin For the future, try 'git fetch -v origin'. A pull is a fetch plus a merge, this error indicates the fetch was failing, and the verbose fetch might give more diagnostics. The following commands show the settings used by fetch. # git config remote.origin.url # git config remote.origin.fetch Maybe one of them was broken? - Daniel _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] git error help?
Four hours ago, Robby Findler wrote: Anyone recognize this? (git up is git pull --ff-only --stat --all) C:\Users\Administrator\git\exp\pltgit up Fetching origin error: unable to resolve reference refs/remotes/origin/master: No error From git:plt ! [new branch] master - origin/master (unable to update local ref) error: Could not fetch origin Possibly an ssh problem? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] git error help?
I ended up just doing a git clone to get a new copy and that worked fine. I also was able to update some other copy I had. Mysterious. I'll just throw the tree away now. Robby On Mon, Apr 25, 2011 at 1:08 PM, Eli Barzilay e...@barzilay.org wrote: Four hours ago, Robby Findler wrote: Anyone recognize this? (git up is git pull --ff-only --stat --all) C:\Users\Administrator\git\exp\pltgit up Fetching origin error: unable to resolve reference refs/remotes/origin/master: No error From git:plt ! [new branch] master - origin/master (unable to update local ref) error: Could not fetch origin Possibly an ssh problem? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Can I do that once I've pushed to robby/plt? What happens to other machines that have unsquashed versions of those commits? Robby On Fri, Jan 7, 2011 at 9:43 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) If you commit something to your own private repository, you can then rebase relative to plt/master, and then the bogus commit won't show up (or rather, whatever the result of the rebase is will show up, which can differ arbitrarily). Once you commit to the main repository, though, history-rewriting is disallowed. Does that answer your question? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
That's what the force option for a rebasing fetch is for, to accept overwriting the history on the machine. [For example, on Matthew's gr2 branch, he would regularly do this.] Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Can I do that once I've pushed to robby/plt? What happens to other machines that have unsquashed versions of those commits? Robby On Fri, Jan 7, 2011 at 9:43 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am Jay 2011/1/7 Robby Findler ro...@eecs.northwestern.edu: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I think what I get from you and Jay is that it is possible to do, but I guess I'm not completely clear on one particular usecase how it would play out. (I understand that history rewriting is not allowed on plt/master and that makes a lot of sense, etc.) Lets say that, on my laptop I make 7 commits. Then I push this to robby/plt and pull that down on my desktop. Now I squash those 7 commits into 3 and then I make another commit (perhaps in the middle somewhere via an interactive rebase). Now I push that. Now I go back to my laptop and everything will be all messed up. Even worse, I forget if I forgot to push some changes from laptop or not. What should I do to deal with this kind of situation? Robby On Fri, Jan 7, 2011 at 9:50 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Jan 7, 2011 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) If you commit something to your own private repository, you can then rebase relative to plt/master, and then the bogus commit won't show up (or rather, whatever the result of the rebase is will show up, which can differ arbitrarily). Once you commit to the main repository, though, history-rewriting is disallowed. Does that answer your question? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Okay, I tried an example of this and I'm getting stuck. I did one commit and pushed on my laptop. On the desktop, I did another commit and then I used an interactive rebase to swap the order of the commits. Then, I did a push --force, which I think I understand and I think worked. Then, on the laptop, I did a git pull, and I ended up with the commits back in the original order and a merge commit afterwards but I would rather just have my state be like the server's was. --- As far as my other question goes, I think that perhaps the right answer is just don't forget. That is, when I go back to my laptop and I see that git status thinks that things are not up to date (ie, before doing a pull or 'git remote update'), then I should take my changes there and just plan to either kill them or put them off in a branch somewhere else, get the latest stuff from the server and then go from there. Thanks, Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: Then, on the laptop, I did a git pull, and I ended up with the commits back in the original order and a merge commit afterwards but I would rather just have my state be like the server's was. Then don't do git pull. That not only updates your remotes, but does a git merge (which will create a merge point if it's not a simple fast-forward, as you've seen here). What you want to do is update your remotes using git remote update, and then use git reset --hard to reset to the server's master (or whichever branch off of which you're working). Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 12:43 PM, Stevie Strickland wrote: On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: Then, on the laptop, I did a git pull, and I ended up with the commits back in the original order and a merge commit afterwards but I would rather just have my state be like the server's was. Then don't do git pull. That not only updates your remotes, but does a git merge (which will create a merge point if it's not a simple fast-forward, as you've seen here). What you want to do is update your remotes using git remote update, and then use git reset --hard to reset to the server's master (or whichever branch off of which you're working). At this point, though, you can still do git reset --hard to just throw away all the merging you did and reset to the server's state. So it's not like you have to go back in time or anything to fix this. In general, this is why people say you really shouldn't train yourself to do git pull automatically, because there's plenty of places where you don't want that. I always do git remote update/git merge ... separately because there's plenty of times where I don't want to merge. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 7:42 AM, Robby Findler wrote: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Taking a step back: is there really anything wrong with such commits? Given that drdr and e-mail alerts are based on pushes rather than commits, it seems not unreasonable to just let those be intermediate commits. I can see that it's a bit easier to give a nice name to a single big commit, but if the alternative is the fancy dance that this thread is suggesting, it seems like it might be simpler just to go with the simple solution (tautology alert). John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 1:39 PM, John Clements cleme...@brinckerhoff.org wrote: On Jan 7, 2011, at 7:42 AM, Robby Findler wrote: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) Taking a step back: is there really anything wrong with such commits? Given that drdr and e-mail alerts are based on pushes rather than commits, it seems not unreasonable to just let those be intermediate commits. I can see that it's a bit easier to give a nice name to a single big commit, but if the alternative is the fancy dance that this thread is suggesting, it seems like it might be simpler just to go with the simple solution (tautology alert). IIUC, avoiding merges is actually the simpler solution overall. In this particular example, the merge came about because I issued the wrong command and Stevie pointed out that getting rid of it required running the same command that I should have run to get things in the right state in the first place. More generally, running git pull (just like that, without, say --ff-only or --rebase) is, I agree with Stevie, a bad idea (because it does two things: downloads and merges). If you're doing something complex like we're talking about you want to see the two steps one at a time as it is easier to fix problems after the first step before the second. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
At Fri, 7 Jan 2011 11:39:33 -0800, John Clements wrote: Taking a step back: is there really anything wrong with such commits? Given that drdr and e-mail alerts are based on pushes rather than commits, it seems not unreasonable to just let those be intermediate commits. I can see that it's a bit easier to give a nice name to a single big commit, but if the alternative is the fancy dance that this thread is suggesting, it seems like it might be simpler just to go with the simple solution (tautology alert) git bisect is less useful if some commits are broken states. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Carl Eastlund wrote: First do a git fetch remote-name for that remote, or just git remote update which fetches from all your remotes. Then git reset --hard remote-name/master will clobber whatever you have and replace it with the remote's master branch. Note that this changes the current branch. (IOW, it can be tricky when the current branch is not `master'.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Robby Findler wrote: So I did this (git means git.racket-lang.org in my ssh setup as I did things that way before Eli's recommendation changed) git clone git:robby/plt git remote add plt git:plt It might be more convenient to flip it -- clone git:plt first, and then add a remote for git:robby/plt, so operations go to the main repo by default and to your copy only when specifically requested (which happens when you move). -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Jan 7, 2011, at 3:43 PM, Eli Barzilay wrote: Yesterday, Robby Findler wrote: So I did this (git means git.racket-lang.org in my ssh setup as I did things that way before Eli's recommendation changed) git clone git:robby/plt git remote add plt git:plt It might be more convenient to flip it -- clone git:plt first, and then add a remote for git:robby/plt, so operations go to the main repo by default and to your copy only when specifically requested (which happens when you move). Personally, I prefer the other way; that I only affect the main repo when I explicitly say so (and thus really mean it). This is especially true when I'm doing branch juggling on my own repository, so that I don't accidentally push new branches onto the main repository. It's easy to fix my repository if I screw up, but things that hit the main repository are forever (or at least, forever in its history somewhere). Then again, I tend to work with larger, longer-lived branches than most people, so YMMV. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yesterday, Carl Eastlund wrote: What you want to do is run gitk and/or git log on origin/master, which is where those 53 show up. A useful bit here -- you can pass `--all' to gitk which will make it show all branches and tags. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
5 hours ago, Robby Findler wrote: Another question: what if I commit something just for the purpose of moving to another machine and I don't want that commit to show up in the main repository? Is that possible? (My tree is currently in that state; it is one commit ahead of plt/master but that commit message is a lie-- I've just started to do that job; ordinarily I'd do git commit --amend to add more stuff to it, but now I'm worried about that.) See my git text, look for squash and fixup -- I also have a description of such checkpoint commits and how they can be squashed away before you push the final product. (And I wrote that description mainly because I had your use case in mind.) 5 hours ago, Jay McCarthy wrote: I like to do an interactive rebase and squash commits together: git rebase -i HEAD^^10 where 10 is how many commits ahead of the master I am You probably mean HEAD~10. But again, see my text -- you don't need to count commits, instead just use git rebase -i origin which will show you all of the commits you have over the origin/master branch for reorganization. 5 hours ago, Robby Findler wrote: Can I do that once I've pushed to robby/plt? What happens to other machines that have unsquashed versions of those commits? Looks like you know what to do with that now, but just to summarize: any kind of history rewriting means that people will have problems updating -- in the case of robby/plt this is easy since people is only you, and you never need to worry about combining stuff if you do it only when you move between machines. It's only when you want others to use it that you need to be careful. (For example, Matthew warning people that he's occasionally rebasing the gr2 repo.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Fri, Jan 7, 2011 at 3:00 PM, Eli Barzilay e...@barzilay.org wrote: 5 minutes ago, Stevie Strickland wrote: On Jan 7, 2011, at 3:43 PM, Eli Barzilay wrote: Yesterday, Robby Findler wrote: So I did this (git means git.racket-lang.org in my ssh setup as I did things that way before Eli's recommendation changed) git clone git:robby/plt git remote add plt git:plt It might be more convenient to flip it -- clone git:plt first, and then add a remote for git:robby/plt, so operations go to the main repo by default and to your copy only when specifically requested (which happens when you move). Personally, I prefer the other way; that I only affect the main repo when I explicitly say so (and thus really mean it). This is especially true when I'm doing branch juggling on my own repository, so that I don't accidentally push new branches onto the main repository. It's easy to fix my repository if I screw up, but things that hit the main repository are forever (or at least, forever in its history somewhere). I should have clarified: It might be more convenient for Robby to flip it This is following the same guess I have about how his working, where he only uses the private repo for machine switches. I'm trying it the way Stevie is saying because I spend ~3 hours/day (two 1.5 hour times) on the bus and I'm experimenting with switching what I've done via robby/plt to home and to work. So if I continue this way, switching will be the norm. Also, in the short term, I think this'll force me to learn git, which may or may not be a good thing. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Four hours ago, Stevie Strickland wrote: On Jan 7, 2011, at 12:29 PM, Robby Findler wrote: Then, on the laptop, I did a git pull, and I ended up with the commits back in the original order and a merge commit afterwards but I would rather just have my state be like the server's was. Then don't do git pull. That not only updates your remotes, but does a git merge (which will create a merge point if it's not a simple fast-forward, as you've seen here). What you want to do is update your remotes using git remote update, and then use git reset --hard to reset to the server's master (or whichever branch off of which you're working). Yes, a hard reset is the simplest thing to do, basically dumping everything you had on the laptop and continuing from where you were on the desktop. But... Four hours ago, Robby Findler wrote: Even worse, I forget if I forgot to push some changes from laptop or not. ...that's the dangerous part -- a hard reset will make your master branch be where the desktop was, and if you forgot to push a change from the laptop then it will be lost. Two ways to solve this: * Use a rebase of the laptop's master on top of the desktop. Usually, git can figure out changes that were already included and it will omit them, leaving you with only forgotten commits, if any. As far as my other question goes, I think that perhaps the right answer is just don't forget. * Yeah -- don't forget to push changes... IOW, just do the hard reset thing. This is practical, btw -- git maintains a reflog which logs where each branch was in the past (keeping information that goes back a month). This means that when you do the hard reset, you still have the old commit sha1 in the reflog, so if you find out that some commits are missing, you can use the reflog to see where you were, and look for the missing commits. (This is actually not as hard as it sounds.) Git does do an occasional GC over the object store, but it considers the reflog as part of the active roots, so you *are* safe for some time. That is, when I go back to my laptop and I see that git status thinks that things are not up to date (ie, before doing a pull or 'git remote update'), then I should take my changes there and just plan to either kill them or put them off in a branch somewhere else, get the latest stuff from the server and then go from there. Remember that creating a branch is *very* cheap, so you can just create a new branch to point to where the master points, then do a hard reset with the master while you have the other branch conveniently available for comparisons etc. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Four hours ago, Stevie Strickland wrote: In general, this is why people say you really shouldn't train yourself to do git pull automatically, because there's plenty of places where you don't want that. I always do git remote update/git merge ... separately because there's plenty of times where I don't want to merge. I have this alias in my ~/.gitconfig file: up = pull --ff-only --stat --all so I can run `git up' conveniently. `--ff-only' is the key here, it makes the branch you're on advance only if it's a fast-forward. Otherwise it stops after fetching and leaves you with resolving things. For people who never use branches, you can alias it to `pull --rebase' instead. (And I wrote about all of this too in the git intro text.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Two hours ago, John Clements wrote: Taking a step back: is there really anything wrong with such commits? What Robby and Vincent generalizes too -- merging can be confusing sometimes, either to the author or to the others; and there are a bunch of tools that become less useful if the history line is cluttered with merges (for example, the log graphs become much less useful). OTOH, doing a rebase means that for most users you end up doing the same amount of work (a conflict to resolve will happen either way). You could argue that these tools are the blame -- they could just ignore these merges -- but there is no proper way to know when a merge commit was really trivial (the notifications script is guessing when it is, and I had a question on this on the git list, bottom line is that you can't tell without replaying the whole thing). Bisecting is even more problematic, since it really wants a flat line to work on. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I'm surprised no one has linked this all-clarifying blog post :) http://tartley.com/?p=1267 On Fri, Jan 7, 2011 at 4:52 PM, Eli Barzilay e...@barzilay.org wrote: Two hours ago, John Clements wrote: Taking a step back: is there really anything wrong with such commits? What Robby and Vincent generalizes too -- merging can be confusing sometimes, either to the author or to the others; and there are a bunch of tools that become less useful if the history line is cluttered with merges (for example, the log graphs become much less useful). OTOH, doing a rebase means that for most users you end up doing the same amount of work (a conflict to resolve will happen either way). You could argue that these tools are the blame -- they could just ignore these merges -- but there is no proper way to know when a merge commit was really trivial (the notifications script is guessing when it is, and I had a question on this on the git list, bottom line is that you can't tell without replaying the whole thing). Bisecting is even more problematic, since it really wants a flat line to work on. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Four hours ago, Stephen Bloch wrote: On Jan 5, 2011, at 8:10 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'd like to move from one machine to another without pushing to the main repo. I know one way to do that is to use my own copy but it also seems like I should be able to just pick up those changes and scp 'em over to some other machine and apply them with git format-patch and git am. Quick note: using patches is not the same -- it means that the target repository will have it's own commit object created rather than the exact same object. Anyone do that? Does it seem advisable? (Any hints on how to do it?) Isn't the approved way to do this simply to pull from one machine to the other? Of course, you would then need to tell it to push back to the main repo, rather than where it pulled from, and I'm not sure how to do that. Decidedly NOT a git guru There's no approval involved here, since doing such things is completely invisible to the rest of the world. In any case, this *is* one option that you (Robby) can use -- you can pull stuff into a git repository from anywhere, including your own provate repositories (that is, you can list an explicit source repository to pull stuff from). You can easily try that -- get two clones of the plt repo in two different directories, then commit something in one, and do a pull from the other and specify the first as the source to pull from. The only question is how convenient the resulting workflow is for you. In your situation, my guess is that the main inconvenience will be ssh access. For example, when you switch from a laptop to a dept server, you'll want to pull changes from the laptop to your dept account -- and this requires that you ssh into the laptop from that account. For cases like this it would be more convenient to push from the laptop to the dept instead -- but git makes it difficult to do that with a non-bare repo (one that has the files checked out), because it won't change those files on the directory you're pushing into[*]. Because pushing is usually more convenient, but pushing to a working repository is bad, the usual solution is to push into a bare repository on the target account, and have another repository there for actual work. So what happens when you want to switch in the above example is: you push from the laptop to the bare repository in your dept account, then (on the dept machine) you pull from that bare repo to the working one. At this point you're implementing the same functionality that the git server provides in the form of user repositories -- so it's really better to use that. So -- is there any reason that you don't want to do that (= use a private fork of the plt repo)? If it's speed, then I can help you set up a your own bare repository. If you're worried about wasting space with such a user repository fork then you shouldn't (the `fork' command creates a clone on the server, and git uses hard links for that which means that the time and space overheads are minimal). And if you're worried about the complications, then I think that you'll find that it's easier than the other solutions (and you get the benefit of avoiding these traps). [*] Actually, if you insist enough, you can allow this, but the target repository will have its tree out of sync with the repository, which is why it's forbidden by default. It's also possible to make add hook scripts in the target repository that will re-sync files after such a push -- but this is something that can easily run into all kinds of subtle problems, which is why it's almost never done. (Look for pages that talk about deploying html content via git pushes -- it's an example of this which is popular enough to have a bunch of descriptions on the web.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Wed, 05 Jan 2011 23:14:58 -0600 Stephen Bloch sbl...@adelphi.edu wrote: On Jan 5, 2011, at 8:10 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'd like to move from one machine to another without pushing to the main repo. I know one way to do that is to use my own copy but it also seems like I should be able to just pick up those changes and scp 'em over to some other machine and apply them with git format-patch and git am. Anyone do that? Does it seem advisable? (Any hints on how to do it?) There is no main repo he mumbled, while changing the bit floating before his face to 2. IOW the graph of git repositories is non-directional. Assuming that you have your changes committed to the repository on machine A, you could run the following on B: git clone m...@a:repo-path This should get you the contents of A onto B and also configure B to use A as origin, so that a git push on B would push the changes to A. Also git pull now tracks the repo at A. To get to the main repo, you could use git remote add main m...@main-repo:repo-path and then use git pull main and git push main to access that one. From the repository's point of view, git clone is basically the same as dragging and dropping the repository's folder in some fancy clicky-pointy UI. You might still have different global settings on B than on A though, like the email address you're using to tag your commits. s. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Three minutes ago, Stefan Schmiedl wrote: Assuming that you have your changes committed to the repository on machine A, you could run the following on B: git clone m...@a:repo-path This should get you the contents of A onto B and also configure B to use A as origin, so that a git push on B would push the changes to A. Also git pull now tracks the repo at A. To get to the main repo, you could use git remote add main m...@main-repo:repo-path and then use git pull main and git push main to access that one. Actually, assuming that Robby wants to push from either place to the main repository, having the default be the local one is something that will be easy to trip over. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, 6 Jan 2011 04:43:12 -0500 Eli Barzilay e...@barzilay.org wrote: Actually, assuming that Robby wants to push from either place to the main repository, having the default be the local one is something that will be easy to trip over. I assumed the alternative, since Robby wrote: I'd like to move from one machine to another without pushing to the main repo. Assumptions are fun :-) s. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Thanks guys for the explanations. I'll study them -- I think I'm missing some (probably simple) key piece of how git works internally that would probably make this all obvious; hopefully these examples will help me figure out what that piece is(!). When I wrote main repo, of course, I meant the one where the rest of the racket dev world sees the changes, intended to be a contrast with my laptop and my desktop where I'll be pushing/pulling/cloning/whatevering between before I'm ready for the world to see. My apologies for offending your git terminology sensibilities. And yes, Eli is right that I'd like to consider moving between my machines to be the exception rather than the norm. Thanks again, Robby On Thu, Jan 6, 2011 at 5:06 AM, Stefan Schmiedl s...@xss.de wrote: On Thu, 6 Jan 2011 04:43:12 -0500 Eli Barzilay e...@barzilay.org wrote: Actually, assuming that Robby wants to push from either place to the main repository, having the default be the local one is something that will be easy to trip over. I assumed the alternative, since Robby wrote: I'd like to move from one machine to another without pushing to the main repo. Assumptions are fun :-) s. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Robby, In case this helps, I maintain a repository cce/plt separate from the regular plt one. I keep it at whatever version I last found to work with my planet packages, etc., so I only have to update at my own pace, as well as my own branches for tinkering with the trunk. That way my state is kept in a shared place, and backed up along with the rest of the PLT repositories, but nobody else has to be bothered by anything I do before I push back to the main repository. (Which, git afficionados, is only main from a pragmatic standpoint.) If you create robby/plt, you can share your work with yourself, but not trouble anyone else. Carl Eastlund On Thu, Jan 6, 2011 at 7:25 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks guys for the explanations. I'll study them -- I think I'm missing some (probably simple) key piece of how git works internally that would probably make this all obvious; hopefully these examples will help me figure out what that piece is(!). When I wrote main repo, of course, I meant the one where the rest of the racket dev world sees the changes, intended to be a contrast with my laptop and my desktop where I'll be pushing/pulling/cloning/whatevering between before I'm ready for the world to see. My apologies for offending your git terminology sensibilities. And yes, Eli is right that I'd like to consider moving between my machines to be the exception rather than the norm. Thanks again, Robby On Thu, Jan 6, 2011 at 5:06 AM, Stefan Schmiedl s...@xss.de wrote: On Thu, 6 Jan 2011 04:43:12 -0500 Eli Barzilay e...@barzilay.org wrote: Actually, assuming that Robby wants to push from either place to the main repository, having the default be the local one is something that will be easy to trip over. I assumed the alternative, since Robby wrote: I'd like to move from one machine to another without pushing to the main repo. Assumptions are fun :-) s. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 8:35 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks, Carl. I have tried that route in the past and I found that I let robby/plt get too far out of sync with the tree. So I'm looking for a workflow where, perhaps, what I do is create robby/plt only when I want to move between machines and use it as a temporary storage place (as Eli's email suggests). Does that sound workable to you? Robby You can always just leave robby/plt around, but only use it for that purpose. Even if you've left it in some odd state, at any point in time you can git push --force and it will just shove whatever you have to robby/plt and erase whatever is there. It's hard to screw up too badly, too -- anything you erase is still available for at least 30 days, and you can't push --force to the public PLT repository anyway, so it'll complain if you try. I have not had the problem you have had -- that is, my tree gets out of sync but I have no trouble rebasing -- but you work on more stuff, and more central stuff, than I usually do, so probably I've just been lucky in that regard. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 7:41 AM, Carl Eastlund c...@ccs.neu.edu wrote: On Thu, Jan 6, 2011 at 8:35 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Thanks, Carl. I have tried that route in the past and I found that I let robby/plt get too far out of sync with the tree. So I'm looking for a workflow where, perhaps, what I do is create robby/plt only when I want to move between machines and use it as a temporary storage place (as Eli's email suggests). Does that sound workable to you? Robby You can always just leave robby/plt around, but only use it for that purpose. Even if you've left it in some odd state, at any point in time you can git push --force and it will just shove whatever you have to robby/plt and erase whatever is there. It's hard to screw up too badly, too -- anything you erase is still available for at least 30 days, and you can't push --force to the public PLT repository anyway, so it'll complain if you try. So, from my laptop, I do a push --force to robby/plt and that'll clobber what is there and make it match my tree? And then if I want to pull that to some other machine, is there an equivalent 'clobber what is here and just give me what is over there' variant of pull? (I recall when Matthew was using push --force to gr2 when it was on a separate branch I sometimes had to just throw away my gr2 tree and try again.) I have not had the problem you have had -- that is, my tree gets out of sync but I have no trouble rebasing -- but you work on more stuff, and more central stuff, than I usually do, so probably I've just been lucky in that regard. I think I didn't run into that kind of trouble, if I understand correctly, I just did work with a tree that was as up to date as I was hoping it would be. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 8:45 AM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Jan 6, 2011 at 7:41 AM, Carl Eastlund c...@ccs.neu.edu wrote: You can always just leave robby/plt around, but only use it for that purpose. Even if you've left it in some odd state, at any point in time you can git push --force and it will just shove whatever you have to robby/plt and erase whatever is there. It's hard to screw up too badly, too -- anything you erase is still available for at least 30 days, and you can't push --force to the public PLT repository anyway, so it'll complain if you try. So, from my laptop, I do a push --force to robby/plt and that'll clobber what is there and make it match my tree? And then if I want to pull that to some other machine, is there an equivalent 'clobber what is here and just give me what is over there' variant of pull? (I recall when Matthew was using push --force to gr2 when it was on a separate branch I sometimes had to just throw away my gr2 tree and try again.) First do a git fetch remote-name for that remote, or just git remote update which fetches from all your remotes. Then git reset --hard remote-name/master will clobber whatever you have and replace it with the remote's master branch. I have not had the problem you have had -- that is, my tree gets out of sync but I have no trouble rebasing -- but you work on more stuff, and more central stuff, than I usually do, so probably I've just been lucky in that regard. I think I didn't run into that kind of trouble, if I understand correctly, I just did work with a tree that was as up to date as I was hoping it would be. In case you find it to be an improved workflow, here's what I do: I maintain cce/plt as a clone of plt. I work on it, on whatever branch. Whenever I feel it has gotten too far behind -- which can be daily, weekly, or whenever -- I run git remote update followed by git rebase plt/master. Nearly all of the time, this runs without complaint and puts me in a state where I have exactly the plt/master history, plus my own edits following all of that. So I can continually develop, and push to plt only when I'm all done, but I maintain a linear history (no forks-and-merges). It also minimizes the amount of clobbering I need to do. But the nice thing about git is there are so many ways to get things done, you can use whatever workflow you prefer. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 12:06 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Jan 6, 2011 at 8:00 AM, Carl Eastlund c...@ccs.neu.edu wrote: In case you find it to be an improved workflow, here's what I do: I maintain cce/plt as a clone of plt. I work on it, on whatever branch. Whenever I feel it has gotten too far behind -- which can be daily, weekly, or whenever -- I run git remote update followed by git rebase plt/master. Nearly all of the time, this runs without complaint and puts me in a state where I have exactly the plt/master history, plus my own edits following all of that. So I can continually develop, and push to plt only when I'm all done, but I maintain a linear history (no forks-and-merges). It also minimizes the amount of clobbering I need to do. Thanks! I'm giving this a try. I created robby/plt and then cloned it. Turns out that robby/plt was an old old copy of the main thingy (which I no longer know how to refer to). So I did this (git means git.racket-lang.org in my ssh setup as I did things that way before Eli's recommendation changed) git clone git:robby/plt git remote add plt git:plt and then git remote -v produced this: origin git:robby/plt (fetch) origin git:robby/plt (push) plt git:plt (fetch) plt git:plt (push) which seems like the right thing. So I did git remote update git rebase -v plt/master and I got lots and lots of messages about files changing which ended like this: delete mode 100644 src/wxxt/utils/image/src/wx_imgx.h delete mode 100644 src/wxxt/utils/image/src/wx_pbm.cc delete mode 100644 src/wxxt/utils/image/src/wx_pcx.cc delete mode 100644 src/wxxt/utils/image/src/wx_pm.cc delete mode 100644 src/wxxt/utils/image/src/wx_xbm.cc Nothing to do. and now I have this: % git status # On branch master # Your branch and 'origin/master' have diverged, # and have 2885 and 53 different commit(s) each, respectively. # nothing to commit (working directory clean) And now I'm a little bit worried. I'd have expected that I would get a message indicating that I was just straight ahead of origin/master instead of diverging from it. Does this mean that my robby/plt thing was not really from a point in the direct past of my plt/master? Any advice on what I should do now? It looks like you had 53 commits that were pushed to plt/master in a slightly modified form -- probably you had them locally, rebased a few commits from plt/master, then pushed them, and robby/plt never got updated to reflect the rebase. The Nothing to do indicates those diffs are reflected in plt/master, so you probably don't need to worry about them. If you have gitk or gitg you can run them to check if master is the same revision as plt/master, or you can run git log plt/master..HEAD to see if you have any lingering commits. But I think you don't. In any event, you can resync robby/plt to what you currently have by running: git push --force From there you'll be ready to do whatever you need to do. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 11:22 AM, Carl Eastlund c...@ccs.neu.edu wrote: It looks like you had 53 commits that were pushed to plt/master in a slightly modified form -- probably you had them locally, rebased a few commits from plt/master, then pushed them, and robby/plt never got updated to reflect the rebase. The Nothing to do indicates those diffs are reflected in plt/master, so you probably don't need to worry about them. If you have gitk or gitg you can run them to check if master is the same revision as plt/master, or you can run git log plt/master..HEAD to see if you have any lingering commits. But I think you don't. In any event, you can resync robby/plt to what you currently have by running: git log plt/master..HEAD didn't print anything out. But I'm not quite understanding what this 53 message is saying to me and I'd like to try. I've opened gitk and I see that there was this commit: commit 69963a1f2c50c902a174af45b96aa21d2d79a6d6 Author: Mike Sperber sper...@deinprogramm.de Date: Thu Jan 6 13:53:51 2011 +0100 Fix bug in struct-wrap signature checking. Only check the fields if we know the struct type is right. that is off on its own side path. Ie my graph looks like this: o improve canvas drawing docs | o Merge remote branch origin (committer Sperber) /| / | | o | | | 73 commits (why 73?!) | | | o like f57b431c2e6466c (missed other case) * | \ | \| o New Racket version 5.0.99.6 where the * is the commit mentioned above. git push --force I assume that even with the information above, this is still sounding like the right thing? ... and now I've opened gitk in another, regular copy of the plt tree and I see the exact same graph. So I've re-read that first paragraph you wrote and I'm sure it contains the answer I seek, but I don't yet understand it. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 12:25 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Thu, Jan 6, 2011 at 12:37 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Jan 6, 2011 at 11:22 AM, Carl Eastlund c...@ccs.neu.edu wrote: It looks like you had 53 commits that were pushed to plt/master in a slightly modified form -- probably you had them locally, rebased a few commits from plt/master, then pushed them, and robby/plt never got updated to reflect the rebase. The Nothing to do indicates those diffs are reflected in plt/master, so you probably don't need to worry about them. If you have gitk or gitg you can run them to check if master is the same revision as plt/master, or you can run git log plt/master..HEAD to see if you have any lingering commits. But I think you don't. In any event, you can resync robby/plt to what you currently have by running: git log plt/master..HEAD didn't print anything out. But I'm not quite understanding what this 53 message is saying to me and I'd like to try. What you want to do is run gitk and/or git log on origin/master, which is where those 53 show up. All you've run it on, I believe, is master, which is now a clone of plt/master, where those 53 commits have already been folded in to the rest of the history. Ah. That actually makes sense! I feel a sense of progress. Thanks. :) If your goal is to figure out this git stuff, I'm happy to keep answering questions. If your goal is, more immediately, to figure out if you need those 53 commits, open up read permissions to robby/plt and I (or someone) more familiar with the commands can check it out real quick. How do I do that? I think I'd like to do that on general principle in case it is useful down the road. FWIW, I did a git push --force, so I'm not sure if I know how to get back there or not. And yes, my goal was to understand more of git, but I'm becoming increasingly convinced that this particular question is probably a waste of time. I'm sure I'll be back in touch when I finish the change I'm working on --- but hopefully just to thank you for giving me the tools to figure out how to get my changes into the main tree Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 1:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: If your goal is to figure out this git stuff, I'm happy to keep answering questions. If your goal is, more immediately, to figure out if you need those 53 commits, open up read permissions to robby/plt and I (or someone) more familiar with the commands can check it out real quick. How do I do that? I think I'd like to do that on general principle in case it is useful down the road. Run ssh git help; it will explain the various commands available to you, including setperms and getperms. FWIW, I did a git push --force, so I'm not sure if I know how to get back there or not. Okay. Moving on, then. And yes, my goal was to understand more of git, but I'm becoming increasingly convinced that this particular question is probably a waste of time. I'm sure I'll be back in touch when I finish the change I'm working on --- but hopefully just to thank you for giving me the tools to figure out how to get my changes into the main tree I await further questions or commit notifications. :) --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
On Thu, Jan 6, 2011 at 12:34 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Thu, Jan 6, 2011 at 1:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: If your goal is to figure out this git stuff, I'm happy to keep answering questions. If your goal is, more immediately, to figure out if you need those 53 commits, open up read permissions to robby/plt and I (or someone) more familiar with the commands can check it out real quick. How do I do that? I think I'd like to do that on general principle in case it is useful down the road. Run ssh git help; it will explain the various commands available to you, including setperms and getperms. Is there docs on what valid lines are somewhere? I'd love to give all the people that have access to the main plt repo access to this one too, or any thing remotely similar to that. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Yep, Eli's git overview had the answer, I think. I did RW @all. Robby On Thu, Jan 6, 2011 at 12:50 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Thu, Jan 6, 2011 at 1:44 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Jan 6, 2011 at 12:34 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Thu, Jan 6, 2011 at 1:29 PM, Robby Findler ro...@eecs.northwestern.edu wrote: If your goal is to figure out this git stuff, I'm happy to keep answering questions. If your goal is, more immediately, to figure out if you need those 53 commits, open up read permissions to robby/plt and I (or someone) more familiar with the commands can check it out real quick. How do I do that? I think I'd like to do that on general principle in case it is useful down the road. Run ssh git help; it will explain the various commands available to you, including setperms and getperms. Is there docs on what valid lines are somewhere? I'd love to give all the people that have access to the main plt repo access to this one too, or any thing remotely similar to that. I don't know off the top of my head. I generally just try things and see, since it's easy to just set them back. I would try * as the everyone wildcard; beyond that, Eli is the one to ask, or maybe he already has documentation somewhere. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
It's so reassuring to know that I'm not the only one floundering with git :-) Stephen Bloch sbl...@adelphi.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
Thanks, Carl! I think I got it! My main missing piece was understanding what remotes tags really are and your messages plus a brush up on the git-for-people-who-are-not-afraid-of-dags made all the difference in the world. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
+1 The learning curve isn't great, but the more I learn about git the more I like it. N. On Wed, Jan 5, 2011 at 8:25 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Me too! Git is great now. Jay 2011/1/5 Carl Eastlund c...@ccs.neu.edu: Thanks to everyone whose efforts and patience helped us switch from Subversion to Git. There was a steep learning curve, but now that I'm familiar with git, its flexibility has been quite handy. It has been invaluable for collaborating with the rest of you on the PLT git repository, with a few remaining uses of the legacy svn repository, and even with myself when switching computers, working on an airplane, etc. It has even proved useful for collaboration with others who do not use version control -- if I get code via an emailed tarball, I can just jump back to wherever those edits started from, commit them, and rebase my changes to go from there, so my history doesn't get out of sync with anyone else's. Thanks again! Carl Eastlund _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Git
I too am quite happy we've switched. Thanks all. And Matthew, not too long ago, showed me git rebase -i origin which, combined with git commit --amend has really helped out my workflow. So.. I have a question. I'd like to move from one machine to another without pushing to the main repo. I know one way to do that is to use my own copy but it also seems like I should be able to just pick up those changes and scp 'em over to some other machine and apply them with git format-patch and git am. Anyone do that? Does it seem advisable? (Any hints on how to do it?) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
