* Re: Problem in update from the linux-2.6 repository
From: Petr Baudis @ 2005-11-07 22:23 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: git
In-Reply-To: <1131401931.5824.149.camel@blade>
Hi,
Dear diary, on Mon, Nov 07, 2005 at 11:18:51PM CET, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> > I run into a weird problem when trying to update my clone of the
> > linux-2.6 repository from Linus:
> >
> > ---
> > # cg-update -f
> > 17:09:00 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> > Getting alternates list
> > Getting pack list
> > error: Unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> >
> > Cannot obtain needed object 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
> > while processing commit 0000000000000000000000000000000000000000.
> > cg-fetch: objects fetch failed
> > ---
>
> forget about this thing. The reason for this problem was the kernel.org
> mirroring and the repository wasn't in a sane state. However it would be
> great if we can detect this somehow.
well, we did detect this and error out. ;-) What else would you like
GIT/Cogito to do? Anything particular that could make this less
confusing?
--
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: Problem cloning the Linux history tree
From: Marcel Holtmann @ 2005-11-07 22:19 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: Junio C Hamano, git
In-Reply-To: <200511072250.03121.tglx@linutronix.de>
Hi Thomas,
> > can please try to fix it according to Junio's proposal.
> >
>
> Done
looks like it is working now. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: Problem in update from the linux-2.6 repository
From: Marcel Holtmann @ 2005-11-07 22:18 UTC (permalink / raw)
To: git
In-Reply-To: <1131380293.5824.139.camel@blade>
Hi,
> I run into a weird problem when trying to update my clone of the
> linux-2.6 repository from Linus:
>
> ---
> # cg-update -f
> 17:09:00 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
> Getting alternates list
> Getting pack list
> error: Unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>
> Cannot obtain needed object 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
> while processing commit 0000000000000000000000000000000000000000.
> cg-fetch: objects fetch failed
> ---
forget about this thing. The reason for this problem was the kernel.org
mirroring and the repository wasn't in a sane state. However it would be
great if we can detect this somehow.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Support for passing path to custom map in git-shortlog.perl
From: Petr Baudis @ 2005-11-07 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek5twc3u.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 07, 2005 at 01:11:33AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Aside of looking into .mailmap, add support for -m MAPFILE.
>
> I thought about this when I did .mailmap because I felt
> the more flexibility the better, but wouldn't maintaining the
> project-wide .mailmap as part of the project easier to manage?
Ok, I'm not a die-hard proponent of this change (the genesis is that it
comes from the ages before .mailmap was supported and was originally
coupled with -n which disabled the internal mappings - but then .mailmap
got supported, I deemed -n useless but this still seemed worth something
so I passed it along), but I think it can be useful - either when you
want to work on readonly tree, or when you want to support custom
mailmap in addition to the default project's one without interference...
*shrug*
--
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: Problem cloning the Linux history tree
From: Thomas Gleixner @ 2005-11-07 21:50 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Junio C Hamano, git
In-Reply-To: <1131119240.11673.6.camel@localhost.localdomain>
On Friday 04 November 2005 16:47, Marcel Holtmann wrote:
>
> can please try to fix it according to Junio's proposal.
>
Done
tglx
^ permalink raw reply
* Re: [PATCH] Fix empty line processing in git-shortlog.perl
From: Petr Baudis @ 2005-11-07 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: bunk, git
In-Reply-To: <7v3bm9upx4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 07, 2005 at 03:56:07AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I think the problem is deeper than that. Shortlog summarizes to
> only one line per commit, so I suspect what you would be feeding
> it would say something like this for the above example:
>
> commit f1b2646c7f2713c3ea4bce120e1d0d8091808be4
> Author: Adrian Bunk <bunk@r063144.stusta.swh.mhn.de>
>
> From: Michal Wronski <wrona@mat.uni.torun.pl>
>
> That is, the commit you quoted is done by 'git log --pretty',
> but a typical shortlog invocation would be:
>
> git log --pretty=short rev1..rev2 | git shortlog
>
> With or without your fix, the command barfs.
>
> Of course, that "From: " line should have been used as the
> commit author by the tool that created the commit out of e-mail
> Adrian received, but that is a separate issue.
Well, on a second though, I don't think we should probably handle this
at all, then. The whole logic for this in git-shortlog.perl seems to be
dubious, so would be a requirement that we require the input to be from
--pretty=short ok?
Simpler code, no bugs, everyone happy, errors during applying (like
stale From) immediately noticeable.
--
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
* [PATCH] Make http-push smarter about creating remote dirs
From: Nick Hengeveld @ 2005-11-07 19:39 UTC (permalink / raw)
To: git
Remember object directories known to exist in the remote repo and don't
bother trying to create them.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
applies-to: 27732582039ada9c7781ce5a1583ee682e0452c6
9904bed158b8c297bfba8a8cff87644619688b62
diff --git a/http-push.c b/http-push.c
index 96d2778..4d41b4f 100644
--- a/http-push.c
+++ b/http-push.c
@@ -56,6 +56,7 @@ static int active_requests = 0;
static int data_received;
static int pushing = 0;
static int aborted = 0;
+static char remote_dir_exists[256];
#ifdef USE_CURL_MULTI
static int max_requests = -1;
@@ -669,6 +670,7 @@ static void finish_request(struct transf
if (request->http_code == 404) {
request->state = NEED_PUSH;
} else if (request->curl_result == CURLE_OK) {
+ remote_dir_exists[request->sha1[0]] = 1;
request->state = COMPLETE;
} else {
fprintf(stderr, "HEAD %s failed, aborting (%d/%ld)\n",
@@ -680,6 +682,7 @@ static void finish_request(struct transf
} else if (request->state == RUN_MKCOL) {
if (request->curl_result == CURLE_OK ||
request->http_code == 405) {
+ remote_dir_exists[request->sha1[0]] = 1;
start_put(request);
} else {
fprintf(stderr, "MKCOL %s failed, aborting (%d/%ld)\n",
@@ -790,7 +793,10 @@ void process_request_queue(void)
start_check(request);
curl_multi_perform(curlm, &num_transfers);
} else if (pushing && request->state == NEED_PUSH) {
- start_mkcol(request);
+ if (remote_dir_exists[request->sha1[0]])
+ start_put(request);
+ else
+ start_mkcol(request);
curl_multi_perform(curlm, &num_transfers);
}
request = request->next;
@@ -1622,6 +1628,8 @@ int main(int argc, char **argv)
break;
}
+ memset(remote_dir_exists, 0, 256);
+
curl_global_init(CURL_GLOBAL_ALL);
#ifdef USE_CURL_MULTI
---
0.99.9.GIT
^ permalink raw reply related
* Re: Notes on http-push
From: Nick Hengeveld @ 2005-11-07 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511071926240.14149@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Nov 07, 2005 at 07:34:34PM +0100, Johannes Schindelin wrote:
> - if you init your test by git-clone'ing from a http repo, be sure to
> add a slash to the URL, else git-push will tell you erroneously
> that the server does not do DAV locking. (Probably http-push.c
> should be fixed to add the slash when needed.)
In the -fetch counterparts, the trailing slash is added by git-fetch.sh,
does this belong in the get_remote_url() function in
git-parse-remote.sh? I've only pushed with DAV, so I'm not sure whether
that would break anything else.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: GIT 0.99.9e
From: Ingo Oeser @ 2005-11-07 19:02 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git
In-Reply-To: <20051107154718.GJ3001@reactrix.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Monday 07 November 2005 16:47, Nick Hengeveld wrote:
> On Sun, Nov 06, 2005 at 09:43:19PM -0800, Junio C Hamano wrote:
>
> > - http-push seems to still have a bug or two but that is to be
> > expected for any new code, and I am reasonably sure it can be
> > ironed out; preferably before 1.0 but it is not a
> > showstopper.
>
> It seems like a minor point, but is this the appropriate name or should
> it be dav-push? Not that there's anything else in the works AFAIK but
> it's certainly possible that something else could run over HTTP later
> on.
e.g. GIT encapsulated in SOAP
/me *ducks* and *runs*
Ingo Oeser
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Notes on http-push
From: Johannes Schindelin @ 2005-11-07 18:34 UTC (permalink / raw)
To: git
Hi,
two little things I noticed while playing around with http-push:
- if you init your test by git-clone'ing from a http repo, be sure to
add a slash to the URL, else git-push will tell you erroneously
that the server does not do DAV locking. (Probably http-push.c
should be fixed to add the slash when needed.)
- if you execute "git push origin", it does not do anything (correctly?),
if there is no "Push:" line in .git/remotes/origin (which is the
default after cloning). Try "git push origin master". (Probably
http-push or git-push should say something about it, not
just quit silently.)
If you want to play with it yourself: A minimal setup using Apache needs
something like this in httpd.conf:
--- snip ---
<Location /gits>
DAV on
Deny From *
Allow From 192.168.0.
</Location>
DAVLockDB "/usr/local/apache2/temp/DAV.lock"
--- snap ---
Make sure that your www user has write permissions on <HTDOCS>/gits and on
the DAV lock.
Have fun,
Dscho
^ permalink raw reply
* [PATCH] Small bugfixes for http-push.c
From: Johannes Schindelin @ 2005-11-07 18:23 UTC (permalink / raw)
To: git, junkio
This patch fixes three things:
- older libexpat does not know about enum XML_Status
- as in my patch for http-fetch, do not rely on a curl result in
free()d data
- calloc the new_lock structure
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
I verified in a small scale test that it works now. The buglets
showed only on my iBook, not on any Linux box I tried.
The calloc'ing of the new_lock structure is necessary, because
activelock_cdata() relies on several members being 0 until
set by start_activelock_element().
The problem I was experiencing with a crash in
cleanup_multi_handle() was due to the curl result not being
interpreted correctly.
Unfortunately, valgrind does not work on macosx, so it could
not help me.
Note: http-push shares a lot of code with http-fetch. It might
be a good idea to refactor them (after some more out-ironing).
http-push.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index c10067c..5532d02 100644
--- a/http-push.c
+++ b/http-push.c
@@ -28,6 +28,15 @@ static const char http_push_usage[] =
#define NO_CURL_EASY_DUPHANDLE
#endif
+#ifndef XML_STATUS_OK
+enum XML_Status {
+ XML_STATUS_OK = 1,
+ XML_STATUS_ERROR = 0
+};
+#define XML_STATUS_OK 1
+#define XML_STATUS_ERROR 0
+#endif
+
#define RANGE_HEADER_SIZE 30
/* DAV method names and request body templates */
@@ -728,11 +737,12 @@ void process_curl_messages(void)
slot->curl != curl_message->easy_handle)
slot = slot->next;
if (slot != NULL) {
+ int curl_result = curl_message->data.result;
curl_multi_remove_handle(curlm, slot->curl);
active_requests--;
slot->done = 1;
slot->in_use = 0;
- slot->curl_result = curl_message->data.result;
+ slot->curl_result = curl_result;
curl_easy_getinfo(slot->curl,
CURLINFO_HTTP_CODE,
&slot->http_code);
@@ -1230,7 +1240,7 @@ struct active_lock *lock_remote(char *fi
in_buffer.posn = 0;
in_buffer.buffer = in_data;
- new_lock = xmalloc(sizeof(*new_lock));
+ new_lock = xcalloc(1, sizeof(*new_lock));
new_lock->owner = NULL;
new_lock->token = NULL;
new_lock->timeout = -1;
^ permalink raw reply related
* Re: git binary directory?
From: Junio C Hamano @ 2005-11-07 17:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0511061653380.3316@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 7 Nov 2005, Petr Baudis wrote:
>>
>> I want to avoid extra fork()s and exec()s. They seem to routinely matter
>> in orders of magnitude of speed in tight loops.
>
> Yes. The more I think about it, the less I like the separate binary
> directory after all. The "git cmd" format is great for high-level
> commands, but we've always done "git-diff-tree" and "git-rev-list" etc
> without the "git cmd" indirection.
Extra fork() and exec() problem still exists, but "git cmd"
format have worked with "git diff-tree" and "git rev-list" for
quite some time (since Jun 14th), so you might've always done it
with dash but that is not a requirement.
It looks like that both you and Pasky are not so enthusiastic
about moving thing out of /usr/bin/, so let's keep things the
way they are for 1.0 release and rethink when we do 2.0 (or
whatever comes after 1.0).
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Nick Hengeveld @ 2005-11-07 17:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511062050geee7e73qddcd52e3a2ec86df@mail.gmail.com>
On Mon, Nov 07, 2005 at 05:50:02PM +1300, Martin Langhoff wrote:
> > Does it always error out on the same pack file?
>
> Yes.
You might try this to see exactly what request/response headers
curl thinks are passing back and forth.
diff --git a/http-fetch.c b/http-fetch.c
index ea8af1b..11d4dca 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -325,6 +325,7 @@ static struct active_request_slot *get_a
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, no_range_header);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
+ curl_easy_setopt(slot->curl, CURLOPT_VERBOSE, 1);
return slot;
}
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply related
* Re: GIT 0.99.9e
From: H. Peter Anvin @ 2005-11-07 17:08 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <20051107154718.GJ3001@reactrix.com>
Nick Hengeveld wrote:
> On Sun, Nov 06, 2005 at 09:43:19PM -0800, Junio C Hamano wrote:
>
>
>> - http-push seems to still have a bug or two but that is to be
>> expected for any new code, and I am reasonably sure it can be
>> ironed out; preferably before 1.0 but it is not a
>> showstopper.
>
> It seems like a minor point, but is this the appropriate name or should
> it be dav-push? Not that there's anything else in the works AFAIK but
> it's certainly possible that something else could run over HTTP later
> on.
>
Push over HTTP POST would at least be theoretically possible.
-hpa
^ permalink raw reply
* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-07 16:56 UTC (permalink / raw)
To: Junio C Hamano, Fredrik Kuivinen; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511070837530.3193@g5.osdl.org>
On Mon, 7 Nov 2005, Linus Torvalds wrote:
>
> I just hit my first real rename conflict, and very timidly tried the
> "recursive" strategy in the hopes that I wouldn't need to do things by
> hand.
>
> It resolved things beautifully. Good job.
Btw, one thing that it does is print out too much information.
In particular, I had renames on both sides of the merge (in case anybody
wants to see which one I'm talking about: it's the current top-of-head
commit in the kernel archives: 333c47c847c90aaefde8b593054d9344106333b5).
Now, renames that you've done yourself you really don't want to hear
about, at least if the other side didn't change anything in that file.
Renames that the _other_ side has done (the one you're merging) you may or
may not want to know about, regardless of whether they happened to files
that are changed. But since "git pull" will do a "git-apply --stat" at the
end and show the renames there, I'd argue that the merge strategy itself
should be quiet about any renames that are trivial.
So how about talking about renames only if you end up also doing a
file-level merge? As it is, doing the merge talked about renames that I
had merged earlier in my own branch, which is just confusing.
Linus
^ permalink raw reply
* Comments on recursive merge..
From: Linus Torvalds @ 2005-11-07 16:48 UTC (permalink / raw)
To: Junio C Hamano, Fredrik Kuivinen; +Cc: Git Mailing List
Guys,
I just hit my first real rename conflict, and very timidly tried the
"recursive" strategy in the hopes that I wouldn't need to do things by
hand.
It resolved things beautifully. Good job.
My only worry is that I don't read python, so I don't really know how it
does what it does, which makes me nervous. Can somebody (Fredrik?) add
some documentation about the merge strategy and how it works.
Considering that the stupid resolve strategy really requires you to know
how git works when rename conflicts happen (things left in unmerged state
are really quite hard to handle by hand unless you know exactly what
you're doing), I'd almost suggest making "recursive" the default. I'm a
bit nervous about it, but knowing how it works would probably put most of
that to rest.
Linus
^ permalink raw reply
* Problem in update from the linux-2.6 repository
From: Marcel Holtmann @ 2005-11-07 16:18 UTC (permalink / raw)
To: git
Hi guys,
I run into a weird problem when trying to update my clone of the
linux-2.6 repository from Linus:
---
# cg-update -f
17:09:00 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
Getting alternates list
Getting pack list
error: Unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c under http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Cannot obtain needed object 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
while processing commit 0000000000000000000000000000000000000000.
cg-fetch: objects fetch failed
---
I use the latest available git and cogito for this and I have no idea
which is at fault. Using rsync as transport it even looks more worse:
---
# cg-update -f
WARNING: The rsync access method is DEPRECATED and will be REMOVED in the future!
receiving file list ... done
sent 111 bytes received 774 bytes 354.00 bytes/sec
total size is 41 speedup is 0.05
receiving file list ... done
progress: 2631 objects, 9754798 bytes, 100% done
info/packs
sent 58020 bytes received 10252045 bytes 74982.29 bytes/sec
total size is 121158464 speedup is 11.75
receiving file list ... done
sent 118 bytes received 1095 bytes 346.57 bytes/sec
total size is 902 speedup is 0.74
Tree change: f912696ab330bf539231d1f8032320f2a08b850f:2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
error: unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
fatal: git-cat-file 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c: bad file
error: unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
fatal: git-cat-file 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c: bad file
Invalid tree id: 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
Applying changes...
error: unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
fatal: git-cat-file 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c: bad file
error: unable to find 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
fatal: git-cat-file 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c: bad file
Invalid commit id: 2ed5e6d09e266bd2288d49aaaf240ed8c468c13c
---
Maybe this is a problem of the kernel.org synchronization, but otherwise
it should be fixed. Will there be a way to get some useful messages to
the end user in case of an error or some sanity checks that the tree you
are pulling from is in sane state or not?
Regards
Marcel
^ permalink raw reply
* Re: GIT 0.99.9e
From: Nick Hengeveld @ 2005-11-07 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v64r5t3m0.fsf@assigned-by-dhcp.cox.net>
On Sun, Nov 06, 2005 at 09:43:19PM -0800, Junio C Hamano wrote:
> - http-push seems to still have a bug or two but that is to be
> expected for any new code, and I am reasonably sure it can be
> ironed out; preferably before 1.0 but it is not a
> showstopper.
It seems like a minor point, but is this the appropriate name or should
it be dav-push? Not that there's anything else in the works AFAIK but
it's certainly possible that something else could run over HTTP later
on.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: GIT Vs CVS
From: Peter Eriksen @ 2005-11-07 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <436F6A32.6040200@op5.se>
On Mon, Nov 07, 2005 at 03:52:34PM +0100, Andreas Ericsson wrote:
> Mukund JB. wrote:
...
> >Can any elaborate on this?
>
>
> It was just done in the list. If you browse the archives you'll find a
> lengthy discussion.
The thread is called 'git versus CVS (versus bk)' and can be found at
http://marc.theaimsgroup.com/?t=113072368900002&r=1&w=2
Regards,
Peter
^ permalink raw reply
* Re: GIT Vs CVS
From: Andreas Ericsson @ 2005-11-07 14:52 UTC (permalink / raw)
To: git
In-Reply-To: <3AEC1E10243A314391FE9C01CD65429B13B2DA@mail.esn.co.in>
Mukund JB. wrote:
> Dear All,
>
> I have been just aware of GIT. As an active Linux device driver developer, I would like to know more about it.
> I have read through the GIT documentation the git native site.http://git.or.cz/
>
> I find lot a similarities between GIT And Cvs.
The similiarities are just because they're both SCM's. It pretty much
ends there.
> Can any elaborate on this?
It was just done in the list. If you browse the archives you'll find a
lengthy discussion. You might also want to read the
Documentation/cvs-migration.txt found in the git distribution.
> Can I use GIT instead of Cvs?
>
Certainly. Prepare to spend a week or so letting the command-structure
and syntax sink in though. It's a steep learning curve at first,
although the git tutorial (Documentation/tutorial.txt) nicely cuts it in
half.
The documentation is also available for online browsing at
http://www.kernel.org/pub/software/scm/git-core/docs/
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* GIT Vs CVS
From: Mukund JB. @ 2005-11-07 14:34 UTC (permalink / raw)
To: git
Dear All,
I have been just aware of GIT. As an active Linux device driver developer, I would like to know more about it.
I have read through the GIT documentation the git native site.http://git.or.cz/
I find lot a similarities between GIT And Cvs.
Can any elaborate on this? Can I use GIT instead of Cvs?
Regards,
Mukund Jampala
^ permalink raw reply
* [PATCH] Use consistent shell prompts and example style.
From: Jon Loeliger @ 2005-11-07 14:33 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/tutorial.txt | 226 +++++++++++++++++++++++++++-----------------
1 files changed, 138 insertions(+), 88 deletions(-)
applies-to: 5ebec76efaa72d55bc18eaadad6e85f03e8173a3
291987d85077f3ce3a9beefe39ab5730262c2317
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 6d2c153..22f21fd 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -36,14 +36,16 @@ To start up, create a subdirectory for i
subdirectory, and initialize the git infrastructure with `git-init-db`:
------------------------------------------------
-mkdir git-tutorial
-cd git-tutorial
-git-init-db
+$ mkdir git-tutorial
+$ cd git-tutorial
+$ git-init-db
------------------------------------------------
to which git will reply
- defaulting to local storage area
+----------------
+defaulting to local storage area
+----------------
which is just git's way of saying that you haven't been doing anything
strange, and that it will have created a local `.git` directory setup for
@@ -114,8 +116,8 @@ in your git repository. We'll start off
get a feel for how this works:
------------------------------------------------
-echo "Hello World" >hello
-echo "Silly example" >example
+$ echo "Hello World" >hello
+$ echo "Silly example" >example
------------------------------------------------
you have now created two files in your working tree (aka 'working directory'), but to
@@ -137,7 +139,7 @@ adding a new entry with the `\--add` fla
So to populate the index with the two files you just created, you can do
------------------------------------------------
-git-update-index --add hello example
+$ git-update-index --add hello example
------------------------------------------------
and you have now told git to track those two files.
@@ -146,12 +148,17 @@ In fact, as you did that, if you now loo
you'll notice that git will have added two new objects to the object
database. If you did exactly the steps above, you should now be able to do
- ls .git/objects/??/*
+
+----------------
+$ ls .git/objects/??/*
+----------------
and see two files:
- .git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
- .git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
+----------------
+.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
+.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
+----------------
which correspond with the objects with names of 557db... and f24c7..
respectively.
@@ -159,13 +166,17 @@ respectively.
If you want to, you can use `git-cat-file` to look at those objects, but
you'll have to use the object name, not the filename of the object:
- git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+----------------
+$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
+----------------
where the `-t` tells `git-cat-file` to tell you what the "type" of the
object is. git will tell you that you have a "blob" object (ie just a
regular file), and you can see the contents with
- git-cat-file "blob" 557db03
+----------------
+$ git-cat-file "blob" 557db03
+----------------
which will print out "Hello World". The object 557db03 is nothing
more than the contents of your file `hello`.
@@ -202,7 +213,7 @@ In particular, let's not even check in t
start off by adding another line to `hello` first:
------------------------------------------------
-echo "It's a new day for git" >>hello
+$ echo "It's a new day for git" >>hello
------------------------------------------------
and you can now, since you told git about the previous state of `hello`, ask
@@ -210,7 +221,7 @@ git what has changed in the tree compare
`git-diff-files` command:
------------
-git-diff-files
+$ git-diff-files
------------
Oops. That wasn't very readable. It just spit out its own internal
@@ -222,12 +233,7 @@ To make it readable, we can tell git-dif
differences as a patch, using the `-p` flag:
------------
-git-diff-files -p
-------------
-
-which will spit out
-
-------------
+$ git-diff-files -p
diff --git a/hello b/hello
index 557db03..263414f 100644
--- a/hello
@@ -264,13 +270,15 @@ filenames with their contents (and their
creating the equivalent of a git "directory" object:
------------------------------------------------
-git-write-tree
+$ git-write-tree
------------------------------------------------
and this will just output the name of the resulting tree, in this case
(if you have done exactly as I've described) it should be
- 8988da15d077d4829fc51d8544c097def6644dbb
+----------------
+8988da15d077d4829fc51d8544c097def6644dbb
+----------------
which is another incomprehensible object name. Again, if you want to,
you can use `git-cat-file -t 8988d\...` to see that this time the object
@@ -299,14 +307,16 @@ that's exactly what `git-commit-tree` sp
all with a sequence of simple shell commands:
------------------------------------------------
-tree=$(git-write-tree)
-commit=$(echo 'Initial commit' | git-commit-tree $tree)
-git-update-ref HEAD $commit
+$ tree=$(git-write-tree)
+$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
+$ git-update-ref HEAD $commit
------------------------------------------------
which will say:
- Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
+----------------
+Committing initial tree 8988da15d077d4829fc51d8544c097def6644dbb
+----------------
just to warn you about the fact that it created a totally new commit
that is not related to anything else. Normally you do this only *once*
@@ -349,7 +359,9 @@ didn't have anything to diff against.
But now we can do
- git-diff-index -p HEAD
+----------------
+$ git-diff-index -p HEAD
+----------------
(where `-p` has the same meaning as it did in `git-diff-files`), and it
will show us the same difference, but for a totally different reason.
@@ -360,7 +372,9 @@ are obviously the same, so we get the sa
Again, because this is a common operation, you can also just shorthand
it with
- git diff HEAD
+----------------
+$ git diff HEAD
+----------------
which ends up doing the above for you.
@@ -396,7 +410,7 @@ work through the index file, so the firs
update the index cache:
------------------------------------------------
-git-update-index hello
+$ git-update-index hello
------------------------------------------------
(note how we didn't need the `\--add` flag this time, since git knew
@@ -417,7 +431,7 @@ this wasn't an initial commit any more),
already, so let's just use the helpful script this time:
------------------------------------------------
-git commit
+$ git commit
------------------------------------------------
which starts an editor for you to write the commit message and tells you
@@ -450,7 +464,9 @@ give it just a single commit object, and
of that commit itself, and show the difference directly. Thus, to get
the same diff that we've already seen several times, we can now do
- git-diff-tree -p HEAD
+----------------
+$ git-diff-tree -p HEAD
+----------------
(again, `-p` means to show the difference as a human-readable patch),
and it will show what the last commit (in `HEAD`) actually changed.
@@ -505,13 +521,17 @@ activities.
To see the whole history of our pitiful little git-tutorial project, you
can do
- git log
+----------------
+$ git log
+----------------
which shows just the log messages, or if we want to see the log together
with the associated patches use the more complex (and much more
powerful)
- git-whatchanged -p --root
+----------------
+$ git-whatchanged -p --root
+----------------
and you will see exactly what has changed in the repository over its
short history.
@@ -547,14 +567,16 @@ it in the `.git/refs/tags/` subdirectory
So the simplest form of tag involves nothing more than
------------------------------------------------
-git tag my-first-tag
+$ git tag my-first-tag
------------------------------------------------
which just writes the current `HEAD` into the `.git/refs/tags/my-first-tag`
file, after which point you can then use this symbolic name for that
particular state. You can, for example, do
- git diff my-first-tag
+----------------
+$ git diff my-first-tag
+----------------
to diff your current state against that tag (which at this point will
obviously be an empty diff, but if you continue to develop and commit
@@ -568,7 +590,9 @@ you really did
that tag. You create these annotated tags with either the `-a` or
`-s` flag to `git tag`:
- git tag -s <tagname>
+----------------
+$ git tag -s <tagname>
+----------------
which will sign the current `HEAD` (but you can also give it another
argument that specifies the thing to tag, ie you could have tagged the
@@ -584,8 +608,8 @@ name for the state at that point.
Copying repositories
--------------------
-git repositories are normally totally self-sufficient, and it's worth noting
-that unlike CVS, for example, there is no separate notion of
+git repositories are normally totally self-sufficient and relocatable
+Unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally *is* the
working tree, with the local git information hidden in the `.git`
subdirectory. There is nothing else. What you see is what you got.
@@ -602,8 +626,10 @@ This has two implications:
- if you grow bored with the tutorial repository you created (or you've
made a mistake and want to start all over), you can just do simple
-
- rm -rf git-tutorial
++
+----------------
+$ rm -rf git-tutorial
+----------------
+
and it will be gone. There's no external repository, and there's no
history outside the project you created.
@@ -618,8 +644,10 @@ Note that when you've moved or copied a
file (which caches various information, notably some of the "stat"
information for the files involved) will likely need to be refreshed.
So after you do a `cp -a` to create a new copy, you'll want to do
-
- git-update-index --refresh
++
+----------------
+$ git-update-index --refresh
+----------------
+
in the new repository to make sure that the index file is up-to-date.
@@ -633,8 +661,10 @@ repositories you often want to make sure
known state (you don't know *what* they've done and not yet checked in),
so usually you'll precede the `git-update-index` with a
- git-read-tree --reset HEAD
- git-update-index --refresh
+----------------
+$ git-read-tree --reset HEAD
+$ git-update-index --refresh
+----------------
which will force a total index re-build from the tree pointed to by `HEAD`.
It resets the index contents to `HEAD`, and then the `git-update-index`
@@ -645,7 +675,9 @@ tells you they need to be updated.
The above can also be written as simply
- git reset
+----------------
+$ git reset
+----------------
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
@@ -665,20 +697,26 @@ first create your own subdirectory for t
raw repository contents into the `.git` directory. For example, to
create your own copy of the git repository, you'd do the following
- mkdir my-git
- cd my-git
- rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+----------------
+$ mkdir my-git
+$ cd my-git
+$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
+----------------
followed by
- git-read-tree HEAD
+----------------
+$ git-read-tree HEAD
+----------------
to populate the index. However, now you have populated the index, and
you have all the git internal files, but you will notice that you don't
actually have any of the working tree files to work on. To get
those, you'd check them out with
- git-checkout-index -u -a
+----------------
+$ git-checkout-index -u -a
+----------------
where the `-u` flag means that you want the checkout to keep the index
up-to-date (so that you don't have to refresh it afterward), and the
@@ -689,9 +727,11 @@ files).
Again, this can all be simplified with
- git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
- cd my-git
- git checkout
+----------------
+$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
+$ cd my-git
+$ git checkout
+----------------
which will end up doing all of the above for you.
@@ -719,7 +759,7 @@ used earlier, and create a branch in it.
saying that you want to check out a new branch:
------------
-git checkout -b mybranch
+$ git checkout -b mybranch
------------
will create a new branch based at the current `HEAD` position, and switch
@@ -733,7 +773,7 @@ just telling `git checkout` what the bas
In other words, if you have an earlier tag or branch, you'd just do
------------
-git checkout -b mybranch earlier-commit
+$ git checkout -b mybranch earlier-commit
------------
and it would create the new branch `mybranch` at the earlier commit,
@@ -743,27 +783,27 @@ and check out the state at that time.
You can always just jump back to your original `master` branch by doing
------------
-git checkout master
+$ git checkout master
------------
(or any other branch-name, for that matter) and if you forget which
branch you happen to be on, a simple
------------
-ls -l .git/HEAD
+$ ls -l .git/HEAD
------------
will tell you where it's pointing (Note that on platforms with bad or no
symlink support, you have to execute
------------
-cat .git/HEAD
+$ cat .git/HEAD
------------
instead). To get the list of branches you have, you can say
------------
-git branch
+$ git branch
------------
which is nothing more than a simple script around `ls .git/refs/heads`.
@@ -773,7 +813,7 @@ Sometimes you may wish to create a new b
checking it out and switching to it. If so, just use the command
------------
-git branch <branchname> [startingpoint]
+$ git branch <branchname> [startingpoint]
------------
which will simply _create_ the branch, but will not do anything further.
@@ -792,9 +832,9 @@ being the same as the original `master`
that branch, and do some work there.
------------------------------------------------
-git checkout mybranch
-echo "Work, work, work" >>hello
-git commit -m 'Some work.' hello
+$ git checkout mybranch
+$ echo "Work, work, work" >>hello
+$ git commit -m 'Some work.' hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
@@ -807,7 +847,7 @@ does some work in the original branch, a
to the master branch, and editing the same file differently there:
------------
-git checkout master
+$ git checkout master
------------
Here, take a moment to look at the contents of `hello`, and notice how they
@@ -815,9 +855,9 @@ don't contain the work we just did in `m
hasn't happened in the `master` branch at all. Then do
------------
-echo "Play, play, play" >>hello
-echo "Lots of fun" >>example
-git commit -m 'Some fun.' hello example
+$ echo "Play, play, play" >>hello
+$ echo "Lots of fun" >>example
+$ git commit -m 'Some fun.' hello example
------------
since the master branch is obviously in a much better mood.
@@ -826,7 +866,9 @@ Now, you've got two branches, and you de
work done. Before we do that, let's introduce a cool graphical tool that
helps you view what's going on:
- gitk --all
+----------------
+$ gitk --all
+----------------
will show you graphically both of your branches (that's what the `\--all`
means: normally it will just show you your current `HEAD`) and their
@@ -840,7 +882,7 @@ script called `git merge`, which wants t
to resolve and what the merge is all about:
------------
-git merge "Merge work in mybranch" HEAD mybranch
+$ git merge "Merge work in mybranch" HEAD mybranch
------------
where the first argument is going to be used as the commit message if
@@ -851,6 +893,7 @@ merge will need to be fixed up by hand,
of it as it can automatically (which in this case is just merge the `example`
file, which had no differences in the `mybranch` branch), and say:
+----------------
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
@@ -859,6 +902,7 @@ file, which had no differences in the `m
ERROR: Merge conflict in hello.
fatal: merge program failed
Automatic merge failed/prevented; fix up by hand
+----------------
which is way too verbose, but it basically tells you that it failed the
really trivial merge ("Simple merge") and did an "Automatic merge"
@@ -879,7 +923,7 @@ Work, work, work
and once you're happy with your manual merge, just do a
------------
-git commit hello
+$ git commit hello
------------
which will very loudly warn you that you're now committing a merge
@@ -929,17 +973,19 @@ to the `master` branch. Let's go back to
resolve to get the "upstream changes" back to your branch.
------------
-git checkout mybranch
-git merge "Merge upstream changes." HEAD master
+$ git checkout mybranch
+$ git merge "Merge upstream changes." HEAD master
------------
This outputs something like this (the actual commit object names
would be different)
- Updating from ae3a2da... to a80b4aa....
- example | 1 +
- hello | 1 +
- 2 files changed, 2 insertions(+), 0 deletions(-)
+----------------
+Updating from ae3a2da... to a80b4aa....
+ example | 1 +
+ hello | 1 +
+ 2 files changed, 2 insertions(+), 0 deletions(-)
+----------------
Because your branch did not contain anything more than what are
already merged into the `master` branch, the resolve operation did
@@ -972,7 +1018,9 @@ followed by a `git resolve`.
Fetching from a remote repository is done by, unsurprisingly,
`git fetch`:
- git fetch <remote-repository>
+----------------
+$ git fetch <remote-repository>
+----------------
One of the following transports can be used to name the
repository to download from:
@@ -1017,7 +1065,7 @@ This transport was designed for anonymou
transport, it finds out the set of objects the downstream side
lacks and transfers (close to) minimum set of objects.
-HTTP(s)::
+HTTP(S)::
`http://remote.machine/path/to/repo.git/`
+
HTTP and HTTPS transport are used only for downloading. They
@@ -1047,7 +1095,9 @@ However -- it's such a common thing to `
immediately `resolve`, that it's called `git pull`, and you can
simply do
- git pull <remote-repository>
+----------------
+$ git pull <remote-repository>
+----------------
and optionally give a branch-name for the remote end as a second
argument.
@@ -1075,8 +1125,8 @@ the remote repository URL in a file unde
directory, like this:
------------------------------------------------
-mkdir -p .git/remotes/
-cat >.git/remotes/linus <<\EOF
+$ mkdir -p .git/remotes/
+$ cat >.git/remotes/linus <<\EOF
URL: http://www.kernel.org/pub/scm/git/git.git/
EOF
------------------------------------------------
@@ -1086,7 +1136,7 @@ The URL specified in such file can even
of a full URL, like this:
------------------------------------------------
-cat >.git/remotes/jgarzik <<\EOF
+$cat >.git/remotes/jgarzik <<\EOF
URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
EOF
------------------------------------------------
@@ -1299,7 +1349,7 @@ project `my-git`. After logging into the
an empty directory:
------------
-mkdir my-git.git
+$ mkdir my-git.git
------------
Then, make that directory into a git repository by running
@@ -1307,7 +1357,7 @@ Then, make that directory into a git rep
`.git`, we do things slightly differently:
------------
-GIT_DIR=my-git.git git-init-db
+$ GIT_DIR=my-git.git git-init-db
------------
Make sure this directory is available for others you want your
@@ -1333,7 +1383,7 @@ Come back to the machine you have your p
there, run this command:
------------
-git push <public-host>:/path/to/my-git.git master
+$ git push <public-host>:/path/to/my-git.git master
------------
This synchronizes your public repository to match the named
@@ -1345,7 +1395,7 @@ repository. Kernel.org mirror network ta
propagation to other publicly visible machines:
------------
-git push master.kernel.org:/pub/scm/git/git.git/
+$ git push master.kernel.org:/pub/scm/git/git.git/
------------
@@ -1360,7 +1410,7 @@ immutable once they are created, there i
storage by "packing them together". The command
------------
-git repack
+$ git repack
------------
will do it for you. If you followed the tutorial examples, you
@@ -1386,7 +1436,7 @@ Once you have packed objects, you do not
unpacked objects that are contained in the pack file anymore.
------------
-git prune-packed
+$ git prune-packed
------------
would remove them for you.
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Add --tags documentation, scraped from JC mail.
From: Jon Loeliger @ 2005-11-07 14:03 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Thin territory here for me. Feel free to alter if not right! :-)
Also notice the lonely --force option still...
Documentation/fetch-options.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
applies-to: e7ff595f1fb6068b11a3a2c7eb71110faea998b8
839bbee0c81567d3f951b0cff3b2b855af6e1a99
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 12d12b2..0e502ae 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -6,6 +6,9 @@
-f, \--force::
-t, \--tags::
+ By default, the git core utilities will not fetch and store
+ tags under the same name as the remote repository; ask it
+ to do so using `--tags`.
-u, \--update-head-ok::
By default `git-fetch` refuses to update the head which
---
0.99.9.GIT
^ permalink raw reply related
* Re: GIT 0.99.9e
From: Johannes Schindelin @ 2005-11-07 11:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v64r5t3m0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 6 Nov 2005, Junio C Hamano wrote:
> - http-push seems to still have a bug or two but that is to be
> expected for any new code, and I am reasonably sure it can be
> ironed out; preferably before 1.0 but it is not a
> showstopper.
I am reasonably sure that a run with valgrind will show the way to a
stable http-push. It is just a little memory corruption: the rest works
wonderfully.
Ciao,
Dscho
^ permalink raw reply
* Re: Tags not transferred with git pull?
From: Erik Mouw @ 2005-11-07 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll04tdsz.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 04, 2005 at 11:26:20AM -0800, Junio C Hamano wrote:
> Sorry for the confusion. The barebone Porcelainish shipped with
> git-core does not fetch and store tags unconditionally under the
> same name as the remote has without being told; you need to
> explicitly tell it to 'git fetch --tags'.
>
> What was added recently was a low level support for Cogito to
> implement the automatic tracking. This is supposed to (I do not
> offhand know if the Cogito side has been updated to do so
> already) work a bit differently. Instead of grabbing all tags
> and all objects reachable from them, as you fetch commits from
> the remote, the automatic tracking fetches tags that point at
> them. What this means is that the tags on the remote branch you
> are tracking would be fetched automatically but tags on a remote
> branch you are not interested in are not.
Thanks for the explanation.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ 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