* cogito-0.10 broken for cg-commit < logmessagefile
From: Russell King @ 2005-06-08 13:46 UTC (permalink / raw)
To: git
The command in the subject prepends the log message with a blank line.
This ain't good because it messes up commit messages as per Linus'
requirements (the first line must be a summary.)
Is this known about / has this been fixed in 0.11 ?
(It's presently a blocking bug...)
--
Russell King
^ permalink raw reply
* Re: [PATCH] Add missing Documentation/*
From: McMullan, Jason @ 2005-06-08 12:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailling list
In-Reply-To: <7vvf4qhuht.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Tue, 2005-06-07 at 11:50 -0700, Junio C Hamano wrote:
> I would suggest dropping "and the git-list" and the rest from
> all the new files. The doc is by you, at least until somebody
> else mucks on it.
Understood. AFAICT, 'and the git-list' was convention.
> +++ b/Documentation/git-get-tar-commit-id.txt
>
> This is by Rene Scharfe. There is no single line from Linus in
> the source file get-tar-commit-id.c, according to my "surviving
> line counter".
Oops! I though I had 'de-Linused' all the ones he didn't do. Guess I
missed one or two. Thanks for the catch!
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Jon Seymour @ 2005-06-08 11:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <2cfc403205060802315ba2433a@mail.gmail.com>
Pasky,
Hey, I was thinking, instead of stop-at-author, how about we call it
prune-at-author instead?
Regards,
jon.
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Jon Seymour @ 2005-06-08 10:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <2cfc403205060802315ba2433a@mail.gmail.com>
Ok, this is how --wrt-author sorts your example:
(Original example transposed so that variable width fonts don't play
havoc with the layout)
a10 b9
| \ |
a9 b8
| |
a8 b7
| |
a7 b6
| / |
a6 b5
| \ |
a5 b4
| |
a4 b3
| \ |
a3 b2
| |
a2 b1
| /
a1
with respect to a and b respectively
A B
| b9 | b9
^ a10 ^ a10
| b8 | a9
| b7 | a8
| b6 | a7
| b5 ^ b8
^ a9 | b7
| a8 | b6
| a7 | a6
| a6 | a5
| b4 | a4
| b3 | a3
^ a5 | a2
| a4 ^ b5
| b2 | b4
| b1 | b3
^ a3 | b2
| a2 | b1
= a1 = a1
In otherwords, B doesn't see any of A's changes after a1 until b6,
whereas A sees some of B's changes at a4 and some at a6, then not
again until a10.
jon.
^ permalink raw reply
* git/cogito usage scenarios for CVS refugee
From: Martin Langhoff @ 2005-06-08 9:51 UTC (permalink / raw)
To: Git Mailing List
Trying to get my head around what usage patterns the git
infrastructure supports. I'm interested in exploring more git-centric
approaches...
For a project that uses CVS with a classic HEAD and FOO_15_STABLE
approach, where FOO_15_STABLE gets only fixes -- how do I manage HEAD
and XX_STABLE where some patches that work well in HEAD I may decide
to merge into XX_STABLE, and some security patch may be applied first
to XX_STABLE and then to HEAD? I can apply the patch on both branches
-- yep. But does git help me in keeping track of what's been merged?
Does git help in any way to keep track of patches across 2.6.11.12 and
2.6.12rc5 ?
In a git-based project, one developer is about to merge from someone
else's tree, are there any tools to review the patchlog that is about
to be applied (or replayed?) against his tree? Is there any way to say
"of the 20 commits that I'm about to merge, hold off 2" other than
letting git apply them ... and backing them out right next?
And generally, is there any long-lived branch support? If I am to run
a "local branch" of the Linux kernel, does git help me at all?
So far I think the answer is "no -- you'll need to keep track of your
damn patches somewhere else" ;-) but there's a lot about the git
mindset I don't quite understand yet. And I'm sure that the workflow
of the Linux team must have some ancillary tools & strategies to keep
track of this.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Jon Seymour @ 2005-06-08 9:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050608085834.GC7916@pasky.ji.cz>
On 6/8/05, Petr Baudis <pasky@ucw.cz> wrote:
> Dear diary, on Tue, Jun 07, 2005 at 11:59:36AM CEST, I got a letter
> where Jon Seymour <jon.seymour@gmail.com> told me that...
> > On 6/7/05, Petr Baudis <pasky@ucw.cz> wrote:
> > > I'd prefer just --wrt-author and --exclude-author to take an argument on
> > > their own.
> >
> > The reason I don't want to do this is that it doesn't really make
> > sense in the context of the change to specify one author for
> > --wrt-author and another for --exclude-author. In normal use --author
> > defaults to GIT_AUTHOR_EMAIL or the locally derived user@host.domain.
> > The intention is simply to override this default derivation.
>
> Hmm, then why not make it --wrt-author[=AUTHOR] ? Similar to the
> --pretty option. BTW, can it do multiple author excludes now? The
> commandline would look especially horrifying in that case now, I guess.
>
No, it doesn't. I can see a use for multiple ^ arguments, but the use
case for multiple --stop-at-author arguments doesn't strike me as
being particularly useful. Multiple ^'s helps you prune the graph at
places you already know about --stop-at-author allows you to prune the
tree with respect to one author. It is particularly useful if you are
the author concerned because you have some recollection of being of
what you did last. I am not sure it is that useful to prune the tree
with respect to multiple authors - the results would be somewhat
unpredictable, I would think.
> I'd prefer --stop-at-author from the choices you offer in your other
> mail.
>
Ok, unless I Linus or the list disagree I will modify my patch to be
--stop-at-author.
> > > (Note that I don't endorse this patch and the --wrt-author behaviour in
> > > particular seems strange. I don't have enough time to comment on it
> > > sensibly now, though. I'm just focusing on style here since I'd like to
> > > still be able to read git's source code few weeks from now on.)
> >
> > The rationale for the change is as follows:
> >
> > During parallel development, one is aware of ones own
> > changes...everyone else changes haven't happened yet as far as you are
> > concerned. Only when they appear in a future merge that incorporates
> > one's own changes do the other changes appear in your own workspace.
> >
> > As far as you are concerned, these changes occurred after you made
> > your own - your changes were not dependent on those changes, only on
> > those that came before. So the linearisation reflects that perceived
> > ordering of changes.
> >
> > --wrt-author helps to reconstruct the merge-history from the
> > perspective of each individual committer.
>
> Yes, such motivation makes sense. But is the author field the right one?
> If you are integrating a lot of other people's patches in particular, I
> think it makes no sense whatsoever - you already reviewed and
> consciously applied them, but your option will regard them as something
> alien and merged from outside, right?
>
> And, after all, the other branches might be _quite_ long-lived. I think
> it would be confusing for the user if the commit graph looked like
>
> a1 -- a2 -- a3 -- a4 -- a5 -- a6 -- a7 -- a8 -- a9 -- a10
> \ / / \ /
> - b1 -- b2 -- b3 -- b4 -- b5 -- b6 -- b7 -- b8 -- b9
>
> If your patch first chooses b1, it then shows all of it, completely
> ignoring a2, right? I can't see how that would be right - the subsequent
> merges from a should be shown.
No, that's not the intent of --wrt-author when specified without
--stop-at-author.
--wrt-author doesn't cause any commits to be ignored ... it simply
changes the order
in which they are displayed by altering the order in which parents are visited.
I'll get it wrong if I do it by hand so I'll create a test case and
show you what the default merge order would be, the --wrt-author
--author=a and the --wrt-author --author=b cases.
Stay tuned...
jon.
^ permalink raw reply
* [PATCH] Tests: read-tree -m test updates.
From: Junio C Hamano @ 2005-06-08 9:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v7jh5ct1b.fsf@assigned-by-dhcp.cox.net>
This updates t1000 (basic 3-way merge test) to check the merge
results for both successful cases (earlier one checked the
result for only one of them). Also fixes typos in t1002 that
broke '&&' chain, potentially missing a test failure before the
chain got broken.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t1000-read-tree-m-3way.sh | 58 ++++++++++++++++++++---------------------
t/t1002-read-tree-m-u-2way.sh | 4 +--
2 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/t/t1000-read-tree-m-3way.sh b/t/t1000-read-tree-m-3way.sh
--- a/t/t1000-read-tree-m-3way.sh
+++ b/t/t1000-read-tree-m-3way.sh
@@ -77,34 +77,6 @@ In addition:
################################################################
# Try merging and showing the various diffs
-# The tree is dirty at this point.
-test_expect_failure \
- '3-way merge with git-read-tree -m' \
- "git-read-tree -m $tree_O $tree_A $tree_B"
-
-# This is done on an empty work directory, which is the normal
-# merge person behaviour.
-test_expect_success \
- '3-way merge with git-read-tree -m' \
- "rm -fr [NDMALTS][NDMALTSF] Z &&
- rm .git/index &&
- git-read-tree -m $tree_O $tree_A $tree_B"
-
-# This starts out with the first head, which is the normal
-# patch submitter behaviour.
-test_expect_success \
- '3-way merge with git-read-tree -m' \
- "git-read-tree $tree_A &&
- git-checkout-cache -f -u -a &&
- git-read-tree -m $tree_O $tree_A $tree_B"
-
-_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
-_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
-test_expect_success \
- 'git-ls-files --stage of the merge result' \
- 'git-ls-files --stage >current- &&
- sed -e "s/ $_x40 / X /" <current- >current'
-
cat >expected <<\EOF
100644 X 2 AA
100644 X 3 AA
@@ -154,8 +126,34 @@ cat >expected <<\EOF
100644 X 0 Z/NN
EOF
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+
+# The tree is dirty at this point.
+test_expect_failure \
+ '3-way merge with git-read-tree -m, dirty cache' \
+ "git-read-tree -m $tree_O $tree_A $tree_B"
+
+# This is done on an empty work directory, which is the normal
+# merge person behaviour.
+test_expect_success \
+ '3-way merge with git-read-tree -m, empty cache' \
+ "rm -fr [NDMALTS][NDMALTSF] Z &&
+ rm .git/index &&
+ git-read-tree -m $tree_O $tree_A $tree_B &&
+ git-ls-files --stage |
+ sed -e 's/ $_x40 / X /' >current &&
+ diff -u expected current"
+
+# This starts out with the first head, which is the normal
+# patch submitter behaviour.
test_expect_success \
- 'validate merge result' \
- 'diff current expected'
+ '3-way merge with git-read-tree -m, match H' \
+ "git-read-tree $tree_A &&
+ git-checkout-cache -f -u -a &&
+ git-read-tree -m $tree_O $tree_A $tree_B &&
+ git-ls-files --stage |
+ sed -e 's/ $_x40 / X /' >current &&
+ diff -u expected current"
test_done
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -93,7 +93,7 @@ test_expect_success \
compare_change 5diff.out expected &&
check_cache_at yomin dirty &&
sha1sum -c M.sha1 &&
- : dirty index should have prevented -u from checking it out.
+ : dirty index should have prevented -u from checking it out. &&
echo yomin yomin >yomin1 &&
diff yomin yomin1 &&
rm -f yomin1'
@@ -122,7 +122,7 @@ test_expect_success \
diff --unified=0 M.out 7.out &&
check_cache_at frotz dirty &&
if sha1sum -c M.sha1; then false; else :; fi &&
- : dirty index should have prevented -u from checking it out.
+ : dirty index should have prevented -u from checking it out. &&
echo frotz frotz >frotz1 &&
diff frotz frotz1 &&
rm -f frotz1'
------------
^ permalink raw reply
* Re: git-rev-list --merge-order hangs
From: Jon Seymour @ 2005-06-08 9:02 UTC (permalink / raw)
To: Radoslaw Szkodzinski
In-Reply-To: <2cfc403205060800337e1ecca0@mail.gmail.com>
Actually, one case that I may not have considered properly is a commit
near the head that has no parents.
git-rev-list --parents v2.6.12-rc6-astorm1 ^v2.6.12-rc6
should tell you if this case exists. Ideally such a case should not
occur, but that isn't a logical certainity, so I should handle it
better than I currently do.
Please let me know if this may explain your case.
Regards,
jon.
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Petr Baudis @ 2005-06-08 8:58 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <2cfc403205060702594da21fb1@mail.gmail.com>
Dear diary, on Tue, Jun 07, 2005 at 11:59:36AM CEST, I got a letter
where Jon Seymour <jon.seymour@gmail.com> told me that...
> On 6/7/05, Petr Baudis <pasky@ucw.cz> wrote:
> > I'd prefer just --wrt-author and --exclude-author to take an argument on
> > their own.
>
> The reason I don't want to do this is that it doesn't really make
> sense in the context of the change to specify one author for
> --wrt-author and another for --exclude-author. In normal use --author
> defaults to GIT_AUTHOR_EMAIL or the locally derived user@host.domain.
> The intention is simply to override this default derivation.
Hmm, then why not make it --wrt-author[=AUTHOR] ? Similar to the
--pretty option. BTW, can it do multiple author excludes now? The
commandline would look especially horrifying in that case now, I guess.
I'd prefer --stop-at-author from the choices you offer in your other
mail.
> > (Note that I don't endorse this patch and the --wrt-author behaviour in
> > particular seems strange. I don't have enough time to comment on it
> > sensibly now, though. I'm just focusing on style here since I'd like to
> > still be able to read git's source code few weeks from now on.)
>
> The rationale for the change is as follows:
>
> During parallel development, one is aware of ones own
> changes...everyone else changes haven't happened yet as far as you are
> concerned. Only when they appear in a future merge that incorporates
> one's own changes do the other changes appear in your own workspace.
>
> As far as you are concerned, these changes occurred after you made
> your own - your changes were not dependent on those changes, only on
> those that came before. So the linearisation reflects that perceived
> ordering of changes.
>
> --wrt-author helps to reconstruct the merge-history from the
> perspective of each individual committer.
Yes, such motivation makes sense. But is the author field the right one?
If you are integrating a lot of other people's patches in particular, I
think it makes no sense whatsoever - you already reviewed and
consciously applied them, but your option will regard them as something
alien and merged from outside, right?
And, after all, the other branches might be _quite_ long-lived. I think
it would be confusing for the user if the commit graph looked like
a1 -- a2 -- a3 -- a4 -- a5 -- a6 -- a7 -- a8 -- a9 -- a10
\ / / \ /
- b1 -- b2 -- b3 -- b4 -- b5 -- b6 -- b7 -- b8 -- b9
If your patch first chooses b1, it then shows all of it, completely
ignoring a2, right? I can't see how that would be right - the subsequent
merges from a should be shown.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: git-rev-list --merge-order hangs
From: Jon Seymour @ 2005-06-08 7:22 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git
In-Reply-To: <42A69550.1030105@gorzow.mm.pl>
On 6/8/05, Radoslaw Szkodzinski <astralstorm@gorzow.mm.pl> wrote:
> I've got a Linux git tree with some merges and some other commits
> interwined.
> I want to print all my changes in merge order, so I do:
>
> git-rev-list --pretty --merge-order v2.6.12-rc6-astorm1 ^v2.6.12-rc6
>
> It prints the first 3 commits (linear), but then hangs, eating all
> available CPU.
> Without --merge-order it works fine, but obviously lists the commits by
> parent.
Can you git-rev-list >/dev/null without arguments, then do a
git-rev-list --pretty --merge-order again and see it works any better?
If it still doesn't work, can you send me the output of:
git-rev-list --parents v2.6.12-rc6-astorm1 ^v2.6.12-rc6
I may then need to request a tarball of the related git objects so
that I can reproduce the problem on my end, but I'll send you the list
I need to see.
Regards,
jon.
^ permalink raw reply
* git-rev-list --merge-order hangs
From: Radoslaw Szkodzinski @ 2005-06-08 6:50 UTC (permalink / raw)
To: git
I've got a Linux git tree with some merges and some other commits
interwined.
I want to print all my changes in merge order, so I do:
git-rev-list --pretty --merge-order v2.6.12-rc6-astorm1 ^v2.6.12-rc6
It prints the first 3 commits (linear), but then hangs, eating all
available CPU.
Without --merge-order it works fine, but obviously lists the commits by
parent.
AstralStorm
^ permalink raw reply
* [PATCH] fix cg-commit new file handling
From: Eugene Surovegin @ 2005-06-08 5:59 UTC (permalink / raw)
To: git
Hi!
There is a problem with committing new files with the current cogito
version.
I got an error like this:
fatal: Unable to add arch/ppc/kernel/dcr.S to database
I think this is caused by the incorrect file list parsing in
cg-commit precommit_update(): it expects new files prefixed with "A",
while they are prefixed with "N".
The following trivial patch fixes this.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -227,7 +227,7 @@ precommit_update () {
for file in "$@"; do
op=${file%% *}
fname=${file#* }
- [ "$op" = "A" ] || [ "$op" = "D" ] || [ "$op" = "M" ] || op=M
+ [ "$op" = "N" ] || [ "$op" = "D" ] || [ "$op" = "M" ] || op=M
eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
done
# XXX: Do we even need to do the --add and --remove update-caches?
^ permalink raw reply
* Re: 3-way read-tree case matrix.
From: Junio C Hamano @ 2005-06-08 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vzmu1ec7w.fsf_-_@assigned-by-dhcp.cox.net>
I suspect my mailer dropped your response on the floor when it
polled my ISP at around 21:27 my time. I found its log
mentioning your address but no message in my mailbox.
Since the last message I sent you, I updated read-tree.c to
match the proposed behaviour, and I found a couple of problems
with it by running the 3-way merge test we already have. I am
attaching a revised one. I have not finished a new test suite
that runs on a populated index file yet, which is what I plan to
do next.
There is one thing that the proposed table changes from the
traditional 3-way merge semantics. I think this is a sensible
change.
- #2 and #3 (I botched #3 in the earlier one I sent you);
traditionally we left <O,H,M>=<none,none,exists> and
<O,H,M>=<none,exists,none> cases to the script policy; we
could salvage a (potentially dirty) cache entry if we say we
pick the one created in only one branch.
Earlier I botched <O,H,M>=<some,H!=O,M!=O> case in the table; we
should collapse to H/M if H==M; this is now handled differently
from H!=O,M!=O,H!=M case (case #10) as case #11 in the updated
table.
------------
"git-diff-tree -m O H M"
O H M result index requirements
------------------------------------------------------------------
1 missing missing missing - must not exist.
-----------------------------------------------------------------
2 missing missing exists take M must match M, if exists.
-----------------------------------------------------------------
3 missing exists missing take H must match H, if exists.
-----------------------------------------------------------------
4 missing exists exists no merge must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
5 exists missing missing no merge must not exist.
-----------------------------------------------------------------
6 exists missing O==M remove must not exist.
-----------------------------------------------------------------
7 exists missing O!=M no merge must not exist.
-----------------------------------------------------------------
8 exists O==H missing remove must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
9 exists O!=H missing no merge must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
10 exists O!=H O!=M no merge must match H and be
M!=H up-to-date, if exists.
-----------------------------------------------------------------
11 exists O!=H O!=M take H must match H, if exists.
M==H
-----------------------------------------------------------------
12 exists O!=H O==M take H must match H, if exists.
-----------------------------------------------------------------
13 exists O==H O!=M take M if exists, must either (1)
match H and be up-to-date,
or (2) match M.
-----------------------------------------------------------------
14 exists O==H O==M take M must match H if exists.
------------------------------------------------------------------
In all "take H" or "take M" cases, if the original index matches
what is taken, I would reuse it, and keep it dirty if it is.
The goal is, "(a) do not clobber the current index; (b) arrive
at the same result as in the case started with an empty index;
(c) favor success over failure as long as (a) and (b) are
satisfied."
^ permalink raw reply
* Re: "git cvsimport"
From: Tommy M. McGuire @ 2005-06-08 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506071556000.2286@ppc970.osdl.org>
On Tue, Jun 07, 2005 at 04:03:53PM -0700, Linus Torvalds wrote:
>
> Ok,
> here's something for testers and/or documentation people: I wrapped a
> little script around cvs2git (which I imported from the git tools thing),
> and now you can do
>
> git cvsimport <cvsroot> <modulename>
>
> and it might all "just work".
>
> Right now the little sript is actually being anal and checking that
> CVSROOT is a directory, even though I think it all _should_ work even if
> CVSROOT is remote too. But I don't have any remote things to test, and for
> all I know maybe performance is horrible, so for now it artificially
> limits it to locally accessible CVS repos.
>
> I'd love it if somebody tested the remote case (and, if it works, sends me
> a patch that just removes the anal tests in git-cvsimport-script), and
> maybe even updated the information a bit more.. As it is, that
> Documentation/cvs-migration.txt file is a bit on the light side.
>
> Finally, I don't know what to do about cvsps options. It seems that the
> default time-fuzz is a bit too long for some projects, so at least that
> one should be overridable. So my silly script is not exactly wonderful,
> but I think it's more approachable than people doing the magic by hand
> (and forgetting to set TZ to UTC and the "-A" flag etc etc).
>
> Linus
It seems to work for me. I'm still sanity checking the results.
Performance is indeed horrible for the remote case. I don't know how
horrible it would be for someone in a sane environment, since I'm behind
one of SBC's DSL gateways, which thinks (emphasis on "thinks") it is a
nameserver.
The script produced by cvs2git checks out every revision of every file,
right? Would "cvsps -g -p<dir>" improve cvs2git? I don't think it
would help performance (it checks out the files to generate the patchset
diffs (?)), but making the ugly someone else's problem is always good.
Also, what about -x, to force cvsps to regenerate it's cached idea of
the repository's patchsets?
cvsps seems a little weak on the whole error message idea (misspelling
cvsroot leads to complaints about CVS versions).
--
Tommy McGuire
^ permalink raw reply
* 3-way read-tree case matrix.
From: Junio C Hamano @ 2005-06-08 3:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506070808180.2286@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I did. It looks fine, although I'd like to point out that even the
LT> three-way merge _does_ mix in the original state for the case where the
LT> merge was trivially resolved...
Thanks. I have another request for sanity checking.
I am not sure if salvaging a dirty tree in a 3-way merge (as
opposed to just downright refusing) would have as much practical
value as the 2-tree fast-forward case, but here is a proposed
case matrix for the 3-way merge.
"git-diff-tree -m O H M"
O H M result index requirements
------------------------------------------------------------------
1 missing missing missing - must not exist.
-----------------------------------------------------------------
2 missing missing exists take M must match M if exists.
-----------------------------------------------------------------
3 missing exists missing remove must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
4 missing exists exists no merge must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
5 exists missing missing no merge must not exist.
-----------------------------------------------------------------
6 exists missing O==M remove must not exist.
-----------------------------------------------------------------
7 exists missing O!=M no merge must not exist.
-----------------------------------------------------------------
8 exists O==H missing remove must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
9 exists O!=H missing no merge must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
10 exists O!=H O!=M no merge must match H and be
up-to-date, if exists.
-----------------------------------------------------------------
11 exists O!=H O==M take H must match H, if exists.
-----------------------------------------------------------------
12 exists O==H O!=M take M if exists, must either (1)
match H and be up-to-date,
or (2) match M.
-----------------------------------------------------------------
13 exists O==H O==M take M must match H if exists.
------------------------------------------------------------------
In all "take H" or "take M" cases, if the original index matches
what is taken, I would reuse it, and keep it dirty if it is.
The goal is, "(1) do not clobber the current index; (2) arrive
at the same result as in the case started with an empty index;
(3) favor success over failure as long as (1) and (2) are
satisfied".
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Jon Seymour @ 2005-06-08 0:54 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205060702594da21fb1@mail.gmail.com>
| not sure why, but my first attempt to post this to the list didn't
seem to make it
| I've also modified my response slightly to suggest an alternate name for the
| --exclude-author swtich which may partly address pasky's concerns. amended
| response marked with ***
On 6/7/05, Petr Baudis <pasky@ucw.cz> wrote:
>
> I'd prefer just --wrt-author and --exclude-author to take an argument on
> their own.
The reason I don't want to do this is that it doesn't really make
sense in the context of the change to specify one author for
--wrt-author and another for --exclude-author. In normal use --author
defaults to GIT_AUTHOR_EMAIL or the locally derived user@host.domain.
The intention is simply to override this default derivation.
*** That said, it might better if --exclude-author was called
something like --following-author --after-author or --stop-at-author,
since its meaning is to stop traversal rather than simply omit match
entries which is the meaning that a reasonable user might attach to
use of the word "exclude"
My preference is --following-author.
Thoughts anyone?
>
> (Note that I don't endorse this patch and the --wrt-author behaviour in
> particular seems strange. I don't have enough time to comment on it
> sensibly now, though. I'm just focusing on style here since I'd like to
> still be able to read git's source code few weeks from now on.)
The rationale for the change is as follows:
During parallel development, one is aware of ones own
changes...everyone else changes haven't happened yet as far as you are
concerned. Only when they appear in a future merge that incorporates
one's own changes do the other changes appear in your own workspace.
As far as you are concerned, these changes occurred after you made
your own - your changes were not dependent on those changes, only on
those that came before. So the linearisation reflects that perceived
ordering of changes.
--wrt-author helps to reconstruct the merge-history from the
perspective of each individual committer.
Let me know if this doesn't explain the rationale completely enough
for your understanding.
jon.
^ permalink raw reply
* Re: [PATCH] Make cvs2git create tags
From: Petr Baudis @ 2005-06-08 0:43 UTC (permalink / raw)
To: torvalds; +Cc: Sven Verdoolaege, git
In-Reply-To: <20050601112723.GA18682@pc117b.liacs.nl>
Dear diary, on Wed, Jun 01, 2005 at 01:27:23PM CEST, I got a letter
where Sven Verdoolaege <skimo@liacs.nl> told me that...
> The current version of cvs2git doesn't propagate tags.
> Trivial patch below.
>
> skimo
> --
> cvs2git: create tags
>
> cvsps seems to put a space after the tag name, so we remove it first.
Hi,
this seems to have been forgotten along the way, and still appears to
be applicable to the latest git.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* "git cvsimport"
From: Linus Torvalds @ 2005-06-07 23:03 UTC (permalink / raw)
To: Git Mailing List
Ok,
here's something for testers and/or documentation people: I wrapped a
little script around cvs2git (which I imported from the git tools thing),
and now you can do
git cvsimport <cvsroot> <modulename>
and it might all "just work".
Right now the little sript is actually being anal and checking that
CVSROOT is a directory, even though I think it all _should_ work even if
CVSROOT is remote too. But I don't have any remote things to test, and for
all I know maybe performance is horrible, so for now it artificially
limits it to locally accessible CVS repos.
I'd love it if somebody tested the remote case (and, if it works, sends me
a patch that just removes the anal tests in git-cvsimport-script), and
maybe even updated the information a bit more.. As it is, that
Documentation/cvs-migration.txt file is a bit on the light side.
Finally, I don't know what to do about cvsps options. It seems that the
default time-fuzz is a bit too long for some projects, so at least that
one should be overridable. So my silly script is not exactly wonderful,
but I think it's more approachable than people doing the magic by hand
(and forgetting to set TZ to UTC and the "-A" flag etc etc).
Linus
^ permalink raw reply
* [PATCH] Use ntohs instead of htons to convert ce_flags to host byte order
From: Timo Hirvonen @ 2005-06-07 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506061858140.1876@ppc970.osdl.org>
Use ntohs instead of htons to convert ce_flags to host byte order
---
commit f827ec4fa1be102bda5b92edbf380defa03e8ae2
tree 735922d31ccdc6a2dc1f8e3f1388445903542385
parent fd787bb8d89cdacedc16cfef9dc4feb0cf843def
author Timo Hirvonen <tihirvon@ee.oulu.fi> Tue, 07 Jun 2005 23:18:02 +0300
committer Timo Hirvonen <tihirvon@ee.oulu.fi> Tue, 07 Jun 2005 23:18:02 +0300
read-cache.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/read-cache.c b/read-cache.c
--- a/read-cache.c
+++ b/read-cache.c
@@ -132,7 +132,7 @@ int cache_name_pos(const char *name, int
while (last > first) {
int next = (last + first) >> 1;
struct cache_entry *ce = active_cache[next];
- int cmp = cache_name_compare(name, namelen, ce->name, htons(ce->ce_flags));
+ int cmp = cache_name_compare(name, namelen, ce->name, ntohs(ce->ce_flags));
if (!cmp)
return next;
if (cmp < 0) {
@@ -206,7 +206,7 @@ static int check_file_directory_conflict
*ep = 0; /* first cut it at slash */
len = ep - pathbuf;
pos = cache_name_pos(pathbuf,
- htons(create_ce_flags(len, stage)));
+ ntohs(create_ce_flags(len, stage)));
if (0 <= pos) {
/* Our leading path component is registered as a file,
* and we are trying to make it a directory. This is
@@ -230,7 +230,7 @@ static int check_file_directory_conflict
* a directory there?
*/
pos = cache_name_pos(path,
- htons(create_ce_flags(namelen, stage)));
+ ntohs(create_ce_flags(namelen, stage)));
/* (0 <= pos) cannot happen because add_cache_entry()
* should have taken care of that case.
@@ -279,7 +279,7 @@ int add_cache_entry(struct cache_entry *
int pos;
int ok_to_add = option & ADD_CACHE_OK_TO_ADD;
int ok_to_replace = option & ADD_CACHE_OK_TO_REPLACE;
- pos = cache_name_pos(ce->name, htons(ce->ce_flags));
+ pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
/* existing match? Just replace it */
if (pos >= 0) {
@@ -307,7 +307,7 @@ int add_cache_entry(struct cache_entry *
if (check_file_directory_conflict(ce, ok_to_replace)) {
if (!ok_to_replace)
return -1;
- pos = cache_name_pos(ce->name, htons(ce->ce_flags));
+ pos = cache_name_pos(ce->name, ntohs(ce->ce_flags));
pos = -pos-1;
}
^ permalink raw reply
* Re: [PATCH] Add missing Documentation/*
From: Junio C Hamano @ 2005-06-07 18:50 UTC (permalink / raw)
To: Jason McMullan; +Cc: git
In-Reply-To: <20050607141736.GA2157@jmcmullan.timesys>
+Documentation
+--------------
+Documentation by Jason McMullan and the git-list <git@vger.kernel.org>.
I would suggest dropping "and the git-list" and the rest from
all the new files. The doc is by you, at least until somebody
else mucks on it.
+++ b/Documentation/git-get-tar-commit-id.txt
@@ -0,0 +1,29 @@
+DESCRIPTION
+-----------
+This shows the commit ID embedded in a git-tar-tree generated file.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
This is by Rene Scharfe. There is no single line from Linus in
the source file get-tar-commit-id.c, according to my "surviving
line counter".
^ permalink raw reply
* Re: [PATCH 3/4] Generic support for pulling refs
From: Daniel Barkalow @ 2005-06-07 16:45 UTC (permalink / raw)
To: McMullan, Jason; +Cc: GIT Mailling list
In-Reply-To: <1118150337.8970.49.camel@jmcmullan.timesys>
On Tue, 7 Jun 2005, McMullan, Jason wrote:
> Well, looks like you beat me to the punch, Daniel!
>
> I hereby concede the Deathmatch to git-ssh-pu{sh,ll}, and withdraw
> git-sync from consideration.
>
> Way to go Daniel!
>
> "Welcome to Git Thunderdome. Two codes enter, one code leaves."
Of course, my secret is that I actually wrote it all in advance, so I just
had to polish it up, rebase, and document the program that was already
in...
Back on topic, are there things you need that git-ssh-* doesn't do? It
would still be good to get the code to write objects to temporary files
until they're determined to be valid.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add support for --wrt-author, --author and --exclude-author switches to git-rev-list
From: Jon Seymour @ 2005-06-07 15:58 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cfc403205060702596dee7341@mail.gmail.com>
> --wrt-author helps to reconstruct the merge-history from the
> perspective of each individual committer.
>
Correction:
--wrt-author helps to reconstruct the merge-history from the
perspective of each individual author.
jon.
^ permalink raw reply
* Re: [PATCH] Add git-help-script
From: McMullan, Jason @ 2005-06-07 14:25 UTC (permalink / raw)
To: Linus Torvalds, GIT Mailling list
In-Reply-To: <20050607141944.GA14915@jmcmullan.timesys>
[-- Attachment #1: Type: text/plain, Size: 4041 bytes --]
NOTE: This patch requires '[PATCH] Add missing Documention/*'
Here's the example output of 'git-help-script', which is called
when the user doesn't supply any options to the 'git' script wrapper,
or -h, or --help
$ git
Commands:
git the stupid content tracker
git apply-patch Sample script to apply the diffs from git-diff-*
git commit Commit working directory
git deltafy Convery repository into delta format
git fetch Fetch an object from a remote repository
git help Short help of all the git commands and scripts
git log
git merge-one-file The standard helper program to use with
"git-merge-cache"
git prune Prunes all unreachable objects from the object
database
git pull Script used by Linus to pull and merge a
remote repository
git resolve Script used to merge two trees
git-shortlog
git status
git tag An example script to create a tag object
signed with GPG
git-whatchanged Find out what changed
git-apply Apply a patch against the current index
cache/working
directory
git-cat-file Provide content or type information for
repository
objects
git-check-files Verify a list of files are up-to-date
git-checkout-cache Copy files from the cache to the working
directory
git-commit-tree Creates a new commit object
git-convert-cache Converts old-style GIT repository
git-diff-cache Compares content and mode of blobs between
the cache and repository
git-diff-files Compares files in the working tree and the
cache
git-diff-helper Generates patch format output for git-diff-*
git-diff-tree Compares the content and mode of blobs found
via two tree objects
git-export Exports each commit and a diff against each
of its parents
git-fsck-cache Verifies the connectivity and validity of
the objects in the database
git-get-tar-commit-idShow the commit ID embedded in a git-tar-tree
file.
git-http-pull Downloads a remote GIT repository via HTTP
git-init-db Creates an empty git object database
git-local-pull Duplicates another GIT repository on a local
system
git-ls-files Information about files in the cache/working
directory
git-ls-tree Lists the contents of a tree object.
git-merge-base Finds as good a common ancestor as possible
for a merge
git-merge-cache Runs a merge for files needing merging
git-mkdelta Creates a delta object
git-mktag Creates a tag object
git-read-tree Reads tree information into the directory
cache
git-rev-list Lists commit objects in reverse chronological
order
git-rev-tree Provides the revision tree for one or more
commits
git-ssh-pull Pulls from a remote repository over ssh
connection
git-ssh-push Pushes to a remote repository over ssh
connection
git-stripspace Strip space from stdin
git-tar-tree Creates a tar archive of the files in the
named tree
git-unpack-file Creates a temporary file with a blob's contents
git-update-cache Modifies the index or directory cache
git-write-blob Creates a blob from a file
git-write-tree Creates a tree from the current cache
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add missing Documentation/*
From: McMullan, Jason @ 2005-06-07 14:20 UTC (permalink / raw)
To: torvalds; +Cc: GIT Mailling list
In-Reply-To: <20050607141736.GA2157@jmcmullan.timesys>
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
This patch (or one like it that just adds Documentation/* stubs) is
a pre-require for '[PATCH] Add git-help-script'
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Add git-help-script
From: Jason McMullan @ 2005-06-07 14:19 UTC (permalink / raw)
To: torvalds, git
Id: 13d680c11f5403f3b1b48e71416e36770cd0aecf
tree 91e05412806336f2c9d989b8d9a2eccb21281efe
parent e774aa5641ca2267e7aba7338da3f7e355b7fb78
author Jason McMullan <jason.mcmullan@gmail.com> 1118153648 -0400
committer Jason McMullan <jason.mcmullan@gmail.com> 1118153648 -0400
Add: 'git help' aka 'git-help-script', built from Documentation/* information
======== diff against e774aa5641ca2267e7aba7338da3f7e355b7fb78 ========
diff --git a/Documentation/git-help-script.txt b/Documentation/git-help-script.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/git-help-script.txt
@@ -0,0 +1,29 @@
+git-help-script(1)
+==================
+v0.1, May 2005
+
+NAME
+----
+git-help-script - Short help of all the git commands and scripts
+
+
+SYNOPSIS
+--------
+'git-help-script'
+
+DESCRIPTION
+-----------
+Shows a brief summary of all the git-* commands.
+
+Author
+------
+Written by Jason McMullan <jason.mcmullan@timesys.com>
+
+Documentation
+--------------
+Documentation by Jason McMullan and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
+
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -23,7 +23,7 @@ INSTALL=install
SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
git-pull-script git-tag-script git-resolve-script git-whatchanged \
git-deltafy-script git-fetch-script git-status-script git-commit-script \
- git-log-script git-shortlog
+ git-log-script git-shortlog git-help-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
@@ -84,6 +84,26 @@ test-delta: test-delta.c diff-delta.o pa
git-%: %.c $(LIB_FILE)
$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
+git-help-script: Makefile $(patsubst %,Documentation/%.txt,$(SCRIPTS) $(PROG))
+ echo "#!/bin/sh" >git-help-script
+ echo "cat <<EOF" >>git-help-script
+ echo "Commands:" >>git-help-script
+ echo >>git-help-script
+ for cmd in $(sort $(SCRIPTS)) $(sort $(PROG)); do \
+ doc="Documentation/$$cmd.txt"; \
+ if [ ! -e "$$doc" ]; then \
+ echo "MISSING: $$doc" 1>&2; \
+ rm -f git-help-script; \
+ exit 1; \
+ fi; \
+ desc=`grep "^$$cmd - " $$doc | cut -d' ' -f3-` ; \
+ desc=`echo "$$desc" | sed -e 's/\(.\{40\}\) /\1\n /g'` ; \
+ cmd=`echo $$cmd | sed -e 's/^git-\(.*\)-script$$/git \1/'`; \
+ printf " %-20s%s\n" "$$cmd" "$$desc" >>git-help-script; \
+ done
+ echo "EOF" >>git-help-script
+ echo "exit 1" >>git-help-script
+
git-update-cache: update-cache.c
git-diff-files: diff-files.c
git-init-db: init-db.c
@@ -143,7 +163,7 @@ test: all
$(MAKE) -C t/ all
clean:
- rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
+ rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) git-help-script
$(MAKE) -C Documentation/ clean
backup: clean
diff --git a/git b/git
--- a/git
+++ b/git
@@ -1,4 +1,8 @@
#!/bin/sh
-cmd="git-$1-script"
+
+cmd="$1"
+
+[ -z "$cmd" -o "$cmd" = "-h" -o "$cmd" = "--help" ] && cmd="help"
+cmd="git-$cmd-script"
shift
exec $cmd "$@"
======== end ========
^ 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