[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] EGit Guidelines
|
Adolfo,
If I am not mistaken, you are missing a push in order to avoid
messing the history :
1 Fetch changes
2 rebase master on top of origin/master
3 rebase bug/xxx on top of master
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
5 merge bug branch into master
6 Push the merge
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.
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
|
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard
