Guys,
Confirmed. After rebasing, the push is rejected (even if I have not
done the merge of the bug into the master) ...
In the attachment you may see both, the result of the push and the
repository history view.
I've done the following:
1. Fetch from upstream.
2. Rebase bug/318090 on to master. I'm interested in doing this,
because I want a commit ([353403]...) from the master which appeared
when the bug/353403 was merged into master.
3. Push... -> Next -> Add an specif ref
(refs/heads/bug/318090) -> Add spec -> Next
P.S: You may try this by yourself, create a local bug/318090 from
the remote tracking origin/bug/318090 branch and follow the steps
above.
Best Regards,
Adolfo.
El 05/08/2011 16:49, Adolfo Sánchez-Barbudo Herrera escribió:
Laurent,
I'm not sure I follow... Your last sentence seems confusing to
me....
Have you tried (Do you usually do) this ?
Comments step-by-step:
El 05/08/2011 15:03, Laurent Goubet escribió:
Adolfo,
If I am not mistaken, you are missing a push in order to avoid
messing the history :
1 Fetch changes
Ok.
2
rebase master on top of origin/master
Ok.
3
rebase bug/xxx on top of master
Ok.
4
Push the bug branch! You need to push the rebase in order for
the remote repository to know that origin/bug/xxx has been
rebased on top of origin/master
I didn't that and I can't do it now... But, after rebasing I'd
have something like the following in the history view:
B' - bug/xxxx
A' -
O - master, origin/master
...
B - origin/bug/xxxx
So that, a merge of the bug/xxxx into local master, would imply a
simple fast forward of the local/master:
B' - bug/xxxx, master
A'
O - origin/master
...
B - origin/bug/xxxx
A
I don't understand why I need to push (the bug branch) prior to do
the merge (of the bug and master branches). Actually I think that
the problem comes from the rebasing that was done in the previous
step.... Anyway, just speculating. I'll try to do any kind of
experiments in local.
5
merge bug branch into master
Ok.
6
Push the merge
Ok.
If you push the merge before (6), you are advancing the remote
"origin/master" branch by one commit, which will prevent the
rebasing of the bug branch to be pushed.
Actually, I had not done any push when detecting the rejected
push... I simply run the "push..." action and after "adding all
branches spec", the wizard said that the bug/xxxx would be
rejected and the master one accepted (but the no push was done at
that moment).
More clues about that rebasing may be the cause of the problem: If
I synchronize my workspace (having bug/xxxx as the current checked
out branch) against the remote tracking origin/bug/xxxx branch, I
see conflicts in the unique changed file for the bug (plus the new
changes which come from the rebased master), which may be the
cause why the push is rejected. If I open the compare editor, I
see no changes in said file. The same file with the same content
(changes) in both branches has conflicts, perhaps giving the fact
that the the changes come from different commits (rebase duplicate
the commit) may be the cause of detecting such a conflict.
Regards,
Adolfo.
Laurent
On 05/08/2011 15:45, Adolfo Sánchez-Barbudo Herrera wrote:
Ed,
More use cases:
In the major change protocol, I'm missing the point in which
we are interested in having changes from an updated local
master into a bug branch. Some reasons to do that:
- To ensure we don't have conflicts in the bug prior to
merging the changes into the local master branch (i.e test an
hypothetical resulting merge in the local branch rather than
in the local master)
- When creating a patch, we should be sure that the list of
commits done in the branch are done against an updated master,
so that applying the patch by other is trivial.
- When a change, which has been added in the master branch and
it has been done after the bug creation, may be relevant when
developing and/or testing said bug branch.
I've found the Rebase command ideal to do this [and
recommended by git doc http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase]
.
I've successfully done that with EGit (bug/353403). "that"
means:
- Fetching and rebasing local master on top remete
origin/master.
- Rebasing bug/353403 on top local master.
- Merging bug/353403 into local master.
However, I've found a minor inconvenience when pushing to
upstream: The bug/353403 push is rejected (although the master
push is ok). This could make sense, the rebase makes the bug
change the point/tip) to which the branch points to, there is
a new chain of commits, etc, and EGit (GIT?) simply doesn't
allow to push ... The point is... What to do now? ... This
inconvenience is quite irrelevant once the bug has been ended
up, since the remote bug will be deleted anyway (we rename the
local bug/xxxxx branch to archive/xxxxx... and simply push).
However, it could be more irritating during the development of
the bug.
Should we :
a) delete the bug from the remote repository (and probably the
remote tracking one from the local repository) and push again
?
b) Renaming the bug (a,b,c...) every time we rebase?
c) Any other idea ?
Best Regards,
Adolfo.
El 04/08/2011 9:27, Ed Willink escribió:
Hi Axel
Thanks. Yes, that looks to provide the key.
You have to have a local branch to push as the new (renamed)
upstream branch.
Then the Push... Dialog allows push of the new and of the
delete in one go.
Then the local tracking branch can be manually deleted; it
seems like a bug that it isn't deleted by a Fetch or Pull
from Upstream.
So once we get in the habit of pruning the upstream bug
braches, everybody can keepo deleting remote tracking
entries, knowing that
they can be brought back again if needed.
Regards
Ed
On 04/08/2011 08:55, Axel Uhl wrote:
Sorry, I can tell you how I would
rename a remote branch using the command line. I'm not
aware of a way to do this in one command. But it's
possible to push to a new remote branch with the new name
and then delete the old branch. I guess this sequence
should also be possible with eGit.
git push origin localBranch:newRemoteBranch
git push origin :oldRemoteBranch
Cheers,
-- Axel
On 8/4/2011 9:14 AM, Ed Willink wrote:
Hi
- OptionallyArchive Old topic
Branch
<http://wiki.eclipse.org/MDT/OCL/Dev/EGit#Archive_Old_Branch>to
prune
the EGit displays
When renaming a local branch, will the branch be
renamed in the
Eclipse repository. Wouldn't be we probably have two
branches
(bug/xxxxx and archive/xxxxx) in the repository ?
Have anybody tried
that ?
I think it should work since rename is supported. If
not Delete the
extra one.
It doesn't work. Or at least the EGit rename of a remote
tracking branch
works within the remote tracking display, but there
seems no way to push
the rename upstream, so other downstreams don't fetch it
and a fetch
from upstream re-instates the original name leaving
original and renamed
remote tracking branches.
A delete doesn't work either; it just temporarily
removes the name from
the remote tracking branches list.
Any ideas how to rename/delete a branch upstream
(preferably with EGit)?
Regards
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1518/3809 - Release
Date: 08/03/11
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
