Bugzilla – Full Text Bug Listing
| Summary: | [server][client][push] missing git push for remote | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Piotr Janik <janikpiotrek> | ||||||
| Component: | Git | Assignee: | Project Inbox <orion.git-inbox> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | john.arthorne, robin, Szymon.Brandys | ||||||
| Version: | 0.2 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 353405 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Piotr Janik
Proposal: https://github.com/pjanik/orion.server/tree/bug352202 https://github.com/pjanik/orion.client/tree/bug352202 I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use. Piotrek, could you please rebase your branches? At least the server side one, I'm getting conflicts when merging with master. Done. There was ultra-conflict in PushJob with your last changes, so better verify carefully if everything is correct from your side. :) (In reply to comment #3) > Done. There was ultra-conflict in PushJob with your last changes, so better > verify carefully if everything is correct from your side. :) It looks that you've done well, except 2 lines in PushJob: fields taskService and taskServiceRef can be removed. Created attachment 200514 [details]
Actions on remote
Pitorek I'm not able to locate the new action. I thought it was supposed to available on a remote, next to Add Remote. Am I missing something?
Created attachment 200515 [details]
mylyn/context/zip
(In reply to comment #5) > Actions on remote > > Pitorek I'm not able to locate the new action. I thought it was supposed to > available on a remote, next to Add Remote. Am I missing something? It's next to the "Fetch Remote". Its tooltip is "Push Remote". You have to look one level deeper. ;) (In reply to comment #4) > It looks that you've done well, except 2 lines in PushJob: fields taskService > and taskServiceRef can be removed. Thx, server branch updated. I'm sorry but it doesn't work for me, at least not as I would expect. Here are steps I followed in the client: 1. Create two clones of the same repo 2. Make sure they have at least two remote branches and that they're in sync 3. In the first clone, make changes on both branches and commit them, do not push yet 4. Go to Repos page and click Push on the remote 5. On the same page, on the second clone, drill down to its remote, do "Fetch" 6. Merge the fetched changes, or checkout those branch and examine if the changes made in 3. are there => SHOULD BE: changes from both branches should be available (pushed in 4. and then fetched in 5.) => IS: only change from the branch that was active while pushing (4.) are available Please note that I haven't checked what actually took place within those clone with git bash. Neither I've prepared a test case that would mimic the steps. Maybe I simply missed something obvious in the UI, but I have a gut feeling that something is wrong. Yes, you missed something. "git push remote_name" pushes only HEAD when there is no config entry "remote.remote_name.push" with refspec. I suppose that you haven't configured such thing, so only HEAD was pushed. It's expected behavior of Git, even covered by my test case afair. If you want to have all branches pushed, add "remote.remote_name.push" entry with value "refs/heads/*:refs/heads/*" (it's only one example). (In reply to comment #10) > "git push remote_name" pushes only HEAD when there is no config entry > "remote.remote_name.push" with refspec. That's funny, because it doesn't work like that in my case. Here's the result of doing the same steps as in comment 9, but this time in git bash: $ git push origin Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (6/6), 468 bytes, done. Total 6 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (6/6), done. To d:/temp/test.git 9ed21bd..ebd9d18 master -> master 2529cc0..a429642 test -> test Notice two branches being pushed. And my config looks like this: [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true hideDotFiles = dotGitOnly [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = d:/temp/test.git [branch "master"] remote = origin merge = refs/heads/master [branch "test"] remote = origin merge = refs/heads/test No sign of "remote.remote_name.push". Anyways, even if you're right I think the action should be more descriptive if the config entry hasn't been set. A tip saying that only the current branch will be pushed and an info where to change that would safe others from the confusion, which I agree is caused by not knowing how the operation works in detail. I've also noticed that the tests you've added fail when rebased with latest changes by Szymon. It seems that all you need to do to make them turn green again is use ProtocolConstants.KEY_FULL_NAME in your assertions. Could you please update them? Ok, case is strange. There are two cases:
1. When I have two branches: master and newbranch, and newbranch wasn't earlier pushed to the remote - only master is pushed after "git push origin".
2. When newbrach exist on the remote - both branches are pushed.
However, look at JGit code:
PushCommand.call() {
[ ... ]
if (refSpecs.isEmpty()) {
RemoteConfig config = new RemoteConfig(repo.getConfig(),
getRemote());
refSpecs.addAll(config.getPushRefSpecs());
}
if (refSpecs.isEmpty()) {
Ref head = repo.getRef(Constants.HEAD);
if (head != null && head.isSymbolic())
refSpecs.add(new RefSpec(head.getLeaf().getName()));
}
[...]
That's the reason. I was reading it earlier and probably verified only with case 1 from Git bash.
(In reply to comment #13) > 2. When newbrach exist on the remote - both branches are pushed. Take a look at step 2. in comment 9. > However, look at JGit code: I'm pretty sure, we both know we should not treat JGit as a reference implementation ;) Tests updated. Have you referenced bug 353405 and bug 353406 in the code? I decided to hold off with releasing the change until bug 353405 is fixed. This makes bug 353406 invalid as it never actually existed. This is still blocked by bug 353405 in JGit. If it's not fixed within a week or so I will change the target to 0.4. To match the reality. Just so I understand correctly, would this allow pushing to multiple remotes at once? No, the bug is about being able to push to a single remote. The problem here is that current implementation of JGit doesn't work as expected, ie. it doesn't push to branches that already exist on the remote. It does it only for the current branch. This is quite different from what you would expect by running "git push origin" in the console, it pushes changes from all local branches that exist remotely. This could be fixed in configuration but I'd rather wait for a fix in JGit. Paraphrasing your question: this would allow pushing to multiple branches of a single remote at once. Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |