W dniu 27.08.2016 o 04:29, Brett Porter pisze:
In a small group, develop is the branch where all fixes/additions/... from topic
branches are merged rather dynamically. Thorough testing of commits
may lag behind, but when we think one is a pretty good commit we want
to identify it as (at least relatively) the latest stable. We could
tag it, but we would like these stable commits to be a branch in the
sense that each commit points back to a previous commit.
Merging from a development branch commit to stable isn't quite what
we want. It seems more like:
checkout the new good development commit
change HEAD to the head of the stable branch
git add --all
git commit
(maybe tag the new commit with the hash of the chosen development commit)
If you are really using topic branches, a better workflow would be
to make use of them. That is, do the development of new features
on topic branches, test them in relative isolation, and when deemed
ready merge them into development branch, for more testing (including
integration testing).
Then, those topic branches that are considered stable are merged
into stable branch ("trunk"). You can think of it as picking
features to have in stable.
Take a look at Junio's blog posts about this topic.
Will that work (one thing beyond my current understanding is if there
are index complications)? Other ideas?
That looks a bit like reimplementation of cherry-picking.
Also, I think you would loose the ability to run git-bisect to find
bad commits.
This could help with applying successively more intense testing over
time and chase down where problems arose.
Reiterationg: if you are using topic branches, use topic-branch workflow.
--
Jakub Narębski
author of "Mastering Git"
https://www.packtpub.com/application-development/mastering-git
Thank you Jakub for your feedback.
On 08/27/2016 03:55 AM, Jakub Narębski wrote:
W dniu 27.08.2016 o 04:29, Brett Porter pisze:
quoted
In a small group, develop is the branch where all fixes/additions/... from topic
branches are merged rather dynamically. Thorough testing of commits
may lag behind, but when we think one is a pretty good commit we want
to identify it as (at least relatively) the latest stable. We could
tag it, but we would like these stable commits to be a branch in the
sense that each commit points back to a previous commit.
Merging from a development branch commit to stable isn't quite what
we want. It seems more like:
checkout the new good development commit
change HEAD to the head of the stable branch
git add --all
git commit
(maybe tag the new commit with the hash of the chosen development commit)
Oops - used tag in a generic sense when discussing git -- not helpful.
Really - would put the hash of the development commit into the log message for
the stable commit.
If you are really using topic branches, a better workflow would be
to make use of them. That is, do the development of new features
on topic branches, test them in relative isolation, and when deemed
ready merge them into development branch, for more testing (including
integration testing).
Then, those topic branches that are considered stable are merged
into stable branch ("trunk"). You can think of it as picking
features to have in stable.
Ok. There are 2 things at play.... The repository contains code for an embedded
system with several subsystems (separate executables on separate processors). We
will be trying to keep testing schemes up to date with respect to the progress
on the code -- but (beyond unit/module tests), the scene will change over time;
and, users may not be able to run much form their local copies. Second, only 2
of us have used git before (and, while trying to get up to speed - I am a ways
from git guru-dom yet), while everyone else has been using visual sourcesafe for
many years.
I want others to merge their work into development sooner rather than later to
minimize their and my problem of untangling conflicts (or - you rebased while
you were sharing work with Jill and...). And, testing on their work may be limited
before they push to our main repository and some integration can be done.
I really want to create a linked list of the development branch commits that are
of interest (their working sets - not the commit objects themselves), and using the
commit object's pointer to its predecessor seems like it could just do the job.
(it wouldn't be the place to go to for history / useful log entries)
Take a look at Junio's blog posts about this topic.
Thanks for that. I will.
quoted
Will that work (one thing beyond my current understanding is if there
are index complications)? Other ideas?
That looks a bit like reimplementation of cherry-picking.
Maybe I've misunderstood cherry-picking, but I've thought it different from the
list view that I've been thinking could help us (with merges and multiple
commits).
Also, I think you would loose the ability to run git-bisect to find
bad commits.
Hmmm - I'm imagining a rather sparse stable, with perhaps time-consuming
integration testing.
quoted
This could help with applying successively more intense testing over
time and chase down where problems arose.
Reiterationg: if you are using topic branches, use topic-branch workflow.
W dniu 27.08.2016 o 15:17, Brett Porter pisze:
On 08/27/2016 03:55 AM, Jakub Narębski wrote:
quoted
W dniu 27.08.2016 o 04:29, Brett Porter pisze:
quoted
In a small group, develop is the branch where all fixes/additions/... from topic
branches are merged rather dynamically. Thorough testing of commits
may lag behind, but when we think one is a pretty good commit we want
to identify it as (at least relatively) the latest stable. We could
tag it, but we would like these stable commits to be a branch in the
sense that each commit points back to a previous commit.
Merging from a development branch commit to stable isn't quite what
we want. It seems more like:
checkout the new good development commit
change HEAD to the head of the stable branch
git add --all
git commit
(maybe tag the new commit with the hash of the chosen development commit)
Actually this is almost exactly equivalent (except for the commit
message template) to squash merge (you lose history, that is resulting
commit have only one parent), using 'ours' merge strategy (or rather
'theirs' - which does not exist in Git).
The visualization of history would look like this:
1<---2<----3<----4<----5<----6<----7 <--- unstable development branch
|\ / /
| \--a<----b<--/ | <--- topic branch 1, merged in
\ /
\---x<----y<----z<-/ <--- topic branch 2, merged in
[1]<-------------[4]<--------------[7] <--- stable branch
where [1]^{tree} === 1^{tree}, that is the state of repository is the same
Note: I don't see how this would be better from just having a stable
branch to be a subset of development branch, that is for example:
/------------------------------- stable branch
|
V
1<---2<----3<----4<----5<----6<----7 <--- unstable development branch
|\ / /
| \--a<----b<--/ | <--- topic branch 1, merged in
\ /
\---x<----y<----z<-/ <--- topic branch 2, merged in
Oops - used tag in a generic sense when discussing git -- not helpful.
Really - would put the hash of the development commit into the log message for
the stable commit.
Well, this does not change my reasoning in any way.
quoted
If you are really using topic branches, a better workflow would be
to make use of them. That is, do the development of new features
on topic branches, test them in relative isolation, and when deemed
ready merge them into development branch, for more testing (including
integration testing).
Then, those topic branches that are considered stable are merged
into stable branch ("trunk"). You can think of it as picking
features to have in stable.
Ok. There are 2 things at play.... The repository contains code for
an embedded system with several subsystems (separate executables on
separate processors). We will be trying to keep testing schemes up to
date with respect to the progress on the code -- but (beyond
unit/module tests), the scene will change over time; and, users may
not be able to run much form their local copies.
If there is problem with developers running tests (or at least running
them comprehensively, that is for all architectures / subsystems), why
not set up a continuous integration / continuous delivery server, that
would run all the tests after push?
Second, only 2 of us
have used git before (and, while trying to get up to speed - I am a
ways from git guru-dom yet), while everyone else has been using
visual sourcesafe for many years.
I have not used Visual SourceSafe myself (though I tried to use CVS
in times before Git), but I have heard horror stories about it...
As to mastering Git - I recommend "Pro Git" (free on-line book),
"Git for Teams" (though more about teams than about Git), or my
"Mastering Git" book.
For beginners, there is "Version Control By Example" (free online
version), or "Git: Version Control for Everyone".
I want others to merge their work into development sooner rather than
later to minimize their and my problem of untangling conflicts (or -
you rebased while you were sharing work with Jill and...). And,
testing on their work may be limited before they push to our main
repository and some integration can be done.
What the setup looks like? Is there a central repository where everyone
publish their changes, or is there one person responsible for integrating
changes from each developer public repository?
I really want to create a linked list of the development branch
commits that are of interest (their working sets - not the commit
objects themselves), and using the commit object's pointer to its
predecessor seems like it could just do the job. (it wouldn't be the
place to go to for history / useful log entries)
That looks like abuse of the DAG of revisions...
Anyway, even if you don't have the access to individual topic
branches, and everybody uses single central repository, merging their
changes into development branch, you can still select a subset
of development-merged topic branches to merge into stable branch.
I'll try to explain it on pictures (note: ASCII-art requires
fixed width font, and preserving spaces).
Let's assume that there are two topic branches merged into
development branch (and there are no commits made directly on
the development branch):
1<---------------2<----3 <--- unstable development branch
|\ / /
| \--a<----b<--/ | <--- topic branch 1, merged in
\ /
\---x<----y<----z<-/ <--- topic branch 2, merged in
Now, you can be conservative, and say that only topic 1 is ready
to be in the stable branch
1<---------------2 <--- stable branch
\ /
\--a<----b<--/ <--- topic branch 1, merged in
Here 'stable' is subset of 'development'.
It might turn out that topic branch 1 was prematurely merged, and
is not yet ready for stable. You could revert a merge (though
troubles lies ahead here), but you can simply select only topic
branch 2 for stable:
1<---------------------β <--- stable branch
| /
| |
\ /
\---x<----y<----z<-/ <--- topic branch 2, merged in
This is simply not possible in your approach.
That is what git.git does (see e.g. "A note from the maintainer"
https://git-blame.blogspot.com/p/a-note-from-maintainer.html).
quoted
quoted
Will that work (one thing beyond my current understanding is if there
are index complications)? Other ideas?
That looks a bit like reimplementation of cherry-picking.
Maybe I've misunderstood cherry-picking, but I've thought it different from the
list view that I've been thinking could help us (with merges and multiple
commits).
I'm sorry, it was my mistake. Cherry-picking is different: it is used
to "copy" changes as a commit (copy a commit in a sense of copying changes
and the commit message). Though git-cherry-pick can add a hash of an
original commit to the commit message of a commit created by cherry-pick.
quoted
Also, I think you would loose the ability to run git-bisect to find
bad commits.
Hmmm - I'm imagining a rather sparse stable, with perhaps time-consuming
integration testing.
That's the problem. Sparse "stable" means that if you do git-bisect on
stable, you would land on large commit, with huge changes and probably
not descriptive commit message. I other words: not that useful.
quoted
quoted
This could help with applying successively more intense testing over
time and chase down where problems arose.
Reiterationg: if you are using topic branches, use topic-branch workflow.
Regards,
--
Jakub Narębski