[Wine] Re: No hide button in 0.9.60 ?

[vitamin]

James McKenzie wrote:
> vitamin wrote:
> 
> > [text on git-revert and git-show | patch -p1 -R removed]
> > 
> > They do both alter source code you are correct. However, that's the only thing my method does. What Austin suggests alters index.
> > 
> > What "git revert" does is it creates and commits a reverse patch on top of HEAD. This something for developers to deal with. And they know where to look and what to do.
> > 
> > 
> > 
> Thank you for the explanation.  However, will the user have to grab a 
> new git or can this simply be undone with the 'git-show | patch -p1' 
> sequence?


That command modifies source only not the git index. Git is different from cvs in the way that all the information is being kept internally. When you modifying source - your are not altering git repository itself.

 To revert source changes you can do number of things:
1. git show <patch-id> | patch -p1   - exact reverse of the original command
2. git checkout -f   - reset all the source changes you might have made
3. git reset --hard  - used this way is exactly the same as #2



James McKenzie wrote:
> This should be explained as well in a Wiki article. 
> 
> > For users it will create extra set of problems. As they can't do 'git pull' anymore - their "master" is no longer the same as "origin". And they explicitly have to remove that commit with "git reset --hard". And if you forget to do this and continue on the standard path 'git fetch; git rebase origin' you will end up with problems down the round. You still have that revert patch in your tree!
> > 
> > 
> > 
> This would seriously break the git.  I usually do a git and then branch 
> into another so that I can work with the problem as defined in issue 
> 6254.  This eliminates not being able to pull the next update.  However, 
> this does lead to a serious use of hard drive space.

Creating branches in git is almost free. The only cost is one file 41 bytes long (not counting additional patches specific for that branch).

However in your case you should really commit that patch into your tree. Then doing 'git fetch && git rebase origin' when updating tree. What that operation does is:
- Downloads new patches from upstream (winehq.org)
- Removes your patches and "forwards" your repository to where upstream is
- Re-applies your extra patches on top.

This is a standard procedure Wine developers go through until their patches are accepted upstream.