Skip to main content

[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


--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231


_______________________________________________
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


Back to the top