GNOME.org
 

Re: Question about git

On 05/06/2009 07:00 AM, Simos Xenitellis wrote:

On Tue, May 5, 2009 at 4:41 PM, Behdad Esfahbod<behdad behdad org>  wrote:

On 05/05/2009 01:28 AM, Shaun McCance wrote:


This assumes that the branch is merged into master otherwise.  I strongly
suggest cherry-pick instead of merge.

Isn't that going to cause merge conflicts for me the
maintainer when I try to merge from my stable branches
to master?  I can pretty much guarantee I will always
do that.  If I have to deal with merge conflicts from
one of 100 translations each time, I'm not going to
be happy.

I *think* if the same commit exists in the destination, it doesn't cause a
merge conflict.  But I didn't test it to make sure right now.


I have tried a few scenarios with 'git merge' and I managed to get a
situation that merge could not take place.
After that, it was not possible to commit and the message was too
cryptic to figure out what to do.
In terms of usability for this process, it was good (I was blocked
from messing up further),
so I resorted to the HowTo item from live.gnome.org named 'Ok, I
messed up, what do I do' in order to reset my clone.

As a workflow, I find that the following is easy to follow
1. First commit to your branch (such as gnome-2-26) as normal.
2. Then, checkout 'master' and 'git merge gnome-2-26'
3. Observe that no errors appear and that only your changes are merged.
4. Do a 'git push' to push your work to git.gnome.org.
What if the branch was not merged, perhaps intentionally? Now the translator will be pushing code changes. 


I am OK to add a section in the HowTO for 'git cherry-pick'. I find however
the process more error prone due to the fact that one needs to figure
out the hash
of the last commit(s) in the branch and use that for cherry-picking.
If it's indeed the last commit, they can cherry pick the branch tip by just cherry-pick'ing the branch. Right? 

behdad


Simos
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]