* Re: HTTP pushes
From: Johannes Schindelin @ 2005-11-01 19:10 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051101020248.GA3928@reactrix.com>
Hi,
On Mon, 31 Oct 2005, Nick Hengeveld wrote:
> HTTP is currently listed as a read-only/unsupported method for doing
> pushes, is that due to inherent problems with HTTP or just because
> it hasn't been written yet?
>
> I've built a working prototype of an HTTP push implementation using DAV.
I think this is useful. There are restrictive firewalls out there, which
only allow ports 80 and 443 to be connected to. Your work would fit in
right there.
BTW, if the push would be relatively big, it would be nice to support
pushing packs...
Ciao,
Dscho
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Chris Mason @ 2005-11-01 18:13 UTC (permalink / raw)
To: Catalin Marinas
Cc: Chuck Lever, Petr Baudis, Theodore Ts'o, Joel Becker,
Junio C Hamano, git
In-Reply-To: <b0943d9e0511010918ob2dbcfcv@mail.gmail.com>
On Tue, Nov 01, 2005 at 05:18:49PM +0000, Catalin Marinas wrote:
> On 01/11/05, Chris Mason <mason@suse.com> 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
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Chris Mason @ 2005-11-01 17:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: Petr Baudis, Theodore Ts'o, Joel Becker, Junio C Hamano, git
In-Reply-To: <b0943d9e0511010929u22b33e4el@mail.gmail.com>
On Tue, Nov 01, 2005 at 05:29:19PM +0000, Catalin Marinas wrote:
> On 01/11/05, Chris Mason <mason@suse.com> wrote:
> > 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
^ permalink raw reply
* Re: git-pull - strange (copy/rename) messages ?!
From: Junio C Hamano @ 2005-11-01 17:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511010801370.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, Junio, I thought "git pull" was only supposed to do rename
> detection, not copy detection.
Sorry, but what do you mean by "only rename detection but not
copy detection" in this case?
When you have "ce A B; ce A C; ce A D;... ; mv A Z", (ce is like
cp but "copy+edit") where B-Z are all new files and A disappears
from the result, trying to detect renames would end up detecting
copies without extra processing; B through Z are rename
destination candidates, and A is a rename source candidate
(there may be others), and it turns out that B-Z all look like
A.
Would it be easier to read if we say A was renamed to B, and A
was renamed to C, and A was renamed to D, ...? I think the
current output is easier to understand than that. B-Y gets
labelled as copy of A and Z gets labelled as rename.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Petr Baudis @ 2005-11-01 17:35 UTC (permalink / raw)
To: Joel Becker
Cc: Martin Langhoff, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <20051101161730.GV11488@ca-server1.us.oracle.com>
Dear diary, on Tue, Nov 01, 2005 at 05:17:30PM CET, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:
> > Personally, from my POV it is the intended mode of development only if
> > you keep strictly topical branches (a single logical change and fixes of
> > it on top of that). Otherwise, this is horrid because it loses the
> > _precious_ history and bundles us different changes to a single commit,
> > which is one of the thing that are wrong on CVS/SVN merging.
>
> Here we have the "precious" history vs the "throwaway" history
> argument again. You are correct, this does look like CVS/Subversion
> merging. But I'm quite capable of keeping my patches single-topic.
> Anything that requires multiple patches in a logical separation still
> needs that extra love.
Well, ok, so I assume you are indeed using strictly topical branches.
.
> > That said, with a big warning, I would be willing to do something like
> > cg-merge -s and cg-update -s (s as squash), with a big warning that this
>
> Wouldn't it be cg-pull? I guess I'm not conversant enough of
> all ways to merge branches in cogito.
cg-pull just fetches stuff, no merging done.
Ok, in theory you do not actually need to fetch the intermediate history
in case you are going to squash (unless you are going to default the
final commit message to concatenation of the intermediate ones), but
arranging that would not be easy to arrange with the current git tools,
I think. And neither feasible. But actually, I would like to do
something like this later, support for CVS/SVN-like tracking by always
having only the latest tree and no intermediate states, so that people
who just want to run the latest and want to do no development are not
forced to download anything useless for them.
> > is suitable only for topical branches. And I think it'd be still much
> > better to spend the work making StGIT able to track history of changes
> > to a particular patch.
>
> I like quilt for certain work, and what I read from you and
> Caitlin makes me interested in StGIT for those large changes that
> require split-out patches. But for simple tasks, I just want to use the
> SCM, you know?
Well, if you are already going to deform the history, StGIT (able to
track patch history) is just the best tool for that.
--
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.
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-01 17:34 UTC (permalink / raw)
To: Petr Baudis
Cc: Theodore Ts'o, Joel Becker, Junio C Hamano, mason, git,
Chuck Lever
In-Reply-To: <20051101101004.GD11618@pasky.or.cz>
On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> > 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.
> > 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...
You are right.
--
Catalin
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-01 17:29 UTC (permalink / raw)
To: Chris Mason
Cc: Petr Baudis, Theodore Ts'o, Joel Becker, Junio C Hamano, git
In-Reply-To: <20051101141149.GA26847@watt.suse.com>
On 01/11/05, Chris Mason <mason@suse.com> wrote:
> On Tue, Nov 01, 2005 at 10:08:04AM +0100, Petr Baudis wrote:
> > 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
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-01 17:18 UTC (permalink / raw)
To: Chris Mason
Cc: Chuck Lever, Petr Baudis, Theodore Ts'o, Joel Becker,
Junio C Hamano, git
In-Reply-To: <20051101153650.GB26847@watt.suse.com>
On 01/11/05, Chris Mason <mason@suse.com> wrote:
> 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.
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
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-01 17:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Chris Mason, Petr Baudis, Theodore Ts'o, Joel Becker,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511010757040.27915@g5.osdl.org>
On 01/11/05, Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 1 Nov 2005, Chris Mason wrote:
> > 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
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Joel Becker @ 2005-11-01 16:17 UTC (permalink / raw)
To: Petr Baudis
Cc: Martin Langhoff, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <20051101091533.GB11618@pasky.or.cz>
On Tue, Nov 01, 2005 at 10:15:33AM +0100, Petr Baudis wrote:
> Personally, from my POV it is the intended mode of development only if
> you keep strictly topical branches (a single logical change and fixes of
> it on top of that). Otherwise, this is horrid because it loses the
> _precious_ history and bundles us different changes to a single commit,
> which is one of the thing that are wrong on CVS/SVN merging.
Here we have the "precious" history vs the "throwaway" history
argument again. You are correct, this does look like CVS/Subversion
merging. But I'm quite capable of keeping my patches single-topic.
Anything that requires multiple patches in a logical separation still
needs that extra love.
> That said, with a big warning, I would be willing to do something like
> cg-merge -s and cg-update -s (s as squash), with a big warning that this
Wouldn't it be cg-pull? I guess I'm not conversant enough of
all ways to merge branches in cogito.
> is suitable only for topical branches. And I think it'd be still much
> better to spend the work making StGIT able to track history of changes
> to a particular patch.
I like quilt for certain work, and what I read from you and
Caitlin makes me interested in StGIT for those large changes that
require split-out patches. But for simple tasks, I just want to use the
SCM, you know?
Joel
--
"The cynics are right nine times out of ten."
- H. L. Mencken
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: git-pull - strange (copy/rename) messages ?!
From: Linus Torvalds @ 2005-11-01 16:10 UTC (permalink / raw)
To: Duncan Mac Leod; +Cc: git
In-Reply-To: <43678C73.1080601@excelsior-online.org>
On Tue, 1 Nov 2005, Duncan Mac Leod wrote:
>
> One Team-Member of our dev.-team has deleted one file called
> Graphics/PaletteGroups.cs in our shared git repository.
>
> As I updated my working dir with git-pull I noticed some strange messages...
>
> What do these many copy and rename messages below the summary '14 files
> changed, 933 insertions(+), 263 deletions(-)' mean ????
First off, you should realize that whenever git says "copy" or "rename",
it never actually tracked the data at that level. git itself never did a
copy or rename operation at all, it just tracked your data contents.
However, the normal "git pull" will show purely for your edification what
git thinks the other end did to get to that data content. And it does so
with copy and rename detection enabled, so in this case it says:
> copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%)
> copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%)
> copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogEntry.cs (74%)
> copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogSection.cs (64%)
> copy Graphics/PaletteGroups.cs => Plot/Journals/Journal.cs (75%)
> copy Graphics/PaletteGroups.cs => Plot/Journals/JournalEntry.cs (73%)
> copy Graphics/PaletteGroups.cs => Plot/Journals/JournalSection.cs (64%)
> copy Graphics/PaletteGroups.cs => Runtime/CompilerServices/eScriptCompiler.cs (74%)
> copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%)
> rename Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs (64%)
Which means that git notices that there are a number of new files, and the
new files all bear a striking resemblance to one file that was deleted.
So it tells you that the new files are probably copies of the old one
(with one final "rename", since the old file doesn't actually exist any
more).
Which may or may not be true, of course. But even if it's not "true", it's
still interesting information - it is a totally objective "those new files
look like the old file" thing. In other words, it tells you something
true about the file contents.
To some degree it would be much more interesting to have
"--find-copies-harder" enabled (which it isn't), which gives better copy
information for new files (it also looks at _unchanged_ old files).
However, that's prohibitively expensive for big projects, so it's not on
by default.
Btw, Junio, I thought "git pull" was only supposed to do rename
detection, not copy detection.
Linus
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Linus Torvalds @ 2005-11-01 16:00 UTC (permalink / raw)
To: Chris Mason
Cc: Petr Baudis, Theodore Ts'o, Joel Becker, Junio C Hamano,
catalin.marinas, git
In-Reply-To: <20051101141149.GA26847@watt.suse.com>
On Tue, 1 Nov 2005, Chris Mason wrote:
>
> 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
^ permalink raw reply
* git-pull - strange (copy/rename) messages ?!
From: Duncan Mac Leod @ 2005-11-01 15:40 UTC (permalink / raw)
To: git
One Team-Member of our dev.-team has deleted one file called
Graphics/PaletteGroups.cs in our shared git repository.
As I updated my working dir with git-pull I noticed some strange messages...
What do these many copy and rename messages below the summary '14 files
changed, 933 insertions(+), 263 deletions(-)' mean ????
Updating from f0df62e7b60c468852d4617505876515f9b305d7 to
8c18245869a9447329dedb4a4cd59d103ee6dbfe.
Fast forward
AssemblyInfo.cs | 2
BaseObjects/Modules.cs | 235 ++++++++
Graphics/PaletteCategories.cs | 12
Plot/Dialogs/Dialog.cs | 12
Plot/Dialogs/DialogEntry.cs | 12
Plot/Dialogs/DialogSection.cs | 14
Plot/Journals/Journal.cs | 12
Plot/Journals/JournalEntry.cs | 12
Plot/Journals/JournalSection.cs | 14
Runtime/CompilerServices/eScriptCompiler.cs | 12
Runtime/Scripting/Script.cs | 12
Runtime/Scripting/ScriptLibrary.cs | 14
doc/excelsior_corelib.xml | 784
++++++++++++++++++++-------
excelsior_corelib.csproj | 49 ++
14 files changed, 933 insertions(+), 263 deletions(-)
copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%)
copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%)
copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogEntry.cs (74%)
copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogSection.cs (64%)
copy Graphics/PaletteGroups.cs => Plot/Journals/Journal.cs (75%)
copy Graphics/PaletteGroups.cs => Plot/Journals/JournalEntry.cs (73%)
copy Graphics/PaletteGroups.cs => Plot/Journals/JournalSection.cs (64%)
copy Graphics/PaletteGroups.cs =>
Runtime/CompilerServices/eScriptCompiler.cs (74%)
copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%)
rename Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs
(64%)
thx in advance,
duncan
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Chris Mason @ 2005-11-01 15:36 UTC (permalink / raw)
To: Chuck Lever
Cc: Catalin Marinas, Petr Baudis, Theodore Ts'o, Joel Becker,
Junio C Hamano, git
In-Reply-To: <436787BD.9080705@citi.umich.edu>
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
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Chuck Lever @ 2005-11-01 15:20 UTC (permalink / raw)
To: Catalin Marinas
Cc: Petr Baudis, Theodore Ts'o, Joel Becker, Junio C Hamano,
mason, git
In-Reply-To: <b0943d9e0511010123i1f9eb679w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]
Catalin Marinas wrote:
> On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
>
>>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.
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.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Chris Mason @ 2005-11-01 14:11 UTC (permalink / raw)
To: Petr Baudis
Cc: Theodore Ts'o, Joel Becker, Junio C Hamano, catalin.marinas,
git
In-Reply-To: <20051101090804.GA11618@pasky.or.cz>
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 <tytso@mit.edu> 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 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
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Catalin Marinas @ 2005-11-01 13:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Joel Becker, Junio C Hamano, git, Petr Baudis
In-Reply-To: <46a038f90510311702wfb43281rf4464a02e8e3be2@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/1/05, Joel Becker <Joel.Becker@oracle.com> wrote:
>> > is possible) offhand. Sometimes, when you want truly logical
>> > steps, you would end up needing intermediate steps that never
>> > existed in your true history (i.e. "in the hindsight, my
>> > development should have progressed in these steps.")
>>
>> Yes, I always do. But I'm not talking about that sort of large
>> feature add or whatever. I'm talking about merely doing something on a
>> small scale, but in a temporary repository.
>
> I'm really surprised that Calalin hasn't chimed in.
Well, it was night here when this discussion took off :-).
> If you are into rewriting/merging/splitting your patches, StGIT is
> your friend. Check out: http://www.procode.org/stgit/
StGIT mainly resembles Quilt workflow but there are no patches, only
commit objects which are indefinitely replaceable (push/pop/refresh).
What I usually do is create smaller commits for different features and
just stack them together. That's usually for features which are
dependent on each-other and you can control them with a finer grain
than having separate branches. One can push/pop patches (commits) to
bring the patch to be modified at the top. After modification, a
refresh command would save it as a commit. All the patches (commits)
in the stack are accessible via HEAD and are seen as GIT commits.
It may happen to just have a bigger patch which needs splitting. What
I usually do in this case is import the patch as an StGIT patch
(i.e. GIT commit object), pop it from the stack so that it is no
longer applied, split the physical patch (diff file) into smaller, logical
changes and apply them one by one with StGIT. When you think al the
big patch was completely applied, pushing it should result in an empty
patch, otherwise you might have missed something that needs applying.
With StGIT you can also pick a commit object from a different branch
as a StGIT patch or you could merge two patches into one.
Once you are OK with the patches in the stack, just ask the gatekeeper
to pull the changes from your tree using plain GIT or mail them
automatically with StGIT.
--
Catalin
^ permalink raw reply
* [BUG] t4102-apply-rename.sh isn't umask aware
From: Peter Baumann @ 2005-11-01 11:03 UTC (permalink / raw)
To: git
xp:~/src/git/t rm -fR trash
xp:~/src/git/t umask
0027
xp:~/src/git/t ./t4102-apply-rename.sh
mv: cannot stat `.git/hooks': No such file or directory
* ok 1: setup
* ok 2: apply
* FAIL 3: validate
test -f bar && ls -l bar | grep "^-..x..x..x"
* failed 1 among 3 test(s)
Setting umask to 0022 fixed the problem.
xp:~/src/git/t rm -fR trash
xp:~/src/git/t umask
0022
xp:~/src/git/t ./t4102-apply-rename.sh
mv: cannot stat `.git/hooks': No such file or directory
* ok 1: setup
* ok 2: apply
* ok 3: validate
* passed all 3 test(s)
Regards
Peter
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Petr Baudis @ 2005-11-01 10:10 UTC (permalink / raw)
To: Catalin Marinas
Cc: Theodore Ts'o, Joel Becker, Junio C Hamano, mason, git,
Chuck Lever
In-Reply-To: <b0943d9e0511010123i1f9eb679w@mail.gmail.com>
Dear diary, on Tue, Nov 01, 2005 at 10:23:55AM CET, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
> > 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.
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-01 9:23 UTC (permalink / raw)
To: Petr Baudis
Cc: Theodore Ts'o, Joel Becker, Junio C Hamano, mason, git,
Chuck Lever
In-Reply-To: <20051101090804.GA11618@pasky.or.cz>
On 01/11/05, Petr Baudis <pasky@suse.cz> wrote:
> 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
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Petr Baudis @ 2005-11-01 9:17 UTC (permalink / raw)
To: Joel Becker; +Cc: Martin Langhoff, Junio C Hamano, git
In-Reply-To: <20051101012915.GR11488@ca-server1.us.oracle.com>
Dear diary, on Tue, Nov 01, 2005 at 02:29:15AM CET, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:
> > I'm really surprised that Calalin hasn't chimed in. If you are into
> > rewriting/merging/splitting your patches, StGIT is your friend. Check
> > out: http://www.procode.org/stgit/
>
> But I'm not. I don't want patches in the first place. I want
> cg-pull but with a flattened history.
StGIT does not work with patches but with commits. You can manage the
logical changes with StGIT and when it's time, just merge your
StGIT-tracked branch with whatever else. "Patch" here is really just a
different name for logical change / commit.
--
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.
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Petr Baudis @ 2005-11-01 9:15 UTC (permalink / raw)
To: Joel Becker
Cc: Martin Langhoff, Linus Torvalds, Johannes Schindelin, walt, git
In-Reply-To: <20051031213003.GN11488@ca-server1.us.oracle.com>
Dear diary, on Mon, Oct 31, 2005 at 10:30:03PM CET, I got a letter
where Joel Becker <Joel.Becker@oracle.com> told me that...
> On Tue, Nov 01, 2005 at 09:28:30AM +1300, Martin Langhoff wrote:
> > You can do a diff that spans all the commits and apply it with a new
> > commit msg. With cogito:
> >
> > cg-diff -r from:to | patch -p1
>
> I'm well aware of this, my question was rather one of
> applicability. First, do we want it to work this way, losing the
> history. Second, you'd like the process to be all encompasing if you go
> this route.
>
> ((cd old-repo && cg-diff -r from) | patch -p1) && cg-commit
>
> or any equivalent. Why should I have to muck with patch and diff, when
> I can have a 'pull-as-one' operation. Sure, it's a wrapper, but if its
> the intended mode of development, let's make it a first-class citizen.
Personally, from my POV it is the intended mode of development only if
you keep strictly topical branches (a single logical change and fixes of
it on top of that). Otherwise, this is horrid because it loses the
_precious_ history and bundles us different changes to a single commit,
which is one of the thing that are wrong on CVS/SVN merging.
That said, with a big warning, I would be willing to do something like
cg-merge -s and cg-update -s (s as squash), with a big warning that this
is suitable only for topical branches. And I think it'd be still much
better to spend the work making StGIT able to track history of changes
to a particular patch.
--
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.
^ permalink raw reply
* hgmq vs. StGIT
From: Petr Baudis @ 2005-11-01 9:08 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Joel Becker, Junio C Hamano, mason, catalin.marinas, git
In-Reply-To: <20051101002554.GA7634@thunk.org>
Dear diary, on Tue, Nov 01, 2005 at 01:25:54AM CET, I got a letter
where Theodore Ts'o <tytso@mit.edu> 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.
^ permalink raw reply
* git-mv dest ending with slash would deletes file only
From: Ben Lau @ 2005-11-01 4:20 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
Hi,
I just tried to use the git-mv to move several files to another
directory. As the bash's auto completetion leaves the dest path ending
with slash, the command become:
$ git-mv entry.c Documentation/
Ignoring path Documentation//entry.c
$ git status
#
# Updated but not checked in:
# (will commit)
#
# deleted: entry.c
#
Checked from the source, git-update-index do not accept
multiple-successive-slashes (verify_path()@update-index.c), which should
be considered as one slash according to POSIX standard.
However, changes the verify_path() function do not help. It seems
that git consider file with single slash and multiple slashes as two
different object. Therefore, I added a line inside git-mv script to
replace multiple-successive-slashes as one and it works fine in my
system now.
[-- Attachment #2: git-mv-remove-multi-slashes.patch --]
[-- Type: text/x-patch, Size: 364 bytes --]
diff --git a/git-mv.perl b/git-mv.perl
index 17e35b0..283d7e1 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -92,6 +92,7 @@ while(scalar @srcArgs > 0) {
$src = shift @srcArgs;
$dst = shift @dstArgs;
$bad = "";
+ $dst =~ s/\/+/\//g;
if ($opt_v) {
print "Checking rename of '$src' to '$dst'\n";
diff --git a/update-index.c b/update-index.c
^ permalink raw reply related
* [OT] ancestor branch in cvsps is wrong for branch-of-branch
From: Chris Shoemaker @ 2005-11-01 3:51 UTC (permalink / raw)
To: cvsps, David Mansfield; +Cc: git
[ Maybe the git list is interested in a problem with cvsps? ]
Summary: When creating a patchset for the first modification in a
branch-off-a-branch, cvsps (version 2.1) declares that the ancestor
branch is HEAD. Presumably this is because the file in the patchset
hadn't been modified since it was on HEAD. But this means that files
that are *added* to the first branch are never counted as added to the
branch-off-a-branch.
Figure:
-HEAD-(add file 'a')--+-------------------------
\
\-stable-(add file 'b')-+
\
\-dev-(change 'a')-->
In CVS, branch "dev" clearly contains both 'a' and 'b'. But cvsps
makes it look like this:
/-dev-(change 'a') ---->
/
-HEAD-(add file 'a')--+-------------------------
\
\-stable-(add file 'b')---->
So that in the imported git repository, the "dev" branch contains ONLY
'a'.
Below are: a script to reproduce this example, the cvs log output, and
cvsps output. It's clear from the cvs log that 'b' has the 'dev'
symbolic tag, so it seems like we should be able to recreate 'dev'.
Before I look into fixing this, I wanted to see if there were any
comments from the list. David?
-chris
#!/bin/sh
dirname=`date +"%Y%m%d%H%M%S"`
mkdir $dirname && cd $dirname
# create the repository
mkdir cvsroot && cd cvsroot
export CVSROOT=`pwd`
cd ..
cvs init
# import an empty project
mkdir project && cd project
cvs import -m "Create initial repo" project yoyo start
cd ..
rmdir project
# checkout the project
cvs co project && cd project
# create a new file on HEAD
echo 1 >a
cvs add a
cvs ci -m "added file a to HEAD" a
# create and switch to "stable" branch
cvs tag -b stable
cvs update -r stable
# add a new file to stable branch
echo 2 > b
cvs add b
cvs ci -m "added file b to 'stable' branch" b
# create and switch to "dev" branch from "stable"
cvs tag -b dev
cvs update -r dev
# modify file 'a' on "dev" branch
echo "change" >> a
cvs ci -m "changed file a on dev branch" a
# see what CVS thinks the "dev" branch looks like
cd ..
rm -rf project
cvs checkout -r dev project
ls project && echo "Note how b is PRESENT"
# check output of cvsps
cd project
cvs log > ../cvslog
cd ..
cvsps -A --test-log cvslog project > cvsps.out
# check behavior of git-cvsimport
git-cvsimport -i -d $CVSROOT -C project.git project
cd project.git
git-checkout -f dev
ls && echo "Note how b is ABSENT!"
#***********EOF*********************
cvsps output
---------------------
PatchSet 1
Date: 2005/10/31 22:30:46
Author: chris
Branch: HEAD
Tag: (none)
Log:
added file a to HEAD
Members:
a:INITIAL->1.1
---------------------
PatchSet 2
Date: 2005/10/31 22:30:47
Author: chris
Branch: stable
Ancestor branch: HEAD
Tag: (none)
Log:
added file b to 'stable' branch
Members:
b:1.1->1.1.2.1
---------------------
PatchSet 3
Date: 2005/10/31 22:30:48
Author: chris
Branch: dev
Ancestor branch: HEAD
Tag: (none)
Log:
changed file a on dev branch
Members:
a:1.1->1.1.4.1
******************EOF*********
cvs log output
RCS file: /home/chris/import/20051031223046/cvsroot/project/a,v
Working file: a
head: 1.1
branch:
locks: strict
access list:
symbolic names:
dev: 1.1.0.4
stable: 1.1.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.1
date: 2005/11/01 03:30:46; author: chris; state: Exp;
branches: 1.1.4;
added file a to HEAD
----------------------------
revision 1.1.4.1
date: 2005/11/01 03:30:48; author: chris; state: Exp; lines: +1 -0
changed file a on dev branch
=============================================================================
RCS file: /home/chris/import/20051031223046/cvsroot/project/Attic/b,v
Working file: b
head: 1.1
branch:
locks: strict
access list:
symbolic names:
dev: 1.1.2.1.0.2
stable: 1.1.0.2
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
----------------------------
revision 1.1
date: 2005/11/01 03:30:47; author: chris; state: dead;
branches: 1.1.2;
file b was initially added on branch stable.
----------------------------
revision 1.1.2.1
date: 2005/11/01 03:30:47; author: chris; state: Exp; lines: +1 -0
added file b to 'stable' branch
=============================================================================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox