* [PATCH] Print an error if cloning a http repo and NO_CURL is set
From: Fernando J. Pereda @ 2006-02-15 11:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
If Git is compiled with NO_CURL=YesPlease and one tries to
clone a http repository, git-clone tries to call the curl
binary. This trivial patch prints an error instead in such
situation.
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
---
Makefile | 1 +
git-clone.sh | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletions(-)
896d96a92a13848ccce19c2f3dee9b5570ef02a7
diff --git a/Makefile b/Makefile
index d40aa6a..648469e 100644
--- a/Makefile
+++ b/Makefile
@@ -419,6 +419,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.
rm -f $@
sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@
chmod +x $@
diff --git a/git-clone.sh b/git-clone.sh
index 47f3ec9..e192b08 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -206,7 +206,13 @@ yes,yes)
fi
;;
http://*)
- clone_dumb_http "$repo" "$D"
+ if test -z "@@NO_CURL@@"
+ then
+ clone_dumb_http "$repo" "$D"
+ else
+ echo >&2 "http transport not supported, rebuild Git with curl support"
+ exit 1
+ fi
;;
*)
cd "$D" && case "$upload_pack" in
--
1.2.0
^ permalink raw reply related
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 11:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060215112502.GC26911@diana.vm.bytemark.co.uk>
On 2006-02-15 12:25:02 +0100, Karl Hasselström wrote:
> However, using git-cherry-pick in this scenario would just recreate
> the initial state exactly, since converting the commits to stgit
> patches was what it was all about.
"since" -> "and"
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <43F305AF.70808@op5.se>
On 2006-02-15 11:42:55 +0100, Andreas Ericsson wrote:
> Karl Hasselström wrote:
>
> > You can actually do this today; just create a new branch where you
> > want your new stgit stack to be based, and "stg pick" the
> > commits/patches from the old branch:
> >
> > $ git-checkout -b new-branch HEAD^^^
> > $ stg init
> > $ stg pick old-branch^^^ -n create-foo
> > $ stg pick old-branch^^ -n improve-foo
> > $ stg pick old-branch^ -n improve-bar
> > $ git-branch -D old-branch
> > $ git-checkout -b old-branch
> > $ git-branch -d new-branch
> >
> > This series of commands also converts the top three commits to
> > stgit patches, and leaves the user on the same branch where she
> > started (it does _exactly_ the same job as "stg uncommit
> > improve-bar improve-foo create-foo"), but it's a lot of work, and
> > a typo could lose commits.
>
> Isn't this akin to what "git cherry-pick" does, except for the
> "convert to stgit patches" thing?
Yes, "stg pick" and git-cherry-pick are very similar as far as I know,
the only difference being that "stg pick" creates an stgit patch while
git-cherry-pick creates a regular commit. (And an applied stgit patch
is just a regular commit which stgit maintains some metadata about.)
However, using git-cherry-pick in this scenario would just recreate
the initial state exactly, since converting the commits to stgit
patches was what it was all about.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FYI] pack idx format
From: Johannes Schindelin @ 2006-02-15 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5hpm2x0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 15 Feb 2006, Junio C Hamano wrote:
> [...]
>
> Before this main table, at the beginning of the idx file, there
> is a table of 256 4-byte network byte order integers. This is
> called "first-level fan-out". N-th entry of this table records
> the offset into the main index for the first object whose object
> name SHA1 starts with N+1. fanout[255] points at the end of
> main index. The offset is expressed in 24-bytes unit.
The description of the n-th entry is not completely correct. How about
something like this:
The fan-out table is sort of an index to the main table: It contains
offsets into the main table, and all SHA1s starting with byte b are
between fanout[b-1] .. fanout[b]-1 (or if b==0 between 0 .. fanout[0]-1).
Comments?
Ciao,
Dscho
^ permalink raw reply
* Use case: GIT to manage transactions in a CMS?
From: "J. David Ibáñez" @ 2006-02-15 10:44 UTC (permalink / raw)
To: git
Hello,
I am working on a project (a content management system) where the data
is stored as files and folders.
Currently, for persistance and transactions we use the ZODB [1] object
database. But our goal is to move away from the ZODB and use directly
the file system, as it will allow us to use all the good unix tools.
We are using git to manage the source code. And now we are exploring git
to see if it can do the job of transactions, so that each transaction in
the system will be a git commit.
One problem we have found is that we can not commit empty directories (what
we need to do). Any idea how to solve or work-around this constraint?
Any suggestions and input on this exotic use case for git will be very
welcomed.
[1] http://www.zope.org/Wikis/ZODB/FrontPage
--
J. David Ibáñez
Itaapy <http://www.itaapy.com> Tel +33 (0)1 42 23 67 45
9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88
^ permalink raw reply
* Re: [PATCH] Detect misspelled pathspec to git-add
From: Johannes Schindelin @ 2006-02-15 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wy5m19t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 15 Feb 2006, Junio C Hamano wrote:
> Comments?
I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Andreas Ericsson @ 2006-02-15 10:42 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060215101136.GB26911@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
>
>
>>Karl Hasselström wrote:
>>
>>
>>>No, I literally want the opposite of "stg commit", so that the
>>>sequence "stg commit; stg uncommit" has zero net effect.
>>
>>well, that would work OK for maintainers, but would be kind of
>>strange for folks who are pulling from such a repository. how would
>>that work?
>
>
> I didn't plan to publish branches where this kind of history munging
> was being done. It's precisely like "git rebase" in that regard --
> it's a tool for cleaning up history before it is published.
>
>
>>my impression of git is that you don't change stuff that's already
>>committed. you revert changes by applying a new commit that backs
>>out the original changes.
>
>
> You don't change stuff that's already committed _and published_ (well,
> except for pu branches :-). Rewriting history is perfectly OK up until
> the moment someone has pulled your branch.
>
>
>>i'm speculating, but i suspect that's why there's a "stg pick
>>--reverse" and not a "stg uncommit."
>
>
> I don't think I've been very successful in communicating exactly what
> I want "stg uncommit" for. It's not that I want to undo a committed
> change -- what I want is to transform it into an stgit patch so that I
> can edit it with a minimum of effort.
>
> $ edit edit edit
> $ git-commit -a -m "create foo"
> $ edit edit edit
> $ git-commit -a -m "improve foo"
> $ edit edit edit
> $ git-commit -a -m "improve bar"
>
> # Oops, I realize that the "create foo" changeset had a debug
> # printout left in it, and I wasn't already using stgit.
>
> $ stg init
> $ stg uncommit improve-bar improve-foo create-foo
> $ stg stg pop --to=create-foo
> $ edit --remove=debug-printout
> $ stg refresh
> $ stg push --all
>
The same workflow, with less hassle (and already implemented)
$ git format-patch -k HEAD~3
$ edit 0001-*
$ git am -k 000*
> Similar use-cases for e.g. reordering commits, merging commits,
> deleting one commit in the middle of a chain of good ones, etc. are
> easy to come up with. The point is that stgit alreay handles all this,
> _but only if you have been using stgit from the start_. What "stg
> uncommit" does is basically to import (linear) git history into stgit,
> where a powerful toolset exists to edit it.
>
> You can actually do this today; just create a new branch where you
> want your new stgit stack to be based, and "stg pick" the
> commits/patches from the old branch:
>
> $ git-checkout -b new-branch HEAD^^^
> $ stg init
> $ stg pick old-branch^^^ -n create-foo
> $ stg pick old-branch^^ -n improve-foo
> $ stg pick old-branch^ -n improve-bar
> $ git-branch -D old-branch
> $ git-checkout -b old-branch
> $ git-branch -d new-branch
>
> This series of commands also converts the top three commits to stgit
> patches, and leaves the user on the same branch where she started (it
> does _exactly_ the same job as "stg uncommit improve-bar improve-foo
> create-foo"), but it's a lot of work, and a typo could lose commits.
>
Isn't this akin to what "git cherry-pick" does, except for the "convert
to stgit patches" thing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Karl Hasselström @ 2006-02-15 10:11 UTC (permalink / raw)
To: git
In-Reply-To: <43F2445A.6020109@citi.umich.edu>
On 2006-02-14 15:58:02 -0500, Chuck Lever wrote:
> Karl Hasselström wrote:
>
> > No, I literally want the opposite of "stg commit", so that the
> > sequence "stg commit; stg uncommit" has zero net effect.
>
> well, that would work OK for maintainers, but would be kind of
> strange for folks who are pulling from such a repository. how would
> that work?
I didn't plan to publish branches where this kind of history munging
was being done. It's precisely like "git rebase" in that regard --
it's a tool for cleaning up history before it is published.
> my impression of git is that you don't change stuff that's already
> committed. you revert changes by applying a new commit that backs
> out the original changes.
You don't change stuff that's already committed _and published_ (well,
except for pu branches :-). Rewriting history is perfectly OK up until
the moment someone has pulled your branch.
> i'm speculating, but i suspect that's why there's a "stg pick
> --reverse" and not a "stg uncommit."
I don't think I've been very successful in communicating exactly what
I want "stg uncommit" for. It's not that I want to undo a committed
change -- what I want is to transform it into an stgit patch so that I
can edit it with a minimum of effort.
$ edit edit edit
$ git-commit -a -m "create foo"
$ edit edit edit
$ git-commit -a -m "improve foo"
$ edit edit edit
$ git-commit -a -m "improve bar"
# Oops, I realize that the "create foo" changeset had a debug
# printout left in it, and I wasn't already using stgit.
$ stg init
$ stg uncommit improve-bar improve-foo create-foo
$ stg stg pop --to=create-foo
$ edit --remove=debug-printout
$ stg refresh
$ stg push --all
Similar use-cases for e.g. reordering commits, merging commits,
deleting one commit in the middle of a chain of good ones, etc. are
easy to come up with. The point is that stgit alreay handles all this,
_but only if you have been using stgit from the start_. What "stg
uncommit" does is basically to import (linear) git history into stgit,
where a powerful toolset exists to edit it.
You can actually do this today; just create a new branch where you
want your new stgit stack to be based, and "stg pick" the
commits/patches from the old branch:
$ git-checkout -b new-branch HEAD^^^
$ stg init
$ stg pick old-branch^^^ -n create-foo
$ stg pick old-branch^^ -n improve-foo
$ stg pick old-branch^ -n improve-bar
$ git-branch -D old-branch
$ git-checkout -b old-branch
$ git-branch -d new-branch
This series of commands also converts the top three commits to stgit
patches, and leaves the user on the same branch where she started (it
does _exactly_ the same job as "stg uncommit improve-bar improve-foo
create-foo"), but it's a lot of work, and a typo could lose commits.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Handling large files with GIT
From: Junio C Hamano @ 2006-02-15 9:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Fredrik Kuivinen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602141953081.3691@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> As far as I can tell, the output from git-merge-tree with that fix to only
> simplify subdirectories that match exactly in all of base/branch1/branch2
> is precisely the output that git-merge-recursive actually wants.
The matches the recollection I had last time I mucked with the
code. Currently it is set up to do one path at a time in both
index and working tree, so it would not be a trivial rewrite,
but merge-tree based approach would speed things up quite a
bit.
I was thinking about implementing mergers as a pipeline:
git-merge-tree O A B |
git-merge-renaming A |
git-merge-aggressive A |
git-merge-filemerge
git-merge-tree (yours) does not do trivial collapsing, and
produce raw-diff from A. git-merge-renaming reads it, finds
copied/renamed entries (maybe reusing parts of diffcore), and
writes out the results in the same format as merge-tree output
(that's why I am giving A on the command line -- so it can also
read A if it wanted to. it may need to talk about what a path in
A was even when merge-tree did not say anything about that
path). Then git-merge-aggressive (bad naming, I know, it only
corresponds to the flag of the same name in read-tree) will
collapse git-merge-one-file equivalent stage collapsing. The
remainder is fed to file-level merger for postprocessing.
Everything except the last step would work on a data format that
merge-tree outputs.
^ permalink raw reply
* [RFC] So... are people happy with commit/status -v?
From: Junio C Hamano @ 2006-02-15 9:41 UTC (permalink / raw)
To: git
I usually never do commits from a subdirectory, also I rarely do
partial commits, so this is not a big issue to me, but are
people happy with the current commit/status?
Regardless of where you started, status is a preview of the next
commit with the same set of flags and arguments, so inherently
that is a whole-tree operation.
One thing that _might_ be better, however, is to shorten certain
parts of the status output when deliberately doing a partial
commit. No matter where you are, "Updated but not checked in --
will commit" section should stay whole-tree, because it is _the_
preview of the next commit. However, "Changed but not updated"
and "Untracked" section are different story.
When committing from a subdirectory with "git commit paths...",
It is likely a user forgets about paths that are changed in the
directory and forgets to list them on the command line, so the
same directory and below should be listed, but it might not be
needed to show files outside the current directory. "Untracked"
files outside the current directory are even less interesting.
Even when committing from a subdirectory with "git commit",
which is "commit the current index contents", the story is the
same. The user could have forgot to add files in the same
directory or below, but it is less likely that things outside
current directory need to draw attention to prevent mistakes.
"Untracked" outside are less interesting in this case as well.
In either partial or whole commit case, however, "Changed but
not updated" part can be argued important and should be kept
whole-tree (myself, I am slightly in favor of keeping this part
whole-tree). After all, the user has changed files in the
directory she happens to be in and outside, and reminding she
has something outstanding while previewing the next commit would
help prevent mistakes, whether that modified files are in the
current directory or outside.
So, I'm wondering. I have a feeling that we might be better of
limiting "Untracked" part to the current directory and below,
while keeping "Updated -- will commit" and "Changed but not
updated" part whole-tree. OTOH, I do not have strong need
_myself_ to change the current setup.
Comments? Opinions?
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-15 9:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F2EF09.5060603@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> The good thing about being past 1.0 in a project is that it's
> feature-complete, or close to. The bad thing is that bloat usually
> starts to happen around 1.1.
Thanks -- be kind and stop me whenever somebody else tempts me
to add excess things to the core, please. Always good to have
adult supervision ;-), eh, voice of sanity.
^ permalink raw reply
* [PATCH] Detect misspelled pathspec to git-add
From: Junio C Hamano @ 2006-02-15 9:14 UTC (permalink / raw)
To: git
This is in the same spirit as an earlier patch for git-commit.
It does an extra ls-files to avoid complaining when a fully
tracked directory name is given on the command line (otherwise
--others restriction would say the pathspec does not match).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I noticed this when I accidentally said "git add /a/b/c"
when I meant "git add a/b/c", and I did not notice it until
I said "git commit" which said "Nothing to commit."
It does one extra ls-files only if any pathspec is given; I
am hoping this slight performance hit is tolerated. I think
people who does "git add ." all the time to mean "add
everything I added anywhere since I did git add last time"
deserve it ;-).
Comments?
git-add.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
ca28a7e03232b9a3b66df8519d9ee827882c83c1
diff --git a/git-add.sh b/git-add.sh
index f719b4b..13fad82 100755
--- a/git-add.sh
+++ b/git-add.sh
@@ -24,6 +24,17 @@ while : ; do
shift
done
+# Check misspelled pathspec
+case "$#" in
+0) ;;
+*)
+ git-ls-files --error-unmatch --others --cached -- "$@" >/dev/null || {
+ echo >&2 "Maybe you misspelled it?"
+ exit 1
+ }
+ ;;
+esac
+
if test -f "$GIT_DIR/info/exclude"
then
git-ls-files -z \
--
1.2.0.gcfba7
^ permalink raw reply related
* Re: several quick questions
From: Andreas Ericsson @ 2006-02-15 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtfxm917.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Junio C Hamano wrote:
>>
>>
>>>Now, read-only ref does not interest me, but "do not commit on
>>>top of this yourself, only fast-forward from somewhere else is
>>>allowed" may be useful, for the reason why you mentioned
>>>"origin".
>>
>>Do my suggestion and you wouldn't have to worry about read-only
>>branches, and although merging any changes from it might be more
>>trouble than its worth, it might be possible to cherry-pick the commit
>>rather than reverting and re-applying it.
>
>
> Sorry, is this "do my suggestion" a solution to my "do not
> commit on top of this yourself, only fast-forward from somewhere
> else is allowed -- e.g. to protect 'origin'" issue, or is it
> something completely different?
>
The "git checkout -b foo HEAD~15", which was already supported, although
I missed that. All programmers have names to use just for throwaway
variables (never heard "frotz" and "nitfol" before though), so adding
the burden of selecting a name for the throw-away search branch
shouldn't be too hard on them. Then it would be possible to commit to
it, and merge or cherry-pick from it later. It's usually preferrable to
amend to a broken patch than to revert it completely.
In essence, I claim that git-seek is superfluous and inferior to "git
checkout -b foo <commit-ish>" and shouldn't be implemented. If anyone
wants to distribute the source to non-scm people as per a given point in
the history I think "git tar-tree" works marvelously as is.
The good thing about being past 1.0 in a project is that it's
feature-complete, or close to. The bad thing is that bloat usually
starts to happen around 1.1.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: StGIT refreshes all added files - limitation of git-write-tree?
From: Pavel Roskin @ 2006-02-15 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacctnnx4.fsf@assigned-by-dhcp.cox.net>
On Tue, 2006-02-14 at 22:20 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > Or maybe git-write-tree and other utilities could be changed to work on
> > a copy of the index file? I would prefer not to move the
> > actual .git/index away, but to make a copy for the current "stg refresh"
> > operation.
>
> There is no need to change the core side.
>
> GIT_INDEX_FILE=temporary-index git-write-tree
>
> would do the job. See the current round of git-commit and how
> it handles "git commit --only these files" case.
Thank you! It's comforting to know that the issue is not unique to
StGIT.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [FYI] pack idx format
From: Junio C Hamano @ 2006-02-15 8:39 UTC (permalink / raw)
To: git
This is still WIP but if anybody is interested... Once done, it
should become Documentation/technical/pack-format.txt.
The reason I started doing this is to prototype this one:
<7v4q3453qu.fsf@assigned-by-dhcp.cox.net>
-- >8 --
Idx file:
The idx file is to map object name SHA1 to offset into the
corresponding pack file. There is the 'first-level fan-out'
table at the beginning, and then the main part of the index
follows. This is a table whose entries are sorted by their
object name SHA1. The file ends with some trailer information.
The main part is a table of 24-byte entries, and each entry is:
offset : 4-byte network byte order integer.
SHA1 : 20-byte object name SHA1.
The data for the named object begins at byte offset "offset" in
the corresponding pack file.
Before this main table, at the beginning of the idx file, there
is a table of 256 4-byte network byte order integers. This is
called "first-level fan-out". N-th entry of this table records
the offset into the main index for the first object whose object
name SHA1 starts with N+1. fanout[255] points at the end of
main index. The offset is expressed in 24-bytes unit.
Example:
idx
+--------------------------------+
| fanout[0] = 2 |-.
+--------------------------------+ |
| fanout[1] | |
+--------------------------------+ |
| fanout[2] | |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| fanout[255] | |
+--------------------------------+ |
main | offset | |
index | object name 00XXXXXXXXXXXXXXXX | |
table +--------------------------------+ |
| offset | |
| object name 00XXXXXXXXXXXXXXXX | |
+--------------------------------+ |
.-| offset |<+
| | object name 01XXXXXXXXXXXXXXXX |
| +--------------------------------+
| | offset |
| | object name 01XXXXXXXXXXXXXXXX |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | offset |
| | object name FFXXXXXXXXXXXXXXXX |
| +--------------------------------+
trailer | | packfile checksum |
| +--------------------------------+
| | idxfile checksum |
| +--------------------------------+
.-------.
|
Pack file entry: <+
packed object header:
1-byte type (upper 4-bit)
size0 (lower 4-bit)
n-byte sizeN (as long as MSB is set, each 7-bit)
size0..sizeN form 4+7+7+..+7 bit integer, size0
is the most significant part.
packed object data:
If it is not DELTA, then deflated bytes (the size above
is the size before compression).
If it is DELTA, then
20-byte base object name SHA1 (the size above is the
size of the delta data that follows).
delta data, deflated.
^ permalink raw reply
* Re: several quick questions
From: Carl Worth @ 2006-02-15 8:21 UTC (permalink / raw)
To: Keith Packard
Cc: Martin Langhoff, Linus Torvalds, Nicolas Vilz 'niv', git
In-Reply-To: <1139981145.4341.137.camel@evo.keithp.com>
[-- Attachment #1.1: Type: text/plain, Size: 2040 bytes --]
On Tue, 14 Feb 2006 21:25:45 -0800, Keith Packard wrote:
> On Wed, 2006-02-15 at 17:11 +1300, Martin Langhoff wrote:
>
> > Did that lead to finding any problems with the import? Can I get my
> > hands on that script you've written to run the comparison?
>
> The only issues we had were with manual changes to the repository;
For anyone interested, here are the problems our script found after
importing cairo with git-cvsimport:
1) Some "future" files existed at old tags since we had copied ,v
files to preserve per-file history. This one was no surprise.
2) We had a couple tags in CVS that didn't tag the current head,
(instead a file had been manually reverted before the tag). In the
git checkout of the same tag name, we got the results as if HEAD
had been tagged.
Those two weren't too surprising. We remembered quite clearly what had
happened as soon as we saw the results. I've fixed these up
post-import by making git commits to fix the problems and then moving
the tags.
3) There are some sub-tree tags in cairo's CVS tree as
well. Obviously, those aren't very interesting for direct
comparison.
Also not surprising. For these, I just modified the script to
whitelist the tags I actually cared about checking.
4) There was a branch that diverged from the main line two commits
"late" in the git history.
I'm not sure what caused this, but it's obviously happening in the
cvsps output. I fixed the problem by capturing the cvsps output into a
file, reordering the branching patchset up two positions in the list,
then feeding the result into git-cvsimport with its -P option.
I've attached the script I used to do the git and cvs comparisons. I
was getting perfect results with a local rsync of cairo's CVS
repository. The version here does a pserver checkout instead. When I
run this I'm apparently getting different substitution of some of
those annoying RCS $Id:...$ strings. Looks like the formatting of the
date is different. So your mileage may vary.
But here it is if its of any interest.
[-- Attachment #1.2: git-cvs-compare --]
[-- Type: application/octet-stream, Size: 1976 bytes --]
#!/bin/sh
set -e
CVSROOT=:pserver:anoncvs@cairographics.org:/cvs/cairo
GITMASTER=git://git.cairographics.org/cairo
if [ ! -e cairo-cvs ]; then
echo -n "Performing CVS checkout to cairo-cvs..."
cvs -d $CVSROOT co -d cairo-cvs cairo > /dev/null
echo "done."
fi
if [ ! -e cairo-git ]; then
echo -n "Cloning git repository to cairo-git..."
git clone $GITMASTER cairo-git
echo "done."
fi
# This is what you probably want to check all tags
#for tag in $(ls cairo-git/.git/refs/tags); do
# Instead, for cairo we whitelist the tags to check since there are
# some bogus partial-tree tags that just aren't interesting.
for tag in SNAPSHOT_0_1_16 SNAPSHOT_0_1_20 SNAPSHOT_0_1_21 SNAPSHOT_0_1_22 SNAPSHOT_0_1_23 LGPL_CHANGE_BEFORE LGPL_CHANGE_AFTER SNAPSHOT_0_2_0 SNAPSHOT_0_3_0 SNAPSHOT_0_4_0 SNAPSHOT_0_5_0 SNAPSHOT_0_5_1 SNAPSHOT_0_5_2 SNAPSHOT_0_6_0 RELEASE_0_9_0 RELEASE_0_9_2 RELEASE_1_0_0 RELEASE_1_0_2; do
echo -n "Performing cvs update to $tag..."
(cd cairo-cvs; cvs -Q update -r $tag > /dev/null)
echo "done."
echo -n "Performing git checkout of $tag..."
# Linus says this is the most efficient way to do this, but it
# seems to leave some empty directories around that shouldn't be
# there.
# (cd cairo-git; git checkout -b cvs-compare >& /dev/null || true; git checkout cvs-compare; git reset --hard $tag)
# This might be slower, but it's plenty fast still and it does the right thing
(cd cairo-git; git checkout master; git branch -D cvs-compare >& /dev/null || true; git checkout -b cvs-compare $tag)
echo "done."
echo -n "Comparing cvs and git trees for $tag..."
if diff -r -x CVS -x .git cairo-cvs cairo-git >& cairo.diff; then
echo "perfect."
rm cairo.diff
else
echo "different. :("
echo " Saving trees to cairo-git-$tag & cairo-cvs-$tag and diff to cairo-$tag.diff"
cp -a cairo-git cairo-git-$tag
cp -a cairo-cvs cairo-cvs-$tag
mv cairo.diff cairo-$tag.diff
fi
done
[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "git reset --hard" leaves empty directories that shouldn't exist
From: Junio C Hamano @ 2006-02-15 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <87y80dhxfd.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I've been exploring the potential for git-sync, and I found some odd
> behavior with "git reset --hard". It appears that if the current tree
> has some directory structure (at least two levels deep) that does not
> exist in the tree being reset to, that empty directories are left
> around after the reset:
>
> $ git --version
> git version 1.2.0.gf6e8
> $ git init-db
> defaulting to local storage area
> $ touch file; git add file; git commit -m "Add file"
> Committing initial tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
> $ git tag OLD
> $ mkdir -p a/b/c; touch a/b/c/foo; git add a/b/c/foo; git commit -m
> "Add foo"
> $ git checkout -b bogus
> $ git reset --hard OLD
> $ find a
> a
> a/b
> a/b/c
> $
>
> Is this operator error?
Git does not track directories but bends backwards to make empty
directories go away. I do not know if it is an operator error
or not, but it appears sometimes it does not bend hard enough.
Interestingly enough, this seems to do things more carefully.
$ ...
$ git commit -m 'Add file'
$ git branch OLD
$ ...
$ git commit -m 'Add a/b/c/foo'
$ git checkout -b bogo
$ git checkout OLD
^ permalink raw reply
* Re: "git reset --hard" leaves empty directories that shouldn't exist
From: Shawn Pearce @ 2006-02-15 8:06 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87y80dhxfd.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> I've been exploring the potential for git-sync, and I found some odd
> behavior with "git reset --hard". It appears that if the current tree
> has some directory structure (at least two levels deep) that does not
> exist in the tree being reset to, that empty directories are left
> around after the reset:
>
> $ git --version
> git version 1.2.0.gf6e8
> $ git init-db
> defaulting to local storage area
> $ touch file; git add file; git commit -m "Add file"
> Committing initial tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
> $ git tag OLD
> $ mkdir -p a/b/c; touch a/b/c/foo; git add a/b/c/foo; git commit -m
> "Add foo"
> $ git checkout -b bogus
> $ git reset --hard OLD
> $ find a
> a
> a/b
> a/b/c
> $
>
> Is this operator error? I don't see any extra options I might be
> missing in the documentation of git-reset.
Its not operator error.
I just dug though git-reset.sh in 1.2.0 and it won't cull
directories, only files. Culling the directories is a little bit
on the ugly side obviously as you must cull bottom-up. The perl
code which git-reset.sh is using to cull files definately won't
cull the directories.
No patch attached. Maybe someone not on the east coast can write
one; I need to go catch some sleep. :-)
--
Shawn.
^ permalink raw reply
* Re: bisect ends with a commit marked good and bad
From: Junio C Hamano @ 2006-02-15 8:01 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: git
In-Reply-To: <E1F9Gwm-0001Dy-3b@approximate.corpus.cam.ac.uk>
Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:
> How would I use gitk to show the those three good and three bad commits,
> and their spanning tree? Neither the man entry nor the examples of its
> use in git-bisect taught me enough to use it properly.
The way bisect narrows down bug hunting is to find a single
regression. IOW, the only question you can ask bisect is "this
older one was known to be good, but somehow this new one is bad.
If it was caused by one bug introduced somewhere during the
course of changes between the two, which one is it?"
So you always start by giving one good and one bad (or one bad
and one good, the order does not matter). That leaves * as
suspects.
o---o---O---*---*---*---*---X---o
\ /
*---*---*---*
O (good) X (bad)
Since it is finding a single regression, o commits are
irrelevant. commits after bad one X may have fixed the bug but
you are not interested in it. Commits before good one O might
have been broken in some other way, but we are looking for a
single regression, so they do not really matter either.
Then bisect suggests you one of (*) commits. Not at random, but
somewhere midway.
o---o---O---*---*---*---*---X---o
\ /
*---*---*---?
O (good) X (bad)
If ? is good, then three * suspects are good so you then have to
worry about remaining four * between the first O and X. That's
how you narrow things down.
You say a2d823bf is bad and 0f442aa2 is good. However, the
a2d823bf is a proper ancestor of 0f442aa2. That is, earlier it
was good but now it is good. As if you are trying to locate the
commit that fixed the bug. This is an impossible situation for
the bisect.
So your initial input may be truly good and bad commits, but
there might be more than one regression involved.
To look at the graph, you could do something like this:
for r in $good; do git tag good-$r $(git-rev-parse --verify $r); done
for r in $bad; do git tag bad-$r $(git-rev-parse --verify $r); done
gitk $(git-rev-parse $good) $(git-rev-parse --not $bad)
You will notice there is only one bad-* way below all the good-*
ones. Another possibility is maybe you have your good and bad
swapped?
^ permalink raw reply
* "git reset --hard" leaves empty directories that shouldn't exist
From: Carl Worth @ 2006-02-15 7:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
I've been exploring the potential for git-sync, and I found some odd
behavior with "git reset --hard". It appears that if the current tree
has some directory structure (at least two levels deep) that does not
exist in the tree being reset to, that empty directories are left
around after the reset:
$ git --version
git version 1.2.0.gf6e8
$ git init-db
defaulting to local storage area
$ touch file; git add file; git commit -m "Add file"
Committing initial tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078
$ git tag OLD
$ mkdir -p a/b/c; touch a/b/c/foo; git add a/b/c/foo; git commit -m
"Add foo"
$ git checkout -b bogus
$ git reset --hard OLD
$ find a
a
a/b
a/b/c
$
Is this operator error? I don't see any extra options I might be
missing in the documentation of git-reset.
I haven't looked into the implementation at all yet to see what might
be going on.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* bisect ends with a commit marked good and bad
From: Sanjoy Mahajan @ 2006-02-15 7:19 UTC (permalink / raw)
To: Git Mailing List
In doing a huge bisect (from 1875 or so revisions but fortunately
log(anything) is not too big) to chase a S3 sleep bug (bugme #5989), I
also noticed another problem. In several 'good' kernels, where S3
sleep-wake worked twice, the fan would not turn on despite the
temperature getting high, after the system went through two sleep-wake
cycles. [In the 'bad' kernels the system hangs on the second sleep, so
I couldn't collect any data about the fan.]
The result is that, for several kernels, I got free bisect data about
this second bug. I tried feeding this data to a fresh bisect, but
bisect says that one particular commit is good and bad. Here's the
script to run bisect:
#!/bin/bash -x
bad="a2d823bf ee408c79 d1138cf0"
good="0f442aa2 49799291 4a90c7e8"
git bisect start
for r in $bad ; do git-bisect bad $r ; done
for r in $good ; do git-bisect good $r ; done
The output:
+ bad='a2d823bf ee408c79 d1138cf0'
+ good='0f442aa2 49799291 4a90c7e8'
+ git bisect start
+ for r in '$bad'
+ git-bisect bad a2d823bf
+ for r in '$bad'
+ git-bisect bad ee408c79
+ for r in '$bad'
+ git-bisect bad d1138cf0
+ for r in '$good'
+ git-bisect good 0f442aa2
d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad
+ for r in '$good'
+ git-bisect good 49799291
d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad
+ for r in '$good'
+ git-bisect good 4a90c7e8
d1138cf035ad5a8dc0796b213bd078a2fb92eb7c was both good and bad
At first I thought it was impossible for a bug to behave this way, and
concluded that my data must be corrupt, since d1138cf0 is marked bad.
But on further thought, I'm not sure. Maybe there are quadratic
interactions between patches. For example, if a particular bug happens
only when two patches occur together? No, that would result in the
merge of their branches being the problematic commit. So I'm stuck.
Before I conclude that the data is corrupt and spend several hours
retesting several kernels, I thought I'd ask for advice from the
entomologists and bisectors.
How would I use gitk to show the those three good and three bad commits,
and their spanning tree? Neither the man entry nor the examples of its
use in git-bisect taught me enough to use it properly.
-Sanjoy
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Shawn Pearce @ 2006-02-15 6:54 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Sam Vilain, Petr Baudis, Chuck Lever, Karl Hasselström,
Catalin Marinas, git
In-Reply-To: <20060215041142.GA21048@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Tue, Feb 14, 2006 at 07:35:10PM -0500, Shawn Pearce wrote:
> > Publishing a repository with a stg (or pg) patch series isn't
> > a problem; the problem is that no clients currently know how to
> > follow along with the remote repository's patch series. And I can't
> > think of a sensible behavior for doing so that isn't what git-core is
> > already doing today for non patch series type clients (as in don't go
> > backwards by popping but instead by pushing a negative delta). :-)
>
> If you represent each patch as a branch, with each modification to the
> patch a commit on the corresponding branch, and each "push" operation a
> merge from the branch corresponding to the previous patch to a branch
> corresponding to the new patch (isn't that what pg's trying to do?),
> then it should be possible just to track the branch corresponding to the
> top patch.
Yes that's pg in a nutshell.
But what happens when I pop back two patches (of three) and then push
down a different (fourth) patch? The tree just rewound backwards
and then forwards again in a different direction. (I apologize for
not being able to draw a nice ASCII art diagram of this, that's a
skill I'll have to learn to keep up with you guys.) This is the
issue with Junio's pu branch in git.git and is why some people
apparently don't follow it.
StGIT and pg aren't the only ones who suffer from this wonderful
little feature of GIT.
> In theory I guess it should also be possible to merge patch series that
> have followed two lines of development, by merging each corresponding
> branch.
Of course. If I delete all of the refs used by pg to mark the patch
boundaries its just another GIT branch. Ditto for StGIT. So clearly
you can merge them together just like any other GIT branch.
The open question is could you preserve the patch boundaries
while doing the merge. Probably not. It would become way to
complicated as you would want to merge the entire branch and not each
individual patch as the individual patch merges may not work but the
larger branch merge might go through without human intervention.
Of course you can try to keep the patch boundaries by exporting
all of the patches from the one branch and push them on top of
the current branch. But isn't that what a 3 way merge is anyway?
And again that might not work as well as taking the larger patch
and pushing that down. :-)
> The history would be really complicated. You'd need to figure out how
> to track the patch comments too, and you'd need scripts to convert to
> just a simple series of commits for submitting upstream. Probably not
> worth the trouble, but I don't know.
I think I'm almost there with pg. One of my next tasks is the
patch log ripping code. This is really only complicated because GIT
won't let me store the base of a 3 way merge as part of a commit;
all I can store is the set of parents. If I had the base in the
commit (and specifically marked as such so I can tell it from the
end points) then I could easily walk through the log to extract all
commits relevant to a patch and seek forward and backward over it.
Perhaps I could cheat and record 3 parents: (HEAD, base, last).
I wonder what gitk would make of that mess. I doubt it would display
any better than the current (HEAD, last) format I'm using now.
> If you really want revision control on patches the simplest thing might
> be just to run quilt or Andrew Morton's scripts on top of a git
> repository--the documentation with Andrew's scripts recommends doing
> that with CVS.
True but you also then run into problems about needing to know which
base each patch revision was applied against so you can reproduce
a source tree plus patch at a specific point in time.
When I started pg I first thought about recording a patch in a
secondary index/working directory where each patch was its own file
and use git-diff-tree to extract the patch, commit it as a blob in
the secondary index/directory, and push it onto the series by reading
the blob in and running git-apply on the patch stored within it.
I ruled this strategy out as it just felt like it would be too
slow and rather unnatural to work on with existing GIT tools.
I didn't want to write a full porcelain; I was really hoping to just
extend Cogito to get a patch stack that worked the way *I* wanted a
patch stack to work, which was close to StGIT but not quite StGIT.
(Of course it didn't work out this way when I picked a prefix of
'pg' instead of 'cg' for my new commands.) :-|
--
Shawn.
^ permalink raw reply
* Re: StGIT refreshes all added files - limitation of git-write-tree?
From: Shawn Pearce @ 2006-02-15 6:28 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1139978528.28292.41.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> Or maybe git-write-tree and other utilities could be changed to work on
> a copy of the index file? I would prefer not to move the
> actual .git/index away, but to make a copy for the current "stg refresh"
> operation.
git-write-tree pays attention to the GIT_INDEX_FILE environment
variable; if this, GIT_DIR and GIT_OBJECT_DIRECTORY are set you can
redirect git-write-tree to look at a different index. One way to
create a tree from a mixture of your current index and the current
HEAD's tree is to set GIT_INDEX_FILE to a temporary file name
(which doesn't exist), use git-read-tree to load the current tree
unmodified into that index, copy the modified records of interest
from the current index to the temporary index, then git-write-tree
from the temporary index. But now you need to update your current
index with the real SHA1s of the written files.
Somewhat convoluted. I think that git-commit.sh and cg-commit.sh
play such games to do partial commits based on what the user has
passed on the command line or modified in their editor (which is
actually a rather cool feature of Cogito). I'm using a similar
trick in pg to load binary objects from a patch directory (for a
specific use case that I have). git-am.sh uses a similar trick
to perform a 3 way merge if git-apply fails.
--
Shawn.
^ permalink raw reply
* Re: several quick questions
From: Junio C Hamano @ 2006-02-15 6:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F26129.4040804@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>
>> Now, read-only ref does not interest me, but "do not commit on
>> top of this yourself, only fast-forward from somewhere else is
>> allowed" may be useful, for the reason why you mentioned
>> "origin".
>
> Do my suggestion and you wouldn't have to worry about read-only
> branches, and although merging any changes from it might be more
> trouble than its worth, it might be possible to cherry-pick the commit
> rather than reverting and re-applying it.
Sorry, is this "do my suggestion" a solution to my "do not
commit on top of this yourself, only fast-forward from somewhere
else is allowed -- e.g. to protect 'origin'" issue, or is it
something completely different?
^ permalink raw reply
* Re: StGIT refreshes all added files - limitation of git-write-tree?
From: Junio C Hamano @ 2006-02-15 6:20 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1139978528.28292.41.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Or maybe git-write-tree and other utilities could be changed to work on
> a copy of the index file? I would prefer not to move the
> actual .git/index away, but to make a copy for the current "stg refresh"
> operation.
There is no need to change the core side.
GIT_INDEX_FILE=temporary-index git-write-tree
would do the job. See the current round of git-commit and how
it handles "git commit --only these files" case.
^ 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