On 07/31/2018 07:31 PM, Chase wrote:
Ahh now I see, thats what I did the first time, so I need to commit the reverts
as well? Because I did revert the commits on my side. Everything works without
errors, just compiler warnings.
When you do a revert, it will add a new commit that undoes the changes
of the commit you are reverting. If you do a git log, you will see the
revert commit there. So reverting creates the necessary commits for you.
When you create your patches via "git format-patch", just make sure to
include *all* of your commits, including the commits created by "git
revert".
-jon
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 31, 2018 8:28 PM, Jon Trulson <j...@radscan.com> wrote:
I think Matthew explained it pretty well. You might do some reading up
on git, and typical git workflows - there's tons of docs out there.
But essentially:
You create a branch from current master, revert the 2(?) previous
commits that removed dtudcfont* programs (look at the "git revert"
command). Use git log to look at the commit history.
Then add your changes, then commit them.
Or you can add your changes in multiple smaller commits (advisable in
case you break something).
But the key point is that it is YOU that does the reverts in your branch.
Then when you have it working and want to submit it, you send a patch
set composed of the patches to apply. This will (should!) include the
reverts you did, in addition to whatever other commits you made since
the branch to get it working.
Rebase your branch on master from time to time to keep your branch up to
date, and especially do this before submitting your final patches to
ensure it will apply.
But before you do that, it needs to actually work completely.
-jon
On 07/31/2018 06:48 PM, Chase wrote:
I guess I'm just having trouble understanding what I must do differently, does my patch
simply need to be rebased and the commits deleting dtudcfonted can be reversed on your
end, or do I need to manually readd all the previous files by hand from a previous
version and repatch? Because one solutions seems a bit more like "madness" than
the other. As for it being almost but not quite finished, I simply need to fix the
remaining compiler warnings, problem is they are kind of stumping me, so I'd like it
committed so that I could have some possible pointers on what I could do better and how
to fix them.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 31, 2018 2:36 PM, Jon Trulson j...@radscan.com wrote:
Yes, what Matthew said below is the way to go - you don't have to throw
everything away and start over from scratch -- though you will need to
start a new, clean branch from master and "construct and maintain" it
properly as Matthew outlines below.
It is important to rebase from time to time as you develop, since as
you've seen, the upstream branch (master in this case) is likely to
diverge while you work on your stuff.
It is definitely a good idea, if not a requirement, to rebase (and of
course fix any conflicts) before preparing a patch or patch set for
submission.
This is common git work flow, so it's worth learning how all this works.
-jon
On 07/30/2018 09:04 PM, Matthew R. Trower wrote:
Chase via cdesktopenv-devel cdesktopenv-devel@lists.sourceforge.net
writes:
To be honest, I don't know how I would go about doing this, help would
be appreciated. Is it at least pheasable to revert the previous
commits and apply this one? I put a lot of work into it. My git
workflow consists of master and then a custom branch where I reverted
the previous commits and patched the software.
That sounds about right. I assume by revert, you mean that you used
`git revert` to cancel out the commits which removed the component to
begin with. So:
- `git checkout -b dtudcfonted`
- `git revert <commit>...`
- Make some commits fixing up the software
- `git rebase master`
You'll need to rebase your branch on master at the end to make sure your
patch is applied to the latest code. I believe Jon wants this fully
fixed up before he will merge it. Him and I discussed these
requirements in a previous thread on this list. As this may take some
time, you may want to periodically rebase to keep the branch in sync,
rather than doing one big rebase at the end.
When you finally do submit, you need to submit all of the patches on
your branch - including the initial reverting commits. This could take
the form of several patches in one E-Mail, or one big squashed patch.
Does this clear things up for you?
-mrt
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
--
Jon Trulson
"Fire all weapons and open a hailing frequency for my victory yodle."
- Zapp Brannigan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
