[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master c6f03ed: Fix a problem in url.el without GnuTLS

From: Eli Zaretskii
Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS
Date: Tue, 16 Dec 2014 21:42:47 +0200

Thanks for taking the time to explain and make suggestions.

> From: David Engster <address@hidden>
> Cc: address@hidden
> Date: Mon, 15 Dec 2014 21:39:58 +0100
> >     when I work on a feature branch that takes weeks, sometimes
> > months, to complete, I merge from master near the end of the
> > development, to make sure landing the feature will not introduce
> > regressions.  Sometimes there's more than one such merge, especially
> > if I discover subtle issues as result of merging.

> I see. I guess you could avoid those problems by merging origin/master
> instead.

Sorry, I don't understand: doesn't origin/master have the same commits
as master (modulo the local commits I did on master since the last
pull)?  If so, how would merging origin/master help me?

Once again, the problem is in this situation:

 . My work on a feature branch is almost finished, so I merge from
   master to make sure my feature doesn't break anything and isn't
   broken by development on master.

 . I then merge from the feature branch to master and attempt to push,
   but the push is rejected.

 . I then pull --rebase=preserve and push again

It's the last step that causes trouble, and the "trouble" here is that
commits I merged from master before merging back might be merged again
in the future, if I need for some reason to continue working on that
feature branch again.

Where will origin/master help in this situation?

> But actually, instead of merging master into your feature
> branch, I'd rather recommend rebasing it *onto* master, but explicitly

That'd lose too much information, so I'd like to avoid that if
possible.  It might also cause complications if I have more than 1
active feature branch, and want to compare or merge between them.  It
is also a bad idea when the branch is a public one, as you point out.

> For local feature branches, I would recommend the following (not saying
> this is "the right way" or anything, but maybe you find something useful
> in there):
> - Instead of merging master into my feature branch, I rebase it
>   explicitly by doing
>   git checkout featurebranch
>   git rebase master
> - I only merge feature branches into master when they are finished and I
>   plan to push directly afterwards.
> - Before merging to master, I rebase onto it one last time so that the
>   merge has no conflicts, then I merge with '--no-ff' and push.
> - If the push fails because there are new commits upstream, instead of
>   using 'pull --rebase=preserve', I rather delete the merge so that I
>   get a "normal" fast-forward pull and merge again. If I'm really
>   unlucky, this new commit from upstream causes a conflict now, in which
>   case I usually just resolve it, simply hoping that the push will work
>   next time.

If "merge --no-ff" and aborting the merge when a push is rejected are
to be used anyway, why do I need to rebase the feature branch onto
master?  That doesn't seem necessary.  I could use normal merges, no?

> Of course, for *public* branches like emacs-24, one must not use
> 'rebase' in any way but do a normal merge. If the push fails, do a
> regular 'pull' so that the new commits are merged and push again.

I would like to have the same workflow for both local branches and
public ones, such as emacs-24, if at all possible.  That will relieve
the "memory pressure" and reduce the probability of errors.

> > No.  When development was on a branch, I generally want to preserve
> > that branch in the history, not flatten it.  My commits on a feature
> > branch follow some logic that is important to me (and documented in
> > the commit log messages), so that long after the job is done these
> > commits make it easier to understand why something was done the way it
> > was, and also find the reasons for bugs or misfeatures.

> I agree. I misunderstood your statement that your commits should not
> look like they were made on another branch, but if I understand you
> correctly now, you mean you don't want to have merge commits from master
> before pushing, but you rather prefer to rebase (to which I agree as
> well).

I actually don't mind merge commits, as long as they reflect what was
actually done, as opposed to being generated by Git out of thin air.

What I certainly want to avoid is any kind of rebasing, cherry-picking
or similar things that will then put me at risk of having the same
commits merged again, because the original commits are rewritten or
not recorded in the DAG.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]