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
|
