Subject: EGIT: problems using eclipse project below root of working tree - msg#02563

Previous Message by Date: click to view message preview

Re: Trying to sync two svn repositories with git-svn (repost)

On Wed, Apr 29, 2009 at 12:01 PM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > On Tue, Apr 28, 2009 at 11:19:51PM -0400, Avery Pennarun wrote: >> Okay, I think I'm following you.  And I think the difficulty of your >> solution will depend on how important it is to cherry-pick each >> individual commit from each repo vs. just merging everything as a >> batch. > > I've already done the cherry-picking. So you're saying that from now on, *all* changes from *both* branches need to be integrated in both directions? If so, you're done with cherry-picking. If not, you're not. >  Basically, I've done this: > >  # first, move patches from second-svn to first-svn >  git checkout first-svn >  git svn rebase >  git cherry-pick sha1 # repeat as needed >  git merge -s ours second-svn > >  # Now, the other way around >  git checkout second-svn >  git svn rebase >  git cherry-pick sha1 # repeat as needed >  git merge -s ours first-svn > > The first git-svn-rebase after the merge causes all the (already picked) > commits from the other branch to be pulled into the current branch. > Adding the --no-ff option does not help.  Omitting the cherry-picking > does not help, either. Hmm, I don't see any 'git svn dcommit' in there. The steps I listed referred to dcommit, but explicitly left out calls to 'git svn rebase'. I think it's likely that your problems stem from this. The git svn documentation refers to the 'git svn rebase' operation a lot, but it's only really useful for one thing: linearizing history to make it look (to svn) like git was never involved. This is handy for people who want to use git at work without their boss knowing about it, but it *loses information* and will mess up future merges. In general, 'git svn rebase' should be avoided for all the same reasons that 'git rebase' should be avoided. They're both great when used carefully, but they shouldn't be your main day-to-day activity. Unfortunately git svn encourages you to use rebase in your day-to-day activity... but the workflow I'm talking about actually avoids this problem completely. What you want most of the time is really just 'git svn fetch'. and 'git svn dcommit'. I think I was also a bit too offhand in my previous email when expanding my suggestion to work with multiple svn hosts. The clearest way to do this is with three branches: - 1 remote branch: git-svn-1 - 1 remote branch: git-svn-2 - 1 local branch: master So the steps are something like this. (Again, WARNING: I'm not running these as I type them, so I could be screwing up just about anything.) Getting started: git checkout master ... Use 'git svn fetch' to update git-svn-1 and git-svn-2 ... ... git merge/cherry-pick what you want from git-svn-1 and git-svn-2. ALWAYS use --no-ff if using git merge git merge --no-ff -s ours git-svn-1 git merge --no-ff -s ours git-svn-2 # now master has everything from both svn repositories >From now on: # Update git-svn-1 with the latest master git checkout git-svn-1 # since git-svn-1 is a remote branch, you now have a detached HEAD git merge --no-ff master git svn dcommit # Update git-svn-2 with the latest master git checkout git-svn-2 # since git-svn-2 is a remote branch, you now have a *different* detached HEAD git merge --no-ff master git svn dcommit # Update master with the latest svn git checkout master # HEAD is now attached to master git merge --no-ff git-svn-1 git merge --no-ff git-svn-2 # no need for '-s ours' in the above merge, as no rebasing means no merge history was lost >> At Versabanq, we're using git for a bunch of stuff including our >> autobuilder (http://github.com/apenwarr/gitbuilder) and my own > > Interesting project.  One question: the README mentions that the > gitbuilder as capable to update itself.  But I can not actually see > this functionality in the scripts.  Is that just a typo or am I missing > something? I guess you're reading the line that says, "Now that your gitbuilder is working, you probably want to have it continue to update itself automatically." This is actually talking about *running* itself automatically, as in "upating the build results to the latest copy of your project." I can see how it's a very unclear word to use there. Thanks for the feedback. >> As long as you "git config merge.summary true" (to make the merge >> commit list all the commits it's merging) > > How does this option influence the merge operation?  Or is this meant > to provide additional information to the person who does the next merge? When you *merge* (as opposed to rebase or cherry-pick) into an svn branch, you only create a *single* svn commit that contains *all* the changes. The above config setting just makes the merge commit contain a list of all the commits it contains. >> Now, your problem is a little more complex, because it sounds like >> people are checking in two types of things on both sides: private >> things and public things.  So if you want *only* the private things, > > I want both.  The difference is that I (usually) want to pull the public > things unmodified, while I want to generalize/localize the private things. > So when merging the private part, I would not want to pick the specific > entries.  But I still want to pick the _structure_ (possibly removing or > modifying the localized entries). If you're going to be mangling things so thoroughly, then you might just have to resort to cherry-picking everything one by one from one branch to the other. It doesn't sound very fun, but if other people are being so uncooperative by mixing public and private stuff in their repositories, there's no way I can see to automate it anyhow. If you're using cherry-pick for everything, there's no reason to use tricks like 'merge -s ours'. Just leave out the merging entirely and don't pretend that what you're doing is merging; it isn't. (You still don't need 'git svn rebase' for anything. Just checkout the branch you want to change, cherry-pick stuff into it, and 'git svn dcommit' if appropriate.) If the situation ever changes, you can always do one last 'merge -s ours' and mark the histories as combined. Then future merges will bring in any future changes. Good luck. Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Date: click to view message preview

Re: (topgit question) deleting a dependency

Hello, > >> This is a little beyond my comprehension :( However, this > >> is also why I am limiting myself to > >> > >> - a single level of dependencies in tg, (master --> > >> multiple t/something --> t/all), and > >> > >> - no changes of its own in t/all > >> > >> When any of the t/something graduates to master, t/all will > >> be blown away (safe, since it has no changes of its own) and > > > What makes you think it will "be blown away"? Or alternatively, what do > > My mistake. I meant that I will blow it away myself, and > create a new one with the same name except it's list of deps > will exclude the one that graduated. > > > you mean saying that? I often use the same approach and I never had the > > feeling anything is blown away. If upstream uses your t/something patch > > it just merges into t/something making it empty without changing the > > How? When I update master from upstream and then tg update > on t/all? yes. I think it's even save to just remove empty dependencies (and add the dependencies of the patch branch to be deleted) from .topdeps. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous Message by Thread: click to view message preview

Question on merge and mergetool settings

In my config files which I inherited from someone else, there is an entry for "url" as well as for "path" under [merge] et al. I can't find that mentioned in the git-config manual. Is that really used? --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Thread: click to view message preview

Re: EGIT: problems using eclipse project below root of working tree

onsdag 29 april 2009 20:28:22 skrev John Bito <jwbito@xxxxxxxxx>: > My Java project is part of a larger repository, so the Eclipse project > I'm opening is rooted one level below the directory containing .git/. > > When I open only the subproject (the root project shows as closed in > the project explorer), all the members of the working directory of the > subproject show in the Project Explorer as if they were untracked > files (query icon). If I open the subproject after opening the root > project, the members correctly appear as committed (can icon). > Opening the root project after opening the subproject seems to produce > an error in references to jars in the subproject - not obviously > related to EGIT. > > If the root project is open, changes made in the subproject are listed > twice in the Commit dialog (once prefixed by root-project-name: and > once prefixed by subproject-name:). If the root project is closed, > the Commit dialog lists the changes once (prefixed by > subproject-name). > > I think the commit dialog gives me the correct status, but I'd have > more confidence if the icons in the Project Explorer were consistent. > I don't want to work with the root project open because it's MUCH > bigger than the Java code I'm working on and Eclipse seems faster with > only the subproject open. I'm also concerned that if I let it commit > with both the root and subproject instances of the changes checked, > I'll cause a problem that'll take some time to unwind (not interested > in experimenting with that at the moment). > > Should I add this as a bug? We had such a bug, fixed in february, I think, but we now have projects at this and and other levels. If you are talking 1) nested repos or 2) nested projects, then 1) Egit doesn't work well with them and 2) Eclipse doesn't work well with them. We have been fiddling around recently with bugs relating to what happends in the repo after fetch. Those would result in lost decorations. If you have an "exact" receipe for reproducing the failure, a bug report helps. Otherwise we know there is some work to do related to nested repos and odd setups in general. -- robin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html