* Re: [1/4] Report info from trees
From: Junio C Hamano @ 2005-04-19 5:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.21.0504182148330.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> This patch adds actual information to struct tree, making it possible to
DB> tell what sorts of things the referenced objects are. This is needed for
DB> http-pull, and Junio wanted something of the sort.
Thanks for keeping me in the loop, but...
DB> --- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.h (mode:100644 sha1:14ebbacded09d5e058c7f94652dcb9e12bc31cae)
DB> +++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.h (mode:100644 sha1:985500e2a9130fe8c33134ca121838af9320c465)
DB> @@ -5,9 +5,20 @@
DB> extern const char *tree_type;
DB> +struct tree_entry_list {
DB> + struct tree_entry_list *next;
DB> + unsigned directory : 1;
DB> + unsigned executable : 1;
DB> + union {
DB> + struct tree *tree;
DB> + struct blob *blob;
DB> + } item;
DB> +};
DB> +
DB> struct tree {
DB> struct object object;
DB> unsigned has_full_path : 1;
DB> + struct tree_entry_list *entries;
DB> };
... what about names? When somebody other than connectivity
checker walks a tree, it would be more likely than not that
it wants to know what each entry is called, wound't it?
I can get the type of the object, either tree or blob, from
tree->object.type, so I do not think the single-bit are needed.
Instead, how about something simpler like this?
struct tree {
struct object object; /* the tree node itself as an object */
unsigned child_nr;
unsigned child_alloc;
struct {
struct object *object;
char *name;
} **child;
};
The tree->child[n].object would point at the same object as one
of the object_list elements in tree->object.refs chain (i.e. you
do not need to read the same object twice). Before the tree is
parsed, tree->child would be NULL. You do not need child_alloc
if the intended use of this API is only parsing existing object
tree. Otherwise keep that and realloc tree->child as needed.
^ permalink raw reply
* [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
From: Greg KH @ 2005-04-19 4:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, linux-kernel, sensors
Alright, let's try some small i2c and w1 patches...
Could you merge with:
kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/
It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is
below, I'll figure out how to send the individual patches later.
thanks,
greg k-h
drivers/i2c/chips/it87.c | 2 +-
drivers/i2c/chips/via686a.c | 7 ++-----
drivers/w1/w1.c | 9 +++++----
drivers/w1/w1_smem.c | 4 ++--
4 files changed, 10 insertions(+), 12 deletions(-)
^ permalink raw reply
* "True" git merge in git-pasky
From: Petr Baudis @ 2005-04-19 3:51 UTC (permalink / raw)
To: git
Hello,
so I've implemented "true" git merge in git-pasky, using core git's
merging capabilities. It seems to even work. :-)
I tested it briefly, and even did one non-conflicting and one
conflicting merge with Linus with this, but I'd like to hear your
comments and possibly more testing before releasing it.
To get the lastest git-pasky, get the tarball at
http://pasky.or.cz/~pasky/dev/git
unpack, build, install, do
git pull
rebuild and reinstall.
The semantics is trivial (and it might get changed so that you would
do git update instead of git pull at most of places). If you don't have
a given GIT repository ready yet, do
git init rsync://example.com/repo
in a new directory. It is by default tracking, therefore if you do
git pull
anytime later, git merge will be automatically invoked. If you want to
prevent this, do
git track
which will untrack your tree; the remote branch you were tracking is
called "origin", shall you want to pull/merge it later. You might want
to also merge with someone else. Do
git addremote elsewhere rsync://example.org/another
git pull elsewhere
git merge elsewhere
(Note that merge won't pull automatically; you must do that on your own
if you want to pull.)
If the merge didn't succeed and you have conflicts, don't panic. The
merge told you about the conflicts, you can also do
git diff
to see the changes, you'll probably spot the conflict markers. Resolve
the conflicts and then simply do
git commit
to commit the pending merge.
Now you decided to do a little bit of parallel development and stick
your patches not ready for 2.6.12 to a separate tree. That's fine, do
git fork experimental ~/linux-2.6.experimental
and get some coffee. (It takes about 8 minutes here, but I think git
isn't at fault - it is probably all spent in
read-tree $(tree-id)
checkout-cache -a
update-cache --refresh
and you pretty much need to call that.)
Then, do some work there, syncing with your main tree periodically:
git merge master
(that's how your first init'd branch is called). You decide to make it
more fun for Linus and push your experimental stuff into your master
tree. Fine, cd there and do
git merge experimental
and there you go!
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* SCM ideas from 2003
From: Kevin Smith @ 2005-04-19 3:38 UTC (permalink / raw)
To: git
I just stumbled across this page, dated 2003, which foreshadows a couple
of the decisions Linus has made for git:
http://ydirson.free.fr/en/software/scm/vc.txt
Here are the parts that particularly caught my eye:
"what's so special about files ?" where the author suggests that
existing SCM systems are so blinded by the tradition of file orientation
that they can't see that there might be alternatives.
"As a goodie we can even note that moving a file inside the hierarchy
has become exactly similar as moving a code statement." where the author
recognizes that renames are merely a special case of code moves.
His implementation ideas are quite different from git, but I thought it
was pretty cool to find that someone was thinking about these ideas a
couple years ago.
Kevin
^ permalink raw reply
* Re: [2/4] Sorting commits by date
From: Daniel Barkalow @ 2005-04-19 3:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: David A. Wheeler, Linus Torvalds, git
In-Reply-To: <20050419025340.GZ5554@pasky.ji.cz>
On Tue, 19 Apr 2005, Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 04:52:26AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > because I can't find a way to make recent GCC reject C99 features but not
> > old GNU extensions.
>
> Do we use any?
Quite a few: "?:", arithmetic on void pointers, C++/99-style comments in
places (if we aren't being C99), zero-size arrays. They're the usual
things that building Linux requires, so I think they are common extensions
beyond gcc.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: Linus Torvalds @ 2005-04-19 3:04 UTC (permalink / raw)
To: James Bottomley; +Cc: git, SCSI Mailing List
In-Reply-To: <1113877071.4998.111.camel@mulgrave>
On Mon, 18 Apr 2005, James Bottomley wrote:
>
> Fair enough. If you pull from
>
> rsync://www.parisc-linux.org/~jejb/scsi-misc-2.6.git
Thanks. Pulled and pushed out.
> Doing this exposed two bugs in your merge script:
>
> 1) It doesn't like a completely new directory (the misc tree contains a
> new drivers/scsi/lpfc)
> 2) the merge testing logic is wrong. You only want to exit 1 if the
> merge fails.
Applied.
Linus
^ permalink raw reply
* Re: [PATCH] Automerge fix
From: Petr Baudis @ 2005-04-19 2:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504181945400.15725@ppc970.osdl.org>
Dear diary, on Tue, Apr 19, 2005 at 04:48:09AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> > git-merge-one-file-script: 7ebf5dac4c69043cd2ff89bf7ee552152802f8d1
> > --- a/git-merge-one-file-script
> > +++ b/git-merge-one-file-script
> > @@ -43,7 +43,7 @@ case "${1:-.}${2:-.}${3:-.}" in
> > orig=$(unpack-file $1)
> > src1=$(unpack-file $2)
> > src2=$(unpack-file $3)
> > - merge "$src2" "$orig" "$src1" || echo Leaving conflict merge in $src2 && exit 1
> > + merge "$src2" "$orig" "$src1" || (echo Leaving conflict merge in $src2 && exit 1)
> > cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
>
> What's the right way?
>
> Maybe
>
> if merge "$src2" "$orig" "$src1"
> then
> cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
> fi
> echo Leaving conflict merge in $src2
> exit 1
>
> would work?
Possibly. Or changing () to {} as suggested by Edgar Toernig.
FWIW, my fragment of this code now looks like:
ret=0
if ! merge "$src2" "$orig" "$src1"; then
echo Conflicting merge!
cat "$src2" >"$4"
ret=1
elif ! cat "$src2" >"$4" && update-cache --add -- "$4"; then
echo "Choosing $src2 -> $4 failed"
ret=1
fi
rm "$orig" "$src1" "$src2"
exit $ret
--
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: [2/4] Sorting commits by date
From: Petr Baudis @ 2005-04-19 2:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: David A. Wheeler, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.21.0504182236050.30848-100000@iabervon.org>
Dear diary, on Tue, Apr 19, 2005 at 04:52:26AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> because I can't find a way to make recent GCC reject C99 features but not
> old GNU extensions.
Do we use any?
--
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: [2/4] Sorting commits by date
From: Daniel Barkalow @ 2005-04-19 2:52 UTC (permalink / raw)
To: David A. Wheeler; +Cc: Petr Baudis, Linus Torvalds, git
In-Reply-To: <42646EB3.8070701@dwheeler.com>
On Mon, 18 Apr 2005, David A. Wheeler wrote:
> Petr Baudis wrote:
> > [Re: Daniel Barkalow <barkalow@iabervon.org>'s patch]
> > Note that you are breaking gcc-2.95 compatibility when using declarator
> > in the middle of a block. Not that it might be a necessarily bad thing
> > ;-) (although I still use gcc-2.95 a lot), just to ring a bell so that
> > it doesn't slip through unnoticed and we can decide on a policy
> > regarding this.
>
> I, at least, would REALLY like to see _highly_ portable C code;
> I'm looking at git as a potential long-term useful SCM tool for
> LOTS of projects, and if you're going to write C, it'd be nice
> to just write it portably to start with. There's certainly
> no crisis in using separate declarators.
Mixing declarations and code is the least of portability issues; it's in
the current C standard unlike a number of other things. I've personally
never found a system where -lz has deflateBound but gcc doesn't support
C99, although they obviously exist. I have no problem with fixing things
up for old GCC, although I'm going to have a hard time finding such things
because I can't find a way to make recent GCC reject C99 features but not
old GNU extensions.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Linus Torvalds @ 2005-04-19 2:51 UTC (permalink / raw)
To: Chris Wedgwood; +Cc: Greg KH, Git Mailing List
In-Reply-To: <20050419014738.GA13602@taniwha.stupidest.org>
On Mon, 18 Apr 2005, Chris Wedgwood wrote:
>
> On Mon, Apr 18, 2005 at 05:45:48PM -0700, Greg KH wrote:
>
> > But if you really don't like it, and you don't want anyone trying to
> > hide anything, at least allow for a proper domainname. On my boxes,
> > the domainname doesn't show up at all without that patch (just the
> > getdomainname() part). I'll split it out if you want.
>
> there are plenty of times you need this... internal domain names
> usually have the MTA rewrite addresses as needed, i don't see how this
> is all the different
>
> we have internal/private state that's not globally useful and need to
> replace it with something that is, how else could we do this?
Guys, I ended up applying Greg's patch, since it's clear that many people
want to do this. So ..
Linus
^ permalink raw reply
* Re: [PATCH] Automerge fix
From: Linus Torvalds @ 2005-04-19 2:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050419010242.GS5554@pasky.ji.cz>
On Tue, 19 Apr 2005, Petr Baudis wrote:
>
> this patch fixes git-merge-one-file-script's automerge.
Nope, it doesn't. The original may not have worked, but neither does your
vesion either: the reason for the exit 1 is that the _script_ should exit,
but when you put it in a sub-shell with (..), now only the subshell exits
with an error code, and we'll happily continue to do the following line
which we should not do (since the merge failed).
> Signed-off-by: Petr Baudis <pasky@ucw.cz>
>
> git-merge-one-file-script: 7ebf5dac4c69043cd2ff89bf7ee552152802f8d1
> --- a/git-merge-one-file-script
> +++ b/git-merge-one-file-script
> @@ -43,7 +43,7 @@ case "${1:-.}${2:-.}${3:-.}" in
> orig=$(unpack-file $1)
> src1=$(unpack-file $2)
> src2=$(unpack-file $3)
> - merge "$src2" "$orig" "$src1" || echo Leaving conflict merge in $src2 && exit 1
> + merge "$src2" "$orig" "$src1" || (echo Leaving conflict merge in $src2 && exit 1)
> cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
What's the right way?
Maybe
if merge "$src2" "$orig" "$src1"
then
cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
fi
echo Leaving conflict merge in $src2
exit 1
would work?
Linus
^ permalink raw reply
* Re: [2/4] Sorting commits by date
From: David A. Wheeler @ 2005-04-19 2:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, Linus Torvalds, git
In-Reply-To: <20050419021338.GX5554@pasky.ji.cz>
Petr Baudis wrote:
> [Re: Daniel Barkalow <barkalow@iabervon.org>'s patch]
> Note that you are breaking gcc-2.95 compatibility when using declarator
> in the middle of a block. Not that it might be a necessarily bad thing
> ;-) (although I still use gcc-2.95 a lot), just to ring a bell so that
> it doesn't slip through unnoticed and we can decide on a policy
> regarding this.
I, at least, would REALLY like to see _highly_ portable C code;
I'm looking at git as a potential long-term useful SCM tool for
LOTS of projects, and if you're going to write C, it'd be nice
to just write it portably to start with. There's certainly
no crisis in using separate declarators.
In fact, in the LONG term I'd like to see the shell code
replaced with code that easily runs "everywhere" (Windows, etc.),
again, for portability's sake. I think that would be unwise to
do that right now; the shell is an excellent prototyping tool.
But once things have settled down & there's been some experience
with the tools, the pieces could be slowly recoded.
(Yes, I know of & use Cygwin. And I prefer Python over Perl,
but I'm really uninterested in language wars.)
--- David A. Wheeler
^ permalink raw reply
* Re: SCSI trees, merges and git status
From: James Bottomley @ 2005-04-19 2:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, SCSI Mailing List
In-Reply-To: <Pine.LNX.4.58.0504181724170.15725@ppc970.osdl.org>
On Mon, 2005-04-18 at 17:29 -0700, Linus Torvalds wrote:
> 2.6.12 is some time away, if for no other reason than the fact that this
> SCM thing has obviously eaten two weeks of my time. So I'd be inclined to
> chalk this up as a "learning experience" with git, and just go forward.
Fair enough. If you pull from
rsync://www.parisc-linux.org/~jejb/scsi-misc-2.6.git
That will pull in the rest of my scsi-misc-2.6 tree (which includes all
of the rc fixes). I've done a test pull and merge and checked the
resulting against BK, so hopefully there should be no more screw ups.
Doing this exposed two bugs in your merge script:
1) It doesn't like a completely new directory (the misc tree contains a
new drivers/scsi/lpfc)
2) the merge testing logic is wrong. You only want to exit 1 if the
merge fails.
James
git-merge-one-file-script: bec009e2c37bacc9e6f9cad1cfa5fd56752c7bf1
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -13,6 +13,11 @@
# do any merges that migth change the tree layout
#
+# if the directory is newly added in a branch, it might not exist
+# in the current tree
+dir=$(dirname "$4")
+mkdir -p "$dir"
+
case "${1:-.}${2:-.}${3:-.}" in
#
# deleted in both, or deleted in one and unchanged in the other
@@ -40,7 +45,11 @@ case "${1:-.}${2:-.}${3:-.}" in
orig=$(unpack-file $1)
src1=$(unpack-file $2)
src2=$(unpack-file $3)
- merge "$src2" "$orig" "$src1" || echo Leaving conflict merge in $src2 && exit 1
+ merge "$src2" "$orig" "$src1"
+ if [ $? -ne 0 ]; then
+ echo Leaving conflict merge in $src2
+ exit 1
+ fi
cp "$src2" "$4" && update-cache --add -- "$4" && exit 0
;;
^ permalink raw reply
* Re: [2/4] Sorting commits by date
From: Petr Baudis @ 2005-04-19 2:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.21.0504182152000.30848-100000@iabervon.org>
Dear diary, on Tue, Apr 19, 2005 at 03:54:56AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> Index: commit.c
> ===================================================================
> --- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.c (mode:100644 sha1:0099baa63971d86ee30ef2a7da25057f0f45a964)
> +++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.c (mode:100644 sha1:ef9af397471817837e1799d72f6707e0ccc949b9)
> @@ -83,3 +83,47 @@
> free(temp);
> }
> }
> +
> +static void insert_by_date(struct commit_list **list, struct commit *item)
> +{
> + struct commit_list **pp = list;
> + struct commit_list *p;
> + while ((p = *pp) != NULL) {
> + if (p->item->date < item->date) {
> + break;
> + }
> + pp = &p->next;
> + }
> + struct commit_list *insert = malloc(sizeof(struct commit_list));
> + insert->next = *pp;
> + *pp = insert;
> + insert->item = item;
> +}
Note that you are breaking gcc-2.95 compatibility when using declarator
in the middle of a block. Not that it might be a necessarily bad thing
;-) (although I still use gcc-2.95 a lot), just to ring a bell so that
it doesn't slip through unnoticed and we can decide on a policy
regarding this.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Change "pull" to _only_ download, and "git update"=pull+merge?
From: David A. Wheeler @ 2005-04-19 2:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20050419011206.GT5554@pasky.ji.cz>
This is a minor UI thing, but what the heck. I propose
changing "pull" to ONLY download, and "update" to pull AND merge.
Whenever you want to update, just say "git update", end of story.
Why? It seems oddly inconsistent that "pull" sometimes merges
in changes, but at other times it doesn't. If I normally
track someone, but temporarily don't want to (I'm in the middle
of lots of changes but I _do_ want to see what's going on),
I have to "untrack", pull, and then "retrack" again (remembering who
I once tracked, which may be more of a trick over time).
Maybe more important, that is more annoying when you're
trying to "just pull data" from a script; I need to
do the untrack, pull, & retrack shuffle just to download data.
I propose that there be two subcommands, "pull" and "update"
(now that "update" isn't a reserved word again).
A "git pull" ONLY downloads; a "git update" pulls AND merges.
That means each command does exactly one thing, very simple &
clean to explain. Also, some tools (such as subversion) already
use "update" as meaning this (auto download & merge from the
given repository), so the terminology would make sense for some.
I'd be happy to send in a patch to do that. The coding is trivial,
but it means a UI change in one of the most common commands
(use "update" instead of "pull" in the typical case).
I could add a "reminder" message after pulling, to let people
adjust to the new commands for a little while.
--- David A. Wheeler
^ permalink raw reply
* Re: [darcs-devel] Darcs and git: plan of action
From: Kevin Smith @ 2005-04-19 2:05 UTC (permalink / raw)
To: Ray Lee; +Cc: git, darcs-devel
In-Reply-To: <1113874931.23938.111.camel@orca.madrabbit.org>
Ray Lee wrote:
> On Mon, 2005-04-18 at 21:05 -0400, Kevin Smith wrote:
>
>>>>The other is "replace very instace of identifier `foo` with identifier`bar`".
>>>
>>>That could be derived, however, by a particularly smart parser [1].
>>
>>No, it can't. Seriously. A darcs replace patch is encoded as rules, not
>>effects, and it is impossible to derive the rules just by looking at the
>>results. Not difficult. Impossible.
>
>
> Okay, either I'm a sight stupider than I thought, or I'm not
> communicating well. Same net effect either way, I 'spose.
>
> If I do a token replace in an editor (say one of those fancy new-fangled
> refactoring thangs, or good ol' vi), a token-level comparator can
> discover what I did. That link I sent is an example of one such beast.
The big feature of a darcs replace patch is that it works forward and
backward in time. Let me try to come up with an example that can help
explain it. Hopefully I'll get it right. Let's start with a file like
this that exists in a project for which both you and I have darcs repos:
cat
dog
fish
Now, you change it to:
cat dog
dog
fish
while I simultaneously do a replace of "dog" with "plant", resulting in:
cat
plant
fish
We merge. The final result in both of our trees is:
cat plant
plant
fish
Notice that just by looking at my diffs, you can't tell that I used a
replace operation. I didn't just replace the instances of "dog" that
were in my file at that moment. I conceptually replaced all instances,
including ones that aren't there yet.
Now, I should mention here that I personally dislike the replace
operation, and I think it is more dangerous than helpful. However, other
darcs users are quite happy with it, and it certainly is a creative and
powerful feature.
Other creative patch types have also been dreamed of. For example, a
powerful language-specific refactoring operation has been discussed as a
far-future possibility. That would be safe, and cool.
>>Automated refactoring tools, for example, perform the
>>rename+modify as an atomic operation.
>
> And that's harder, I agree. But unless I'm missing some nifty
> refactoring editor out there that integrates with darcs during the edit
> session, the user *still* has to tell the SCM about the rename manually.
Although there are no such nifty refactoring tools available today, they
will exist at some point. If they existed today, the world would be a
better place.
Even without tools, many shops have policies against checking in code
that won't compile. If you rename a java class, you must simultaneously
perform the rename and modify the class name inside. If you commit
between those steps, it's broken. [I do realize that the kernel doesn't
have java code, by the way.]
I should also mention that I currently believe that Linus is correct
that explicit rename tracking is not required for git. I have every hope
that his plan for handling the more general case of "moved text" will
take care of renames as a side effect. I don't know if that will be
sufficient to allow a two-way lossless gateway between git and darcs or
other systems that do track renames explicitly.
Kevin
^ permalink raw reply
* Re: [0/5] Parsers for git objects, porting some programs
From: Daniel Barkalow @ 2005-04-19 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Petr Baudis, git
In-Reply-To: <7v7jizsh1f.fsf@assigned-by-dhcp.cox.net>
On Mon, 18 Apr 2005, Junio C Hamano wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> DB> On Mon, 18 Apr 2005, Linus Torvalds wrote:
> >> On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> >> >
> >> > This series introduces common parsers for objects, and ports the programs
> >> > that currently use revision.h to them.
> >> >
> >> > 1: the header files
> >> > 2: the implementations
> >> > 3: port rev-tree
> >> > 4: port fsck-cache
> >> > 5: port merge-base
> >>
> >> Ok, having now looked at the code, I don't have any objections at all.
>
> I was looking at the tree part and am thinking that it would
> make it much nicer if your tree object records path for each
> entry.
As it turns out, the code I just doesn't actually record the path; it does
everything else, and it should be easy to add the path to those entries. I
mainly wanted object type (i.e., do I have to recurse into the object), so
I skipped that one. But it should now be clear what you need to add.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [4/4] Make merge-base use dates to find answer
From: Daniel Barkalow @ 2005-04-19 2:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504182139250.30848-100000@iabervon.org>
This changes merge-base to use the dates of commit to search the
history. It will find the most recent common ancestor, rather than the one
the fewest generations away. It also demonstrates scanning the history by
date.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: merge-base.c
===================================================================
--- fb7b671eb0da01b9a9998ab58b3717da9f983456/merge-base.c (mode:100644 sha1:414ff419c679dba122b2f21b698c1e2c8abdd965)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/merge-base.c (mode:100644 sha1:61e408e5d158f3dde6153ccbe9ee6fbbf1136225)
@@ -5,42 +5,30 @@
static struct commit *process_list(struct commit_list **list_p, int this_mark,
int other_mark)
{
- struct commit_list *parent, *temp;
- struct commit_list *posn = *list_p;
- *list_p = NULL;
- while (posn) {
- parse_commit(posn->item);
- if (posn->item->object.flags & this_mark) {
- /*
- printf("%d already seen %s %x\n",
- this_mark
- sha1_to_hex(posn->parent->sha1),
- posn->parent->flags);
- */
- /* do nothing; this indicates that this side
- * split and reformed, and we only need to
- * mark it once.
- */
- } else if (posn->item->object.flags & other_mark) {
- return posn->item;
- } else {
- /*
- printf("%d based on %s\n",
- this_mark,
- sha1_to_hex(posn->parent->sha1));
- */
- posn->item->object.flags |= this_mark;
-
- parent = posn->item->parents;
- while (parent) {
- temp = malloc(sizeof(struct commit_list));
- temp->next = *list_p;
- temp->item = parent->item;
- *list_p = temp;
- parent = parent->next;
- }
- }
- posn = posn->next;
+ struct commit *item = (*list_p)->item;
+
+ if (item->object.flags & this_mark) {
+ /*
+ printf("%d already seen %s %x\n",
+ this_mark
+ sha1_to_hex(posn->parent->sha1),
+ posn->parent->flags);
+ */
+ /* do nothing; this indicates that this side
+ * split and reformed, and we only need to
+ * mark it once.
+ */
+ *list_p = (*list_p)->next;
+ } else if (item->object.flags & other_mark) {
+ return item;
+ } else {
+ /*
+ printf("%d based on %s\n",
+ this_mark,
+ sha1_to_hex(posn->parent->sha1));
+ */
+ pop_most_recent_commit(list_p);
+ item->object.flags |= this_mark;
}
return NULL;
}
@@ -56,16 +44,27 @@
rev2list->item = rev2;
rev2list->next = NULL;
+ parse_commit(rev1);
+ parse_commit(rev2);
+
while (rev1list || rev2list) {
struct commit *ret;
- ret = process_list(&rev1list, 0x1, 0x2);
- if (ret) {
- /* XXXX free lists */
- return ret;
+ if (!rev1list) {
+ // process 2
+ ret = process_list(&rev2list, 0x2, 0x1);
+ } else if (!rev2list) {
+ // process 1
+ ret = process_list(&rev1list, 0x1, 0x2);
+ } else if (rev1list->item->date < rev2list->item->date) {
+ // process 2
+ ret = process_list(&rev2list, 0x2, 0x1);
+ } else {
+ // process 1
+ ret = process_list(&rev1list, 0x1, 0x2);
}
- ret = process_list(&rev2list, 0x2, 0x1);
if (ret) {
- /* XXXX free lists */
+ free_commit_list(rev1list);
+ free_commit_list(rev2list);
return ret;
}
}
^ permalink raw reply
* [3/4] Add http-pull
From: Daniel Barkalow @ 2005-04-19 1:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.21.0504182139250.30848-100000@iabervon.org>
This adds a command to pull a commit and dependant objects from an HTTP
server.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: Makefile
===================================================================
--- 50afb5dd4184842d8da1da8dcb9ca6a591dfc5b0/Makefile (mode:100644 sha1:803f1d49c436efa570d779db6d350efbceb29ddd)
+++ f7f62e0d2a822ad0937fd98a826f65ac7f938217/Makefile (mode:100644 sha1:a3d26213c085e8b6bbc1ec352df0996e558e7c38)
@@ -15,7 +15,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
- check-files ls-tree merge-base merge-cache unpack-file
+ check-files ls-tree merge-base merge-cache unpack-file http-pull
all: $(PROG)
@@ -81,6 +81,11 @@
unpack-file: unpack-file.o $(LIB_FILE)
$(CC) $(CFLAGS) -o unpack-file unpack-file.o $(LIBS)
+http-pull: LIBS += -lcurl
+
+http-pull: http-pull.o $(LIB_FILE)
+ $(CC) $(CFLAGS) -o http-pull http-pull.o $(LIBS)
+
blob.o: $(LIB_H)
cat-file.o: $(LIB_H)
check-files.o: $(LIB_H)
@@ -105,6 +110,7 @@
usage.o: $(LIB_H)
unpack-file.o: $(LIB_H)
write-tree.o: $(LIB_H)
+http-pull.o: $(LIB_H)
clean:
rm -f *.o $(PROG) $(LIB_FILE)
Index: http-pull.c
===================================================================
--- /dev/null (tree:50afb5dd4184842d8da1da8dcb9ca6a591dfc5b0)
+++ f7f62e0d2a822ad0937fd98a826f65ac7f938217/http-pull.c (mode:100644 sha1:bd251f9e0748784bbd2cd5cf720f126d852fe888)
@@ -0,0 +1,170 @@
+#include <fcntl.h>
+#include <unistd.h>
+#include <string.h>
+#include <stdlib.h>
+#include "cache.h"
+#include "commit.h"
+#include <errno.h>
+#include <stdio.h>
+
+#include <curl/curl.h>
+#include <curl/easy.h>
+
+static CURL *curl;
+
+static char *base;
+
+static int tree = 0;
+static int commits = 0;
+static int all = 0;
+
+static int has(unsigned char *sha1)
+{
+ char *filename = sha1_file_name(sha1);
+ struct stat st;
+
+ if (!stat(filename, &st))
+ return 1;
+ return 0;
+}
+
+static int fetch(unsigned char *sha1)
+{
+ char *hex = sha1_to_hex(sha1);
+ char *filename = sha1_file_name(sha1);
+
+ char *url;
+ char *posn;
+ FILE *local;
+ struct stat st;
+
+ if (!stat(filename, &st)) {
+ return 0;
+ }
+
+ local = fopen(filename, "w");
+
+ if (!local)
+ return error("Couldn't open %s\n", filename);
+
+ curl_easy_setopt(curl, CURLOPT_FILE, local);
+
+ url = malloc(strlen(base) + 50);
+ strcpy(url, base);
+ posn = url + strlen(base);
+ strcpy(posn, "objects/");
+ posn += 8;
+ memcpy(posn, hex, 2);
+ posn += 2;
+ *(posn++) = '/';
+ strcpy(posn, hex + 2);
+
+ curl_easy_setopt(curl, CURLOPT_URL, url);
+
+ printf("Getting %s\n", hex);
+
+ if (curl_easy_perform(curl))
+ return error("Couldn't get %s for %s\n", url, hex);
+
+ fclose(local);
+
+ return 0;
+}
+
+static int process_tree(unsigned char *sha1)
+{
+ struct tree *tree = lookup_tree(sha1);
+ struct tree_entry_list *entries;
+
+ if (parse_tree(tree))
+ return -1;
+
+ for (entries = tree->entries; entries; entries = entries->next) {
+ if (fetch(entries->item.tree->object.sha1))
+ return -1;
+ if (entries->directory) {
+ if (process_tree(entries->item.tree->object.sha1))
+ return -1;
+ }
+ }
+ return 0;
+}
+
+static int process_commit(unsigned char *sha1)
+{
+ struct commit *obj = lookup_commit(sha1);
+
+ if (fetch(sha1))
+ return -1;
+
+ if (parse_commit(obj))
+ return -1;
+
+ if (tree) {
+ if (fetch(obj->tree->object.sha1))
+ return -1;
+ if (process_tree(obj->tree->object.sha1))
+ return -1;
+ if (!all)
+ tree = 0;
+ }
+ if (commits) {
+ struct commit_list *parents = obj->parents;
+ for (; parents; parents = parents->next) {
+ if (has(parents->item->object.sha1))
+ continue;
+ if (fetch(parents->item->object.sha1)) {
+ /* The server might not have it, and
+ * we don't mind.
+ */
+ continue;
+ }
+ if (process_commit(parents->item->object.sha1))
+ return -1;
+ }
+ }
+ return 0;
+}
+
+int main(int argc, char **argv)
+{
+ char *commit_id;
+ char *url;
+ int arg = 1;
+ unsigned char sha1[20];
+
+ while (arg < argc && argv[arg][0] == '-') {
+ if (argv[arg][1] == 't') {
+ tree = 1;
+ } else if (argv[arg][1] == 'c') {
+ commits = 1;
+ } else if (argv[arg][1] == 'a') {
+ all = 1;
+ tree = 1;
+ commits = 1;
+ }
+ arg++;
+ }
+ if (argc < arg + 2) {
+ usage("http-pull [-c] [-t] [-a] commit-id url");
+ return 1;
+ }
+ commit_id = argv[arg];
+ url = argv[arg + 1];
+
+ get_sha1_hex(commit_id, sha1);
+
+ curl_global_init(CURL_GLOBAL_ALL);
+
+ curl = curl_easy_init();
+
+ base = url;
+
+ if (fetch(sha1))
+ return 1;
+ if (process_commit(sha1))
+ return 1;
+
+ curl_global_cleanup();
+ return 0;
+}
^ permalink raw reply
* [2/4] Sorting commits by date
From: Daniel Barkalow @ 2005-04-19 1:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.21.0504182139250.30848-100000@iabervon.org>
Functions for a date-ordered queue of commits, progressively pulled out of
the history incrementally. Linus wanted this for finding the most recent
common ancestor, and it might be relevant to logging.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: commit.c
===================================================================
--- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.c (mode:100644 sha1:0099baa63971d86ee30ef2a7da25057f0f45a964)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.c (mode:100644 sha1:ef9af397471817837e1799d72f6707e0ccc949b9)
@@ -83,3 +83,47 @@
free(temp);
}
}
+
+static void insert_by_date(struct commit_list **list, struct commit *item)
+{
+ struct commit_list **pp = list;
+ struct commit_list *p;
+ while ((p = *pp) != NULL) {
+ if (p->item->date < item->date) {
+ break;
+ }
+ pp = &p->next;
+ }
+ struct commit_list *insert = malloc(sizeof(struct commit_list));
+ insert->next = *pp;
+ *pp = insert;
+ insert->item = item;
+}
+
+
+void sort_by_date(struct commit_list **list)
+{
+ struct commit_list *ret = NULL;
+ while (*list) {
+ insert_by_date(&ret, (*list)->item);
+ *list = (*list)->next;
+ }
+ *list = ret;
+}
+
+struct commit *pop_most_recent_commit(struct commit_list **list)
+{
+ struct commit *ret = (*list)->item;
+ struct commit_list *parents = ret->parents;
+ struct commit_list *old = *list;
+
+ *list = (*list)->next;
+ free(old);
+
+ while (parents) {
+ parse_commit(parents->item);
+ insert_by_date(list, parents->item);
+ parents = parents->next;
+ }
+ return ret;
+}
Index: commit.h
===================================================================
--- b3cf8daf9b619ae9f06a28f42a4ae01b69729206/commit.h (mode:100644 sha1:8cd20b046875f5f7e534b0607fdd97f330f53272)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/commit.h (mode:100644 sha1:35679482132ae5a6b7d72bbb684f21472470717c)
@@ -24,4 +24,8 @@
void free_commit_list(struct commit_list *list);
+void sort_by_date(struct commit_list **list);
+
+struct commit *pop_most_recent_commit(struct commit_list **list);
+
#endif /* COMMIT_H */
^ permalink raw reply
* [1/4] Report info from trees
From: Daniel Barkalow @ 2005-04-19 1:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.21.0504182139250.30848-100000@iabervon.org>
This patch adds actual information to struct tree, making it possible to
tell what sorts of things the referenced objects are. This is needed for
http-pull, and Junio wanted something of the sort.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
Index: tree.c
===================================================================
--- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.c (mode:100644 sha1:7c5e5e46f4967b0812b06c0114946c3a6432c8d8)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.c (mode:100644 sha1:39f9cbd1908e9046c148339f816025c9313ec142)
@@ -27,6 +27,7 @@
char type[20];
void *buffer, *bufptr;
unsigned long size;
+ struct tree_entry_list **list_p;
if (item->object.parsed)
return 0;
item->object.parsed = 1;
@@ -38,8 +39,10 @@
if (strcmp(type, tree_type))
return error("Object %s not a tree",
sha1_to_hex(item->object.sha1));
+ list_p = &item->entries;
while (size) {
struct object *obj;
+ struct tree_entry_list *entry;
int len = 1+strlen(bufptr);
unsigned char *file_sha1 = bufptr + len;
char *path = strchr(bufptr, ' ');
@@ -48,6 +51,11 @@
sscanf(bufptr, "%o", &mode) != 1)
return -1;
+ entry = malloc(sizeof(struct tree_entry_list));
+ entry->directory = S_ISDIR(mode);
+ entry->executable = mode & S_IXUSR;
+ entry->next = NULL;
+
/* Warn about trees that don't do the recursive thing.. */
if (strchr(path, '/')) {
item->has_full_path = 1;
@@ -56,12 +64,17 @@
bufptr += len + 20;
size -= len + 20;
- if (S_ISDIR(mode)) {
- obj = &lookup_tree(file_sha1)->object;
+ if (entry->directory) {
+ entry->item.tree = lookup_tree(file_sha1);
+ obj = &entry->item.tree->object;
} else {
- obj = &lookup_blob(file_sha1)->object;
+ entry->item.blob = lookup_blob(file_sha1);
+ obj = &entry->item.blob->object;
}
add_ref(&item->object, obj);
+
+ *list_p = entry;
+ list_p = &entry->next;
}
return 0;
}
Index: tree.h
===================================================================
--- 1172a9b8f45b2fd640985595cc5258db3b027828/tree.h (mode:100644 sha1:14ebbacded09d5e058c7f94652dcb9e12bc31cae)
+++ 7e5a0d93117ecadfb15de3a6bebdb1aa94234fde/tree.h (mode:100644 sha1:985500e2a9130fe8c33134ca121838af9320c465)
@@ -5,9 +5,20 @@
extern const char *tree_type;
+struct tree_entry_list {
+ struct tree_entry_list *next;
+ unsigned directory : 1;
+ unsigned executable : 1;
+ union {
+ struct tree *tree;
+ struct blob *blob;
+ } item;
+};
+
struct tree {
struct object object;
unsigned has_full_path : 1;
+ struct tree_entry_list *entries;
};
struct tree *lookup_tree(unsigned char *sha1);
^ permalink raw reply
* Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
From: Petr Baudis @ 2005-04-19 1:51 UTC (permalink / raw)
To: Steven Cole; +Cc: git
In-Reply-To: <200504181940.54453.elenstev@mesatop.com>
Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> Here is perhaps a better way to provide detailed help for each
> git command. A command.help file for each command can be
> written in the style of a man page.
I don't like it. I think the 'help' command should serve primarily as a
quick reference, which does not blend so well with a manual page - it's
too long and too convoluted by repeated output.
I'd just print the top comment from each file. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* More patches
From: Daniel Barkalow @ 2005-04-19 1:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
Here are the things I was saving for after the previous set:
1: Report the actual contents of trees
2: Add functions for scanning history by date
3: Add http-pull, a program to fetch the objects you need by HTTP
4: Change merge-base to find the most recent common ancestor
1 and 2 are core extensions. 3 might be best for the pasky tree. 4 is
mostly a demo of 2 and because Linus thought it was a better algorithm.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] provide better committer information to commit-tree.c
From: Chris Wedgwood @ 2005-04-19 1:47 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050419004548.GA21623@kroah.com>
On Mon, Apr 18, 2005 at 05:45:48PM -0700, Greg KH wrote:
> But if you really don't like it, and you don't want anyone trying to
> hide anything, at least allow for a proper domainname. On my boxes,
> the domainname doesn't show up at all without that patch (just the
> getdomainname() part). I'll split it out if you want.
there are plenty of times you need this... internal domain names
usually have the MTA rewrite addresses as needed, i don't see how this
is all the different
we have internal/private state that's not globally useful and need to
replace it with something that is, how else could we do this?
^ permalink raw reply
* [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
From: Steven Cole @ 2005-04-19 1:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <4263E782.6040608@mesatop.com>
On Monday 18 April 2005 10:59 am, Steven Cole wrote:
> Petr Baudis wrote:
> > Dear diary, on Mon, Apr 18, 2005 at 06:42:26AM CEST, I got a letter
> > where Steven Cole <elenstev@mesatop.com> told me that...
> [snippage]
> >
> >>This patch will provide the comment lines in the shell script associated
> >>with the command, cleaned up a bit for presentation.
> >>
> >>BUGS: This will also print any comments in the entire file, which may
> >>not be desired. If a command name and shell script filename
> >>do not follow the usual convention, this won't work, e.g. ci for commit.
> >
> >
> > Hey, those BUGS are the only slightly non-trivial thing on the whole
> > thing! I could do this patch myself... ;-) Also, you don't want to print
> > the first newline and the Copyright notices.
Here is perhaps a better way to provide detailed help for each
git command. A command.help file for each command can be
written in the style of a man page.
The modfication to the main git script will be trivial.
Here are the two commands I've done so far.
What do folks think about this approach?
Steven
[steven@spc git-pasky]$ ./git help add
NAME
add - Add new file or files to a GIT repository.
SYNOPSIS
add FILE...
DESCRIPTION
Takes a list of file names at the command line, and schedules them
for addition to the GIT repository at the next commit.
AUTHOR
Written by Petr Baudis.
REPORTING BUGS
Report bugs to <git@vger.kernel.org>
COPYRIGHT
Copyright (c) Petr Baudis, 2005
BUGS
Those files are omitted from show-diff output!
SEE ALSO
The source code for this command is gitadd.sh.
[steven@spc git-pasky]$ ./git help addremote
NAME
addremote - Add new "remote" to the GIT repository.
SYNOPSIS
addremote RNAME RSYNC_URL
DESCRIPTION
Takes the remote's name and rsync URL.
After you add a remote, you can "git pull" it whenever you want
and it will keep your dircache in sync with it. Its latest commit
is accessible as .git/heads/remotename (or - more conveniently -
as $(commit-id remotename)). For example, to make a diff between
Linus (after you added him) and your current tree, do
git pull linus
git diff $(commit-id linus)
AUTHOR
Written by Petr Baudis.
REPORTING BUGS
Report bugs to <git@vger.kernel.org>
COPYRIGHT
Copyright (c) Petr Baudis, 2005
TODO
gitdiff.sh et al should accept remote names as ids.
SEE ALSO
The source code for this command is gitaddremote.sh.
^ 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