Is there any way to back out a change that has been pushed to the
remote? Would giving it a branch-name make that possible?
Henry
On 5/31/2016 8:00 AM, bill lam wrote:
It assume you have switch to the desired branch, A to E are
commits that in your "git log". Git encourages commit often, so
that you may have many commits in your git log something like in
your _local_ branch,
A1 A2 B1 B2 A3 C D E A4
where A1,..A4 are commits for the same feature, similar for
B1..B2, and you decide D is not needed. You can cleanup
using git-rebase to arrange them
A1 keep
A2 squash
A3 squash
A4 squash
B1 keep
B2 squash
C keep
E keep # D removed
so that it becomes
A' B' C E
But you cannot rebase commits that have been push to remote,
because that will affect everyone.
Вт, 31 май 2016, Henry Rich написал(а):
OK, that helps. But is it necessary to B and D to be branches? If they are
just commits, how do you identify an individual commit?
Henry
On 5/31/2016 12:56 AM, bill lam wrote:
If the changes have already been push, then use "git revert",
otherwise you can also "git rebase".
You may also want to use "git rebase" to clean up before pushing
to remote repos. eg, change commits from
A
B (buggy)
C
D (being a fix for B)
E
into
A
B' (squash B and D)
C
E
see help:
man git-rebase
man git-revert
Пн, 30 май 2016, Henry Rich написал(а):
Re: parser.
The original idea with the parser rewrite was to make it run as fast as
possible with zero change to external interfaces. As far as I can tell by
analysis and testing, that has been achieved, and it passes your test of
"this will always be with us".
I do intend further changes to the parser: one right away to fix a
long-standing bug, and eventually some code to support in-place operations.
But, while work continues on the parser, the branch 'parser' is rightly
retired, I think.
It looks like branch names should be fairly long, to be descriptive. I
should have used 'ParserPerformanceRewrite'. Shouldn't I?
You wrote:It also remains possible to revert to a version without the branch
feature.
Can you say a little more about that? For example, if changes A, B, C, and
D are made, and I want to back out B while leaving the rest, what is needed?
Henry
On 5/30/2016 4:04 PM, neit...@gaertner.de wrote:
NOTE: I have not yet deleted on the remote repo the branches that have been
merged. I will do this in a few days.
I use the initial repository
jsource 692 > git remote -v
origin g...@jsoftware.com:jsource (fetch)
origin g...@jsoftware.com:jsource (push)
and I still pull from that. Only some time after the initial JPD/JCD
announcement, http://code.jsoftware.com/wiki/Git started to refer to
https://github.com/jsoftware/jsource
as an additional read-only mirror.
Which one is "the remote repo"?
Regarding deleting a branch:
It is absolutely OK to remove branches created to deal with
specific bugs, once the work is done and integrated.
(Example: the origin/Edotnonchar mini branch.)
Is the larger work on the "parser" really, really closed, though?
In the sense of: "it passes the entire test suite; it has no (known)
memory leaks anymore;" etc. Henry?
As long as a topic branch exists, further fixes/improvements specific
to these features can be maintained. It also remains possible to revert
to a version without the branch feature.
Much more than a merging a topic branch, deleting it expresses "this
is now part of the master branch and will always be."
Martin
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
