* Re: Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-13 1:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512121720150.15597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So I think your diffcore-break.c patch is much more appropriate: it also
> fixes the bug, but it fixes it by virtue of realizing that the delta
> cannot matter and thus should never even be computed.
Agreed, redone and pushed out.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9m aka 1.0rc5
From: Paul Dickson @ 2005-12-13 1:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqznm4b7.fsf@assigned-by-dhcp.cox.net>
On Sun, 11 Dec 2005 18:34:20 -0800, Junio C Hamano wrote:
> GIT 0.99.9m aka 1.0rc5 is found at usual places:
Is it just me or do most paragraphs (blocks of text) end with a ".sp"?
>From git-repack man file:
AUTHOR
Written by Linus Torvalds <torvalds@osdl.org>.sp
DOCUMENTATION
Documentation by Ryan Anderson <ryan@michonline.com>.sp
SEE-ALSO
git-pack-objects(1) git-prune-packed(1).sp
GIT
Part of the git(7) suite.sp
-Paul
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Linus Torvalds @ 2005-12-13 1:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkypdcsb.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005, Junio C Hamano wrote:
>
> I'll revert the changes anyway, but not because I necessarily
> agree with you two. I am not 100% confident that the core of
> the diff_delta code would work fine with empty input (it seems
> to from my limited test), and I do not want to break things
> unnecessarily at this point.
Well, I checked the pack-objects.c side, and your patch to diff_delta()
should not hurt at least there. We already check the size and would have
broken out long before if either side was zero-sized.
But that's kind of part of the point - any user of diff_delta() is likely
to have checked the size anyway for other reasons. There's just very
seldom any valid reason to generate a delta against an empty file, there's
no interesting information that diff_delta() can really give us.
Basically, the binary diffs that diff-delta returns are interesting for
just two things:
- efficient packing, in the pack-objects.c style.
As mentioned, pack-objects.c needs to check the size heuristics before
doing diff_delta() _anyway_, for performance reasons as well as simply
because the secondary use of diff_delta() is to estimate how big the
delta is, and it's always pointless to generate a delta that is
guaranteed to be bigger than the file (which is always the case with
either side being an empty file - the size difference will inevitably
be bigger than the size of the resulting file).
- difference size estimation (ie for rename/copy detection)
This boils down to the same case as the secondary use of pack-objects,
ie delta size estimation. Again, if either side is empty, we _know_
that the delta generation is pointless, because the delta is always
going to be bigger than the end result, and thus it can't be sensible
for rename/copy detection.
So in one sense I actually agree with your patch: it makes the deltifier
code more generic and actually simplifies the diff_delta() code a bit by
avoiding one special case, and in that sense it's a good change.
So the reason I disagree with it is that doing the delta is always going
to be unnecessary work. And regardless of how we're ever going to use the
delta, we _know_ that it's unnecessary work.
So I think your diffcore-break.c patch is much more appropriate: it also
fixes the bug, but it fixes it by virtue of realizing that the delta
cannot matter and thus should never even be computed.
Now, your diff_setup() change may actually be worth it because of the
simplification, but on the other hand, you can also consider the NULL
return as being nice because it's effectively a way of saying "the delta
is meaningless, why did you even ask me?"
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.16.1
From: Paul Dickson @ 2005-12-13 1:26 UTC (permalink / raw)
To: git
In-Reply-To: <20051212011210.GC12373@pasky.or.cz>
On Mon, 12 Dec 2005 02:12:10 +0100, Petr Baudis wrote:
> this is Cogito version 0.16.1, the next stable release of the
> human-friendly version control UI for the Linus' GIT tool.
Can the -help argument be supported too? It's pretty annoying to end up
typing -help and having that used as a tag or commit.
Any chance of man files? I'm more use to type man than cg-help.
How about giving instructions in the edited commit message about how to
abort the commit. I've figured out you can just delete all the
referenced files, but this was just by accident. (0.15.1) I had my emacs
segfault and that commit was performed too.
Any chance a creating a very simple cg-mv? Having to switch is a lower
level (git) to perform this function takes time (verifying the
functionality).
Is there a cogito equivalent of "git-branch foo"? It seems cg-branch-add
does everything but that.
-Paul
Using git/cogito for 9 days.
^ permalink raw reply
* Re: Problems with cg-admin-setuprepo
From: Petr Baudis @ 2005-12-13 1:16 UTC (permalink / raw)
To: Paul Dickson; +Cc: git
In-Reply-To: <20051212180215.e9b687e4.paul@permanentmail.com>
Dear diary, on Tue, Dec 13, 2005 at 02:02:15AM CET, I got a letter
where Paul Dickson <paul@permanentmail.com> said that...
> On Mon, 12 Dec 2005 02:12:10 +0100, Petr Baudis wrote:
> > this is Cogito version 0.16.1, the next stable release of the
> > human-friendly version control UI for the Linus' GIT tool.
>
> The help from cg-admin-setuprepo say it will create the repo in the given
> directory, but doesn't say it must create the directory.
>
> $ mkdir ~/test
> $ cg-admin-setuprepo ~/test
> cg-admin-setuprepo: /home/dickson/test already exists
Good point. I've added it to the description.
> There seems to be a missing step in the help instructions:
>
> $ cg-admin-setuprepo ~/test/test1
> $ cg-push
> cg-push: where to push to?
You need to first add the remote branch to your local repository by the
cg-branch-add origin ~/test/test1
command. I've added it to the instructions.
Thanks,
--
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: Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-13 1:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512121529200.15597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Do what pack-objects.c does: just call "diff_delta()" and check the result
> for NULL. If the result is NULL, then you have to do some special code,
> because that means that it's a full create or a full delete (or it's an
> unchanged empty file). Regardless, it really _is_ a special case, and it
> would be silly to generate a delta for it.
When the result is NULL, it could be delta against empty, or
other failure in diff_delta() (could be it exceeded max_size,
could be it could not allocate memory, could be we introduced
some other failure modes later...).
I'll revert the changes anyway, but not because I necessarily
agree with you two. I am not 100% confident that the core of
the diff_delta code would work fine with empty input (it seems
to from my limited test), and I do not want to break things
unnecessarily at this point. More importantly, for the updated
delta code that allows empty input to work, the codepaths the
various existing callers that check with NULL must not be
assuming non-NULL return means non empty input -- otherwise my
change would subtly break things -- and I do not have enough
energy to verify that right now.
Since we do not break files smaller than MINIMUM_BREAK_SIZE,
this becomes a non-issue with the attached patch. I do not know
why I did not check both sides when I did it the first time; I
do not know why I was too stupid to notice that the earlier test
in the if() was far more expensive than the later one, either ;-).
-- >8 --
diff --git a/diffcore-break.c b/diffcore-break.c
index e6a468e..9b27456 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -55,12 +55,6 @@ static int should_break(struct diff_file
* is the default.
*/
- if (!S_ISREG(src->mode) || !S_ISREG(dst->mode))
- return 0; /* leave symlink rename alone */
-
- if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
- return 0; /* error but caught downstream */
-
base_size = ((src->size < dst->size) ? src->size : dst->size);
delta = diff_delta(src->data, src->size,
@@ -169,9 +163,15 @@ void diffcore_break(int break_score)
if (DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two) &&
!S_ISDIR(p->one->mode) && !S_ISDIR(p->two->mode) &&
!strcmp(p->one->path, p->two->path)) {
- if (should_break(p->one, p->two,
- break_score, &score) &&
- MINIMUM_BREAK_SIZE <= p->one->size) {
+
+ if (S_ISREG(p->one->mode) &&
+ S_ISREG(p->two->mode) &&
+ !diff_populate_filespec(p->one, 0) &&
+ MINIMUM_BREAK_SIZE <= p->one->size &&
+ !diff_populate_filespec(p->two, 0) &&
+ MINIMUM_BREAK_SIZE <= p->two->size &&
+ should_break(p->one, p->two,
+ break_score, &score)) {
/* Split this into delete and create */
struct diff_filespec *null_one, *null_two;
struct diff_filepair *dp;
^ permalink raw reply related
* ([ANNOUNCE] Cogito-0.16)
From: Petr Baudis @ 2005-12-13 1:07 UTC (permalink / raw)
To: git
It seems the actual announcement has never really hit the list, for
some reason. I'm posting this only so that the history can record this
and people can look it up later. And so that I don't feel silly wasting
time putting it together. ;-) But the current version is 0.16.1 right
now, and another release will be coming up soon.
============
Hello,
here goes Cogito version 0.16, the human-friendly version control UI
for the Linus' GIT tool. Share and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Plenty of new features and bugfixes. There are only few minor bugfixes
since rc2, and one major bugfix concerning possible weirdness after
cg-merge failing with the git-read-tree error - for this reason, it's
recommended to upgrade.
I changed my tactics wrt. the minor versions; 0.16 has now dedicated
branch and I will try to accumulate at least non-trivial bugfixes there,
so 0.16.1 will be probably purely bugfix release. The "stable" 0.16
branch is available in the Cogito repository as "v0.16".
The notable new stuff since 0.15.1 includes:
* Significant fetching surgery:
- host:path location now means git+ssh instead of rsync (but it
is deprecated in favour of explicit protocol name - safer and
less confusing for you)
- git+ssh uses packed transport instead of the dated git-ssh-fetch
- Tags fetching is now much more reliable, saner and faster
- More robust rsync fetching (for anyone actually still using it)
- Local fetching should work even without GNU cp now
- curl is used instead of wget for fetching over HTTP
- Non-symlink HEADs are now fetched from properly
- Speedup of the whole thing (the progressbar was actually slowing
the process down so much that I'm almost afraid to say it)
* The one-file merging autoresolver covers much more cases now;
it still probably doesn't handle file-symlink and file-directory
conflicts (actually, I didn't even test anything related to that
yet), but otherwise it should handle pretty much any conflict now
(except that it yet won't make sure that you resolved the conflict
before committing)
* New command cg-admin-setuprepo for creating public repositories
* Major cg-restore surgery - more pleasant to use, more powerful,
more robust
* Handle multiple merge bases (leaving the decision on the user)
* Fix another bug related to dirty merges - files containing local
changes would be left marked as ignored for committing ('m' in
cg-status) until after the next commit in case cg-merge failed
with git-read-tree error - please upgrade!
* Fix a long-standing bug with some stale files not being removed
during large fast-forwards
* Heaps of other both major and minor bugfixes; I won't name them,
you can look at "cg-log -s -r cogito-0.15.1.." - but you should
certainly upgrade
* cg-push -t will push tags
* cg-merge -j will join projects with disjoint histories
* cg-merge --squash will do the "squash merge" (see docs for details)
* cg-log --summary will show the shortlog output
* cg-diff -s will show diffstat
* cg-reset --adds-removes will reset only index (cancel the
adds/removes recorded, from the user perspective)
* cg-status DIRNAME will show the status relative to that directory
* cg-status -s will filter for only the given status flags
* cg-tag always creates the tag object
* cg-init -m'msg' support
* Deprecated .git/branch-name
* First draft of the VCS-neutral interface implemented as
contrib/neutral.sh
* Speedups all around (e.g. per-file cg-log SIXTY times)
* Reorganized cg-help output
* More new tests in the testsuite
* Documentation stuff - the "scripted tutorial", README expanded,
tiny stuff all around
Happy hacking,
--
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: qgit reports errors in the git repository
From: Linus Torvalds @ 2005-12-13 1:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Marco Costalba
In-Reply-To: <1134433440.3798.27.camel@dv>
On Mon, 12 Dec 2005, Pavel Roskin wrote:
>
> Git says:
> fatal: git-cat-file 23ea3e201cea0deea909569e08e950a9ec2345f7: bad file
>
> I believe qgit runs "git-cat-file -t tag" on in, but it's a commit. If
> I change the git-cat-file invocation in src/git_startup.cpp to use
> "commit" instead of "tag", qgit complains about
> 0918385dbd9656cab0d1d81ba7453d49bbc16250.
>
> Maybe qgit should check the type of the object first? Or maybe there
> should another type for git-cat-file that would match both tag and
> commit?
Using "git-cat-file commit <object>" already works for both real commits
and for tags that point to commits.
However, the "0918385dbd9656cab0d1d81ba7453d49bbc16250" object is a tag
that points to a blob (Junios public gpg key), so you can't use that.
Basically, qgit should do either:
- check the type of the object by hand first (using "git-cat-file -t" and
then follow any tags it finds by hand)
_or_
- just use "git-cat-file commit" and if an error occurs, just silently
ignore that ref since it doesn't understand them.
which one is the right strategy depends on usage.
Linus
^ permalink raw reply
* Problems with cg-admin-setuprepo
From: Paul Dickson @ 2005-12-13 1:02 UTC (permalink / raw)
To: git
In-Reply-To: <20051212011210.GC12373@pasky.or.cz>
On Mon, 12 Dec 2005 02:12:10 +0100, Petr Baudis wrote:
> this is Cogito version 0.16.1, the next stable release of the
> human-friendly version control UI for the Linus' GIT tool.
The help from cg-admin-setuprepo say it will create the repo in the given
directory, but doesn't say it must create the directory.
$ mkdir ~/test
$ cg-admin-setuprepo ~/test
cg-admin-setuprepo: /home/dickson/test already exists
There seems to be a missing step in the help instructions:
$ cg-admin-setuprepo ~/test/test1
$ cg-push
cg-push: where to push to?
-Paul
^ permalink raw reply
* Re: [PATCH] cg-clean: fix directory cleaning
From: Petr Baudis @ 2005-12-13 0:42 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1134420860.4695.14.camel@dv>
Dear diary, on Mon, Dec 12, 2005 at 09:54:20PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> cg-clean is broken by commit 3cddede46dcd24bd7c36827ca564de23b2bb3517 -
> it removes all subdirectories when run in the top level directory.
>
> Although it's easy to make a one-line fix, I'd prefer a solution that
> makes cg-clean potentially safer. Since git-ls-files runs in
> subdirectories now, it's no longer needed to run anything in the top
> level directory and filter out the results. cg-clean now changes to
> $_git_relpath on startup and never uses $_git_relpath again.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Oops! Many thanks to both this and the testcase - I was just about to
write one, because those cg-clean bugs are really quite ugly. I'll
release 0.16.2 tomorrow if no other bug will be found.
--
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
* qgit reports errors in the git repository
From: Pavel Roskin @ 2005-12-13 0:24 UTC (permalink / raw)
To: git, Marco Costalba
Hello!
qgit reports an error from git-cat-file when run in the git repository.
The error shown in a message box with the text:
Git says:
fatal: git-cat-file 23ea3e201cea0deea909569e08e950a9ec2345f7: bad file
I believe qgit runs "git-cat-file -t tag" on in, but it's a commit. If
I change the git-cat-file invocation in src/git_startup.cpp to use
"commit" instead of "tag", qgit complains about
0918385dbd9656cab0d1d81ba7453d49bbc16250.
Maybe qgit should check the type of the object first? Or maybe there
should another type for git-cat-file that would match both tag and
commit?
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Everyday: some examples.
From: Junio C Hamano @ 2005-12-13 0:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512120827440.15597@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 9 Dec 2005, Junio C Hamano wrote:
>>
>> Exactly. That's why task oriented list would be most useful.
>> Here is a starter.
>>
>>
>> Everyday GIT Cheat Sheet Or Git With 20 Commands
>> ================================================
>
> Would this file perhaps also have examples?
How about...
---
Documentation/everyday.txt | 72 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 68 insertions(+), 4 deletions(-)
44db136cad84c003506e231a38935ca6acba4d7d
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 5775cd2..ded4d51 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -59,9 +59,6 @@ following commands.
* gitlink:git-show-branch[1] to see where you are.
- * gitlink:git-diff[1] and gitlink:git-status[1] to see what
- you are in the middle of doing.
-
* gitlink:git-log[1] to see what happened.
* gitlink:git-whatchanged[1] to find out where things have
@@ -70,7 +67,11 @@ following commands.
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
branches.
- * gitlink:git-update-index[1] to manage the index file.
+ * gitlink:git-add[1] and gitlink:git-update-index[1] to manage
+ the index file.
+
+ * gitlink:git-diff[1] and gitlink:git-status[1] to see what
+ you are in the middle of doing.
* gitlink:git-commit[1] to advance the current branch.
@@ -83,6 +84,37 @@ following commands.
* gitlink:git-rebase[1] to maintain topic branches.
+Examples
+~~~~~~~~
+
+* Extract a tarball and create a working tree and a new repository to keep track of it.
+------------
+$ tar zxf frotz.tar.gz
+$ cd frotz
+$ git-init-db
+$ git add .
+$ git commit -m 'import of frotz source tree.'
+------------
+
+* Create a topic branch and develop
+------------
+$ git checkout -b private
+$ edit/compile/test
+$ git diff <1>
+$ git checkout -- foo.c <2>
+$ edit/compile/test
+$ git commit -a -s <3>
+$ git checkout master <4>
+$ git pull . private <5>
+
+<1> to see what changes you are committing.
+<2> revert your botched changes in selected path "foo.c".
+<3> commit everything as you have tested.
+<4> switch to the master branch.
+<5> merge a topic branch into your master branch
+------------
+
+
Individual Developer (Participant)[[Individual Developer (Participant)]]
------------------------------------------------------------------------
@@ -100,6 +132,38 @@ addition to the ones needed by a standal
you adopt Linux kernel-style public forum workflow.
+Examples
+~~~~~~~~
+
+* Clone the upstream and work on it. Feed changes to upstream.
+------------
+$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
+$ cd my2.6
+$ edit/compile/test; git commit -a -s <1>
+$ git format-patch master <2>
+$ git pull <3>
+$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <4>
+
+<1> repeat as needed.
+<2> extract patches from your branch for e-mail submission.
+<3> "pull" fetches from "origin" by default and merges.
+<4> fetch from a specific branch from a specific repository and and merge.
+------------
+
+* Branch off of a specific tag.
+------------
+$ git checkout -b private2.6.14 v2.6.14 <1>
+$ edit/compile/test; git commit -a
+$ git checkout master
+$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
+ git am -3 -k <2>
+<1> create a private branch based on a well known (but somewhat behind)
+tag.
+<2> forward port all changes in private2.6.14 branch to master
+branch without formal "merging".
+------------
+
+
Integrator[[Integrator]]
------------------------
--
0.99.9.GIT
^ permalink raw reply related
* Re: branching and supporting a tagged kernel version
From: Petr Baudis @ 2005-12-13 0:01 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512121558s6e300103t95fcc0e9573604a7@mail.gmail.com>
Dear diary, on Tue, Dec 13, 2005 at 12:58:38AM CET, I got a letter
where Don Zickus <dzickus@gmail.com> said that...
> Thanks for clearing things up.
>
> > I'll refrain from saying that it is not the usual way to work
> > with git, since you seem to know what you are doing. So let's
>
> Either this or cvs. :) Anyway my work involves releasing a platform
> to customers who don't want to constantly upgrade their kernel. And
> instead of waiting for bugs to be filed, I was just trying to find a
> way to be pro-active and fix certain bugs _before_ our customers hit
> them.
You might also consider managing your patches in StGIT, which could give
you more comfort for managing them. StGIT provides quilt-like
functionality on top of GIT, and it's easy to reorder, add, and remove
patches, as well as submit them to the upstream and remove them
automatically when they get merged.
--
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: branching and supporting a tagged kernel version
From: Don Zickus @ 2005-12-12 23:58 UTC (permalink / raw)
Cc: git
In-Reply-To: <7virtueycd.fsf@assigned-by-dhcp.cox.net>
Thanks for clearing things up.
> I'll refrain from saying that it is not the usual way to work
> with git, since you seem to know what you are doing. So let's
Either this or cvs. :) Anyway my work involves releasing a platform
to customers who don't want to constantly upgrade their kernel. And
instead of waiting for bugs to be filed, I was just trying to find a
way to be pro-active and fix certain bugs _before_ our customers hit
them.
Cheers,
Don
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Linus Torvalds @ 2005-12-12 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vek4igevq.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> >
> > I would say involving an empty blob with deltas _is_ the bug in the
> > first place. Please don't let that happen.
I agree with Nicolas.
> Not all use of delta is to produce a pack. An empty->empty
> delta is a valid two byte \0\0 sequence, and I do not see any
> reason to forbid it. Although using such delta to represent
> anything in a pack does *not* make any sense as you say, it
> makes other callers simpler if they do not have to check if
> from_len and to_len are empty before calling the delta code.
And you don't need to.
Do what pack-objects.c does: just call "diff_delta()" and check the result
for NULL. If the result is NULL, then you have to do some special code,
because that means that it's a full create or a full delete (or it's an
unchanged empty file). Regardless, it really _is_ a special case, and it
would be silly to generate a delta for it.
Linus
^ permalink raw reply
* Re: branching and supporting a tagged kernel version
From: Junio C Hamano @ 2005-12-12 22:37 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512121331x13bfb691t62224d02ced04a27@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
> So my questions (for now) are:
>
> 1) what is the easiest way to branch off on a tagged version (in this
> case 2.6.14)? I didn't quite understand what <starting point>
> referred to in the git-branch docs.
Starting point is badly worded, but essentially it means
"anything that names a particular commit". That's the commit
you want to base your branch off of.
In your case, you would run:
------------
$ git clone git://git.kernel.org/pub/.../torvalds/linux-2.6/ my2.6
$ cd my2.6
$ git checkout -b private v2.6.14
------------
to create and checkout a branch called "private" to house your
personal changes, based on v2.6.14. Your working tree is based
on v2.6.14 and you are on the "private" branch immediately after
this operation, and you should see no diff from either of these
commands:
------------
$ git diff v2.6.14 <1>
$ git diff private v2.6.14 <2>
<1> compare your work tree with v2.6.14 tagged by Linus
<2> compare "private" branch head with v2.6.14 tagged by Linus
------------
Then work as usual, the cycle is:
------------
$ edit
$ git diff ;# to see how well you are doing
$ compile
$ test
$ git diff HEAD ;# final review before committing
$ git commit -a ;# commit all changes as you tested
------------
> 2) is there a way to get a list of commits from upstream that are not
> in my branch and then selectively apply them? Yes, I understand the
> potential merge mess...
I'll refrain from saying that it is not the usual way to work
with git, since you seem to know what you are doing. So let's
assume that you somehow do not ever want to merge from Linus
head into the "private" branch.
After you have worked there:
------------
$ git fetch origin
$ git cherry origin private
------------
would show the list of commits since you forked from origin,
which is Linus head --- when you run "git clone" to set up
"my2.6" repository, it would have made .git/remotes/origin
shorthand that has this line in it:
------------
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Pull: master:origin
------------
pick the ones you want, and apply them with:
------------
$ git cherry-pick 12233445....
------------
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Junio C Hamano @ 2005-12-12 21:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512121620380.26663@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
>> This is not just "diff". Our deltify code is half-broken, and
>> in the worst case this can corrupt our packs if an empty blob is
>> involved.
>
> I would say involving an empty blob with deltas _is_ the bug in the
> first place. Please don't let that happen.
Not all use of delta is to produce a pack. An empty->empty
delta is a valid two byte \0\0 sequence, and I do not see any
reason to forbid it. Although using such delta to represent
anything in a pack does *not* make any sense as you say, it
makes other callers simpler if they do not have to check if
from_len and to_len are empty before calling the delta code.
They care about from_len=0 (or to_len=0) case to produce similar
results as from_len=1 (or to_len=1) case and do not care at all
about the produced delta being a useful one for compressed
storage purposes.
> Especially with pack files, an empty blob can be represented with a
> _single_ byte. A delta must always be against something else and simply
> storing the reference for the object the delta is against will always
> use at least 20 bytes even for empty ones.
True, and the pack code is actually safe. It punts on NULL
return, so my initial worry about packs turns out to be
unneeded.
> If my opinion is still of any weight I'd strongly vote for the former.
I ended up doing both ;-). The call site of diffcore-break was
certainly careless and broken (fixed); I've run git-grep to
check all callers to diff_delta() and the only one that did not
check the return value with NULL was the one that started with
thread.
^ permalink raw reply
* branching and supporting a tagged kernel version
From: Don Zickus @ 2005-12-12 21:31 UTC (permalink / raw)
To: git
Hello,
I was trying to see if I can use git for a particular way of
supporting a kernel and was hoping for some feedback if this approach
would work.
Basically I wanted to branch off of 2.6.14 and support personal
patches. However over time I would like to be able to merge in
hand-pick commits from upstream.
So my questions (for now) are:
1) what is the easiest way to branch off on a tagged version (in this
case 2.6.14)? I didn't quite understand what <starting point>
referred to in the git-branch docs.
2) is there a way to get a list of commits from upstream that are not
in my branch and then selectively apply them? Yes, I understand the
potential merge mess...
Thanks,
Don
^ permalink raw reply
* Re: Delitifier broken (Re: diff-core segfault)
From: Nicolas Pitre @ 2005-12-12 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Darrin Thompson, git, Linus Torvalds
In-Reply-To: <7virtui1kj.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 12 Dec 2005, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Darrin Thompson <darrint@progeny.com> writes:
> >
> >> Could someone confirm that this exists on more recent git heads and fix
> >> if needed?
> >
> > (1) Yup. I can reproduce it.
> > (2) Will look into it when able.
>
> This is not just "diff". Our deltify code is half-broken, and
> in the worst case this can corrupt our packs if an empty blob is
> involved.
I would say involving an empty blob with deltas _is_ the bug in the
first place. Please don't let that happen.
Especially with pack files, an empty blob can be represented with a
_single_ byte. A delta must always be against something else and simply
storing the reference for the object the delta is against will always
use at least 20 bytes even for empty ones.
> The problem is if from_size or to_size is empty, it does not
> produce any.
>
> if (!from_size || !to_size || delta_prepare(from_buf, from_size, &bdf))
> return NULL;
>
>
> I think either we need to make the users more careful or fix
> deltifier to produce trivial delta. I'd vote for the latter;
> let me rig up something.
If my opinion is still of any weight I'd strongly vote for the former.
A delta against an empty object, or a delta that produces an empty
object simply makes no sense since it is always suboptimal compared to
storing the non deltified object (or finding another object to deltify
against). Allowing empty deltas only paper over another more
fundamental bug IMHO.
Nicolas
^ permalink raw reply
* Re: [PATCH 2/2] diff-delta.c: allow delta with empty blob.
From: Darrin Thompson @ 2005-12-12 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacf6hwwc.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-12-12 at 12:40 -0800, Junio C Hamano wrote:
> Could you try this patch? It is marked as 2/2 but 1/2 is a
> test script to reproduce the problem with the current code,
> which this patch is supposed to fix, and this should be the
> only fix you need.
I'm almost out of time for today. Possibly tomorrow I can get to it.
--
Darrin
^ permalink raw reply
* [PATCH] cg-clean test
From: Pavel Roskin @ 2005-12-12 20:56 UTC (permalink / raw)
To: git, Petr Baudis
This is a test for cg-clean functionality.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/t/t9400-clean.sh b/t/t9400-clean.sh
new file mode 100755
index 0000000..76186b6
--- /dev/null
+++ b/t/t9400-clean.sh
@@ -0,0 +1,112 @@
+#!/usr/bin/env bash
+#
+# Copyright (c) 2005 Pvel Roskin
+#
+test_description="Tests basic cg-clean functionality
+
+Create files and directories and check that cg-clean removes them."
+
+. ./test-lib.sh
+
+# Use spaces in names to make sure they are handled properly.
+echo "repo file 1" >"repo file 1"
+mkdir "repo dir"
+echo "repo file 2" >"repo dir/repo file 2"
+echo "*.ign" >".gitignore"
+echo "*.ign1" >"repo dir/.gitignore"
+
+test_expect_success 'initialize repo' \
+ "(cg-add -r * .gitignore && \
+ cg-commit -C -m\"Initial commit\")"
+
+echo "extra file 1" >"extra file 1"
+mkdir "extra dir 1"
+echo "extra file 2" >"repo dir/extra file 2"
+mkdir "repo dir/extra dir 2"
+echo "extra file 3" >"extra dir 1/extra file 3"
+echo "ign file 1" >"ign file 1.ign"
+echo "ign file 2" >"ign file 2.ign1"
+echo "ign file 3" >"repo dir/ign file 3.ign"
+echo "ign file 4" >"repo dir/ign file 4.ign1"
+
+# Create file lists under .git/temp, exclude .git/ from listings.
+# Compare lists before and after cg-clean and check if only the expected
+# files were removed.
+topdir="`pwd`"
+mkdir .git/temp
+list="$topdir/.git/temp/list"
+
+mklist()
+{
+ cd "$topdir"
+ find . 2>/dev/null |sed -n "/^.\/.git\//d;s/^..//p" | \
+ sort > "$list-$1"
+}
+
+check_loss()
+{
+ mklist new
+ echo "$loss" | cat - "$list-new" | \
+ grep -v ^$ | sort >"$list-combined"
+ diff -u "$list-init" "$list-combined" > "$list.diff" && \
+ cp -f "$list-new" "$list-init"
+}
+
+mklist init
+loss=''
+test_expect_success 'cg-clean -n in top-level dir' \
+ "(cg-clean -n && check_loss)"
+
+test_expect_success 'cg-clean -Ddxqn in top-level dir' \
+ "(cg-clean -Ddxqn && check_loss)"
+
+test_expect_success 'cg-clean -n in subdir' \
+ "(cd 'repo dir' && cg-clean -n && check_loss)"
+
+loss='repo dir/extra file 2'
+test_expect_success 'cg-clean in subdir' \
+ "(cd 'repo dir' && cg-clean && check_loss)"
+
+loss='repo dir/extra dir 2'
+test_expect_success 'cg-clean -d in subdir' \
+ "(cd 'repo dir' && cg-clean -d && check_loss)"
+
+loss='repo dir/ign file 3.ign
+repo dir/ign file 4.ign1'
+test_expect_success 'cg-clean -x in subdir' \
+ "(cd 'repo dir' && cg-clean -x && check_loss)"
+
+# Restore extra files in "repo dir"
+echo "extra file 2" >"repo dir/extra file 2"
+mkdir "repo dir/extra dir 2"
+echo "ign file 3" >"repo dir/ign file 3.ign"
+echo "ign file 4" >"repo dir/ign file 4.ign1"
+mklist init
+
+# FIXME: cg-clean shouldn't clean unknown directories without "-d"
+loss='extra file 1
+ign file 2.ign1
+extra dir 1/extra file 3
+repo dir/extra file 2'
+test_expect_success 'cg-clean in top-level dir' \
+ "(cg-clean && check_loss)"
+
+loss='ign file 1.ign
+repo dir/ign file 3.ign
+repo dir/ign file 4.ign1'
+test_expect_success 'cg-clean -x in top-level dir' \
+ "(cg-clean -x && check_loss)"
+
+loss='extra dir 1
+repo dir/extra dir 2'
+test_expect_success 'cg-clean -d in top-level dir' \
+ "(cg-clean -d && check_loss)"
+
+mkdir "extra dir 3"
+chmod 000 "extra dir 3"
+mklist init
+loss='extra dir 3'
+test_expect_success 'cg-clean -D in top-level dir' \
+ "(cg-clean -D && check_loss)"
+
+test_done
--
Regards,
Pavel Roskin
^ permalink raw reply related
* [PATCH] cg-clean: fix directory cleaning
From: Pavel Roskin @ 2005-12-12 20:54 UTC (permalink / raw)
To: git, Petr Baudis
cg-clean is broken by commit 3cddede46dcd24bd7c36827ca564de23b2bb3517 -
it removes all subdirectories when run in the top level directory.
Although it's easy to make a one-line fix, I'd prefer a solution that
makes cg-clean potentially safer. Since git-ls-files runs in
subdirectories now, it's no longer needed to run anything in the top
level directory and filter out the results. cg-clean now changes to
$_git_relpath on startup and never uses $_git_relpath again.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-clean b/cg-clean
index 92fc48e..6909076 100755
--- a/cg-clean
+++ b/cg-clean
@@ -60,8 +60,6 @@ clean_dirs()
git-ls-files --cached |
sed -n 's|/[^/]*$||p' |
while IFS=$'\n' read dir; do
- [ x"${dir#$_git_relpath}" = x"${dir}" ] && continue
- dir="${dir#$_git_relpath}"
while true; do
echo "$dir"
updir="${dir%/*}"
@@ -74,32 +72,27 @@ clean_dirs()
save_IFS="$IFS"
IFS=$'\n'
- fpath=${_git_relpath-./}
- find "$fpath" -type d -print |
- while read dir; do
- echo "${dir#$fpath}"
- done |
- sed '/^$/d;/^\.git$/d;/^\.git\//d' |
+ find ./ -type d -print |
+ sed 's/^\.\///;/^$/d;/^\.git$/d;/^\.git\//d' |
cat - "$dirlist" | sort -u |
diff - "$dirlist" |
sed -n 's/< //p' |
- while read file; do
- path="${_git_relpath}$file"
- if [ ! -d "$path" ]; then
+ while read dir; do
+ if [ ! -d "$dir" ]; then
# Perhaps directory was removed with its parent
continue
fi
if [ -z "$cleandir" ]; then
- echo "Not removing $file/"
+ echo "Not removing $dir/"
continue
fi
- [ "$quiet" ] || echo "Removing $file/"
+ [ "$quiet" ] || echo "Removing $dir/"
if [ "$cleandirhard" ]; then
- chmod -R 700 "$path"
+ chmod -R 700 "$dir"
fi
- $rm -rf "$path"
- if [ -e "$path" -o -L "$path" ]; then
- echo "Cannot remove $file/"
+ $rm -rf "$dir"
+ if [ -e "$dir" -o -L "$dir" ]; then
+ echo "Cannot remove $dir/"
fi
done
@@ -117,14 +110,13 @@ clean_files()
cg-status -n -s '?' "$xopt" -w |
while read file; do
- path="${_git_relpath}$file"
- if [ -d "$path" -a ! -L "$path" ]; then
+ if [ -d "$file" -a ! -L "$file" ]; then
# Sanity check, shouldn't happen
echo "FATAL: cg-status reports directories (internal error)" >&2
exit 1
- elif [ -e "$path" -o -L "$path" ]; then
+ elif [ -e "$file" -o -L "$file" ]; then
[ "$quiet" ] || echo "Removing $file"
- $rm -f "$path"
+ $rm -f "$file"
# rm would complain itself on failure
else
echo "File $file has disappeared!"
@@ -135,6 +127,8 @@ clean_files()
}
+cd "${_git_relpath-.}"
+
# Even if -d or -D is not specified, we want to tell user about
# directories that are not removed
if [ -z "$quiet" -o "$cleandir" ]; then
--
Regards,
Pavel Roskin
^ permalink raw reply related
* [PATCH 1/2] Add deltifier test.
From: Junio C Hamano @ 2005-12-12 20:41 UTC (permalink / raw)
To: git
This test kicks in only if you built test-delta executable, and
makes sure that the basic delta routine is working properly even
on empty files.
This commit is to make sure we have a test to catch the
breakage. The delitifier code is still broken, which will be
fixed with the next commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is a more general reproduction recipe for the problem
Darrin Thompson reported. We did not produce delta from or
to an empty blob.
t/t0001-delta.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
test-delta.c | 11 +++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
create mode 100755 t/t0001-delta.sh
9cfcbd609c42c08de54733e610846dc6dfd22495
diff --git a/t/t0001-delta.sh b/t/t0001-delta.sh
new file mode 100755
index 0000000..2dd88e5
--- /dev/null
+++ b/t/t0001-delta.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+test_description='Deltification regression test'
+
+../test-delta 2>/dev/null
+test $? == 127 && {
+ echo "* Skipping test-delta regression test."
+ exit 0
+}
+
+. ./test-lib.sh
+
+>empty
+echo small >small
+echo smallish >smallish
+cat ../../COPYING >large
+sed -e 's/GNU/G.N.U/g' large >largish
+
+test_expect_success 'No regression in deltify code' \
+'
+fail=0
+for src in empty small smallish large largish
+do
+ for dst in empty small smallish large largish
+ do
+ if test-delta -d $src $dst delta-$src-$dst &&
+ test-delta -p $src delta-$src-$dst out-$src-$dst &&
+ cmp $dst out-$src-$dst
+ then
+ echo "* OK ($src->$dst deitify and apply)"
+ else
+ echo "* FAIL ($src->$dst deitify and apply)"
+ fail=1
+ fi
+ done
+done
+case "$fail" in
+0) (exit 0) ;;
+*) (exit $fail) ;;
+esac
+'
+
+test_done
diff --git a/test-delta.c b/test-delta.c
index 1be8ee0..cc05794 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -38,7 +38,10 @@ int main(int argc, char *argv[])
return 1;
}
from_size = st.st_size;
- from_buf = mmap(NULL, from_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (from_size)
+ from_buf = mmap(NULL, from_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ else
+ from_buf = "";
if (from_buf == MAP_FAILED) {
perror(argv[2]);
close(fd);
@@ -52,7 +55,11 @@ int main(int argc, char *argv[])
return 1;
}
data_size = st.st_size;
- data_buf = mmap(NULL, data_size, PROT_READ, MAP_PRIVATE, fd, 0);
+
+ if (data_size)
+ data_buf = mmap(NULL, data_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ else
+ data_buf = "";
if (data_buf == MAP_FAILED) {
perror(argv[3]);
close(fd);
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/2] diff-delta.c: allow delta with empty blob.
From: Junio C Hamano @ 2005-12-12 20:40 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1134404990.5928.4.camel@localhost.localdomain>
Delta computation with an empty blob used to punt and returned NULL.
This commit allows creation with empty blob; all combination of
empty->empty, empty->something, and something->empty are allowed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Darrin Thompson <darrint@progeny.com> writes:
> $ git-diff-files -B
> Segmentation fault
> Could someone confirm that this exists on more recent git heads and fix
> if needed?
Could you try this patch? It is marked as 2/2 but 1/2 is a
test script to reproduce the problem with the current code,
which this patch is supposed to fix, and this should be the
only fix you need.
delta.h | 4 ++--
diff-delta.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
1e4d6f6618abb72e3948419d113a6f2f14c83ebc
diff --git a/delta.h b/delta.h
index 31d1820..c6a4763 100644
--- a/delta.h
+++ b/delta.h
@@ -9,8 +9,8 @@ extern void *patch_delta(void *src_buf,
void *delta_buf, unsigned long delta_size,
unsigned long *dst_size);
-/* the smallest possible delta size is 4 bytes */
-#define DELTA_SIZE_MIN 4
+/* the smallest possible delta size is 2 bytes (empty to empty) */
+#define DELTA_SIZE_MIN 2
/*
* This must be called twice on the delta data buffer, first to get the
diff --git a/diff-delta.c b/diff-delta.c
index b2ae7b5..cf50138 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -213,7 +213,7 @@ void *diff_delta(void *from_buf, unsigne
bdrecord_t *brec;
bdfile_t bdf;
- if (!from_size || !to_size || delta_prepare(from_buf, from_size, &bdf))
+ if (delta_prepare(from_buf, from_size, &bdf))
return NULL;
outpos = 0;
--
0.99.9.GIT
^ permalink raw reply related
* Re: as promised, docs: git for the confused
From: Randal L. Schwartz @ 2005-12-12 20:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Timo Hirvonen, junkio, linux, git
In-Reply-To: <Pine.LNX.4.64.0512121010550.15597@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> So instead of teaching people about "git-read-tree --reset HEAD" etc that
Linus> you'd never know on your own, just teach about "git reset". And not
Linus> bothering with the "git-write-tree + git-commit-tree + git-update-ref"
Linus> approach, just make people use "git commit" from the very beginning.
I learned more by reading the cg-tutorial, at least from the user
perspective. I then went back to the git-tutorial, and was able to
finally understand that these commands are worth ignoring. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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