* Re: How to commit removed file?
From: Junio C Hamano @ 2007-01-03 7:14 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhcv8r4ac.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ... That's a
> great news.
>
> I am not interested to make it "all" myself -- if somebody else
> does it, that is fine, though ;-).
Just in case you do not know me, sorry for too much negative
tone in my message. I was just venting. It was not like I was
offended by something you said or anything like that.
The "commit path..." feature, while I would even agree that it
sometimes is useful in simple cases, is something that goes
quite against what git does normally, and anybody would
understand why after inspecting what git-commit has to do to
implement that. I personally hate that "feature".
Having said that, I am known to support features that I do not
agree with myself for other people, and sometimes even implement
them myself. But that does not mean I have to like them ;-).
^ permalink raw reply
* Re: [PATCH] git-branch: show detached HEAD
From: Lars Hjemli @ 2007-01-03 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wmcr3nz.fsf@assigned-by-dhcp.cox.net>
On 1/3/07, Junio C Hamano <junkio@cox.net> wrote:
> Can we have two patches, one for loop restructuring without
> detached HEAD support, and then another to add support for it?
Sure, I'll do it tonight
--
larsh
^ permalink raw reply
* Re: [PATCH] git-branch: show detached HEAD
From: Lars Hjemli @ 2007-01-03 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7v7iw4r47e.fsf@assigned-by-dhcp.cox.net>
On 1/3/07, Junio C Hamano <junkio@cox.net> wrote:
> I would even make it stronger to say something like:
>
> * You are not on ANY branch right now.
> master
> next
> pu
> ...
>
Hmm, that wouldn't be very nice for 'git-branch -v' (which suddenly
got extra useful with detached head).
--
larsh
^ permalink raw reply
* Re: [PATCH] git-branch: show detached HEAD
From: Junio C Hamano @ 2007-01-03 7:52 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580701022350n13742ec1n6f5fadcf1dfb18aa@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 1/3/07, Junio C Hamano <junkio@cox.net> wrote:
>> I would even make it stronger to say something like:
>>
>> * You are not on ANY branch right now.
>> master
>> next
>> pu
>> ...
>>
>
> Hmm, that wouldn't be very nice for 'git-branch -v' (which suddenly
> got extra useful with detached head).
Ah, please scratch that.
I did not remember that option, since I do not use it myself.
Thanks for injecting sanity.
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Marco Costalba @ 2007-01-03 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vodpja0u8.fsf@assigned-by-dhcp.cox.net>
On 1/1/07, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >>
> >> Further, if you rely on parsing being super-fast, why not just parse
> >> _only_ the header information that you actually need? The header still
> >> consists of
> >>
> >> - exactly one "tree",
> >> - an arbitrary amount of "parent" lines,
> >> - exactly one "author", and
> >> - exactly one "committer" line
> >>
> >> After that may come optional headers,
>
> They are more like 'other' headers. Nobody said the set of
> headers are cast in stone forever. The only things parsers
> safely can assume are that the original four kinds come at the
> beginning in the above order, and there is a blank line that
> separates headers and the body.
>
I'm cooking the qgit parser fix, please confirm the following
assumption is correct:
When git-rev-list is called with --header option, after the first
line with the commit sha, the following information is produced
- one line with "tree"
- an arbitrary amount of "parent" lines
- one line with "author"
- one line with "committer"
- zero or more *non blank* lines with other info, as the encoding
- one blank line
- zero or one line with log title
- zero or more lines with log message
- a terminating '\0'
Thanks
Marco
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Junio C Hamano @ 2007-01-03 10:10 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550701030121n700fab25x63278457c884a3f7@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 1/1/07, Junio C Hamano <junkio@cox.net> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> >>
>> >> Further, if you rely on parsing being super-fast, why not just parse
>> >> _only_ the header information that you actually need? The header still
>> >> consists of
>> >>
>> >> - exactly one "tree",
>> >> - an arbitrary amount of "parent" lines,
>> >> - exactly one "author", and
>> >> - exactly one "committer" line
>> >>
>> >> After that may come optional headers,
>>
>> They are more like 'other' headers. Nobody said the set of
>> headers are cast in stone forever. The only things parsers
>> safely can assume are that the original four kinds come at the
>> beginning in the above order, and there is a blank line that
>> separates headers and the body.
>>
>
> I'm cooking the qgit parser fix, please confirm the following
> assumption is correct:
>
> When git-rev-list is called with --header option, after the first
> line with the commit sha, the following information is produced
>
> - one line with "tree"
> - an arbitrary amount of "parent" lines
> - one line with "author"
> - one line with "committer"
> - zero or more *non blank* lines with other info, as the encoding
> - one blank line
> - zero or one line with log title
> - zero or more lines with log message
> - a terminating '\0'
I think that is correct, except that rev-list does not even care
the distinction between log title and log message.
I do not think of a reason to change the order of the first four
offhand, so while it might be prudent to prepare the code to
accept them in any order if it is not too much trouble from
purist point of view, I do not think it is necessary in practice
and you should be able to depend on the order in which they
appear. I do not think it would hurt anybody if we right now
declared that other extra headers people have talked about (such
as "notes") should always come after the first four.
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Lars Hjemli @ 2007-01-03 10:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <e5bfff550701030121n700fab25x63278457c884a3f7@mail.gmail.com>
On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
> - one blank line
> - zero or one line with log title
> - zero or more lines with log message
> - a terminating '\0'
I think the should be:
-zero or more blank lines
-zero or more non-blank lines with log title
-zero or more blank lines
-zero or more lines with log message
-a terminating '\0'
...which implies that all of these rules (except the last) are
optional and only triggers if the _previous_ rule triggered.
In other words:
commit ::= header [blank+ [title+ [blank+ text*]]] '\0'
header ::= tree parent* author committer
--
larsh
^ permalink raw reply
* preview of "What's cooking" (topics)
From: Junio C Hamano @ 2007-01-03 10:25 UTC (permalink / raw)
To: git
My git day this week hasn't started yet, but for people to base
their improvements on, here is a quick status before I go to
bed.
- Detached HEAD along with two patches to teach git-status and
git-branch about not being on any branch are in 'pu'; I
removed -d option from git-checkout from the previous round.
- Jürgen's git-status improvements are mostly in 'next' but
one of them is queued in 'pu', waiting for comments.
- I've queued my counterproposal to Shawn's lockfile fix in
'pu', waiting for comments.
On the 'master' front, I've merged Andy's xwrite() loop. I
think this is applicable to many other places after generalizing
it a bit more and perhaps merging it with safe_write in
pkt-line.c.
builtin-apply.c, builtin-unpack-objects.c, copy.c, csum-file.c,
index-pack.c, merge-recursive.c and pkt-line.c have
implementations of something very similar, with different policy
on error handling.
Also index-pack.c and upload-pack.c (in the status reporting
code path) also has unprotected xwrite() that can result in
short write.
Have fun.
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Marco Costalba @ 2007-01-03 10:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <8c5c35580701030221w5c04e2eaq757d12c4ca0b0780@mail.gmail.com>
On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
> On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
> > - one blank line
> > - zero or one line with log title
> > - zero or more lines with log message
> > - a terminating '\0'
>
> I think the should be:
> -zero or more blank lines
Isn't it zero or _one_ blank line? Why more then one? would be it
useful? surely is slower to parse.
> -zero or more non-blank lines with log title
multi lines titles are allowed? never saw one of them.
> -zero or more blank lines
Why? this is necessary only to disambiguate muti (non blank) lines
titles, but as Junio pointed out distinction between log title and log
message is only in the Porcelain, not encoded in git. So the Porcalain
is going to show _one_line title if any an the remaining stuff in the
log message.
> -zero or more lines with log message
> -a terminating '\0'
>
Marco
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Lars Hjemli @ 2007-01-03 10:38 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <8c5c35580701030221w5c04e2eaq757d12c4ca0b0780@mail.gmail.com>
On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
> commit ::= header [blank+ [title+ [blank+ text*]]] '\0'
> header ::= tree parent* author committer
Sorry, this should have been
commit ::= header [blank+ [title+ [blank+ text*]]] '\0'
header ::= tree parent* author committer other_header*
--
larsh
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Jeff King @ 2007-01-03 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7virfprquo.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 02, 2007 at 02:44:31PM -0800, Junio C Hamano wrote:
> necessarily a better option of the two. We could allow commits
> and prevent the user from switching out of the detached HEAD
> state without an explicit action instead. If we go the first
I think you should only enact this safety valve if there have actually
been commits. Otherwise, people who are just tracking and do a
"git-checkout v1.4.0; look look look; git-checkout v1.5.0" will get a
confusing message.
Personally, I like the "don't allow commit without a branch" approach,
but only if you can "git-commit -b newbranch" and "git-merge -b
newbranch" to make it convenient to create a branch. Making commits that
aren't on any branch seems like a broken state (and indeed, you have to
use special options to get out of the state); it makes more sense to me
to never enter the state in the first place.
Also, the implementation should be conceptually simple. Put
refs/tags/v1.4.0 into HEAD on checkout. Disallow commit/merge unless
HEAD points to refs/heads/*.
Just my 2 cents...
-Peff
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Lars Hjemli @ 2007-01-03 11:14 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <e5bfff550701030235g6f26044h8dd73e8abe1ec9e3@mail.gmail.com>
On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
> > > - one blank line
> > > - zero or one line with log title
> > > - zero or more lines with log message
> > > - a terminating '\0'
> >
> > I think the should be:
> > -zero or more blank lines
>
> Isn't it zero or _one_ blank line? Why more then one? would be it
> useful? surely is slower to parse.
My point is just that the log message is unformatted. There is nothing
stopping you from
adding blank lines at the start of the message.
But then I tested it, and it seems as 'git-commit' strips off any
leading blank lines (but git-commit-tree does not). So expecting one
blank _might_ be good enough.
>
> > -zero or more non-blank lines with log title
>
> multi lines titles are allowed? never saw one of them.
It is allowed (I tested this)
>
> > -zero or more blank lines
>
> Why? this is necessary only to disambiguate muti (non blank) lines
> titles, but as Junio pointed out distinction between log title and log
> message is only in the Porcelain, not encoded in git. So the Porcalain
> is going to show _one_line title if any an the remaining stuff in the
> log message.
Well, if the porcelain chooses to do so, it probably is ok. But I
think the parsing/presentation of the log title/message would be more
correct/better formatted if the parser is more "adaptive" to the
content.
--
larsh
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Jeff King @ 2007-01-03 11:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <20070103104620.GA27015@coredump.intra.peff.net>
On Wed, Jan 03, 2007 at 05:46:20AM -0500, Jeff King wrote:
> Also, the implementation should be conceptually simple. Put
> refs/tags/v1.4.0 into HEAD on checkout. Disallow commit/merge unless
> HEAD points to refs/heads/*.
Let me take that back. It is actually still annoying to implement, since
many things (at least commit-tree, branch) are unhappy with a non-branch
in HEAD. Moreover, it's not as flexible as simply putting the commit
sha1 into the HEAD, as you suggested. My suggestion allows only
non-branch refs to be checked-out; however, it's likely somebody might
want to git-checkout HEAD~10 or some other unnamed thing.
-Peff
^ permalink raw reply
* [PATCH] git-tag: add flag to verify a tag
From: Santi Béjar @ 2007-01-03 12:59 UTC (permalink / raw)
To: Git Mailing List
This way "git tag -v $tag" is the UI for git-verify-tag.
---
Documentation/git-tag.txt | 7 ++++++-
generate-cmdlist.sh | 1 -
git-tag.sh | 10 +++++++++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 48b82b8..80bece0 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,7 @@ git-tag - Create a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg> | -F <file>]
+'git-tag' [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg> | -F <file>]
<name> [<head>]
'git-tag' -l [<pattern>]
@@ -35,6 +35,8 @@ GnuPG key for signing.
`-d <tag>` deletes the tag.
+`-v <tag>` verifies the gpg signature of the tag.
+
`-l <pattern>` lists tags that match the given pattern (or all
if no pattern is given).
@@ -55,6 +57,9 @@ OPTIONS
-d::
Delete an existing tag with the given name
+-v::
+ Verify the gpg signature of given the tag
+
-l <pattern>::
List tags that match the given pattern (or all if no pattern is given).
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 06c42b0..1de14ea 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -37,7 +37,6 @@ show
show-branch
status
tag
-verify-tag
EOF
while read cmd
do
diff --git a/git-tag.sh b/git-tag.sh
index e1bfa82..c9e1180 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2005 Linus Torvalds
-USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
+USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -12,6 +12,7 @@ force=
message=
username=
list=
+verify=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -69,6 +70,13 @@ do
echo "Deleted tag $tag_name."
exit $?
;;
+ -v)
+ shift
+ tag_name="$1"
+ tag=$(git-show-ref --verify --hash -- "refs/tags/$tag_name") ||
+ die "Seriously, what tag are you talking about?"
+ git-verify-tag -v "$tag"
+ exit $?
-*)
usage
;;
--
1.5.0.rc0.g91ea
^ permalink raw reply related
* [PATCH/RFC] tutorial.txt: update to use the "git clone --add"
From: Santi Béjar @ 2007-01-03 12:57 UTC (permalink / raw)
To: Git Mailing List
---
This is a RFC because there is not such "git clone --add".
I think it make sense to have it and to use it in the tutorial. This
way all the branches are in the separate-layout, so newbies only have
to understand one layout.
Comments?
Documentation/tutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index f0a5526..637d9d7 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -271,10 +271,12 @@ at /home/bob/myrepo. She does this with:
------------------------------------------------
$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+$ git clone --add bob /home/bob/myrepo
+$ git pull bob master
------------------------------------------------
-This merges the changes from Bob's "master" branch into Alice's
+First it clones the Bob's repository with the name "bob" and
+then it merges the changes from Bob's "master" branch into Alice's
current branch. If Alice has made her own changes in the meantime,
then she may need to manually fix any conflicts. (Note that the
"master" argument in the above command is actually unnecessary, as it
@@ -284,18 +286,16 @@ The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
You can perform the first operation alone using the "git fetch"
-command. For example, Alice could create a temporary branch just to
-track Bob's changes, without merging them with her own, using:
+command without merging them with her own branch, using:
-------------------------------------
-$ git fetch /home/bob/myrepo master:bob-incoming
+$ git fetch bob
-------------------------------------
-which fetches the changes from Bob's master branch into a new branch
-named bob-incoming. Then
+which fetches the changes from Bob's branches. Then
-------------------------------------
-$ git log -p master..bob-incoming
+$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -306,21 +306,21 @@ could pull the changes into her master branch:
-------------------------------------
$ git checkout master
-$ git pull . bob-incoming
+$ git pull . bob/master
-------------------------------------
-The last command is a pull from the "bob-incoming" branch in Alice's
+The last command is a pull from the "bob/master" branch in Alice's
own repository.
Alice could also perform both steps at once with:
-------------------------------------
-$ git pull /home/bob/myrepo master:bob-incoming
+$ git pull bob
-------------------------------------
-This is just like the "git pull /home/bob/myrepo master" that we saw
+This is just like the "git pull bob master" that we saw
before, except that it also stores the unmerged changes from bob's
-master branch in bob-incoming before merging them into Alice's
+master branch in bob/master before merging them into Alice's
current branch. Note that git pull always merges into the current
branch, regardless of what else is given on the commandline.
--
1.5.0.rc0.g91ea
^ permalink raw reply related
* [PATCH] Documentation/tutorial: misc updates
From: Santi Béjar @ 2007-01-03 12:53 UTC (permalink / raw)
To: Git Mailing List
Three changes:
1) Teach how to delete a branch with "git branch -d name".
2) The first commit does not have a parent.
3) Teach "git show" instead of "git cat-file -p".
---
Documentation/tutorial.txt | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index d043e84..f0a5526 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -222,6 +222,15 @@ $ gitk
will show a nice graphical representation of the resulting history.
+At this point you could delete the experimental branch with
+
+------------------------------------------------
+$ git branch -d experimental
+------------------------------------------------
+
+This command ensures that the changes in the experimental branch are
+already in the current branch.
+
If you develop on a branch crazy-idea, then regret it, you can always
delete the branch with
@@ -391,8 +400,8 @@ $ git show HEAD # the tip of the current branch
$ git show experimental # the tip of the "experimental" branch
-------------------------------------
-Every commit has at least one "parent" commit, which points to the
-previous state of the project:
+Every commit has at least one "parent" commit (except the first),
+which points to the previous state of the project:
-------------------------------------
$ git show HEAD^ # to see the parent of HEAD
@@ -510,10 +519,10 @@ of the file:
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use "git cat-file -p" to see any such file:
+You can also use "git show" to see any such file:
-------------------------------------
-$ git cat-file -p v2.5:Makefile
+$ git show v2.5:Makefile
-------------------------------------
Next Steps
--
1.5.0.rc0.g91ea
^ permalink raw reply related
* HTTP access via proxy
From: Guilhem Bonnefille @ 2007-01-03 13:05 UTC (permalink / raw)
To: git
Hi,
I'm new to GIT. I've just discovered it recenntly, I found it powerfull.
Actually, I'm trying to "connect" to GIT repositories from office.
There is a proxy. I set the http_proxy varenv. But the cloning failed.
Seems to be a 407 error, but I do not understand what to do. Any help
is welcome.
Here is the output:
$ git-clone http://repo.or.cz/r/cogito.git
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting pack list for http://repo.or.cz/r/cogito.git/
Getting index for pack 605b6b3b97cd6a8725f9be2c858812646de69340
Getting index for pack fbfa016d2f36e7317c82ccae9ba84f98ee23c232
Getting index for pack 3e83e7bd975592d35f507a83d9d72b8f6fa2f90c
Getting index for pack 3718e548f38e28d2b5c0fa845ecde4fa8011097f
Getting index for pack 2ca93e541574382d920bb2310d774e1c4ce3f097
Getting index for pack ec503789c27cc660192d567defd4d4620e5ff433
Getting index for pack be4d257c2efb91623aeb6031689f348aa897cfd6
Getting index for pack b8d235df7313ca48648dedea9fd059d7fe0fc440
Getting index for pack 05ee5f60265a8cf543e5a42c04af0f7dacdf7ce3
Getting index for pack a33f5335e33bb274e7c838fc0dc6deec5713ca3f
Getting index for pack 8530b481a7f02b3d09fe00c6b6afedc658933dc1
Getting index for pack 4b7808cea29f690eaa10aacff9eac93a38b5ddd3
Getting index for pack f8c8b06fec5010796ce83d3809d022e8e2ac1c16
Getting index for pack 7ddc7c3ff0dc06aefe42ad477ba3be48a54b6c48
Getting index for pack f3e337782d2bf95568a7bd96866c4bdffb2f183f
Getting index for pack 298348359dbe6956c697261eb88b47d9e6c6666e
Getting index for pack 57964c548d649be865d283d6ab3ca10bf302f082
Getting index for pack 78202a8501eff4614d7bb1972902a6c880bb2002
Getting index for pack 51412f3fc46ba6059457a5890369895a96a6b427
Getting index for pack 9b452ef8de67af41587ebb196ca4518280ba1795
Getting index for pack 56df4494fdb935bb2f8de3388c901be086cf9bd7
Getting index for pack cd046245115aa0b088f1b53bba2e68e0000b1c54
Getting index for pack bdf83dd134bd89eca9431f0d6b7601e32d516ae9
Getting index for pack 48baac389492f0071f8713547371eaae5507868d
Getting index for pack 8b4c56b9f2e0d9586b10c24ef87b933f8d3c0d72
Getting index for pack 49e12d13de0cb60255b343c59eeaf61b168fa0de
Getting index for pack 9af7de2760000428a9bb60ea5afc150bb8a60fb8
Getting pack 9af7de2760000428a9bb60ea5afc150bb8a60fb8
which contains b6a6e87cb3e1368ad0f78c18fdb6c29dde4ae83e
walk b6a6e87cb3e1368ad0f78c18fdb6c29dde4ae83e
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting alternates list for http://repo.or.cz/r/cogito.git/
Getting pack 49e12d13de0cb60255b343c59eeaf61b168fa0de
which contains 18d0bd75adae8c1994373e8e5afdb388268c048c
error: Unable to get pack file
http://repo.or.cz/r/cogito.git//objects/pack/pack-49e12d13de0cb60255b343c59eeaf61b168fa0de.pack
The requested URL returned error: 407
Getting alternates list for http://repo.or.cz/r/cogito.git/
error: Unable to find 18d0bd75adae8c1994373e8e5afdb388268c048c under
http://repo.or.cz/r/cogito.git/
Cannot obtain needed commit 18d0bd75adae8c1994373e8e5afdb388268c048c
while processing commit b6a6e87cb3e1368ad0f78c18fdb6c29dde4ae83e.
Waiting for http://repo.or.cz/r/cogito.git/objects/c2/8d9943e5d8a51088266db92030480602c35fc1
Surprisingly, if I download the pack file directly with curl, it works:
curl http://repo.or.cz/r/cogito.git//objects/pack/pack-49e12d13de0cb60255b343c59eeaf61b168fa0de.pack
I'm using:
- a freshly downloaded GIT tarball.
- curl-7.12.1-5.rhel4
- curl-devel-7.12.1-5.rhel4
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: [PATCH] git-reset --hard: tell the user what the HEAD was reset to
From: Andy Whitcroft @ 2007-01-03 13:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <Pine.LNX.4.63.0612211525070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> ---
>
> On Wed, 20 Dec 2006, Han-Wen Nienhuys wrote:
>
> > It would be nice if git-reset printed
> >
> > HEAD is now <sha1> - <excerpt of commit message>
>
> This patch does that, but only for --reset.
>
> Without reset, HEAD is _not_ changed, just the contents of the
> working directory and/or the index.
>
> git-reset.sh | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/git-reset.sh b/git-reset.sh
> index 8d95e37..2379db0 100755
> --- a/git-reset.sh
> +++ b/git-reset.sh
> @@ -86,7 +86,12 @@ update_ref_status=$?
>
> case "$reset_type" in
> --hard )
> - ;; # Nothing else to do
> + test $update_ref_status = 0 && {
> + echo -n "HEAD is now at "
> + GIT_PAGER= git log --max-count=1 --pretty=oneline \
> + --abbrev-commit HEAD
> + }
> + ;;
> --soft )
> ;; # Nothing else to do
> --mixed )
Ok, this sounds like a good change in principle, but the output format
it introduces seems likely to cause confusion. For sure the first
couple of times I saw it I though there was a bug and I was seeing an
error from the plumbing. See below for an example where you would swear
something bad had occured.
apw@pinky$ git checkout -b bar master
apw@pinky$ git reset --hard ac9c1108d8915f0937795e354ad72c4ae6890a3f
HEAD is now at ac9c110... git-fetch: remove .keep file at the end.
Huh, fetch? Remove what .keep file? Did I do a fetch? What?
I think we need to delimit the name better, probabally we need to quote
it. Perhaps something like:
HEAD is now at ac9c110: "git-fetch: remove .keep file at the end".
-apw
^ permalink raw reply
* [PATCH] Skip excessive blank lines before commit body
From: Lars Hjemli @ 2007-01-03 13:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This modifies pretty_print_commit() to make the output of git-rev-list and
friends a bit more predictable.
A commit body starting with blank lines might be unheard-of, but still possible
to create using git-commit-tree (so is bound to appear somewhere, sometime).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
commit.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/commit.c b/commit.c
index 544e426..2a58175 100644
--- a/commit.c
+++ b/commit.c
@@ -703,7 +703,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
const char *after_subject,
int relative_date)
{
- int hdr = 1, body = 0;
+ int hdr = 1, body = 0, seen_title = 0;
unsigned long offset = 0;
int indent = 4;
int parents_shown = 0;
@@ -809,6 +809,8 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
body = 1;
if (is_empty_line(line, &linelen)) {
+ if (!seen_title)
+ continue;
if (!body)
continue;
if (subject)
@@ -817,6 +819,7 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,
break;
}
+ seen_title = 1;
if (subject) {
int slen = strlen(subject);
memcpy(buf + offset, subject, slen);
--
1.5.0.rc0.ge900
^ permalink raw reply related
* Re: [PATCH] Documentation/tutorial: misc updates
From: Horst H. von Brand @ 2007-01-03 13:50 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <87fyastgoo.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> wrote:
> Three changes:
> 1) Teach how to delete a branch with "git branch -d name".
> 2) The first commit does not have a parent.
> 3) Teach "git show" instead of "git cat-file -p".
> ---
> Documentation/tutorial.txt | 17 +++++++++++++----
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
> index d043e84..f0a5526 100644
> --- a/Documentation/tutorial.txt
> +++ b/Documentation/tutorial.txt
> @@ -222,6 +222,15 @@ $ gitk
>
> will show a nice graphical representation of the resulting history.
>
> +At this point you could delete the experimental branch with
> +
> +------------------------------------------------
> +$ git branch -d experimental
> +------------------------------------------------
> +
> +This command ensures that the changes in the experimental branch are
> +already in the current branch.
> +
Huh? This deletes the branch, it doesn't ensure changes have been saved.
> If you develop on a branch crazy-idea, then regret it, you can always
> delete the branch with
>
> @@ -391,8 +400,8 @@ $ git show HEAD # the tip of the current branch
> $ git show experimental # the tip of the "experimental" branch
> -------------------------------------
>
> -Every commit has at least one "parent" commit, which points to the
> -previous state of the project:
> +Every commit has at least one "parent" commit (except the first),
> +which points to the previous state of the project:
And how can it have more than one parent? If you mention it, better come
clean about merges (can be explained in detail later).
> -------------------------------------
> $ git show HEAD^ # to see the parent of HEAD
And if there are several parents?
> @@ -510,10 +519,10 @@ of the file:
> $ git diff v2.5:Makefile HEAD:Makefile.in
> -------------------------------------
HEAD:Makefile.in doesn't need HEAD.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Andreas Ericsson @ 2007-01-03 13:55 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Randal L. Schwartz, Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <46a038f90612181502y3e2a41cds7f16113ad0270f31@mail.gmail.com>
Martin Langhoff wrote:
>
> Once you are packed it's sweet, but large repos are a pain to deal
> with. You won't impress anyone with performance over a linux kernel
> repo -- starting up gitk can take a long time.
I'd suggest running qgit instead, and make sure you've run it once on
the repo you're demoing. qgit has a nice little cache where it tucks
away most of the data it uses, which makes it draw things a lot faster.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Documentation/tutorial: misc updates
From: Jakub Narebski @ 2007-01-03 14:07 UTC (permalink / raw)
To: git
In-Reply-To: <200701031350.l03Doulu015800@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
>> +------------------------------------------------
>> +$ git branch -d experimental
>> +------------------------------------------------
>> +
>> +This command ensures that the changes in the experimental branch are
>> +already in the current branch.
>> +
>
> Huh? This deletes the branch, it doesn't ensure changes have been saved.
It ensures that the branch we want to delete is in lineage of
current branch (otherwise we would have to use -D).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/tutorial: misc updates
From: Santi Béjar @ 2007-01-03 14:09 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Git Mailing List
In-Reply-To: <200701031350.l03Doulu015800@laptop13.inf.utfsm.cl>
On 1/3/07, Horst H. von Brand <vonbrand@inf.utfsm.cl> wrote:
> Santi Béjar <sbejar@gmail.com> wrote:
> > Three changes:
> > 1) Teach how to delete a branch with "git branch -d name".
> > 2) The first commit does not have a parent.
> > 3) Teach "git show" instead of "git cat-file -p".
> > ---
> > Documentation/tutorial.txt | 17 +++++++++++++----
> > 1 files changed, 13 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
> > index d043e84..f0a5526 100644
> > --- a/Documentation/tutorial.txt
> > +++ b/Documentation/tutorial.txt
> > @@ -222,6 +222,15 @@ $ gitk
> >
> > will show a nice graphical representation of the resulting history.
> >
> > +At this point you could delete the experimental branch with
> > +
> > +------------------------------------------------
> > +$ git branch -d experimental
> > +------------------------------------------------
> > +
> > +This command ensures that the changes in the experimental branch are
> > +already in the current branch.
> > +
>
> Huh? This deletes the branch, it doesn't ensure changes have been saved.
It deletes the branch only if the current branch is fast-forwarding it.
Could be rephrase as:
This command only delete the experimental branch if it is already
merge in the current branch.
>
> > If you develop on a branch crazy-idea, then regret it, you can always
> > delete the branch with
> >
> > @@ -391,8 +400,8 @@ $ git show HEAD # the tip of the current branch
> > $ git show experimental # the tip of the "experimental" branch
> > -------------------------------------
> >
> > -Every commit has at least one "parent" commit, which points to the
> > -previous state of the project:
> > +Every commit has at least one "parent" commit (except the first),
> > +which points to the previous state of the project:
>
> And how can it have more than one parent? If you mention it, better come
> clean about merges (can be explained in detail later).
I have not mentined it, I've just added the exception that the
firt/root commits have zero parents.
>
> > -------------------------------------
> > $ git show HEAD^ # to see the parent of HEAD
>
> And if there are several parents?
Already explained before.
>
> > @@ -510,10 +519,10 @@ of the file:
> > $ git diff v2.5:Makefile HEAD:Makefile.in
> > -------------------------------------
>
> HEAD:Makefile.in doesn't need HEAD.
Not needed if the Makefile.in in the working directory is equal to the
file in HEAD.
But better explain new things.
Santi
^ permalink raw reply
* [PATCH] gitweb: Fix error in git_project_index subroutine
From: Jakub Narebski @ 2007-01-03 15:03 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Instead of "$projectroot/$pr->{'path'}" to get the path to project
GIT_DIR, it was used "$projectroot/$project" which is valid only
for actions where project parameter is set, and 'project_index' is not
one of them.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d845e91..7f54834 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2995,7 +2995,7 @@ sub git_project_index {
foreach my $pr (@projects) {
if (!exists $pr->{'owner'}) {
- $pr->{'owner'} = get_file_owner("$projectroot/$project");
+ $pr->{'owner'} = get_file_owner("$projectroot/$pr->{'path'}");
}
my ($path, $owner) = ($pr->{'path'}, $pr->{'owner'});
--
1.4.4.3
^ permalink raw reply related
* Re: [BUG] daemon.c blows up on OSX
From: Andreas Ericsson @ 2007-01-03 15:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Terje Sten Bjerkseth, Linus Torvalds, git
In-Reply-To: <7vtzzq3wo6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Does everybody use Apple CC on OSX? Is the symbol defined even
> with GCC? Or Gcc fixes headers well enough and makes this a
> non-issue?
>
Just for future reference
http://predef.sourceforge.net/preos.html
holds a pretty complete list of identifying macros for more kinds of
systems than I've had the questionable privilege of having to work with.
I've used it pretty extensively when trying to write portable code,
since I too have a hard time liking autoconf and friends.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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