From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:10
Joel Becker [off-list ref] writes:
On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:
quoted
Do you think anybody is that perfect?
I was being slightly facetious. Of course everyone makes
mistakes and corrects them. But if you _want_ the history, you have to
take it. Otherwise, you are required to throw away the history
completely. And that -- do you want the whole history or none of it --
is the crux of my question.
I could care less about preserving my public image. I'm an
idiot, I screw up all the time. I only care that the tip of my tree is
respectable.
I've seen arguments from folks on both sides -- the intermediate
history is important, warts and all, vs throw it all out for a clean
public history. It seems that you fall into the second camp.
That's fine, but can we make that work model a first-class
citizen? Can we get a script that pulls one branch as a single,
un-historied (sic) commit into the current branch?
I think you read me wrong. Didn't I say "decompose and make
them into logical stepS", emphasis on plural "S"?
Single big consolidated patch is not what I am advocating for.
It is impossible to review and evaluate. To be merged into a
public tree, such unhistoried commit is often unacceptable.
From: Joel Becker <hidden> Date: 2016-06-15 22:42:10
On Mon, Oct 31, 2005 at 02:14:58PM -0800, Junio C Hamano wrote:
I think you read me wrong. Didn't I say "decompose and make
them into logical stepS", emphasis on plural "S"?
Single big consolidated patch is not what I am advocating for.
It is impossible to review and evaluate. To be merged into a
public tree, such unhistoried commit is often unacceptable.
No, you're reading me wrong, but I wasn't clear enough either.
At the end of my message, I'm noting that I'm considering smaller
changes here, not huge features.
Basically, I'm not talking about merging with Linus. I'm
talking about merging with myself. Let's assume we're all going with
the clean-up-your-history model. It is quite clear that you and Linus
agree on that model, and I wasn't so much arguing against it as querying
everyone's opinion on it.
So, I have a git repository that is my For-Linus repository.
It's got a clean history. What's my workflow?
1) Clone the repo to a Work tree.
2) Create and test fix X, with perhaps some >1 number of commits.
3) Bring that fix back to the For-Linus repository.
This is a small change. It's not something that needs stepS, as
you put them. But my history in the Work tree is "dirty," so I cannot
just pull from Work to For-Linus.
As the tools currently stand, I need to hand-diff and patch my
commits. Neither git nor cogito have a command to do this first-class
"the way you should do it" common operation. It is, in my experience, a
pain. Not as large a pain as some things, but certainly second class to
much of the workflow git/cogito provide. If it is supposed to be a
regular part of my workflow, what's wrong with making it a first-class
operation?
Obviously, large features should and do have logical steps. I'm
never going to be against that.
Joel
--
Life's Little Instruction Book #15
"Own a great stereo system."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
On Mon, Oct 31, 2005 at 02:42:46PM -0800, Joel Becker wrote:
As the tools currently stand, I need to hand-diff and patch my
commits. Neither git nor cogito have a command to do this first-class
"the way you should do it" common operation. It is, in my experience, a
pain. Not as large a pain as some things, but certainly second class to
much of the workflow git/cogito provide. If it is supposed to be a
regular part of my workflow, what's wrong with making it a first-class
operation?
For an example of how to make it a first-class operation, it might be
worthwhile to look at Chris Mason's "Mercurial Queues" extention to
Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
I've used it once or twice, and hg mq is definitely very nice and
convenient, and it makes commits a first-class operation. On the
other hand, I've found that the combination of quilt and
Mercurial/BK/git works just fine, even for my own internal development
of (for example) the e2fsprogs tree.
- Ted
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:10
On Mon, 31 Oct 2005, Joel Becker wrote:
So, I have a git repository that is my For-Linus repository.
It's got a clean history. What's my workflow?
1) Clone the repo to a Work tree.
2) Create and test fix X, with perhaps some >1 number of commits.
3) Bring that fix back to the For-Linus repository.
This is a small change. It's not something that needs stepS, as
you put them. But my history in the Work tree is "dirty," so I cannot
just pull from Work to For-Linus.
As the tools currently stand, I need to hand-diff and patch my
commits. Neither git nor cogito have a command to do this first-class
"the way you should do it" common operation.
I actually have a set of scripts that I use for this, which I've been too
lame to clean up properly and send in. The basic idea is:
(1) "git branch clean mainline"
(2) "git checkout clean"
(now I'm looking at the clean history, which doesn't have anything
yet)
(3) "git refine dirty"
(this says I'm trying to match the content of the head with the
dirty history)
(4) editor window pops up with the diff between the working tree and
dirty
(5) edit the patch, removing hunks which go later in the series, or which
I don't want to do at all and forgot to revert.
(6) it applies the patch; if there are rejects, it goes back to (4)
(7) normal thing for committing happens
(8) if there is any difference between the working tree and dirty, it
goes back to (4) for the next in the series
I still need to correct the flow control and make it invoke the editor
automatically and such, and provide some way out of the middle if you want
to give up or stop without reaching the end, and I have to detect the done
condition. But the general method does work, provided you're at least
somewhat comfortable editing patches (with the safety net that nobody else
will ever see the patch, so it doesn't matter too much if you screw it
up).
If somebody else wants to clean this up, I can post my version; dunno when
I'll get around to making it really right.
-Daniel
*This .sig left intentionally blank*
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:10
Dear diary, on Tue, Nov 01, 2005 at 01:25:54AM CET, I got a letter
where Theodore Ts'o [off-list ref] told me that...
For an example of how to make it a first-class operation, it might be
worthwhile to look at Chris Mason's "Mercurial Queues" extention to
Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
I've used it once or twice, and hg mq is definitely very nice and
convenient, and it makes commits a first-class operation. On the
other hand, I've found that the combination of quilt and
Mercurial/BK/git works just fine, even for my own internal development
of (for example) the e2fsprogs tree.
Did anyone do any current detailed comparison between hg mq and StGIT?
I'm very happy with StGIT, modulo few UI gripes I'm still not getting
around to fix, and the fact that I cannot version my changes to patches
- this is one advantage of having quilt stuff tracked by GIT, I think,
but that feels ugly.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
Did anyone do any current detailed comparison between hg mq and StGIT?
Not AFAIK. I looked a bit at mq but didn't have time to play with it.
I'm very happy with StGIT, modulo few UI gripes I'm still not getting
around to fix, and the fact that I cannot version my changes to patches
- this is one advantage of having quilt stuff tracked by GIT, I think,
but that feels ugly.
That's not too far away. Chuck Lever has a patch (and there were some
other discussions in the past) for tracking the history of a patch.
Basically, there would be another commit object, not reachable from
HEAD but only via an StGIT command, which would chain all the versions
of a patch. You would be able to view them with gitk for example.
My main issue was whether we should store every state resulted from a
refresh or use a separate command (somebody suggested 'freeze') to
mark the states that should be preserved in the history. Chuck's patch
implements the first. The drawback is that a future 'stg prune'
command would not be able to remove the history and some states of the
patch might not be useful (there are times when I do a refresh only to
pop the patch and modify a different one, without any logical meaning
for the state of the patch).
I'm open to other suggestions as well. Otherwise, Chuck's patch should
do the job.
--
Catalin
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:10
Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
where Catalin Marinas [off-list ref] told me that...
On 01/11/05, Petr Baudis [off-list ref] wrote:
quoted
and the fact that I cannot version my changes to patches
- this is one advantage of having quilt stuff tracked by GIT, I think,
but that feels ugly.
That's not too far away. Chuck Lever has a patch (and there were some
other discussions in the past) for tracking the history of a patch.
Basically, there would be another commit object, not reachable from
HEAD but only via an StGIT command, which would chain all the versions
of a patch. You would be able to view them with gitk for example.
Perhaps you could emulate the topical branches - one patch == one head.
E.g. for patch foo-bar on branch 'master', you would create head
master/foo-bar, etc.
My main issue was whether we should store every state resulted from a
refresh or use a separate command (somebody suggested 'freeze') to
mark the states that should be preserved in the history. Chuck's patch
implements the first. The drawback is that a future 'stg prune'
command would not be able to remove the history and some states of the
patch might not be useful (there are times when I do a refresh only to
pop the patch and modify a different one, without any logical meaning
for the state of the patch).
I'd prefer the snapshotting being done in refresh anyway. Perhaps you
would be asked for log message when you refresh by default, but when you
refresh -n or something, only a temporary commit would be created and
next refresh would mutate it instead of creating another commit.
Anyway, "freeze" is confusing. Perhaps "snapshot" if anything...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
From: Chris Mason <hidden> Date: 2016-06-15 22:42:10
On Tue, Nov 01, 2005 at 10:08:04AM +0100, Petr Baudis wrote:
Dear diary, on Tue, Nov 01, 2005 at 01:25:54AM CET, I got a letter
where Theodore Ts'o [off-list ref] told me that...
quoted
For an example of how to make it a first-class operation, it might be
worthwhile to look at Chris Mason's "Mercurial Queues" extention to
Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension
I've used it once or twice, and hg mq is definitely very nice and
convenient, and it makes commits a first-class operation. On the
other hand, I've found that the combination of quilt and
Mercurial/BK/git works just fine, even for my own internal development
of (for example) the e2fsprogs tree.
Did anyone do any current detailed comparison between hg mq and StGIT?
I don't think so, but I'll give it a rough try. I have not used stgit
extensively, so please correct any mistakes below. Most of the
differences center around the ways we store patches.
Both tools make patches into commits during push. This allows the
various history commands to see the currently applied patches.
Both tools allow you to make changes to files without running some form
of quilt add first.
StGIT has the ability to rebase patches via three-way merge. This is
still on my todo list for mq.
StGIT patch storage is very different from quilt and mq. StGIT keeps
git commit/tree objects around for patches that have been applied. It
then stores a directory with metadata about the patch
(author/description etc) and the ids of the git commit objects.
In StGIT, importing new patches seems to require stg import, and exporting patches
requires stg export (or a similar git command). But once the patches
are stored in stgit, push/pop will be very fast.
mq is closer to quilt. The patches are stored as patches, and hg qpush
is very similar to importing a patch. This means metadata must be
stored at the top of the patch in some form the import code can
understand (it tries to be smart about this).
hg qrefresh will update the patch file, so the patch is always up to
date wrt to the hg repo.
You can import/export patches with hg commands, or by copying patches
into/from the .hg/patches directory. This also means you can take a
quilt patch dir, copy it into .hg/patches and just start using mq.
mq has some support for putting the patches directory under
revision control (as a separate repository).
Most of the other differences come from differences between hg and git.
I'm not sure if stgit has some form of annotate, but it's a nice way to
find out which patch changed a given loc in hg/mq.
-chris
From: Chuck Lever <hidden> Date: 2016-06-15 22:42:10
Catalin Marinas wrote:
On 01/11/05, Petr Baudis [off-list ref] wrote:
quoted
Did anyone do any current detailed comparison between hg mq and StGIT?
Not AFAIK. I looked a bit at mq but didn't have time to play with it.
quoted
I'm very happy with StGIT, modulo few UI gripes I'm still not getting
around to fix, and the fact that I cannot version my changes to patches
- this is one advantage of having quilt stuff tracked by GIT, I think,
but that feels ugly.
That's not too far away. Chuck Lever has a patch (and there were some
other discussions in the past) for tracking the history of a patch.
Basically, there would be another commit object, not reachable from
HEAD but only via an StGIT command, which would chain all the versions
of a patch. You would be able to view them with gitk for example.
My main issue was whether we should store every state resulted from a
refresh or use a separate command (somebody suggested 'freeze') to
mark the states that should be preserved in the history. Chuck's patch
implements the first. The drawback is that a future 'stg prune'
command would not be able to remove the history and some states of the
patch might not be useful (there are times when I do a refresh only to
pop the patch and modify a different one, without any logical meaning
for the state of the patch).
I'm open to other suggestions as well. Otherwise, Chuck's patch should
do the job.
if there is interest i can post what i have. unfortunately there's some
other stuff in front of it so i don't think it will apply directly to
catalin's stgit without some futzing. in lieu of that, here's a command
synopsis:
[cel@seattle ~]$ stg revisions -h
usage: stg revisions [options] [patch-name]
Display the change history of a patch or revert a patch to a previous
commit. By itself, the command will display all committed changes,
ordered by date, of a patch. Each committed change is listed with a
numeric label. The label can be used with the --patch or --diff options
to examine specific changes in detail. The --revert option can revert
a patch to any previous version.
options:
--commit=commit-label
show the commit details of the specified commit
--diff=commit-label show changes between the specified commit and
the next
--file=<file name> show changes made to a specific file
--patch=commit-label show the state of patch-name at the specified
commit
--revert=commit-label
revert the patch to the specified previous commit
-h, --help show this help message and exit
[cel@seattle ~]$
and some usage examples:
[cel@seattle main]$ stg revisions
Previous revisions of patch "revisions-command":
0: Sat Oct 1 21:54:43 2005 -0400
1: Sat Oct 1 21:58:45 2005 -0400
2: Sat Oct 1 22:13:27 2005 -0400
3: Sat Oct 1 22:55:28 2005 -0400
4: Sat Oct 1 23:02:22 2005 -0400
... snipped ...
86: Mon Oct 31 14:19:25 2005 -0500
87: Mon Oct 31 14:22:00 2005 -0500
88: Mon Oct 31 14:23:40 2005 -0500
89: Mon Oct 31 14:24:39 2005 -0500
90: Mon Oct 31 14:27:34 2005 -0500
[cel@seattle main]$
an entry is added to this list automatically after every operation that
does a "refresh".
the idea is to expose and manipulate the change history of a patch
without having to use cumbersome sha1 hash values.
without options, "stg revisions" shows a list of changes to a patch, by
date. each change has a label (just a number) which you can use to
generate diffs and such. to wit:
stg revisions --patch=45
would show a diff between the previous patch, and the state of the patch
at change 45.
stg revisions --diff=45
would show a diff between change 45 and change 44.
stg revisions --commit=45
would show pretty-printed commit information for change 45.
stg revisions --revert=45
would revert the patch back to the way it was in change 45. notably,
you don't throw away changes 46 through 90 when you do this. a new
change is added which changes the state of the patch to the way it was
in change 45. (well, that's how it's supposed to work, anyway).
i'm interested to hear what folks on the list think of the idea.
From: Chris Mason <hidden> Date: 2016-06-15 22:42:10
On Tue, Nov 01, 2005 at 10:20:29AM -0500, Chuck Lever wrote:
[ ... ]
would show pretty-printed commit information for change 45.
stg revisions --revert=45
would revert the patch back to the way it was in change 45. notably,
you don't throw away changes 46 through 90 when you do this. a new
change is added which changes the state of the patch to the way it was
in change 45. (well, that's how it's supposed to work, anyway).
i'm interested to hear what folks on the list think of the idea.
I'm probably not familiar enough with stgit, but it
looks to me as though you're tracking individual patch history only.
In trees I work with, patches rarely stand alone. There are typically
collections of patches implementing a given feature, or a change to one
patch requires rebasing a number of (perhaps unrelated) others.
I think the command set you describe above will lose that grouping.
-chris
StGIT has the ability to rebase patches via three-way merge. This is
still on my todo list for mq.
Btw, I have to say that I was a bit uncertain about doing the rebasing by
way of a three-way merge, but when I recently did a revert, I was _really_
happy with how well "git revert" did the rebasing of the revert. It wasn't
even a clean merge, but leaving the conflict in the tree and allowing me
to fix it up made what would otherwise have been a much more complex
manual operation be 99% automated.
So I'm _neither_ a StGIT not mq user, but I can definitely say that
rebasing with a three-way merge instead of just trying to apply the patch
(whether in reverse like in a merge, or just re-apply it straigt) is
really really nice.
Linus
StGIT has the ability to rebase patches via three-way merge. This is
still on my todo list for mq.
So I'm _neither_ a StGIT not mq user, but I can definitely say that
rebasing with a three-way merge instead of just trying to apply the patch
(whether in reverse like in a merge, or just re-apply it straigt) is
really really nice.
StGIT first tries a "git-diff-tree | git-apply" since it is faster but
when this fails it falls back to a three-way merge. A 'stg status'
command would show the conflicted files and they should be marked as
resolved before refreshing the patch.
One of the good parts of the three-way merge is that it detects when a
patch you sent was fully merged upstream, the local patch becoming
empty after the merge. If not, you either get a conflict or the merge
leaves the patch with only the unmerged parts.
--
Catalin
On Tue, Nov 01, 2005 at 10:20:29AM -0500, Chuck Lever wrote:
[ ... ]
quoted
would show pretty-printed commit information for change 45.
stg revisions --revert=45
would revert the patch back to the way it was in change 45. notably,
you don't throw away changes 46 through 90 when you do this. a new
change is added which changes the state of the patch to the way it was
in change 45. (well, that's how it's supposed to work, anyway).
i'm interested to hear what folks on the list think of the idea.
I'm probably not familiar enough with stgit, but it
looks to me as though you're tracking individual patch history only.
That's true, but you can use a 'git tag' command to mark the whole
stack as something useful and this would include the state of all the
patches on the stack. This would be a whole stack history, not
individual patch history. Maybe we should implement this as well (or
maybe only this).
Anyway, I wasn't sure that's the right implementation and that's why I
didn't include Chuck's patch yet.
--
Catalin
On Tue, Nov 01, 2005 at 10:08:04AM +0100, Petr Baudis wrote:
quoted
Did anyone do any current detailed comparison between hg mq and StGIT?
I don't think so, but I'll give it a rough try. I have not used stgit
extensively, so please correct any mistakes below. Most of the
differences center around the ways we store patches.
Thanks for this comparison. It is correct.
mq is closer to quilt. The patches are stored as patches, and hg qpush
is very similar to importing a patch. This means metadata must be
stored at the top of the patch in some form the import code can
understand (it tries to be smart about this).
The problem with this is allowing people to modify the patch directly
(with vi). This would make it difficult to do a three-way merge
without either losing the direct changes or simply failing to apply a
modified patch to its old base (I thought about using patches as an
optimisation but after some benchmarking found that "git-diff-tree |
git-apply" is fast enough and most of the time when pushing is
calculating the sha1 hash of the resulting index file).
hg qrefresh will update the patch file, so the patch is always up to
date wrt to the hg repo.
Chuck, I think, has a patch to automatically export the patch when
pushing or refreshing. With the latest StGIT snapshot, the tool
reports if the patch was modified during push and can only be exported
in this case (the way it detects this is by assuming that if git-apply
is successful, the patch is unmodified since no fuzzy applying is
accepted; the fall back to three-way merge just reports the patch as
modified).
You can import/export patches with hg commands, or by copying patches
into/from the .hg/patches directory. This also means you can take a
quilt patch dir, copy it into .hg/patches and just start using mq.
As I said, you might have problems with implementing a three-way merge.
I'm not sure if stgit has some form of annotate, but it's a nice way to
find out which patch changed a given loc in hg/mq.
There is git-whatchanged which also reports the StGIT patches applied
onto the stack. But there is no command similar to 'quilt patches'
yet.
--
Catalin
Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
where Catalin Marinas [off-list ref] told me that...
quoted
That's not too far away. Chuck Lever has a patch (and there were some
other discussions in the past) for tracking the history of a patch.
Basically, there would be another commit object, not reachable from
HEAD but only via an StGIT command, which would chain all the versions
of a patch. You would be able to view them with gitk for example.
Perhaps you could emulate the topical branches - one patch == one head.
E.g. for patch foo-bar on branch 'master', you would create head
master/foo-bar, etc.
The patches need to be chained so a top patch would also refer to the
previously applied patches since they are its base. Anyway, I don't
like adding too many files to the refs/heads directory.
quoted
My main issue was whether we should store every state resulted from a
refresh or use a separate command (somebody suggested 'freeze') to
mark the states that should be preserved in the history. Chuck's patch
implements the first. The drawback is that a future 'stg prune'
command would not be able to remove the history and some states of the
patch might not be useful (there are times when I do a refresh only to
pop the patch and modify a different one, without any logical meaning
for the state of the patch).
I'd prefer the snapshotting being done in refresh anyway. Perhaps you
would be asked for log message when you refresh by default, but when you
refresh -n or something, only a temporary commit would be created and
next refresh would mutate it instead of creating another commit.
The refresh -n should be the default and maybe just specifying an
option when you want to add a comment to that commit. But, by mutating
the temporary commit, wouldn't this mean that you lose the refresh
history?
Anyway, "freeze" is confusing. Perhaps "snapshot" if anything...
From: Chris Mason <hidden> Date: 2016-06-15 22:42:10
On Tue, Nov 01, 2005 at 05:29:19PM +0000, Catalin Marinas wrote:
On 01/11/05, Chris Mason [off-list ref] wrote:
quoted
mq is closer to quilt. The patches are stored as patches, and hg qpush
is very similar to importing a patch. This means metadata must be
stored at the top of the patch in some form the import code can
understand (it tries to be smart about this).
The problem with this is allowing people to modify the patch directly
(with vi). This would make it difficult to do a three-way merge
without either losing the direct changes or simply failing to apply a
modified patch to its old base (I thought about using patches as an
optimisation but after some benchmarking found that "git-diff-tree |
git-apply" is fast enough and most of the time when pushing is
calculating the sha1 hash of the resulting index file).
The three way merge is still possible even if someone hand edits the
patch. For a three way merge, you just need to know the parent revision
of the change you want to merge. parent can mean the revision in the
repository that precedes this patch (mq stores this information, just
not in the patch), or it can mean any revision where the patch applies
cleanly.
Both approaches (mq vs stgit) have advantages...you can get roughly the same
functionality either way.
-chris
From: Chris Mason <hidden> Date: 2016-06-15 22:42:10
On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote:
On 01/11/05, Chris Mason [off-list ref] wrote:
That's true, but you can use a 'git tag' command to mark the whole
stack as something useful and this would include the state of all the
patches on the stack. This would be a whole stack history, not
individual patch history. Maybe we should implement this as well (or
maybe only this).
Anyway, I wasn't sure that's the right implementation and that's why I
didn't include Chuck's patch yet.
I would suggest just putting the .git/patches directory under revision
control. If you make it a head in git and then add helper functions so
that common operations are easy to do, you won't be reimplementing the
whole SCM wheel just for patches.
For example:
stg commit-patch-tree:
does git-write-tree and git-commit-tree on .git/patches
stg checkout-patches sha1:
updates .git/patches to a given patch commit
stg diff-patches [-p] [-f]:
by default this does the same as git-diff-tree
-p, read the patch commit objects and diff the patch files
-f, read the patch commit objects and diff the source files
The command names could be better, but the idea is to make commits that
change the state of your patch tree. Later on, you'll be able to find the
one commit where you added 6 patches, or the one commit where you
adapted the whole tree to some new feature.
More importantly, you can reuse gitk and all of the other history
functionality in the SCM.
-chris
The three way merge is still possible even if someone hand edits the
patch. For a three way merge, you just need to know the parent revision
of the change you want to merge. parent can mean the revision in the
repository that precedes this patch (mq stores this information, just
not in the patch), or it can mean any revision where the patch applies
cleanly.
Yes, but what I meant is that someone may modify the patch in a way
that it is no longer appliable to its parent or to any other revision
in the tree. A this point, a three-way merge is no longer possible
(but, well, if someone modifies the patches this way should be able to
cope with the consequences).
Both approaches (mq vs stgit) have advantages...you can get roughly the same
functionality either way.
Yes, you are right. The big difference is the underlying tool (hg or git).
--
Catalin
I would suggest just putting the .git/patches directory under revision
control.
Putting them under a separate revisions repository, i.e. having a
.git/patches/,git directory? Otherwise there would be some problems
with the modified files automatically included in a patch.
More importantly, you can reuse gitk and all of the other history
functionality in the SCM.
Doing it the above way wouldn't be of much help with gitk. You would
get files like .git/patches/master/patchX/top etc. under revision
control which only contain some hash strings, not meaningful. With GIT
you have the advantage of being able to specify the DAG structure. It
is pretty simple to just link the commit objects corresponding to a
patch into a DAG and using gitk would allow you to navigate through
the history and also look at the diff itself.
--
Catalin
From: Chris Mason <hidden> Date: 2016-06-15 22:42:10
On Tue, Nov 01, 2005 at 09:30:06PM +0000, Catalin Marinas wrote:
On 01/11/05, Chris Mason [off-list ref] wrote:
quoted
I would suggest just putting the .git/patches directory under revision
control.
Putting them under a separate revisions repository, i.e. having a
.git/patches/,git directory? Otherwise there would be some problems
with the modified files automatically included in a patch.
quoted
More importantly, you can reuse gitk and all of the other history
functionality in the SCM.
Doing it the above way wouldn't be of much help with gitk. You would
get files like .git/patches/master/patchX/top etc. under revision
control which only contain some hash strings, not meaningful. With GIT
you have the advantage of being able to specify the DAG structure. It
is pretty simple to just link the commit objects corresponding to a
patch into a DAG and using gitk would allow you to navigate through
the history and also look at the diff itself.
I think we're talking past each other a little, partially because
I'm not sure exactly what features you want from revision control on the
patches.
But, my suggestion is to remember that once you add some sort of
revision control, people are going to want all of the features they are
used to with git/hg/their favorite SCM. You'll probably get better
results if you patch git to your needs then if you try to reimplement
things all over again.
-chris
Sorry for the delay in replying.
On 02/11/05, Chris Mason [off-list ref] wrote:
I think we're talking past each other a little, partially because
I'm not sure exactly what features you want from revision control on the
patches.
That's unclear for me too :-). I would like to have a way of checking
the changes to individual patches, just to be able to go back if some
changes broke it. It's also useful to have some kind of revision
control for the whole stack, but this can be achieved with tags at the
moment. What I usually do is export the series when I'm happy with it
and keep that directory safe. I could add revision control for the
directory containing the exported series but this would be somehow
outside StGIT.
But, my suggestion is to remember that once you add some sort of
revision control, people are going to want all of the features they are
used to with git/hg/their favorite SCM. You'll probably get better
results if you patch git to your needs then if you try to reimplement
things all over again.
That's true. I think that people who want a full revision control of
the patches should rather use separate branches instead of stacked
patches. It's indeed more convenient to be able to add or remove
features with push/pop but providing yet another SCM layer on top of
these would make the tool hard to understand (and maybe make Quilt
fans run away from it).
The current StGIT features are enough for my needs but I'll
accept/implement new features based on others' requirements.
BTW, the latest StGIT snapshot has support for a 'patches' command
which shows the patches modifying a file or set of files (that's
because I needed this feature recently).
--
Catalin
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:11
Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter
where Catalin Marinas [off-list ref] said that...
I would like to have a way of checking the changes to individual
patches, just to be able to go back if some changes broke it.
Yes, that would be nice to have as well (although in general I lean to
recording the whole stack now). Model scenario:
A night city, the snow slowly falling. Approaching the roofs covered in
white and illuminated by the yellow street lighting, dark windows - but
one dimly glowing, a computer screen inside. Close-up on a hacker:
$EDITOR opened, lost deep in hack mode, fingers dancing over the
keyboard. Dreamy-monumental music in the background.
StGIT user, only part of the patches in stack, and the rest depends on
the one currently edited, and I want to record my work on this one.
I can either:
(i) Just keep per-patch history only.
(ii) Keep _both_ per-patch and per-stack history (since I don't want to
record the stack when I have to keep some patches out of it - the
history would look like randomly removing and adding tons of patches,
and jumping around would be difficult because of this too).
(iii) Keep per-patchlist history - do not actually record only our
current stack, but all the patches StGIT knows about. The patches
depending on the one currently being changed will not be in consistent
state, but that's tough. Actually, this seems to be the most viable
strategy. One question is whether to record if some patch is actually
applied right now or not (I'd say don't record it since you again have
the "bouncing problem" otherwise).
Ideas?
It's also useful to have some kind of revision control for the whole
stack, but this can be achieved with tags at the moment.
Yes, now let's sequence the tags... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
From: Pavel Machek <hidden> Date: 2016-06-15 22:42:11
Hi!
Dear diary, on Sat, Nov 05, 2005 at 09:23:33PM CET, I got a letter
where Catalin Marinas [off-list ref] said that...
...
A night city, the snow slowly falling. Approaching the roofs covered in
white and illuminated by the yellow street lighting, dark windows - but
one dimly glowing, a computer screen inside. Close-up on a hacker:
$EDITOR opened, lost deep in hack mode, fingers dancing over the
keyboard. Dreamy-monumental music in the background.
StGIT user, only part of the patches in stack, and the rest depends on
the one currently edited, and I want to record my work on this one.
I can either:
Are you sure you are git hacker? Maybe you should have been fiction
writer :-).
(i) Just keep per-patch history only.
(ii) Keep _both_ per-patch and per-stack history (since I don't want to
record the stack when I have to keep some patches out of it - the
history would look like randomly removing and adding tons of patches,
and jumping around would be difficult because of this too).
(iii) Keep per-patchlist history - do not actually record only our
current stack, but all the patches StGIT knows about. The patches
depending on the one currently being changed will not be in consistent
state, but that's tough. Actually, this seems to be the most viable
strategy. One question is whether to record if some patch is actually
applied right now or not (I'd say don't record it since you again have
the "bouncing problem" otherwise).
I do not know if ii or iii is better, but please *do* record what
patches were applied at what moment. That is useful info. "I'd like to
go back to know working configuration". If I do not know what patches
were applied at what moment, going back to working config is hard to
do.
Pavel
--
Thanks, Sharp!
A night city, the snow slowly falling. Approaching the roofs covered in
white and illuminated by the yellow street lighting, dark windows - but
one dimly glowing, a computer screen inside. Close-up on a hacker:
$EDITOR opened, lost deep in hack mode, fingers dancing over the
keyboard. Dreamy-monumental music in the background.
I agree with Pavel here :-)
StGIT user, only part of the patches in stack, and the rest depends on
the one currently edited, and I want to record my work on this one.
I can either:
(i) Just keep per-patch history only.
That's probably the simplest.
(ii) Keep _both_ per-patch and per-stack history (since I don't want to
record the stack when I have to keep some patches out of it - the
history would look like randomly removing and adding tons of patches,
and jumping around would be difficult because of this too).
It happens to me to keep some patches popped which aren't really part
of the stack (i.e. splitting a big patch, I still keep it in the
unapplied patches to push it later and check what was left after
splitting). From this point of view, (ii) would be better but with the
drawback that you need to have a valid stack with all the patches
pushed.
(iii) Keep per-patchlist history - do not actually record only our
current stack, but all the patches StGIT knows about. The patches
depending on the one currently being changed will not be in consistent
state, but that's tough. Actually, this seems to be the most viable
strategy. One question is whether to record if some patch is actually
applied right now or not (I'd say don't record it since you again have
the "bouncing problem" otherwise).
(iii) is the most comprehensive method and, as Pavel said, we should
record what patches were applied or not and reproduce them exactly
when retrieving a different state.
Another big problem is the base of the stack, which can change. Would
retrieving an old state of the stack also restore the old the base? I
think it should and its up to the user to rebase it.
A simple way to partially achieve (iii) is to extend the existing
'branch' command to clone the whole series into a new one, including
all the patches. The problem with this approach is that there is no
temporal relation between branches.
How would you expect to switch between different states of the stack?
As Chris Mason mentioned, once you start doing this people might ask
for full SCM features (like diffs between revisions) where the objects
are stack states. This would complicate StGIT quite a lot.
--
Catalin