* Re: fix t5000-tar-tree.sh when $TAR isn't set
From: Alex Riesen @ 2005-11-08 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0511081250020.2649@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/8/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > $TAR isn't set everywhere. Provide a default (tar)
>
> You run "sh t5000*" in t/, right? Usually, TAR is set in t/Makefile (that
> is why it Just Works in the normal case). Note that you can -- instead of
> your patch -- run "TAR=tar sh t5000*".
Oh, I see... I did "make -C t" to avoid recompilation tests (this is
unbearably slow on the system Not To Be Named). Maybe put such
variables in the separate makefile and include it?
^ permalink raw reply
* git-pull.sh's bad mode
From: Jon Loeliger @ 2005-11-08 14:19 UTC (permalink / raw)
To: git
Public apology and brown paper bag. My patch
accidentally twiddled the mode on git-pull.sh:
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Documentation/git-pull.txt | 17 +++++++----------
Documentation/merge-options.txt | 16 ++++++++++++++++
Documentation/merge-pull-opts.txt | 14 --------------
git-format-patch.sh | 4 ++++
git-pull.sh | 12 +++++++++++-
9 files changed, 70 insertions(+), 48 deletions(-)
create mode 100644 Documentation/fetch-options.txt
create mode 100644 Documentation/merge-options.txt
delete mode 100644 Documentation/merge-pull-opts.txt
mode change 100755 => 100644 git-pull.sh
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Petr Baudis @ 2005-11-08 12:04 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511081150.10867.Josef.Weidendorfer@gmx.de>
Dear diary, on Tue, Nov 08, 2005 at 11:50:10AM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> On Monday 07 November 2005 23:56, Petr Baudis wrote:
> > Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
> > where Petr Baudis <pasky@suse.cz> told me that...
> > > That said, with a big warning, I would be willing to do something like
> > > cg-merge -s and cg-update -s (s as squash)
> > ...
> > FWIW, cg-merge -s and cg-update -s is supported now.
>
> The -s option of git merge is about choosing a strategy.
> How can I choose the "recursive" strategy with cg-merge?
> Some consistency would be good here.
Good point. You can't now, but you should be able to in the future.
I renamed this from -s to --squash.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git-daemon enabled on kernel.org
From: Johannes Schindelin @ 2005-11-08 12:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20051107231157.GX1431@pasky.or.cz>
Hi,
On Tue, 8 Nov 2005, Petr Baudis wrote:
> Dear diary, on Tue, Oct 18, 2005 at 09:30:23PM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
> > I consider this experimental so far, and if it imposes an unacceptable
> > load I'll have to disable it. It currently runs with an inetd-imposed
> > limits of 10 instances per server.
>
> I'm curious - how well does it do wrt. the load so far? Do you have any
> statistics about the number of users and how CPU-intensive is it?
I have a simple statistics to contribute out of my head. A while ago (when
people complained about gitweb.cgi taking too much load), a simple pull
where my local repo was up-to-date took about 4 seconds. Now it takes just
1 second.
I choose to believe that this is a sign of not too much load.
Ciao,
Dscho
^ permalink raw reply
* Re: Comments on recursive merge..
From: Johannes Schindelin @ 2005-11-08 11:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.64.0511071629270.3247@g5.osdl.org>
Hi,
On Mon, 7 Nov 2005, Linus Torvalds wrote:
> Is the recursive thing noticeably slower for the "easy" cases (ie things
> that the old regular resolve strategy does well)?
IIRC recursive does nothing else than recursively merging the merge-bases
(granted, in a clever way). So if there is only one merge-base, the only
slow-down would be the startup of python (which is probably worth it,
anyway).
> It's certainly an option to just do what I just did, namely use the
> default one until it breaks, and then just do "git reset --hard" and re-do
> the pull with "-s recursive". A bit sad, and it would be good to have
> coverage on the recursive strategy..
We already have a fallback list: after really-trivial, try automatic, ...,
try resolve. Why not just add recursive? So, if even resolve failed, just
try once more, with recursive.
Ciao,
Dscho
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Johannes Schindelin @ 2005-11-08 11:54 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nick Hengeveld, Git Mailing List
In-Reply-To: <46a038f90511071837g474bdc44vf60dd0758511f24c@mail.gmail.com>
Hi,
On Tue, 8 Nov 2005, Martin Langhoff wrote:
> On 11/8/05, Nick Hengeveld <nickh@reactrix.com> wrote:
>
> > You might try this to see exactly what request/response headers
> > curl thinks are passing back and forth.
>
> It definitely looks like it's doing a few requests in parallel and
> getting them mixed up. BTW, this repo is public and sitting on a box
> that doubles up as kernel mirror -- feel free to hit it ;-)
It could be a similar problem to what I experienced in http-push:
Uninintialized memory due to the code path. Can you run
valgrind --leak-check=yes --show-reachable=yes git-http-fetch...
and check for jump depending on uninitialized memory?
Hth,
Dscho
^ permalink raw reply
* Re: fix t5000-tar-tree.sh when $TAR isn't set
From: Johannes Schindelin @ 2005-11-08 11:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0511080245m12ed5fe0ha0ed98ca25e2f6e9@mail.gmail.com>
Hi,
On Tue, 8 Nov 2005, Alex Riesen wrote:
> $TAR isn't set everywhere. Provide a default (tar)
You run "sh t5000*" in t/, right? Usually, TAR is set in t/Makefile (that
is why it Just Works in the normal case). Note that you can -- instead of
your patch -- run "TAR=tar sh t5000*".
Ciao,
Dscho
^ permalink raw reply
* Re: git versus CVS (versus bk)
From: Josef Weidendorfer @ 2005-11-08 10:50 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20051107225652.GW1431@pasky.or.cz>
On Monday 07 November 2005 23:56, Petr Baudis wrote:
> Dear diary, on Tue, Nov 01, 2005 at 10:15:33AM CET, I got a letter
> where Petr Baudis <pasky@suse.cz> told me that...
> > That said, with a big warning, I would be willing to do something like
> > cg-merge -s and cg-update -s (s as squash)
> ...
> FWIW, cg-merge -s and cg-update -s is supported now.
The -s option of git merge is about choosing a strategy.
How can I choose the "recursive" strategy with cg-merge?
Some consistency would be good here.
Josef
^ permalink raw reply
* fix t5000-tar-tree.sh when $TAR isn't set
From: Alex Riesen @ 2005-11-08 10:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
$TAR isn't set everywhere. Provide a default (tar)
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5000-tar-tree.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[-- Attachment #2: TAR-not-set.patch --]
[-- Type: application/xxxxx, Size: 237 bytes --]
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Ben Clifford @ 2005-11-08 10:16 UTC (permalink / raw)
To: Blaisorblade, git
In-Reply-To: <200510251642.46169.blaisorblade@yahoo.it>
> I'm using stgit on the Linux kernel so when on a command I don't
> have tab
> completion I add the needed one (having the time and feeling to do
> it).
>
> However, it's still done with enough care and polish to be shippable.
>
>
I've added some stuff to this to do a few cogito, gitk and (one) git
completions, split into different files. I thought I might as well
toss what I have out for anyone interested to play with.
I tried to put it in a new git repo online, but I'm having
difficulties - the poor link I'm on makes it not so much fun to
experiment. So I've tarred up my local repo warts and all and put it at:
http://www.hawaga.org.uk/ben/tech/gitcompletion-
a108bdc110dad770ec5c092759a8bc511790d21f.tar
Ben
--
Ben Clifford
http://www.hawaga.org.uk/ben/
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-08 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vwtjjllw4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Nov 08, 2005 at 07:00:11AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Nobody complained so far about this, probably because two side
> adding different versions is rare enough. And the reasoning
> behind the current behaviour is probably because the tool cannot
> automerge them sensibly anyway. Leaving the SHA1 in index file
> might probably be easier to clean up by hand (e.g. see ls-files
> --unmerged, and cut&paste the desired SHA1 to 'git-cat-file
> blob' command line, or something silly like that). But if we
> were to go that route, adding --stage=[123] flag so that the
> user can say 'git-checkout-index --stage=3 file3'might have
> helped a bit more.
#
# Added in both (different in each).
#
".$id1$id2")
#echo "Adding $file"
filev="$file"
while [ -e "$filev~1" ] || [ -e "$filev~2" ]; do
filev="$filev~"
done
error "File $file added in both branches, but different in each!"
error "Conflicting versions saved as '$filev~1' and '$filev~2'."
git-update-index --add --cacheinfo "$mode1" "$id1" "$file" &&
git-checkout-index -u -f -- "$file" &&
mv "$file" "$filev~1" ||
error "Cannot create '$filev~1'"
git-update-index --add --cacheinfo "$mode2" "$id2" "$file" &&
git-checkout-index -u -f -- "$file" &&
mv "$file" "$filev~2" ||
error "Cannot create '$filev~2'"
exit 1
;;
is what Cogito's automerger does. It ain't very pretty, but it works.
:-) (At least it seems to.) I yet need to add some conflicts tracking to
Cogito to prevent accidental checking in of conflicts.
> We could instead use the attached patch to get the behaviour you
> are expecting. I have a feeling that the result from this might
> be a little more intuitive and easier to resolve by hand than
> the current one. Although we may end up unresolvable mess in
> file3 if either side is binary, in that case the user can still
> sift through 'diff-tree A B file3' output to find out the
> relevant SHA1 to recover the blobs from both sides by hand
> anyway. Does anybody have strong opinion on this?
I think having
<<<<<
file1
=====
file2
>>>>>
is an awful PITA to resolve, especially when the files actually are
similar. Running some vimdiff (or just diff and possibly applying either
way) on two separate files is much more convenient.
--
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
* make tests ignorable with "make -i"
From: Alex Riesen @ 2005-11-08 9:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Allow failed tests to be ignored using make's "-i". The patch also
disables parallel make in t/. This doesn't make the testing any
different as before: the tests were run sequentially before.
It also allows to run more tests, ignoring the ones usually failing
just to figure out if something else broke. (Or to ignore plainly
uninteresting situations because of the testing being done on say...
cygwin ;)
---
How about hiding "ok ..." output?
[-- Attachment #2: make-tests-ignorable.patch --]
[-- Type: application/xxxxx, Size: 491 bytes --]
^ permalink raw reply
* [PATCH] Make the templates building a bit more silent
From: Petr Baudis @ 2005-11-08 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The 'all' target in templates/Makefile contained 'find blt', which is
extremely annoying since it dumps all the files to stdout everytime,
cluttering the output and making the build of whole GIT a lot more noisy.
My guess is that it is some debugging leftover, actually.
This patch kills it.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
templates/Makefile | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/templates/Makefile b/templates/Makefile
index 07e928e..8f7f4fe 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -13,7 +13,6 @@ shq = $(subst ','\'',$(1))
shellquote = '$(call shq,$(1))'
all: boilerplates.made custom
- find blt
# Put templates that can be copied straight from the source
# in a file direc--tory--file in the source. They will be
^ permalink raw reply related
* Re: ls-files and read-tree need core.filemode
From: Alex Riesen @ 2005-11-08 9:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacgfldry.fsf@assigned-by-dhcp.cox.net>
On 11/8/05, Junio C Hamano <junkio@cox.net> wrote:
> However, please note that git-mailinfo which splits a piece of
> e-mail into metainformation and patch part takes commit log
> material only from the main message part, so having this
> one-line explanation inside attachment is like having it under
> the three-dash line.
Noted, thanks!
> >>diff --git a/ls-files.c b/ls-files.c
> >>--- a/ls-files.c
> >>+++ b/ls-files.c
> >>@@ -569,10 +569,11 @@ int main(int argc, const char **argv)
> >> argv0 = *argv;
>
> I wonder what this thing is, though. I sense that usage()
> cleanup patch that makes programs state their names
> semi-automatically is coming...
>
That's just me, trying to figure out were all the errors were coming from.
Promise to try to base patches properly in the future.
^ permalink raw reply
* Re: Notes on http-push
From: Junio C Hamano @ 2005-11-08 8:59 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051108084620.GA5830@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> In the interest of testing push against another DAV server
> implementation, I tried using Subversion's Apache DAV/DeltaV module.
> It works if you enable autoversioning and authentication, which makes
> for a slightly different minimal Apache setup:
>...
> While it's kind of useless to place immutable objects under version
> control, it is sort of an interesting side effect that all the meta
> files will have a history.
Pushing git commit history into SVN server --- this must be a
sick joke ;-). Can you pull over http from there?
But seriously, it is good that you are trying out talking with
different servers. Thanks.
I'm planning to push out the final bit to make git-push aware of
http-push tonight or tomorrow.
^ permalink raw reply
* Re: ls-files and read-tree need core.filemode
From: Junio C Hamano @ 2005-11-08 8:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511080023k1384dc26j944e9a07987be436@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> As usual, sorry for attachments.
Attachments are a bit cumbersome to quote but otherwise OK, at
least for me. Linus never admits it, but I am hoping that he is
having a bit easier time applying e-mailed patches ever since
rudimentally MIME attachment handling was added.
However, please note that git-mailinfo which splits a piece of
e-mail into metainformation and patch part takes commit log
material only from the main message part, so having this
one-line explanation inside attachment is like having it under
the three-dash line.
>> ls-files needs default config to ignore filemode on cygwin
I think this case you meant to do that; your main message part
was almost fine as is, as a commit log message (except perhaps
the initial "Hi," part ;-).
>>diff --git a/ls-files.c b/ls-files.c
>>--- a/ls-files.c
>>+++ b/ls-files.c
>>@@ -569,10 +569,11 @@ int main(int argc, const char **argv)
>> argv0 = *argv;
I wonder what this thing is, though. I sense that usage()
cleanup patch that makes programs state their names
semi-automatically is coming...
^ permalink raw reply
* Re: Notes on http-push
From: Nick Hengeveld @ 2005-11-08 8:46 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 want to play with it yourself: A minimal setup using Apache needs
> something like this in httpd.conf:
In the interest of testing push against another DAV server
implementation, I tried using Subversion's Apache DAV/DeltaV module.
It works if you enable autoversioning and authentication, which makes
for a slightly different minimal Apache setup:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
<Location /svn>
DAV svn
SVNPath /path/to/svn/repo
SVNAutoversioning on
AuthName "Subversion Repo"
AuthType Basic
AuthUserFile ....
AuthGroupFile ....
<LimitExcept GET>
require ....
</LimitExcept>
</Location>
While it's kind of useless to place immutable objects under version
control, it is sort of an interesting side effect that all the meta
files will have a history.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* ls-files and read-tree need core.filemode
From: Alex Riesen @ 2005-11-08 8:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
Hi,
ls-files.c and read-tree.c miss the default configuration, in
particular the filemode=false part.
The recent +x bit flip made me notice that, because git-merge refused
to merge anything saying that git-pull.sh is not up to date.
As usual, sorry for attachments.
[-- Attachment #2: ls-files-filemode.patch --]
[-- Type: application/xxxxx, Size: 426 bytes --]
[-- Attachment #3: read-tree-filemode.patch --]
[-- Type: application/xxxxx, Size: 452 bytes --]
^ permalink raw reply
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Nick Hengeveld @ 2005-11-08 6:31 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511071837g474bdc44vf60dd0758511f24c@mail.gmail.com>
On Tue, Nov 08, 2005 at 03:37:29PM +1300, Martin Langhoff wrote:
> It definitely looks like it's doing a few requests in parallel and
> getting them mixed up. BTW, this repo is public and sitting on a box
> that doubles up as kernel mirror -- feel free to hit it ;-)
Can you run git-http-fetch after the failure to attempt to pick up where
it left off? It should fail right away, and hopefully contain less
confusing output from parallel requests.
Was there a request header for pack-9cbe...d3a5.pack earlier in the
output, and were there response headers for successful or failed
requests?
FWIW, I've tried cloning that repository a few times and haven't seen
the problem yet.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-08 6:00 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EZKOB-0002j5-VY@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> That is, after the merge, file3 appears to have simply kept
> the contents of the current, master branch. Why wasn't the
> dev branch represented here?
>
> I _almost_ think I get it, and then *poof*...
Automerge completely punted for this path, and at this point, it
is still unmerged:
------------
$ git ls-files --unmerged
100644 c4da0eb.... 2 file3
100644 fbc2aa4.... 3 file3
------------
Three-way "git-read-tree -m -u O A B" (O is for old, A is ours
and B is hers) puts O in stage1, A in stage2 and B in stage3.
This path did not exist in O so we only have them in stage2 and
stage3. You could compare the stages like this:
------------
$ git diff-stages -p 2 3 file3
diff --git a/file3 b/file3
index c4da0eb..fbc2aa4 100644
--- a/file3
+++ b/file3
@@ -1 +1 @@
-Stuff for a conflict.
+Another file!
------------
When we do a file-level merge (and possibly leave conflicts), we
register _our_ version in the index and leave the merge result
in the working tree. However, when O is empty like this case,
we leave the conflicting path simply unmerged and do not touch
the working tree. We say "ERROR: not handling case" when this
happens.
Nobody complained so far about this, probably because two side
adding different versions is rare enough. And the reasoning
behind the current behaviour is probably because the tool cannot
automerge them sensibly anyway. Leaving the SHA1 in index file
might probably be easier to clean up by hand (e.g. see ls-files
--unmerged, and cut&paste the desired SHA1 to 'git-cat-file
blob' command line, or something silly like that). But if we
were to go that route, adding --stage=[123] flag so that the
user can say 'git-checkout-index --stage=3 file3'might have
helped a bit more.
We could instead use the attached patch to get the behaviour you
are expecting. I have a feeling that the result from this might
be a little more intuitive and easier to resolve by hand than
the current one. Although we may end up unresolvable mess in
file3 if either side is binary, in that case the user can still
sift through 'diff-tree A B file3' output to find out the
relevant SHA1 to recover the blobs from both sides by hand
anyway. Does anybody have strong opinion on this?
--
[PATCH] merge with /dev/null as base, instead of not handling O=='' case
Instead of leaving the path unmerged in a case where each side
adds different version of the same path, attempt to merge it
with empty base and leave "our" version in the index file, just
like we do for the case in conflicting merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 5419e59..32e17cb 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -56,9 +56,18 @@ case "${1:-.}${2:-.}${3:-.}" in
#
# Modified in both, but differently.
#
-"$1$2$3")
- echo "Auto-merging $4."
- orig=`git-unpack-file $1`
+"$1$2$3" | ".$2$3")
+ case "$1" in
+ '')
+ echo "Added $4 in both, but differently."
+ orig=`git-unpack-file $2`
+ : >$orig
+ ;;
+ *)
+ echo "Auto-merging $4."
+ orig=`git-unpack-file $1`
+ ;;
+ esac
src2=`git-unpack-file $3`
# We reset the index to the first branch, making
@@ -73,6 +82,9 @@ case "${1:-.}${2:-.}${3:-.}" in
echo "ERROR: Permissions conflict: $5->$6,$7."
ret=1
fi
+ if [ "$1" = '' ]; then
+ ret=1
+ fi
if [ $ret -ne 0 ]; then
echo "ERROR: Merge conflict in $4."
^ permalink raw reply related
* Re: git-rev-tree
From: Junio C Hamano @ 2005-11-08 4:55 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20051108021232.GB10835@redhat.com>
Dave Jones <davej@redhat.com> writes:
> Can someone remind me what the deprecated git-rev-tree command did,
> or how this should be fixed up to use newer git commands?
Alternatively, can somebody comment on the git-changes in the
"pu" branch?
^ permalink raw reply
* _Almost_Totally_ Off Topic Story (*)
From: Jon Loeliger @ 2005-11-08 4:08 UTC (permalink / raw)
To: git
So, last week I get hornswaggled into picking my kid
up from school. I arrive a bit early, so I actually
park the car and wander into the classroom just before
it all lets out.
Now this is a private school for special needs kids,
so painting and staining gourds with pictures of Bono
burn etched into them wasn't unusual behavior.
What _is_ unusual, though, is the set of names on
the side of the whiteboard, about 20 of them:
William Shakespeare
Albert Einstein
Zeus
Edgar Allan Poe
George Washington
Richard Feynman
Linus Torvalds
Isaac Newton
Marie Curie
Earnest Hemmingway
Hamlet
...
Naturally, the questions: "Uh, what do these people have
in common? Or why _these_ people? And *wait*, one of
those people is still alive!"
So, it turns out they were producing a list of names for
the set of computers that were recently donated to the school!
jdl
[ (*) Sorry. I just know Linus is reading over here these days. ]
^ permalink raw reply
* Re: git-rev-tree
From: Dave Jones @ 2005-11-08 3:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511071934410.3247@g5.osdl.org>
On Mon, Nov 07, 2005 at 07:35:55PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 7 Nov 2005, Dave Jones wrote:
> >
> > (18:47:37:davej@hera:agp2)$ export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
> > (18:47:43:davej@hera:agp2)$ git fetch $KERNEL/torvalds/linux-2.6 master:linus
> > davej@master.kernel.org's password:
> > Packing 35335 objects
> > Unpacking 35335 objects
> > 100% (35335/35335) done
> > * committish: d27ba47e7e8c466c18983a1779d611f82d6a354f
> > branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
> > * refs/heads/linus: storing branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
> >
> > which looks ok, but then when I do the git log linus..HEAD, I get no output at all.
>
> You've got the right "linus" commit.
>
> However, are you aware that I did pull from you? If you don't have
> anything new, "no output at all" is the right thing.
I only just saw my changes turn up on the commits list, so I was
completely unaware until now. Hohum.
I'll figure it out next time I have something for you to pull again :)
thanks,
Dave
^ permalink raw reply
* Re: Expected Behavior?
From: Jon Loeliger @ 2005-11-08 3:43 UTC (permalink / raw)
To: git
> Yup, it uses "git-ls-files --others", which considers that
> unmerged paths do not "exist" in the index. This is wrong.
>
> The attached is a patch to fix ls-files.
>
> I also think that file3 should not appear in "Updated but not
> checked in (will commit)" list -- we are _not_ going to commit
> unmerged paths until you tell git what you want to do with
> them. The patch in the next message fixes it.
Patch looks good here! Thanks!
% git status
#
# Updated but not checked in:
# (will commit)
#
# modified: file1
# deleted: file2
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# unmerged: file3
#
But I have a lingering question. Same script as before.
% git diff file3
* Unmerged path file3
% cat file3
Stuff for a conflict.
Why didn't file3 show something like:
% cat file3
<<<<<
Stuff for a conflict.
=====
Another file!
>>>>>
That is, after the merge, file3 appears to have simply kept
the contents of the current, master branch. Why wasn't the
dev branch represented here?
I _almost_ think I get it, and then *poof*...
Thanks,
jdl
^ permalink raw reply
* Re: git-rev-tree
From: Linus Torvalds @ 2005-11-08 3:35 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20051108025755.GA22243@redhat.com>
On Mon, 7 Nov 2005, Dave Jones wrote:
>
> (18:47:37:davej@hera:agp2)$ export KERNEL=master.kernel.org:/pub/scm/linux/kernel/git/
> (18:47:43:davej@hera:agp2)$ git fetch $KERNEL/torvalds/linux-2.6 master:linus
> davej@master.kernel.org's password:
> Packing 35335 objects
> Unpacking 35335 objects
> 100% (35335/35335) done
> * committish: d27ba47e7e8c466c18983a1779d611f82d6a354f
> branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
> * refs/heads/linus: storing branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git//torvalds/linux-2.6
>
> which looks ok, but then when I do the git log linus..HEAD, I get no output at all.
You've got the right "linus" commit.
However, are you aware that I did pull from you? If you don't have
anything new, "no output at all" is the right thing.
> *click*, ahh wait, I didn't have a 'linus' branch before I did that fetch.
> For the above to work, do I need there to be a 'linus' branch before
> I start making changes ? Or am I barking up the wrong tree ?
No, the above will have created the "linus" branch as needed.
Linus
^ 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