Hi
Finally plucked up the enthusiasm to look at this nasty GIT problem.
Adolfo:
I see local/master as purely temporary, so I would bypass one stage
in your activities by rebasing the local/bug/xxx on top of
origin/master. Using the local/master in both downstream and
upstream sub-workflows creates an ambiguity between rebase
downstream and merge upstream.
Laurent:
The extra Push... seems to explain a few weird things I've seen too.
But I'm not sure that I understand it.
[In practice I no longer "Push to Upstream" since it pushes all
local branches, hence some of the extra clutter that I pushed
inadvertently. I now always Push... so that I push only what I
intend.]
Surely whenever a push is performed, all relevant commits are
transferred, so the upstream repository can create the updated
history rather than report a conflict? If it's possible to push the
rebase upstream as a merge in tow stages, why isn't it possible in
one stage?
-----
I've had some major difficulties rescuing some branches that I did a
month ago before I had the confidence to push them to master.
Create patch failed totally (https://bugs.eclipse.org/bugs/show_bug.cgi?id=343276)
and compare was very flaky (https://bugs.eclipse.org/bugs/show_bug.cgi?id=354074).
I had to resort to cutting all changed lines into a naked text edit
while the old branch was in use, then reediting after switching to
the branch state from which I wished to progress.
Regards
Ed
On 05/08/2011 15:03, Laurent Goubet wrote:
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
_______________________________________________
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.1391 / Virus Database: 1518/3811 - Release Date:
08/04/11
|