Bugzilla – Full Text Bug Listing
| Summary: | [project] Migrate to GIT | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | adolfosbh, eclipse, laurent.goubet |
| Version: | 3.2.0 | Flags: | ed:
juno+
|
| Target Milestone: | M1 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | Release Currency | ||
|
Description
Ed Willink
Not sure about the WWW stuff. How does it get from there to the web presence? I guess that the webmaster would have to migrate this part as a whole, no? PSFs: see https://bugs.eclipse.org/bugs/show_bug.cgi?id=296082 Ed, I can't seem to be able to edit http://www.eclipse.org/projects/project_summary.php?projectid=modeling.mdt.ocl regarding the repository location. Can you? (In reply to comment #1) > PSFs: see https://bugs.eclipse.org/bugs/show_bug.cgi?id=296082 I guess we change after Indigo release and hope that the support is in Indigo. > Ed, I can't seem to be able to edit > http://www.eclipse.org/projects/project_summary.php?projectid=modeling.mdt.ocl > regarding the repository location. Can you? It's autogenerated. I've edited the Project metadata. GIT now shows up. Maybe once we do some work the dash statistics and activity will be sensible again. Hello, I'm using this bugzilla to do some minor repository reestructure (apart from experimenting with EGit ;P). I have created a local bug/349114 branch (from my local master one). The idea (as we had discussed) is moving the old stuff in the /releng folder to a new org.eclipse.ocl.releng.athena project (inside /releng subfolder). I also wanted to remove the .project file from the releng folder, just keeping the README.txt (readable from the GIT Repositories view) and the releng projects themself.... However, I've noticed the presence of the PSF folder I'm wondering if these PSFs make sense in the releng area. Not really... Perhaps we could create a "developers" area, the PSF subfolder could make sense here, we could also rescue OCLCodeFormatter file, etc What do you think ? P.S: I'll shortly do my first pushes to our Eclipse GIT repository. Regards, Adolfo. Cheers, Adolfo. I kind of see the releng as a 'developers' area already. It's the only 'plugin' that isn't deliverable. The crunch question for content is: Should this file be part of a source bundle? For the PSFs, no since the PSFs provide an alternate source load mechanism. For the OCLCodeFormatter, perhaps yes since users might find it useful, but anyone editing should really be checking out from CM rather than editing sources. If OCLCodeFormatter is to be in sources, the we need a plugin for it, ?? doc ?? But, I'm not that convinced that it needs changing. Try providing a list of files that you want to move with a destination for them. Ed, It looks like your comments in bug Bug 346140 (and webmaster fixes) have solved the problems I was yesterday with EGIT.... I thought to try command line client today, but it seems that it was a server problem rather and EGit one... Now it's supposed we have a couple of changes in the bug/349114 branch... I guess that somebody should review said branch, when approved I merge said branch with my local master, then I push my local master to the remote repository, right ? ... Is this the general protocol? (In reply to comment #4) > I kind of see the releng as a 'developers' area already. It's the only 'plugin' > that isn't deliverable. I can't see that. The releng area has a clear purpose, stuff to deal whit building/releases, and every potential developer wouldn't even need to know about it. That's why I'd create seperate location for the stuff needed by source code developers from the stuff needed by release engineers. Let's go deeper with the original problem I have (I found it when dealing with Bug 349179). One idea I had (even before starting to deal with EGIT) was considering org.eclipse.ocl/releng area as a non project, which contained several releng projects (build fuateres, buckminster stuff). This idea gets momentum when EGIT doesn't allow to share a project (I have an org.eclipse.ocl.releng.b3 project in my workspace to share) inside another project, that is, a location which contains a .project file. Therefore, if I try to share my new project inside org.eclipse.ocl/releng I get the follwing error: Can not move project org.eclipse.ocl.releng.b3 to target location XXXXXXX\org.eclipse.ocl\releng\org.eclipse.ocl.releng.b3, as this location overlaps with location XXXXXXX\org.eclipse.ocl\releng, which contains a .project file So now, once I moved the old releng stuff to a new (I obviously had to import org.eclipse.ocl/releng as a project to do that) org.eclipse.ocl.releng.athena folder, I wanted to delete the .project file. However, we need to sort out the psf folder: - either we create a new project (create .project in the folder) for the psf folder - or, as I thought it could be good idea, move it to a different area. If you don't want to create a different area, we could rename psf as "org.eclipse.ocl.developers" project which contained the psf files and the OCL Code Formatter file. > > The crunch question for content is: > > Should this file be part of a source bundle? > > For the PSFs, no since the PSFs provide an alternate source load mechanism. > > For the OCLCodeFormatter, perhaps yes since users might find it useful, but > anyone editing > should really be checking out from CM rather than editing sources. > I'm not sure you mean with "checking out from CM rather than editing sources." > If OCLCodeFormatter is to be in sources, the we need a plugin for it, ?? doc ?? > I don't think OCLCodeFormatter is useful for users, but for developers which write java code for the OCL project. > But, I'm not that convinced that it needs changing. > > Try providing a list of files that you want to move with a destination for them. I've glanced at our develepers setup wiki page http://wiki.eclipse.org/MDT/OCL/Dev/Setup: In principle, I only see references to: - PSF (wiki page refers to org.eclipse CVS) - OCLCodeFormateer (wiki page refers to our old releng CVS) So, I'd have the PSF folder and the OCLCodeFormatting.xml file in one of the following locations: - either org.eclipse.ocl.git/developers - or org.eclipse.ocl.git/releng/org.eclipse.ocl.developers NB: Buckminster materialization files could be used to download our source code into the workspace (instead of using and updating PSFs). So, this could be a reason to have all the stuff in the same releng area (mixing releng - developers setup is needed). Regards, Adolfo. More suggestions to discuss: - "features" folder is more appropriate than "feature" one. - There are several features along "doc", "examples" and "tests" folders. Shouldn't we move them to the "features" folder ? - Do we want to remove the "coordinated" folder, and move its features to the "features" folder. Otherwise, I'd move the "org.eclipse.ocl.master" feature (which is present in the "features" folder) to the "coordinated" folder one. Cheers, Adolfo. More GIT practicing... Facing on the obvious first suggestion.
>
> - "features" folder is more appropriate than "feature" one.
Done by combining both: command line client + EGit...Steps done:
- In my local git repository directory:
git mv feature features
- EGIT (Taking into account I'm using my local bug/349114 branch):
Right click on an git-imported project -> Team -> Commit...
Select all the corresponding changes for the "feature" folder + Insert Comment + OK
Right click on a git-imported project -> Push to Upstream
EGIT detects that my bug/349114 branch may be pushed + OK.
So, if I'm not wrong our bug/349114 branch in the remote repository should contain this feature moving (among other commits I've done concerning this bug).
If anyone of you could confirm/review the changes, I could then start with the merging process (Well, perhaps we should wait until all the changes are ready to be merged with the master branch ?)...
Cheers,
Adolfo.
(In reply to comment #7) > More GIT practicing... Facing on the obvious first suggestion. > > > > > - "features" folder is more appropriate than "feature" one. +1 > Done by combining both: command line client + EGit...Steps done: > > - In my local git repository directory: > git mv feature features > - EGIT (Taking into account I'm using my local bug/349114 branch): > Right click on an git-imported project -> Team -> Commit... > Select all the corresponding changes for the "feature" folder + Insert Comment > + OK > Right click on a git-imported project -> Push to Upstream > EGIT detects that my bug/349114 branch may be pushed + OK. > > So, if I'm not wrong our bug/349114 branch in the remote repository should > contain this feature moving (among other commits I've done concerning this > bug). The bug/349117 branch at 8c1b0a6b46435ddb57b8690cd823264f98132d71 has no contents under features/ Axel, Comparing (synchronizing) my local working directory with the remote bug/349114 one, it looks fine (learning, learning :D) Anyway, I think you have missed the branch number, it's the 349114 (instead of the 349117 you mentioned) one ;) Cheers, Adolfo. (In reply to comment #6) > More suggestions to discuss: > > - "features" folder is more appropriate than "feature" one. > - There are several features along "doc", "examples" and "tests" folders. > Shouldn't we move them to the "features" folder ? > - Do we want to remove the "coordinated" folder, and move its features to the > "features" folder. Otherwise, I'd move the "org.eclipse.ocl.master" feature > (which is present in the "features" folder) to the "coordinated" folder one. > > Cheers, > Adolfo. +1 All features in 'features' probably without '-feature' in their name. I'd like to see -feature in the name. If in the workspace these projects are next to each other it helps a lot to see which ones are features and which ones aren't. (In reply to comment #11) > I'd like to see -feature in the name. If in the workspace these projects are > next to each other it helps a lot to see which ones are features and which ones > aren't. OK. Though with 10 features that are of very little development interest, I partition them off to a Features Working Set; the PSF does this by default. While tidying up the structure: How about moving the following from "plugins" to "archive" *emf.ocl* *examples.editor* *examples.parser* (In reply to comment #13) > While tidying up the structure: > > How about moving the following from "plugins" to "archive" > *emf.ocl* > *examples.editor* > *examples.parser* +1 I'll do the move on the branch. (In reply to comment #14) > (In reply to comment #13) > > While tidying up the structure: > > > > How about moving the following from "plugins" to "archive" > > *emf.ocl* > > *examples.editor* > > *examples.parser* > > +1 > > I'll do the move on the branch. pushed to branch bug/349114 Good... I'll do some minor changes in my local branch, to check how the EGIT branches syncronization works ;P P.S: I still need to know what to do with the "releng" folder. I mean, what to do with the PSF one. P.S2: Hudson jobs have been renamed, I hope to merge this branch with the master one. After merging, could/should we carry on working on the same branch? Regards, Adolfo. > P.S2: Hudson jobs have been renamed, I hope to merge this branch with the
> master one. After merging, could/should we carry on working on the same branch?
What do you mean by "same branch?" Are you referring to this branch bug/394114? I suggest we merge this branch once we agree it shall be merged. That should be possible independently of the releng stuff, shouldn't it?
Moving the features seems to have totally hosed my repository. a) the ocl feature has gone in one leve too high. b) the directory structure change seems to be one of the Rebase graphs that EGIT cannot handle. I now have a Repo that's stuck in Rebase Interactive, and initially any attempt at Abort gives index locked. Deleting the lock file helps but then just bombs again on incompatible directory structures. It seems I have to create a new repo. Generally I see a major lack of synchronisation options and numerour unexpected or unconfirmed things happening. The Merge Tools seems useless. Give me back CVS conflict merge. I am not convinced that EGIT is ready for prime-time. Now is a much better time to rethink than in 6 weeks time. (In reply to comment #17) > What do you mean by "same branch?" Are you referring to this branch bug/394114? Yes. > I suggest we merge this branch once we agree it shall be merged. That should be > possible independently of the releng stuff, shouldn't it? Of course, I agree with the suggestion. Just wondering if it makes sense continuing development with a branch, which has already been merged with a different one. Makes sense ? Why is it not recomendable ?. On the other hand: (In reply to comment #16) > Good... I'll do some minor changes in my local branch, to check how the EGIT > branches syncronization works ;P I can't see any change while synchronizing the branches. Expected, since your changes imply restructuring the repository... and I simply have a couple of unaffected projects. However, I've tried a to do a "Fetch from Upstream" and It doesn't detect any change: "No ref to fetch from org.eclipse.ocl - origin - everything up to date." Do you have an idea, about what could be happening ? Cheers, Adolfo. (In reply to comment #19) > However, I've tried a to do a "Fetch from Upstream" and It doesn't detect any > change: > > "No ref to fetch from org.eclipse.ocl - origin - everything up to date." > > Do you have an idea, about what could be happening ? To me this stinks. The major diagnostic problem is that I cannot see any EGIT facility to browse a branch, so you cannot see what is actually where. I have successfully reconciled bug 349125 by recreating as a bug 349125a and rebasing immediately before commit. Switch to the remote bug 349125 allowed me to work but all changes seem to vanish into the ether. 349125a enabled me to get a better local master and push it upstream from my tower, but on my laptop. Switching to local master gives 3.1.0 in o.e.o.e.build MANIFEST Switch to remote master gives 3.2.0 Yet fetching from upstream reports nothing to change. This would be really cool if it worked, but it doesn't today in EGIT. I do not want to spend 10% of my time till SR1 fighting CM eccentricities, so I hope there is a simple explanation of why I and Adolfo are so stupid.
>
> Do you have an idea, about what could be happening ?
>
Well, I think I'm starting to understand how this works... My "Local" (sub folder local) branch bug/349114, doesn't get updated with a Fetch from Upstream. Fetching from upstream updates the "Remote Tracking" one. If I want to have my Local one updated, I should merge the "Remote tracking" branch into the "Local" one.
This also explains why when I push my Local branch to the upstream remote repository, then I may do a "fetch from upstream", so that my "Remote Tracking" branch is then updated.
This also explains why I can't see differences when "fetching from upstream", as I would have expected. This action simply updates the "Remote Tracking" branches (in my local repository;) ). It's then my turn when I can "synchronize" (compare) my local branches with the remote tracking one, merge them, etc...
On the other hand... I'm not sure what would happen if I worked on "Remote Tracking" branch (I can certainly checkout said "Remote Tracking" branches) instead of . Perhaps I'm not allowed to push from said "Remote Tracking" branches.
I'm not sure if this make sense, if I'm using a proper vocabulary, etc... Perhaps a good knowledge of git, then egit, should help. Maybe Axel could give some lessons on this ;P
I hope to sort out the current git repository structure in bug/349114 soon.
Cheers,
Adolfo.
Good, The current bug/349114 folder should now include the proper features restructure: - doc examples and tests features were moved to "features" folder. - the org.eclipse.ocl feature content has been moved to the proper "org.eclipse.ocl-feature" project inside "features" project (I think that this problem came from the migration or when Axel moved some the features to the "feature" folder, because my "local" master branch also has this deficiency. Finally, in the "working directory" (when working/checking out the bug/349114 branch) I see some residual folders (i.e the "feature" one) after moving. I guess that this will disappear as soon as no branches need them (perhaps when this bug branch is merged into the master)... ¿ Axel ? I think that I'm going to do some hudson tests (probably using this bug if we don't agree to merge and push to master :) ). In case I had not said it yet, I'm also considering buckminster modification in this bug, since the features/plugins reestructure affects. Cheers, Adolfo. > Well, I think I'm starting to understand how this works... My "Local" (sub
> folder local) branch bug/349114, doesn't get updated with a Fetch from Upstream.
> Fetching from upstream updates the "Remote Tracking" one. If I want to have my
> Local one updated, I should merge the "Remote tracking" branch into the "Local"
> one.
>
More learning/thoughts (the experience has been quite COOL !!)
The behaviour explained above has some reasoning. My "Local" bug/349114 branch was not created against the "Remote tracking" bug/349114... simply, because it didn't exist, which is obviou.... Let me try to explain the history as I understand it:
1. I create a "Local" branch named bug/349114. I created from my "Local" master branch (NB: no the remote tracking one). By default (if you don't change anything in the wizard) the "Pull policy" is "none".
2. I push the branch to the remote server, so that now a new origin/bug/349114 branch is created in the remote server.
3. Then I fetch from upstream, so that now, in my local repository, I have the "Remoting Tracking" bug/349114 (apart from the "Local" one ;) ).
Because, my "Local" bug/349114 points to (was created from) my "Local" master (besides with a none pull policy) I don't get it updated when I do a "fetch from upstream". Only the "Remote Tracking" origin/bug/349114 gets updated, and that's why I need to manually merge the "Local" bug/349114 one.
Probably, If you created your "Local" bug/349114 branch from your "Remote Tracking" origin/bug/349114, you wouldn't experience the same issue every time you do a "fetch from upstream".
Do you follow me? Does this make sense ?
Well... I hope to invest more time on this on Monday (I have to leave now). My next idea is making the maintenance hudson job work. This will involve (From EGIT point of view)
1. Create a "Local" maintenance/R3_1 branch from the "Remote Tracking" origin/maintenance/R3_1 one (with a "Merge" pull strategy).
2. Try to merge my (updated) "Local" bug/349114 into the newly created "Local" maintenance/R3_1 branch.
3. Commit changes.
4. Push to upstream (remote server).
5. Configure hudson job to use git.
6. Build to see what happens :)
If steps above work (specially the 2 one), I think that I'll definitely +1 GIT.
Any thought/correction will be welcome...
Cheers,
Adolfo.
(In reply to comment #18) > Moving the features seems to have totally hosed my repository. > > a) the ocl feature has gone in one leve too high. Fixed. Sorry. > b) the directory structure change seems to be one of the Rebase graphs that > EGIT cannot handle. Don't know about egit. Likely that there are a number of things that still go wrong. I encourage you to file bugs against egit to ensure that things improve. Until things get fixed, try the command line client. One thing that helped me in using egit was turning off the "Refresh resources when index changes" check box in the Git preferences in Eclipse. > or unconfirmed things happening. The Merge Tools seems useless. Give me back > CVS conflict merge. I use kdiff3 with the command-line tools. This works really well. > I am not convinced that EGIT is ready for prime-time. Now is a much better time > to rethink than in 6 weeks time. I only use egit as support when quickly adding files or performing diffs against history in Eclipse. Also, moves (explicit or implicit through refactorings) work well with egit according to my experience. Branching, merging, pushing, fetching, cherry-picking and pulling I always do from the command line. (In reply to comment #19) > Of course, I agree with the suggestion. Just wondering if it makes sense > continuing development with a branch, which has already been merged with a > different one. Makes sense ? Why is it not recomendable ?. I don't think its useful to merge one bug branch into another except for very rare occasions where the two bugs are closely related and the one depends on the other. > However, I've tried a to do a "Fetch from Upstream" and It doesn't detect any > change: > > "No ref to fetch from org.eclipse.ocl - origin - everything up to date." Have you tried "git pull origin bug/...:bug/..." on the command line? (In reply to comment #20) > To me this stinks. > > The major diagnostic problem is that I cannot see any EGIT facility to browse a > branch, so you cannot see what is actually where. The major tool to browse git branches comes with git itself and is called gitk. It works like a charm on all platforms that I've seen and used so far. It wonderfully shows commits, branches, merges, lets you search through a lot of history information and performs well. > I have successfully reconciled bug 349125 by recreating as a bug 349125a and > rebasing immediately before commit. Switch to the remote bug 349125 allowed me > to work but all changes seem to vanish into the ether. Not sure what you mean. Can you be more specific? Did you maybe forget to add the files changed to the index? Or did you forget to commit them to your branch? But even then, when I do a "git checkout some-other-branch" with non-added and changed files in the workspace, git will warn and leave the changed files in place. Maybe an egit problem? > 349125a enabled me to get a better local master and push it upstream from my > tower, but on my laptop. > > Switching to local master gives 3.1.0 in o.e.o.e.build MANIFEST > Switch to remote master gives 3.2.0 > Yet fetching from upstream reports nothing to change. Again, maybe consider using the command line for branch management and at the same time file respective bugs against egit. > This would be really cool if it worked, but it doesn't today in EGIT. > > I do not want to spend 10% of my time till SR1 fighting CM eccentricities, so I > hope there is a simple explanation of why I and Adolfo are so stupid. Sounds like egit bugs or unsupported features to me. Again: my recommendation for now is using the command line at least for branch and remotes management. (In reply to comment #21) Right. And by the way, all the remote tracking branches and local branches are nicely displayed in gitk. You should really give it a try. (In reply to comment #21) > On the other hand... I'm not sure what would happen if I worked on "Remote > Tracking" branch (I can certainly checkout said "Remote Tracking" branches) > instead of . Perhaps I'm not allowed to push from said "Remote Tracking" > branches. > > I'm not sure if this make sense, if I'm using a proper vocabulary, etc... > Perhaps a good knowledge of git, then egit, should help. Maybe Axel could give > some lessons on this ;P I'm not sure if you *can* progress a remote tracking branch locally and hence make it run out of sync with its remote counterpart. Most definitely you shouldn't (even in case it was somehow possible). (In reply to comment #22) > Finally, in the "working directory" (when working/checking out the bug/349114 > branch) I see some residual folders (i.e the "feature" one) after moving. I > guess that this will disappear as soon as no branches need them (perhaps when > this bug branch is merged into the master)... ¿ Axel ? That's what I experience with the command-line client. (In reply to comment #23) The "fetch" concept, as you observed, only updates the remote tracking branches. There is a special form of "fetch" on the command line which will also advance your local branch to the commit fetched on the remote tracking branch: git fetch origin remote-branch-name:local-branch-name It only handles fast-forwards. The "pull" command does a fetch with a subsequent merge. That's what you want to do if you want to perform the merge of the remote tracking branch immediately. If you don't do it immediately, you may, e.g., use "git diff" to compare the branches before you perform the merge which can also be handy at times. It seems our problems have been - bad initial permissions - a nuisance - finger trouble - always happens - poor branch maintenance documentation - still learning - inadequate EGIT user interface - GIT mandatory So GIT is ok, just EGIT is bad. This was my reason for delaying till Indigo; give EGIT time to mature. I checked one of my nightmares and found a Bugzilla open since January. I guess we have to learn to love the command line and keep pressing on EGIT. Axel: It would be really helpful, for all Eclipse users, if you could identify the correct EGIT-only actions to maintain two conflicting topic branches concurrently with two users each working on each branch. i.e. How is the checkout performed so that local tracks remote and my local can become your local. How is the switch to the other local performed? How is the rebase performed? How is the merge conflict resolved? [I still don't know the answers, but I think I know the questions.] This might avoid the traps that both Adolfo and I have fallen into whereby we have not got our branches correctly configured. Since both of us have got it wrong, it would seem that 50% of Eclipse committers will also get it wrong. So let's have an Eclipse Corner article. (In reply to comment #30) Let me check back with our eGit committers. I'm sure they have something to say on this. Maybe there's a good tutorial that avoids the trouble you were facing. Axel, I'm afraid I need your help. While trying to fix hudson job, I've realized that we have a problem with the shell scripts because they don't have executable permissions. I think that I've fixed that by doing the following via command line: git update-index –chmod=+x <file> However I also did the commit via command line, and I've found the following incovenience: The push can't be done because the commit's author is not the proper one: hook declined error: git.eclipse.org does not know this committer, or this is not you: adolfosbh@adolfosbh-PC.(none). denied: You (adolfosbh@opencanarias.com) cannot push changes that were not committed by you. Please fix your repository, and see http://wiki.eclipse.org/Git for information on configuring your Git environment. error: hook declined to update refs/heads/bug/349114 I hope to fix the configuration so that the author is the proper time, the next time I make a commit... For the current issue, I'm not sure how is the best way to fix that. Ideally, I'd like to remove that commit from my local branch, but I'm not sure if this is possible. git-revert seems to (obviously) apply commits to revert the change, rather than "removing" commits. What do you suggest to do ? P.S: I get the same error doing the push via Eclipse and via command line P.S: I could temporarily change my user's configuration in Eclipse to make the push using the expected user, but I'm looking for alternatives Regards, Adolfo. Hello, Yesterday, I could sort out the problem, with some Axel suggestions: 1. Create a new branch from the previous valid commit. 2. Do the good commit (cherry-pick could suffice, since it was the same commit but using the proper author). 3. Remove the bug/349114 4. Rename the new created branch as bug/349114 and push !! Yesterday, I found another irritating (but overtaken) problem: committing changes on our *.sh scripts, made them lose the +x permission again... After, restoring the permissions and doing some fixes... I finally got stuck with the following problem: Bug 350130 Waiting for some answers to this to go ahead... Regards, Adolfo. Hello all, Bug 350130 is getting clearer, however there is still an inconvenience which prevents me to make progress with the maintenance build configuration. However, I think I could make progress configuring our Juno hudson jobs (I don't need to specify a branch name) . To do that I'd need: 1. To merge this bug branch (bug/349114) into our master one (and push) 2. Create a new bug to make the required changes to our buckminster files (platform.rmap) to get feeded by Juno repos instead of Inidigos one. Optionally, to do a faster sanity check of the current releng infrastructure (after moving git), I could temporally make our maintenance build use the master branch, so I'd simply have to do step 1. and run a build. Regards, Adolfo. Adolfo: (+1) releng doesn't need approval so long as you're only changing build (or source code in emergencies). Do whatever you need so long as you think you knwo what you're doing and if it can be undone and doesn't disrupt code unduly. I would be surprised if a few releng commits will make any difference to Axel or me provided we rebase before merging as should always be done anyway. (In reply to comment #36) > I would be surprised if a few releng commits will make any difference to Axel or > me provided we rebase before merging as should always be done anyway. It sounds like a good practice, however, I get the following error when I try to rebase my local bug/349114 onto both the local master and the remote trancking origin/master... Can only cherry-pick commits which have exactly one parent Can only cherry-pick commits which have exactly one parent Any suggestion ?. Best Regards, Adolfo. > It sounds like a good practice, however, I get the following error when I try > to rebase my local bug/349114 onto both the local master and the remote > trancking origin/master... Careful with your words. I find the GIT terminology very confusing "onto" to me implies that the target is modified not the source. From what I gather, you should never rebase so as to change the master. you should always rebase to resync your branch with the master > Can only cherry-pick commits which have exactly one parent > Can only cherry-pick commits which have exactly one parent This is probably the problem. I made a mess of my first branches too, before learning: always branch from the remote master always rebase 'from' the remote master the local master is just a temporary home for a local merge before push > Any suggestion ?. Scrap the branch and create another one. cf my bug/......a > > Careful with your words. I find the GIT terminology very confusing "onto" to me > implies that the target is modified not the source. > Well, It hasn't been confusing to me... However, you are native english, so... ;P > From what I gather, > you should never rebase so as to change the master. > you should always rebase to resync your branch with the master > Not sure what you mean with the first sentence, but as you say, I understand "rebase" as the second one. That is, to make branch be "updated" with the master's content by making the current point/state (tip) of the master be the new parent tip of the branch... Is that understood/right ? > > Can only cherry-pick commits which have exactly one parent > > Can only cherry-pick commits which have exactly one parent > > This is probably the problem. I made a mess of my first branches too, before > learning: > always branch from the remote master > always rebase 'from' the remote master Yes I have also learned that, actually with EGit, when you create the branch and select "Rebase" as the pull strategy. As soon as the remote master is updated (pull from upstream) the branch is automatically rebased... BTW, To me, 'from' doesn't sounds better than 'onto'... Take a look to the following sentence to know if it make sense.... "We would be rebasing the branch 'from' the master (the old point - tip - the branch referred to) 'onto' the master (the new point - tip -, the more recient one, the branch now refers to) > the local master is just a temporary home for a local merge before push > Right !! > > Any suggestion ?. > > Scrap the branch and create another one. cf my bug/......a I'm not sure if there were any different result than directly merging my local bug/349114 into my local master... Hopefully, it will simply apply the commits without any conflict nor pain... I don't want to carry on changes (then, no future, commits, rebase, etc) on this bug/349114... BTW, when the bugs ares merged, pushed, and closed ... I suppose we could freely remove our local one... Concerning the remote one, well, I guess there is not too much trouble if we keep them...Perhaps some annoyances if we have a lot of bugs ;P Regards, Adolfo. > (pull from upstream) the branch is automatically rebased...
>
Sorry, I should have said "should be"... That's EGit theory/documentation, I've not had time to check that... As soon as, we start to proper control/manage EGit, with frequent branch creations, commmits, pushes, pulls, etc, we will be able to check it ;P
Cheers,
Adolfo.
(In reply to comment #39) > > > > Careful with your words. I find the GIT terminology very confusing "onto" to > me > > implies that the target is modified not the source. > > > > Well, It hasn't been confusing to me... However, you are native english, so... > ;P > > > From what I gather, > > you should never rebase so as to change the master. > > you should always rebase to resync your branch with the master > > > > Not sure what you mean with the first sentence, but as you say, I understand > "rebase" as the second one. That is, to make branch be "updated" with the > master's content by making the current point/state (tip) of the master be the > new parent tip of the branch... Is that understood/right ? > > > > Can only cherry-pick commits which have exactly one parent > > > Can only cherry-pick commits which have exactly one parent > > > > This is probably the problem. I made a mess of my first branches too, before > > learning: > > always branch from the remote master > > always rebase 'from' the remote master > > Yes I have also learned that, actually with EGit, when you create the branch and > select "Rebase" as the pull strategy. As soon as the remote master is updated > (pull from upstream) the branch is automatically rebased... > > BTW, To me, 'from' doesn't sounds better than 'onto'... Take a look to the > following sentence to know if it make sense.... "We would be rebasing the branch > 'from' the master (the old point - tip - the branch referred to) 'onto' the > master (the new point - tip -, the more recient one, the branch now refers to) > > > the local master is just a temporary home for a local merge before push > > > > Right !! > > > > Any suggestion ?. > > > > Scrap the branch and create another one. cf my bug/......a > > I'm not sure if there were any different result than directly merging my local > bug/349114 into my local master... Hopefully, it will simply apply the commits > without any conflict nor pain... I don't want to carry on changes (then, no > future, commits, rebase, etc) on this bug/349114... > > BTW, when the bugs ares merged, pushed, and closed ... I suppose we could freely > remove our local one... Concerning the remote one, well, I guess there is not > too much trouble if we keep them...Perhaps some annoyances if we have a lot of > bugs ;P > > Regards, > Adolfo. Well, since the master's tip doesn't appear along bug/349114 history, I'm afraid that merging fails with errors I'll create a bug/349114a branch from the remote master, as suggested.... and see how to proper "copy" the commits from one branch to other (cherry picking, probably)... Although I'm not sure which commits should really be done... Axel, could you give a hand, or do any kind of suggestions... I don't want to mess this up more than what I've already done >.< Regards, Adolfo. >
> Well, since the master's tip doesn't appear along bug/349114 history, I'm afraid
> that merging fails with errors
>
Forget this last statement, I think that the trip I arrived some hours ago has exhausted my mind... I think that it's better to face on this tomorrow...
Regards,
Adolfo.
I would totally abandon the 'old' branch. Just use diff to see what you've changed and do it again in a new branch as if it was brand new work. Trying to rescue the old work is just too hard (unless of course you have 1000 files, but I suspect you've only changed one or two). Ed, If it were only changes to files which I may synchronize and update, it could be a good idea... however there are also some repository structuring (features movement), which I can't track with Eclipse-EGit synchronization... Let's see if Axel has something else to say. I think that when every ocl project (plugin, feature,etc) is in place (no-nested projects) in the repository, dealing with EGit may be a satisfactory task. Best Regards, Adolfo. Not sure I understand what the problem was. One thing I find surprising is that you get a "cherry-pick" warning when what you should have been doing is a "merge" and not a "cherry-pick." To rebase a branch I usually, while having the branch checked out, do a "git fetch origin master:master" followed by a "git merge master" which merges changes that occurred after you branched out or re-based your branch the last time. Then, when I want to merge the branch into master, I do git checkout master git merge bug/xxxxx If merge conflicts show up, no auto-commit happens. I then do a git mergetool which I've set to use kdiff3 for merging. This works really well for me. When the conflicts are resolved, I can do a git commit and, if it's a change/branch that can be pushed without review or has gotten the necessary review / +1, I do a git push origin master:master Cheers, -- Axel (In reply to comment #45) > Not sure I understand what the problem was. One thing I find surprising is that > you get a "cherry-pick" warning when what you should have been doing is a > "merge" and not a "cherry-pick." > To rebase a branch I usually, while having the > branch checked out, do a "git fetch origin master:master" followed by a "git > merge master" which merges changes that occurred after you branched out or > re-based your branch the last time. Those "cherry-pick" errors have appeared when doing an EGIT - "rebase" (not "merging"). I guess that it tries to cherry-pick commits from the master into the branch... instead of doing a merge of master into the checked-out branch... I'll try your command-line suggestions to see what happens (Don't want to w8 until tomorrow... >.<) Cheers, Adolfo. Axel, Thanks a lot. It worked... I guess that this should be the usual way of working: 1. Create bug/xxxx branch from master remote tracking branch 2. When the the bug is finished -> Rebase bug/xxxx onto master (this may work via EGit, otherwise use command line) 3. Merge bug/xxxx into master. 4. Push to upstream. 5. If bug needs to be moved into maintenance stream -> Rebase bug/xxxx onto maintenance/R3_1 (this will fail via EGit -> use command line) 6. Merge bug/xxxx into maintenance/R3_1 7. Push to upstream. Does this make sense ? On the other hand buckminster-mdt-ocl-3.1-maintenance (temporarily using master) fails .... org.eclipse.ocl.examples.parser.ocl can't be found >.< ... (it has been moved to archived folder). Tomorrow, I'll try to configure our 3.2 build to finally have a successful one. For that, apart from fixing Bug 350862, features in master will also need to be updated to not include the archved plugins (already fixed in a different bug ?). Maintenance build will be fixed as soon as Bug 350210 is fixed. The ocl.rmap file will be updated so that features may be found into the "archived" folder. Regards, Adolfo. More interesting learn EGit behaviour, about how the (EGit) merge works: Situation: I wanted to merge bug/349179 and bug/349300 into master. -bug/349179 1. I did a rebase of the branch onto the master. 2. I committed some changes in the branch (I'm now ready to do the merge) 3. I checked out master. 4. I Selected bug/349179 (from git repositories view) -> Merge The result was that a couple of commits from the bug/349179 were cherry picked into the master. -bug/349300 1. I'm still on master branch. 2. I selected bug/349300 (from git repositories view) -> Merge. The result was a 'merge branch 'bug/349300' into the master, that is a pure git merge... Curious, isn't it ? Axel, any recommendation ? What do you recommend to do now, if I want to merge the same bugs into the maintenance/branch ?... I didn't hear any opinion about the way of working I mentioned in my previous comment. Regards, Adolfo. (In reply to comment #48) > More interesting learn EGit behaviour, about how the (EGit) merge works: > > Situation: I wanted to merge bug/349179 and bug/349300 into master. > > -bug/349179 > 1. I did a rebase of the branch onto the master. Why a "rebase?" Why not merge the master into your bug/349179 branch and, if everything works ok on the branch, checkout master, then merge bug/349179? > 2. I committed some changes in the branch (I'm now ready to do the merge) > 3. I checked out master. If you rebased onto master you would already have been on master. I'm confused. > 4. I Selected bug/349179 (from git repositories view) -> Merge Not sure why you try to merge again when you rebased before. > The result was that a couple of commits from the bug/349179 were cherry picked > into the master. > > -bug/349300 > 1. I'm still on master branch. > 2. I selected bug/349300 (from git repositories view) -> Merge. > > The result was a 'merge branch 'bug/349300' into the master, that is a pure git > merge... That sounds like it should be, doesn't it? Any problems with this? (In reply to comment #49) > (In reply to comment #48) > > More interesting learn EGit behaviour, about how the (EGit) merge works: > > > > Situation: I wanted to merge bug/349179 and bug/349300 into master. > > > > -bug/349179 > > 1. I did a rebase of the branch onto the master. > > Why a "rebase?" Why not merge the master into your bug/349179 branch and, if > everything works ok on the branch, checkout master, then merge bug/349179? Good point, it sounds like another alternative, that one I ... The question now is "Why not" ?. I understand that if I rebase my bug/349179 onto master, I'll have my bug/349179 pointing to the newest master's tip. Then the commits which I had in my branch would be easily merged into the master, when doing said merge.. Anyway, you are the experienced gitter, correct me if I'm wrong... and it's also true that I'm not sure I had any commit in the bug/349179 branch, so if that was the case rebasing should have been quite straight forward... > > > 2. I committed some changes in the branch (I'm now ready to do the merge) > > 3. I checked out master. > > If you rebased onto master you would already have been on master. I'm confused. Not really, from the EGit point of view... expanding point 1: I did a rebase of the branch onto the master. 1.a) Checking out bug/349179 2.b) Select master in the Git Repositories view -> Rebase So: 1. After rebasing I'm still on bug/349179. 2. I obviously commit changes on bug/349179. 3. I finally checkout master to do the merge (bug/349179 into the checked out master, as explained in 4.)- > > > 4. I Selected bug/349179 (from git repositories view) -> Merge > > Not sure why you try to merge again when you rebased before. > Perhaps, I don't understand rebase, yet ... but that's what I did using EGit, and all looks consistent in the History View (I hven't pushed yet). > > The result was that a couple of commits from the bug/349179 were cherry picked > > into the master. > > > > -bug/349300 > > 1. I'm still on master branch. > > 2. I selected bug/349300 (from git repositories view) -> Merge. > > > > The result was a 'merge branch 'bug/349300' into the master, that is a pure > git > > merge... > > That sounds like it should be, doesn't it? Any problems with this? Not really, they were different attempts to do the merge of a bug into the master one, by the means of EGit: The first one, produced cherry picks. The second one, produced a real merge. You also provided a third case, in which we include the changes made to a master, made after a branch was created, into said branch .... Then (if all goes fine) you merge all the branch into the master .... Instead, what I tried is to rebase the branch onto the master, then merge.... I'm not sure if this conceptually right, ... perhaps, I'm wrongly using the concepts ;P Any correction/advise would be welcome... If something needs restate again because is not clear, please let me know... Cheers, Adolfo. (In reply to comment #50) See http://kernel.org/pub/software/scm/git/docs/git-rebase.html > Good point, it sounds like another alternative, that one I ... The question now > is "Why not" ?. I understand that if I rebase my bug/349179 onto master, I'll > have my bug/349179 pointing to the newest master's tip. Then the commits which > I had in my branch would be easily merged into the master, when doing said > merge.. Anyway, you are the experienced gitter, correct me if I'm wrong... You're right; you should remain on the bug branch after a rebase according to the man page. I usually work the other way around and I couldn't say if one is better than the other. What I like about a "git merge master" is that it doesn't need to re-write my commits which later simply merge unchanged into master whereas a "rebase" produces a chain of new commits. "rebase" may be more appropriate in case some of the commits already got cherry-picked into master. > 1. After rebasing I'm still on bug/349179. > 2. I obviously commit changes on bug/349179. > 3. I finally checkout master to do the merge (bug/349179 into the checked out > master, as explained in 4.)- And what's the problem now? Didn't the merge go through? > Perhaps, I don't understand rebase, yet ... but that's what I did using EGit, > and all looks consistent in the History View (I hven't pushed yet). Again, if I need to understand the branch structure I use gitk. eGit history for me doesn't do the same because history is largely for a single file only and not for the entire tree of commits. > > That sounds like it should be, doesn't it? Any problems with this? > > Not really, they were different attempts to do the merge of a bug into the > master one, by the means of EGit: > > The first one, produced cherry picks. > The second one, produced a real merge. > > You also provided a third case, in which we include the changes made to a > master, made after a branch was created, into said branch .... Then (if all > goes fine) you merge all the branch into the master .... Instead, what I tried > is to rebase the branch onto the master, then merge.... I'm not sure if this > conceptually right, ... perhaps, I'm wrongly using the concepts ;P See above, both are valid with subtle differences as to which commits remain in place and which ones are re-written / cherry-picked. It leads to a slightly different commit tree eventually, but the snapshot produced by both should be equivalent. (In reply to comment #51) > (In reply to comment #50) > > See http://kernel.org/pub/software/scm/git/docs/git-rebase.html > > > Good point, it sounds like another alternative, that one I ... The question > now > > is "Why not" ?. I understand that if I rebase my bug/349179 onto master, I'll > > have my bug/349179 pointing to the newest master's tip. Then the commits which > > I had in my branch would be easily merged into the master, when doing said > > merge.. Anyway, you are the experienced gitter, correct me if I'm wrong... > > You're right; you should remain on the bug branch after a rebase according to > the man page. I usually work the other way around and I couldn't say if one is > better than the other. What I like about a "git merge master" is that it doesn't > need to re-write my commits which later simply merge unchanged into master > whereas a "rebase" produces a chain of new commits. "rebase" may be more > appropriate in case some of the commits already got cherry-picked into master. I think we are now following each other ;)... your last sentence, is something on which I have not realized, and I'll take it into account for the future. So the conclusion is, it's "better" to merge rather than "rebase" + merge. > > > 1. After rebasing I'm still on bug/349179. > > 2. I obviously commit changes on bug/349179. > > 3. I finally checkout master to do the merge (bug/349179 into the checked out > > master, as explained in 4.)- > > And what's the problem now? Didn't the merge go through? No problems, just explaining everything again :) > > > Perhaps, I don't understand rebase, yet ... but that's what I did using EGit, > > and all looks consistent in the History View (I hven't pushed yet). > > Again, if I need to understand the branch structure I use gitk. eGit history for > me doesn't do the same because history is largely for a single file only and not > for the entire tree of commits. You actually can do it (and that's one of the things I love from EGit). You can select a branch from the Git Repositories view and you see all the entire history of commits for that branch, you can also view some "labels" (boxes) which show the commits to where other branches/tags are pointing (local and remote tracking branches). Moreover, you have a button in the view which shows all branches and tags, which makes the task of cherry-picking commits from other branches quite easy/user-friendly. > > > > That sounds like it should be, doesn't it? Any problems with this? > > > > Not really, they were different attempts to do the merge of a bug into the > > master one, by the means of EGit: > > > > The first one, produced cherry picks. > > The second one, produced a real merge. > > > > You also provided a third case, in which we include the changes made to a > > master, made after a branch was created, into said branch .... Then (if all > > goes fine) you merge all the branch into the master .... Instead, what I tried > > is to rebase the branch onto the master, then merge.... I'm not sure if this > > conceptually right, ... perhaps, I'm wrongly using the concepts ;P > > See above, both are valid with subtle differences as to which commits remain in > place and which ones are re-written / cherry-picked. It leads to a slightly > different commit tree eventually, but the snapshot produced by both should be > equivalent. Ok, I was only wondering if one is better than the other. Since commits are not duplicated, perhaps we should try to merge rather than rebase + merging... BTW, thinking on the third alternative you proposed, I beliece that it's not appropriate when you have to deal with a bug which needs to be applied into master and the maintenance branch, because we would be including commits from the master, which we won't include later in the maintenance branch ;). So I think it's good having the bug branch only with the commits which have been done to solve said bug. I'm going to try again some merging of said bugs on the maintenance branch, I think that I won't be able to properly do that without rebasing... I'll update the protocol in comment 47 with my conclusions. Cheers, Adolfo. Well, I haven't had any interesting progress concerning how to "merge" a bug branch in both "master" branch and "maintenance/R3_1" one. It looks like that the bug 349114 was "easy" to merge because said branch was created in a close point to where the maintenance branch was created... As soon as master start to receive commits, the new branches created hold the history of the master commits, and then is not "easy" to later merge said bug branch into the maintenance one (at least I'm not sure which is the better way, and how much easy it is). By the moment, I merged Bug 349179 via cherry picking the three individual commits. I'll wait until I receive some feedback about this issue before trying to "merge" Bug 349300 into the maintenance branch (it's already pushed into the master). On the other hand, If I wanted to cherry pick into the maintenance branch the commits of said Bug 349300 it would be "easy" (the more commits the more laborious, though) to do it using the EGit "History View". Following the line, selecting the commit and cheery-picking. However I'm not inclined to do that in this way... let's see if any of you have a better idea to do such kind of tasks (merging a bug branch into two branches). BTW, I think it's quite important specifying the bug id in every commit (specially if we were interested in a cherry-picking task). I've discovered an interesting way to "automatically" include bugId and description. 1. Install EGit Mylyn plugin (Collaboration category). 2. Configure the Commit Comment template: Preferences -> Mylyn -> Team I set the following one: [${task.key}] - ${task.description} 3. Activate the proper mylyn task (bugzilla in the Mylyn task list), at least, when doing a commit. You would have the following dialog when commiting (taking this bugzilla as example): [349114] - [project] Migrate to GIT Also remember to include some description of the commit in the lines below the automatically created comment. P.S: Next week I'll be out of the office. Cheers, Adolfo. For back-porting a set of commits onto the maintenance branch cherry-picking should be the option of choice. If I'm not mistaken, there should be an option to specify a *range* of commits, as in 9642ab..7392bd or similar, such that all commits from the first to the last are cherry-picked onto the branch you're currently on. Well, I've cherry picked all bug/349300 commits into the maintenance branch... If I've not erroneously concluded, our (via EGIT) protocol should be the following: 1. Create bug/xxxx branch from master remote tracking branch. 2. When the the bug is finished -> Merge bug/xxxx into master. 3. Push to upstream. (If our push is rejected, that is, somebody previously pushed to master) 4. Rebase our local master onto the remote origin/master. 5. Push to upstream. (If bug/xxxx needs to be moved into maintenance stream). 6. Checkout maintenance/R3_1 branch 7. Cherry pick bug/xxxx commits into maintenance/R3_1. 8. Push to upstream. (If our push is rejected, that is, somebody previously pushed to maintenance/R3_1) 9. Rebase our local maintenance/R3_1 into the remote origin/maintenance/R3_1. 10. Push to upstream. Comments ? Cheers, Adolfo. 11. Fetch from upstream (to have our remote tracking branches also updated) Cheers, Adolfo. Sounds good to me. Axel, Sorry for insisting on this, but I have the feelings that I ( Oh dear, I should have deleted most of the comment content, before submitting >.<.... Trying again. ------- Axel, Sorry for insisting on this, but I have the feelings that I ( This is kidding me... it looks like a mylyn/bugzilla bug. I'll look into that >.<. The comment later... I'm sick of this ... I'll do the third try after having lunch. Regards, Adolfo. Axel, Sorry for insisting on this, but I have the feelings that I (maybe, we) are not properly using/ doing best practices with GIT/EGIT. We NEED to elaborate some kind of protocol/recipes probably driven by typical uses cases... Firstly, you mentioned that you were agreed on the general protocol I described above, which I believe that it's not completed / needs some working, but I think it's a good point to start from. Now, I've recently noticed a commit from 19 hours ago: Merge branch 'master' into bug/349117 (commit bd2c009f6696e8d44d7dbaa395bfd6174a6b33a6). This step is not definitely described in such a protocol, so please, could you enlighten us about the intention of this action ?. I'd like to understand in which circumstances we should be interested in doing merges from the master to any bug. If there is a clear use case about this, could you update the instruccions/recipe I described above, and/or create a different one?. We should probably move this recipes to somewhere in the wiki to make present and/or future project developers. Best Regards, Adolfo. I agree; it seems we want at least EVERY modifying use case as a Wiki section comprising clear EGIT actions. Laurent's comments on Bug 353171 suggest that it is possible to do almost everything with EGIT, so we should. GIT is clearly very powerful/too powerful for novices so we must have precise procedures. Where GIT must be used, I think there should still be a Wiki section, and that section should reference the Bugzilla requesting resolution of the EGIT inadequacy. ---- RE [xxxx] prefixes on commit comments. This should be in the wiki. Here I feel the bug/xxxxx should be an additional/optional column in the show commits report, making [xxxxx] redundant. Maybe this should be an enhancement Bugzilla. (In reply to comment #62) > I agree; it seems we want at least EVERY modifying use case as a Wiki section > comprising clear EGIT actions. Laurent's comments on Bug 353171 suggest that it > is possible to do almost everything with EGIT, so we should. I also share (Haven't I recall that) Laurent's feelings. It's a matter of how to properly and efficiently use EGit. > > GIT is clearly very powerful/too powerful for novices so we must have precise > procedures. > > Where GIT must be used, I think there should still be a Wiki section, and that > section should reference the Bugzilla requesting resolution of the EGIT > inadequacy. > > ---- > > RE [xxxx] prefixes on commit comments. This should be in the wiki. Here I feel > the bug/xxxxx should be an additional/optional column in the show commits > report, making [xxxxx] redundant. Maybe this should be an enhancement Bugzilla. Again... cherry picking "duplicates"/"clones" the commit so there shouldn't be any "bug/xxxx" branch info in the new commit. It's like a pure new commit (set of changes) which belongs to the branch into which you are cherry picking... However, this commit (and tis set of changes) have previously been done, and you want to reuse them (cloning said changes, author, date, comment, etc). The only way I see to have info about the related bugzilla is including such an info in the comment. Regards, Adolfo. Adolfo, I wanted to make sure at this point that the changes I've done so far on the bug branch are still compatible with the changes on master. Therefore, merging the master at any point into a bug branch is ok IMO. Why do you think it may not be ok? I can't see any reason for prescribing which git client to use. If we feel a comment change is required after cherry-picking, one way is to use "git commit --amend" which allows you to edit the commit message of the tip of the current branch, replacing this commit by another one with the changed commit message. Not sure how this is done in eGit, but I'm sure Laurent will know ;-) (In reply to comment #65) > I can't see any reason for prescribing which git client to use. Eclipse committers have a responsibilty to Eclipse as a whole. We should be making sure that EGIT is fit for purpose. If we can't use it we must complain to get it resolved. (In reply to comment #66) > If we feel a comment change is required after cherry-picking, one way is to use > "git commit --amend" which allows you to edit the commit message of the tip of > the current branch, replacing this commit by another one with the changed > commit message. Not sure how this is done in eGit, but I'm sure Laurent will > know ;-) Challenge accepted! Hem... I never had to use it myself, but trying to commit (right-click > Team > commit) when there is nothing to commit will have a dialog pop up to amend the last commit. As for the rest... I too am struggling with git since I didn't know anything about this VCS (save for its name) until mid-April. The difference being that I strive to do everything with eGit, and I've been experimenting a lot with the many different actions available (I've messed up quite a few clones, but as long as it is not pushed to upstream, anything's allowed :p). Also note that the eGit user guide as a comprehensive list of what can be done, and how : http://wiki.eclipse.org/EGit/User_Guide. As for the rest, I do not really understand why you commit the "bugs" branches on the Eclipse repo, having it in your clone is one thing, but I doubt that having it on Eclipse is useful to anyone but the person working on that bug. Commiting so many branches make the history difficult to read (https://github.com/eclipse/ocl/network as compared to https://github.com/eclipse/emf.compare/network). I may talk out of place as I am no longer a commiter on OCL and don't really have a say in the way you decide to work, but it if helps, here is the workflow we roughly follow on Acceleo and EMF Compare : A) begin work on a 'small' bug (which will require little investigating and little coding) : 1- checkout the target branch (usually master) 2- work : change code, commit when needed... once happy with the fix 3- pull (NOTE: I always configure my repositories to "rebase" on pull. the "real" step 3 is fetch + rebase) 4- push to upstream Optional : If I believe that fix is worthy of a backport 5- checkout maintenance branch 6- cherry-pick the commit(s) of the fix B) begin work on a 'large' bug or on a new feature 1- checkout the target branch (again, usually master) 2- create a new branch "bug######" or "<feature_name>" 3- work : change code, commit when needed... once happy with the fix/feature 4- fetch 5- rebase branch on the latest commit of my target branch 6- push to upstream Optional : If i was working on a fix, and I deem it worthy of a backport 7- checkout maintenance branch 8- cherry-pick the commit(s) of the fix The "bug######" branch is never pushed to the Eclipse repo : I dont think I will ever need that branch again once the fix is pushed. However "feature" branches will be pushed to the Eclipse repo as they are "long running" devs that I need to save elsewhere than on my own computer, and other commiters might be interested in checking out the current dev state. And since that concerns me directly as a client of the OCL code : (In reply to comment #62) > RE [xxxx] prefixes on commit comments. This should be in the wiki. Here I feel > the bug/xxxxx should be an additional/optional column in the show commits > report, making [xxxxx] redundant. Maybe this should be an enhancement Bugzilla. I share Adolfo's thoughts on this. The [######] info in the commit comment is extremely useful for those who read the code (commiters or not). The CVS plugin had the invaluable feature of "right-click > Team > Show Annotations" on a source file which allowed anyone to see _why_ a given line of code had been changed. For the record, that action displayed in the editor's ruler the time and comment of the last commit which changed the lines of code. Well, eGit has this same feature, and it is a great help to the dev : "Right-click > Team > Show Blame Annotations". As this displays the commit comment, it allows anyone to quickly get the number of the bug which triggered such or such change in the code. Laurent: many thanks for your inputs; you are about 2 months ahead of Adolfo and myself in endeavouring to use EGIT consistently, so your thoughts are very helpful. This bug has got too big; somehow we must condense the learning from this bug and a couple of others into a working practice. Laurent's two workflows with optional paths look like a good starting point, but I'm not sure about the small workflow; it doesn't allow for review by another committer for which a repo branch is useful. I suspect that the small workflow is only applicable to emergency releng activities. Nearly all coding needs the big workflow. For the big workflow, I would like to know how developer A creates the bug branch and offers it for review and further development by developer B; EGIT doesn't seem to allow a repo branch to be pulled into an existing workspace. I'm also concerned about the size of the remote branches list. Can we 'lose' old bug branches by renaming bug/123456 as archive/123456? Can we make current branches more memorable by renaming as "bug/349114 GIT migration"? (In reply to comment #70) > Laurent's two workflows with optional paths look like a good starting point, > but I'm not sure about the small workflow; it doesn't allow for review by > another committer for which a repo branch is useful. When I wish for someone to review the changes I made for bug "x", I wish to ease his task. Making him save his own work (commit or stash), fetch the new branch, checkout that branch, review, check out the branch he was previously on, and finally unstash if he did not commit his changes is _not_ something I want to force on the reviewer. Instead, I will do that work myself : fetch, check out master, merge my bug branch, commit, create a patch ... and provide that patch for review. The reviewer will then only have to apply the patch, and reverse it after the review. On my own repo, I only have to reset the merge since it hasn't been pushed ("show in History > locate the commit with the gray "origin/master" tag > right-click > reset > Hard" will reset the "master" branch to its "eclipse" state). > I suspect that the small > workflow is only applicable to emergency releng activities. Nearly all coding > needs the big workflow. For the big workflow, I would like to know how > developer A creates the bug branch and offers it for review and further > development by developer B; EGIT doesn't seem to allow a repo branch to be > pulled into an existing workspace. See above. Forcing the reviewer into checkouting a branch he has no interest in (save for the review itself) is an extra step that will make it postpone the review. Let's face it : there are fixes we are confident in, and I believe that commiters trust one another not to push the "risky" fixes without a review. when I commit a "!= null", I don't go through all the trouble of creating a branch and doing the commit there :). I do create branches for a good number of bugs. But as I mentionned I do not push those new branches as they would be like noise to my fellow commiters. (At least, that's how I would see them ^^.) > I'm also concerned about the size of the remote branches list. Can we 'lose' > old bug branches by renaming bug/123456 as archive/123456? Can we make current > branches more memorable by renaming as "bug/349114 GIT migration"? You can rename branches easily from eGit : in the git repositories view, right-click the branch and hit "rename...". You will have to push that change. I did it on a few occasions and don't remember encountering issues. Branch tags can easily be removed, e.g., by git push :bug/xxxxxx Of course, this should only happen after the bug branch was successfully merged. I don't find the checkout of a bug branch a hindrance or major effort and therefore like this way of working. As Ed said, it easily allows multiple committers to work on the same bug. (In reply to comment #64) > Adolfo, > > I wanted to make sure at this point that the changes I've done so far on the bug > branch are still compatible with the changes on master. Therefore, merging the > master at any point into a bug branch is ok IMO. Why do you think it may not be > ok? Have I said it is not ok ? :) ... As commented, I only want to understand the best practices and properly update our EGit cooking book :) ... From your intention it looks like we could sensibly add an extra step before doing the "Merge of the bug branch into the master one" (step 2). - You propose merging master into the bug/xxxx branch. - Laurent proposes rebasing bug/xxxx onto master. I think I raised this question some weeks ago... From Axel's comment 51: "You're right; you should remain on the bug branch after a rebase according to the man page. I usually work the other way around and I couldn't say if one is better than the other. What I like about a "git merge master" is that it doesn't need to re-write my commits which later simply merge unchanged into master whereas a "rebase" produces a chain of new commits. "rebase" may be more appropriate in case some of the commits already got cherry-picked into master." Thinking on EGit use, I'm not sure if one could be more appropriate than the other when solving conflicts .... perhaps the practice/experience will dictate which practice is better than the other. > > B) begin work on a 'large' bug or on a new feature > 1- checkout the target branch (again, usually master) > 2- create a new branch "bug######" or "<feature_name>" > 3- work : change code, commit when needed... > once happy with the fix/feature > 4- fetch > 5- rebase branch on the latest commit of my target branch > 6- push to upstream > Optional : If i was working on a fix, and I deem it worthy of a backport > 7- checkout maintenance branch > 8- cherry-pick the commit(s) of the fix Laurent, looking at your recipe, I'm missing some kind of step to make the commits of the bug branch included into the target branch. After rebasing (your step5), don't we have to merge the bug branch in to the master branch ? Trying to sumarize different/new ideas, our recipe could be as follows. 1. Fetch from upstream. 2. Checkout master branch. 3. Create bug/xxxx branch (¿Should we use the local checked out master? the remote tracking one ?) 4. When the the bug is finished, ensure the bug is ready to be merged: 4.a) Rebase bug/xxxx onto master branch. 4.b) Merge master into bug/xxxx 5. Merge bug/xxxx into master. 6. Push to upstream. (If our push is rejected, that is, somebody previously pushed to master). 7. Fetch from upstream (to ensure that our remote our remote tracking master branch is updated) 8. Ensure our local master branch is ready to be pushed: 8.a) Rebase our local master onto the remote origin/master 8.b) Merge the remote origin/master branch into our local master branch. 9. Push to upstream. (If bug/xxxx needs to be moved into maintenance stream). 10. Checkout maintenance/R3_1 branch 11. Cherry pick bug/xxxx commits into maintenance/R3_1. 12. Push to upstream. (If our push is rejected, that is, somebody previously pushed to maintenance/R3_1) 13. Fetch from upstream (to ensure that our remote tracking maintenance/R3_1 branch is updated) 14. Ensure our local maintenance/R3_1 branch is ready to be pushed: 14.a) Rebase our local maintenance/R3_1 onto the remote origin/maintenance/R3_1 14.b) Merge the remote origin/maintenance/R3_1 branch into our local maintenance/R3_1 branch. 15. Push to upstream. 16. Fetch from upstream (to have our remote tracking branches also updated) Comments ? Cheers, Adolfo. (In reply to comment #54) > For back-porting a set of commits onto the maintenance branch cherry-picking > should be the option of choice. If I'm not mistaken, there should be an option > to specify a *range* of commits, as in 9642ab..7392bd or similar, such that all > commits from the first to the last are cherry-picked onto the branch you're > currently on. Yes, but for bug 353171, I cherry picked the two commits, quite possibly selecting the later one first, the result had conflicts and not even a convincing result; I think a change was missing. I reset hard and tried again cherry picking one at time in the correct order; worked beautifully. Conclusion cherry pick one at a time. (In reply to comment #62) > RE [xxxx] prefixes on commit comments. This should be in the wiki. Here I feel > the bug/xxxxx should be an additional/optional column in the show commits > report, making [xxxxx] redundant. Maybe this should be an enhancement Bugzilla. EGit describes a "Bug: xxxxxx" commit note. It seems to be ignored. After viewing some history, it is clear that the [xxxxxx] is currently very useful, so I agree with Adolfo and Laurent that it should be present on all commits. I'm not keen on the auto-inserted Mylyn header; if there are multiple commits for a single bug, I would like the comment to reflect the commit intent. This is particularly true of releng commits where experimentation is necessary; the experiment should be summarized on the top line.(In reply to comment #68) > (In reply to comment #66) > > If we feel a comment change is required after cherry-picking, one way is to use > > "git commit --amend" which allows you to edit the commit message of the tip of > > the current branch, replacing this commit by another one with the changed > > commit message. Not sure how this is done in eGit, but I'm sure Laurent will > > know ;-) > > Challenge accepted! Hem... The EGit commit dialog has an amend last commit checkbox. The User Guide strongly recommends that this only used if the commit has not been pushed upstream. (In reply to comment #64) > I wanted to make sure at this point that the changes I've done so far on the > bug branch are still compatible with the changes on master. Therefore, merging > the master at any point into a bug branch is ok IMO. Why do you think it may > not be ok? The two approaches may give the same lexical result, but a different ordering. If you rebase, all changes occur after the last master change correctly reflecting the responsibility of the addition not to degrade the master. If you merge, you interleave changes into the master, so the responsibility is unclear. This matters when merges present no lexical problems but have an adverse semantic interaction. The rebase clearly shows that the bug was caused in the rebased stream. The merge can suggest that a master rather than branch commit broke the semantics. Therefore I feel we should follow the EGit guideline, always rebase before merge into master. (In reply to comment #71) > Instead, I will do that work myself : fetch, check out master, merge my bug > branch, commit, create a patch ... and provide that patch for review. The > reviewer will then only have to apply the patch, and reverse it after the > review. On my own repo, I only have to reset the merge since it hasn't been > pushed ("show in History > locate the commit with the gray "origin/master" tag > > right-click > reset > Hard" will reset the "master" branch to its "eclipse" > state). That's much more like what I wanted to do; I just couldn't Create Patch. I can now, but only between one commit and its displayed parent. However the filtering doesn't allow me to arbitrarily remove commits from view so how do I create a patch between branch and master, if master is not the parent? (In reply to comment #72) > Branch tags can easily be removed, e.g., by > > git push :bug/xxxxxx > > Of course, this should only happen after the bug branch was successfully > merged. Is this an EGIT delete? Presumably if we delete old branches, it addresses some GitHub network readability issues. However I'm not keen on deleting CM history, so I favour renaming bug/xxxxxx to archive/xxxxxx; at least until we get annoyed by them and decide to delete them after all. Ed,
I quite agree with your conclusions.
Just a correction:
>
> I'm not keen on the auto-inserted Mylyn header; if there are multiple commits
> for a single bug, I would like the comment to reflect the commit intent. This
> is particularly true of releng commits where experimentation is necessary; the
> experiment should be summarized on the top line.(In reply to comment #68)
>
Mylyn/git plugin, auto-insert in the commit box whatever you had configured in the template. However, you are still free to change the commit's comment (removing the text, adding more text to the comment, etc) before committing.
I'll definitely use this utility. A simple click (task activation, if it were not already active) would help me to avoid copy-pasting Bug id and description every time I do a commit, likewise, it allows to add some extra information to reflect the commit intent... Very useful when I have to do several commits related the same releng based bug, in which I have to see how hudson behaves with my changes.
Best Regards,
Adolfo.
It seems that GIT doesn't support CVS' $Id$ keyword substitution, so we are now carrying around misleading baggage. I found a web posting indicating that this was deliberate design; a CM that modifies your files is bad. Yes, but... the residual $Id$ have already allowed me to find one CVS increment that occurred around the time of the migration that somehow got lost by a bug merge. Maybe working $Id$ wouldn't have helped since the bad merge might have incremented anyway. I guess we just have to run a mega-search and replace to delete all $Id$. For better or worse we are now using GIT. Bug 355912 is open for PSFs. CLOSED after a year in the RESOLVED state. |