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
|