You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(10) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Ross S. <ros...@ny...> - 2008-07-29 23:10:34
|
Sigh... scratch that. It's actually at: http://linserv3.cims.nyu.edu:11000/cru/Javagit-10 On Jul 29, 2008, at 6:20 PM, Ross Snyder wrote: > Wooo - I'm back in Crucible. Can I get some feedback on my stuff > here? > > http://linserv3.cims.nyu.edu:11000/cru/Javagit-9 > > On Jul 29, 2008, at 1:34 AM, Ross Snyder wrote: > >> I just checked in my JavaGitConfiguration stuff I've been working >> on for a little while. I'd appreciate some feedback - but I can't >> create a code review for it at the moment (see my previous e-mail >> about being locked out of Crucible). It's r549, in the branch >> branches/reviews/rs2705/2. As soon as I can get back into >> Crucible, I'll create a real code review. >> >> The JavaGitConfiguration class is all-static as of now, so it >> exists globally and can be accessed from anywhere. Is that cool? >> When you attempt to set the path, it tries to run a git --version >> command to check the path's validity. >> >> I put the parser and response objects for the git --version call >> inline, since they're only used for this one specific purpose in >> JavaGitConfiguration. Is that kosher, or would you recommend I >> move them outside of the class? >> >> Once I get some feedback and everyone signs off on it, I'll go >> through the code and hook up >> JavaGitConfiguration.getGitCommandPrefix() anywhere we run git. (I >> looked at Google Guice, but in the interest of not introducing 3rd- >> party library dependencies, I'm willing to do it the old-fashioned >> way - by hand). > > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Javagit-codereview mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/javagit-codereview |
From: Ross S. <ros...@ny...> - 2008-07-29 22:21:31
|
Wooo - I'm back in Crucible. Can I get some feedback on my stuff here? http://linserv3.cims.nyu.edu:11000/cru/Javagit-9 On Jul 29, 2008, at 1:34 AM, Ross Snyder wrote: > I just checked in my JavaGitConfiguration stuff I've been working > on for a little while. I'd appreciate some feedback - but I can't > create a code review for it at the moment (see my previous e-mail > about being locked out of Crucible). It's r549, in the branch > branches/reviews/rs2705/2. As soon as I can get back into > Crucible, I'll create a real code review. > > The JavaGitConfiguration class is all-static as of now, so it > exists globally and can be accessed from anywhere. Is that cool? > When you attempt to set the path, it tries to run a git --version > command to check the path's validity. > > I put the parser and response objects for the git --version call > inline, since they're only used for this one specific purpose in > JavaGitConfiguration. Is that kosher, or would you recommend I > move them outside of the class? > > Once I get some feedback and everyone signs off on it, I'll go > through the code and hook up > JavaGitConfiguration.getGitCommandPrefix() anywhere we run git. (I > looked at Google Guice, but in the interest of not introducing 3rd- > party library dependencies, I'm willing to do it the old-fashioned > way - by hand). |
From: Ross S. <ros...@ny...> - 2008-07-29 05:35:56
|
I just checked in my JavaGitConfiguration stuff I've been working on for a little while. I'd appreciate some feedback - but I can't create a code review for it at the moment (see my previous e-mail about being locked out of Crucible). It's r549, in the branch branches/reviews/rs2705/2. As soon as I can get back into Crucible, I'll create a real code review. The JavaGitConfiguration class is all-static as of now, so it exists globally and can be accessed from anywhere. Is that cool? When you attempt to set the path, it tries to run a git --version command to check the path's validity. I put the parser and response objects for the git --version call inline, since they're only used for this one specific purpose in JavaGitConfiguration. Is that kosher, or would you recommend I move them outside of the class? Once I get some feedback and everyone signs off on it, I'll go through the code and hook up JavaGitConfiguration.getGitCommandPrefix () anywhere we run git. (I looked at Google Guice, but in the interest of not introducing 3rd-party library dependencies, I'm willing to do it the old-fashioned way - by hand). |
From: Gurdeep D. <gs...@ny...> - 2008-07-20 16:57:17
|
I believe I should have sent the below mail to code-review mailing list. (re-sending) On Jul 20, 2008, at 1:35 AM, Gurdeep Dhindsa wrote: > > Hi > > I have closed the review javagit-2 ( Initial checkin for git- > checkout ) and opened a new review after making all the suggested > changes and additional re-factoring done for git-checkout. > Some of the changes include - > > 1. All the references to Files have been moved from String > implementation to File implementation. > 2. All references to branch changed from String type to Ref type. > 3. Added api methods to 'checkout' in GitCheckout and IGitCheckout. > 4. Added more test_cases but there is scope for doing a lot much more. > > thanks > Gurdeep |
From: Michael S. <mic...@cs...> - 2008-07-17 16:03:43
|
ah, ok. On Thu, Jul 17, 2008 at 11:54 AM, Ross Snyder <ros...@ny...> wrote: > Just svn - I know we discussed switching over, but I haven't made the leap > yet. > > On Jul 17, 2008, at 11:49 AM, Michael Schidlowsky wrote: > >> Just to clarify, are you using git-svn or just svn? >> >> -Michael >> >> >> On Thu, Jul 17, 2008 at 11:11 AM, Ross Snyder <ros...@ny...> wrote: >>> >>> On Jul 17, 2008, at 10:56 AM, Michael Schidlowsky wrote: >>> >>>> On Thu, Jul 17, 2008 at 3:24 AM, Ross Snyder <ros...@ny...> >>>> wrote: >>>>> >>>>> Hey gang, I made those changes related to how we create GitFile/ >>>>> GitDirectory objects. It's in review here: >>>>> >>>>> http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 >>>>> >>>>> Please throw me some feedback. James - I haven't finished yours that >>>>> I started Tuesday - will do so tomorrow, but if you'd like to just >>>>> close it out and keep moving, that's a-okay by me. >>>>> >>>>> Please note that I still haven't mastered the art of checking in just >>>>> my stuff (I merged trunk into my code review branch, which had grown >>>>> stale, and when I checked it all in, I got some of Max's changes in >>>>> my commit too). What should I have done in this case? >>>>> >>>>> -- I made a new branch on Monday >>>>> -- I made my changes today >>>>> -- A bunch of changes were made between Monday and now to trunk >>>>> -- I merged head of trunk into my code review branch, which already >>>>> had my changes >>>>> -- I resolved a bunch of conflicts >>>>> -- I committed the final product >>>>> >>>>> Without something like a git-stash, how do I merge the updated trunk >>>>> stuff into my branch and commit it in a separate commit without >>>>> losing the work I've already done in my branch? >>>> >>>> There's no easy answer to merging code into a stale client that has >>>> lots of your own changes in it. Even git-stash wouldn't help you. At >>>> some point someone has to reconcile the set of changes you're making >>>> with the set of changes made on the repository. That having been >>>> said, if you merged properly you shouldn't have lost any of your local >>>> work. >>> >>> I was thinking git stash would've allowed me to: >>> >>> - stash away my current changes >>> - merge trunk into my branch >>> - commit >>> - un-stash my changes, resolve conflicts >>> - commit >>> >>> Would that work? That way, at least the 2nd commit would be solely my I'm not sure what problems you ran into... normally if you make changes locally, then bring in changes that someone else made, and then do a commit, the commit should only include your new changes and not re-include the changes that you pulled down from the server. I think we'd have to look at a specific example to work through the problem you had. If you can put together an example with some real code that we can try it might be useful. Also, don't forget the command svn status -u (that will show you the svn status including new changes on the server). -Michael >>> stuff. As it stands, some of the changed lines in my code review are >>> actually changes other people made to trunk. >>> >>> > > |
From: Ross S. <ros...@ny...> - 2008-07-17 15:55:32
|
Just svn - I know we discussed switching over, but I haven't made the leap yet. On Jul 17, 2008, at 11:49 AM, Michael Schidlowsky wrote: > Just to clarify, are you using git-svn or just svn? > > -Michael > > > On Thu, Jul 17, 2008 at 11:11 AM, Ross Snyder <ros...@ny...> > wrote: >> On Jul 17, 2008, at 10:56 AM, Michael Schidlowsky wrote: >> >>> On Thu, Jul 17, 2008 at 3:24 AM, Ross Snyder >>> <ros...@ny...> wrote: >>>> >>>> Hey gang, I made those changes related to how we create GitFile/ >>>> GitDirectory objects. It's in review here: >>>> >>>> http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 >>>> >>>> Please throw me some feedback. James - I haven't finished yours >>>> that >>>> I started Tuesday - will do so tomorrow, but if you'd like to just >>>> close it out and keep moving, that's a-okay by me. >>>> >>>> Please note that I still haven't mastered the art of checking in >>>> just >>>> my stuff (I merged trunk into my code review branch, which had >>>> grown >>>> stale, and when I checked it all in, I got some of Max's changes in >>>> my commit too). What should I have done in this case? >>>> >>>> -- I made a new branch on Monday >>>> -- I made my changes today >>>> -- A bunch of changes were made between Monday and now to trunk >>>> -- I merged head of trunk into my code review branch, which already >>>> had my changes >>>> -- I resolved a bunch of conflicts >>>> -- I committed the final product >>>> >>>> Without something like a git-stash, how do I merge the updated >>>> trunk >>>> stuff into my branch and commit it in a separate commit without >>>> losing the work I've already done in my branch? >>> >>> There's no easy answer to merging code into a stale client that has >>> lots of your own changes in it. Even git-stash wouldn't help >>> you. At >>> some point someone has to reconcile the set of changes you're making >>> with the set of changes made on the repository. That having been >>> said, if you merged properly you shouldn't have lost any of your >>> local >>> work. >> >> I was thinking git stash would've allowed me to: >> >> - stash away my current changes >> - merge trunk into my branch >> - commit >> - un-stash my changes, resolve conflicts >> - commit >> >> Would that work? That way, at least the 2nd commit would be >> solely my >> stuff. As it stands, some of the changed lines in my code review are >> actually changes other people made to trunk. >> >> |
From: Michael S. <mic...@cs...> - 2008-07-17 15:49:33
|
Just to clarify, are you using git-svn or just svn? -Michael On Thu, Jul 17, 2008 at 11:11 AM, Ross Snyder <ros...@ny...> wrote: > On Jul 17, 2008, at 10:56 AM, Michael Schidlowsky wrote: > >> On Thu, Jul 17, 2008 at 3:24 AM, Ross Snyder <ros...@ny...> wrote: >>> >>> Hey gang, I made those changes related to how we create GitFile/ >>> GitDirectory objects. It's in review here: >>> >>> http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 >>> >>> Please throw me some feedback. James - I haven't finished yours that >>> I started Tuesday - will do so tomorrow, but if you'd like to just >>> close it out and keep moving, that's a-okay by me. >>> >>> Please note that I still haven't mastered the art of checking in just >>> my stuff (I merged trunk into my code review branch, which had grown >>> stale, and when I checked it all in, I got some of Max's changes in >>> my commit too). What should I have done in this case? >>> >>> -- I made a new branch on Monday >>> -- I made my changes today >>> -- A bunch of changes were made between Monday and now to trunk >>> -- I merged head of trunk into my code review branch, which already >>> had my changes >>> -- I resolved a bunch of conflicts >>> -- I committed the final product >>> >>> Without something like a git-stash, how do I merge the updated trunk >>> stuff into my branch and commit it in a separate commit without >>> losing the work I've already done in my branch? >> >> There's no easy answer to merging code into a stale client that has >> lots of your own changes in it. Even git-stash wouldn't help you. At >> some point someone has to reconcile the set of changes you're making >> with the set of changes made on the repository. That having been >> said, if you merged properly you shouldn't have lost any of your local >> work. > > I was thinking git stash would've allowed me to: > > - stash away my current changes > - merge trunk into my branch > - commit > - un-stash my changes, resolve conflicts > - commit > > Would that work? That way, at least the 2nd commit would be solely my > stuff. As it stands, some of the changed lines in my code review are > actually changes other people made to trunk. > > |
From: Ross S. <ros...@ny...> - 2008-07-17 15:13:05
|
On Jul 17, 2008, at 10:56 AM, Michael Schidlowsky wrote: > On Thu, Jul 17, 2008 at 3:24 AM, Ross Snyder <ros...@ny...> > wrote: >> Hey gang, I made those changes related to how we create GitFile/ >> GitDirectory objects. It's in review here: >> >> http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 >> >> Please throw me some feedback. James - I haven't finished yours that >> I started Tuesday - will do so tomorrow, but if you'd like to just >> close it out and keep moving, that's a-okay by me. >> >> Please note that I still haven't mastered the art of checking in just >> my stuff (I merged trunk into my code review branch, which had grown >> stale, and when I checked it all in, I got some of Max's changes in >> my commit too). What should I have done in this case? >> >> -- I made a new branch on Monday >> -- I made my changes today >> -- A bunch of changes were made between Monday and now to trunk >> -- I merged head of trunk into my code review branch, which already >> had my changes >> -- I resolved a bunch of conflicts >> -- I committed the final product >> >> Without something like a git-stash, how do I merge the updated trunk >> stuff into my branch and commit it in a separate commit without >> losing the work I've already done in my branch? > > There's no easy answer to merging code into a stale client that has > lots of your own changes in it. Even git-stash wouldn't help you. At > some point someone has to reconcile the set of changes you're making > with the set of changes made on the repository. That having been > said, if you merged properly you shouldn't have lost any of your local > work. I was thinking git stash would've allowed me to: - stash away my current changes - merge trunk into my branch - commit - un-stash my changes, resolve conflicts - commit Would that work? That way, at least the 2nd commit would be solely my stuff. As it stands, some of the changed lines in my code review are actually changes other people made to trunk. |
From: Michael S. <mic...@cs...> - 2008-07-17 14:56:03
|
On Thu, Jul 17, 2008 at 3:24 AM, Ross Snyder <ros...@ny...> wrote: > Hey gang, I made those changes related to how we create GitFile/ > GitDirectory objects. It's in review here: > > http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 > > Please throw me some feedback. James - I haven't finished yours that > I started Tuesday - will do so tomorrow, but if you'd like to just > close it out and keep moving, that's a-okay by me. > > Please note that I still haven't mastered the art of checking in just > my stuff (I merged trunk into my code review branch, which had grown > stale, and when I checked it all in, I got some of Max's changes in > my commit too). What should I have done in this case? > > -- I made a new branch on Monday > -- I made my changes today > -- A bunch of changes were made between Monday and now to trunk > -- I merged head of trunk into my code review branch, which already > had my changes > -- I resolved a bunch of conflicts > -- I committed the final product > > Without something like a git-stash, how do I merge the updated trunk > stuff into my branch and commit it in a separate commit without > losing the work I've already done in my branch? There's no easy answer to merging code into a stale client that has lots of your own changes in it. Even git-stash wouldn't help you. At some point someone has to reconcile the set of changes you're making with the set of changes made on the repository. That having been said, if you merged properly you shouldn't have lost any of your local work. -Michael > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Javagit-codereview mailing list > Jav...@li... > https://lists.sourceforge.net/lists/listinfo/javagit-codereview > > |
From: Ross S. <ros...@ny...> - 2008-07-17 07:25:38
|
Hey gang, I made those changes related to how we create GitFile/ GitDirectory objects. It's in review here: http://linserv3.cims.nyu.edu:11000/cru/Javagit-4 Please throw me some feedback. James - I haven't finished yours that I started Tuesday - will do so tomorrow, but if you'd like to just close it out and keep moving, that's a-okay by me. Please note that I still haven't mastered the art of checking in just my stuff (I merged trunk into my code review branch, which had grown stale, and when I checked it all in, I got some of Max's changes in my commit too). What should I have done in this case? -- I made a new branch on Monday -- I made my changes today -- A bunch of changes were made between Monday and now to trunk -- I merged head of trunk into my code review branch, which already had my changes -- I resolved a bunch of conflicts -- I committed the final product Without something like a git-stash, how do I merge the updated trunk stuff into my branch and commit it in a separate commit without losing the work I've already done in my branch? |