openbsd version?

openbsd version?

[Randal L. Schwartz]

I noticed "openbsd" in the operating systems detected in Makefile,
but when I tried this on my openbsd system, I get an abort here:

    gcc -g -O2 -Wall -I/usr/local/include -L/usr/local/lib '-DSHA1_HEADER=<openssl/sha.h>' -o git-mailinfo mailinfo.o libgit.a  -liconv
    mailinfo.o(.text+0x22d): In function `slurp_attr':
    /opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'
    mailinfo.o(.text+0x2a9): In function `handle_subcontent_type':
    /opt/git/src/git-snapshot-20051010/mailinfo.c:155: undefined reference to `strcasestr'
    mailinfo.o(.text+0x39d): In function `handle_content_transfer_encoding':
    /opt/git/src/git-snapshot-20051010/mailinfo.c:181: undefined reference to `strcasestr'
    mailinfo.o(.text+0x3c6):/opt/git/src/git-snapshot-20051010/mailinfo.c:183: undefined reference to `strcasestr'
    collect2: ld returned 1 exit status
    gmake: *** [git-mailinfo] Error 1

What am I doing wrong?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: openbsd version?

[Peter Eriksen]

On Mon, Oct 10, 2005 at 09:12:34AM -0700, Randal L. Schwartz wrote:
> 
> I noticed "openbsd" in the operating systems detected in Makefile,
> but when I tried this on my openbsd system, I get an abort here:
> 
>     gcc -g -O2 -Wall -I/usr/local/include -L/usr/local/lib '-DSHA1_HEADER=<openssl/sha.h>' -o git-mailinfo mailinfo.o libgit.a  -liconv
>     mailinfo.o(.text+0x22d): In function `slurp_attr':
>     /opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'
>     mailinfo.o(.text+0x2a9): In function `handle_subcontent_type':
>     /opt/git/src/git-snapshot-20051010/mailinfo.c:155: undefined reference to `strcasestr'
>     mailinfo.o(.text+0x39d): In function `handle_content_transfer_encoding':
>     /opt/git/src/git-snapshot-20051010/mailinfo.c:181: undefined reference to `strcasestr'
>     mailinfo.o(.text+0x3c6):/opt/git/src/git-snapshot-20051010/mailinfo.c:183: undefined reference to `strcasestr'
>     collect2: ld returned 1 exit status
>     gmake: *** [git-mailinfo] Error 1
> 
> What am I doing wrong?

You need to compile with

$ gmake NO_STRCASESTR=Indeed

Peter

Re: openbsd version?

[Linus Torvalds]

On Mon, 10 Oct 2005, Randal L. Schwartz wrote:
> 
> I noticed "openbsd" in the operating systems detected in Makefile,
> but when I tried this on my openbsd system, I get an abort here:
> 
>     /opt/git/src/git-snapshot-20051010/mailinfo.c:130: undefined reference to `strcasestr'

Either do

	make NO_STRCASESTR=1 ..

or add that explicitly to the makefile in the OpenBSD rules and send Junio 
a tested patch ;)

		Linus

Re: openbsd version?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Either do
>
> 	make NO_STRCASESTR=1 ..
>
> or add that explicitly to the makefile in the OpenBSD rules and send Junio 
> a tested patch ;)

Thanks; this has been resolved underwater.

Re: openbsd version?

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> Linus Torvalds <torvalds@osdl.org> writes:
>> Either do
>> 
>> make NO_STRCASESTR=1 ..
>> 
>> or add that explicitly to the makefile in the OpenBSD rules and send Junio 
>> a tested patch ;)

Junio> Thanks; this has been resolved underwater.

And yes, I made my first patch with git today!  But I cut-n-pasted
it and blew the leading tabs.

Related question.  I created "mybranch" to do the patch, but how
can I have my repository now forget that mybranch was ever made?
Is it sufficient to remove the branch link, and then type some "fsck"
operation?

That's also a question in general... how can I remove a commit,
knowing that I'd never refer to it again?  Or is disk space so cheap
that it wouldn't make any difference anyway?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: openbsd version?

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> Related question.  I created "mybranch" to do the patch, but how
> can I have my repository now forget that mybranch was ever made?
> Is it sufficient to remove the branch link, and then type some "fsck"
> operation?

Removing non-current branch -- you may need to do -D instead of -d. 

$ git branch -d mybranch

> That's also a question in general... how can I remove a commit,
> knowing that I'd never refer to it again?  Or is disk space so cheap
> that it wouldn't make any difference anyway?

Removing from the tip of the current branch:

$ git reset HEAD^

Removing from the tip of non-current branch:

$ git update-ref mybranch mybranch^

Re: openbsd version?

[Randal L. Schwartz]

>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:

Junio> Removing non-current branch -- you may need to do -D instead of -d. 

Junio> $ git branch -d mybranch

<sarcasm>Undocumented secret switches.  Nice.</sarcasm>  No wonder
I couldn't find it.

>> That's also a question in general... how can I remove a commit,
>> knowing that I'd never refer to it again?  Or is disk space so cheap
>> that it wouldn't make any difference anyway?

Junio> Removing from the tip of the current branch:

Junio> $ git reset HEAD^

Junio> Removing from the tip of non-current branch:

Junio> $ git update-ref mybranch mybranch^

Do these also flush any related object files?  Or do I need git-fsck still?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: openbsd version?

[Johannes Schindelin]

Hi,

On Mon, 10 Oct 2005, Randal L. Schwartz wrote:

> >>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> 
> Junio> Removing non-current branch -- you may need to do -D instead of -d. 
> 
> Junio> $ git branch -d mybranch
> 
> <sarcasm>Undocumented secret switches.  Nice.</sarcasm>  No wonder
> I couldn't find it.

<optimism>Maybe he who found the documentation lacking is going to fix 
it?</optimism>

Re: openbsd version?

[Randal L. Schwartz]

>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> <sarcasm>Undocumented secret switches.  Nice.</sarcasm>  No wonder
>> I couldn't find it.

Johannes> <optimism>Maybe he who found the documentation lacking is going to fix 
Johannes> it?</optimism>

I'd be happy to do that.  But as a tech writer, I know that it's
insane to not work at least from an implementor's rough draft, to at
least understand the intent of a mechanism, if not the precise design.
There's no implementor's rough draft here, so I can't help.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: openbsd version?

[H. Peter Anvin]

Randal L. Schwartz wrote:
> 
> Johannes> <optimism>Maybe he who found the documentation lacking is going to fix 
> Johannes> it?</optimism>
> 
> I'd be happy to do that.  But as a tech writer, I know that it's
> insane to not work at least from an implementor's rough draft, to at
> least understand the intent of a mechanism, if not the precise design.
> There's no implementor's rough draft here, so I can't help.
> 

Sounds like an offer to send Mr. Schwartz some notes to work from.  In 
my experience, sending notes to a good tech writer is about an order of 
magnitude less painful than writing polished documentation, so that 
should be easier.

	-hpa

Re: openbsd version?

[Randal L. Schwartz]

>>>>> "H" == H Peter Anvin <hpa@zytor.com> writes:

H> Sounds like an offer to send Mr. Schwartz some notes to work from.  In
H> my experience, sending notes to a good tech writer is about an order
H> of magnitude less painful than writing polished documentation, so that
H> should be easier.

Since I'm benefitting from this project, I'd be happy to offer my services
as time permits.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: openbsd version?

[Daniel Barkalow]

On Mon, 10 Oct 2005, Randal L. Schwartz wrote:

> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> <sarcasm>Undocumented secret switches.  Nice.</sarcasm>  No wonder
> >> I couldn't find it.
> 
> Johannes> <optimism>Maybe he who found the documentation lacking is going to fix 
> Johannes> it?</optimism>
> 
> I'd be happy to do that.  But as a tech writer, I know that it's
> insane to not work at least from an implementor's rough draft, to at
> least understand the intent of a mechanism, if not the precise design.
> There's no implementor's rough draft here, so I can't help.

The mailing list thread on the subject is at:

 http://www.gelato.unsw.edu.au/archives/git/0509/8902.html

(That's the middle of the thread, when the patch was actually written. 
There's discussion before and after if you need more info.)

You can actually get a pretty good explanation of features, once you know 
they exist at all, by looking for the discussion on the list. This tends 
to at least give you the person who did the patch explaining how to use it 
to the person who wanted the feature. And it'll also tell you who the 
implementor was, so you can bug the right person directly. :)

What does get written about a feature generall ends up in the commit 
message for the commit that adds it, so that's another good place to look. 
(In this case, it's missing a "not" and description of an option, so it's 
quite rough as a draft.)

In this case:

 "git branch -d <name>" deletes a branch with that name; but it checks 
that you're not on that branch, and it checks that that branch doesn't 
have any commits which aren't merged into the current branch.
 "git branch -D <name>" deletes a branch, and skips the second check.

	-Daniel
*This .sig left intentionally blank*

Re: openbsd version?

[Junio C Hamano]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

> <sarcasm>Undocumented secret switches.  Nice.</sarcasm>  No wonder
> I couldn't find it.

Sorry.  This is taken from the log message from the commit that
introduced the switch.

    git-branch -d <branch>: delete unused branch.
    
    The new flag '-d' lets you delete a branch.  For safety, it does not
    lets you delete the branch you are currently on, nor a branch that
    has been fully merged into your current branch.
    
    The credit for the safety check idea goes to Daniel Barkalow.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>

There should be a document in Documentation/howto/ to describe
how to find the commit that introduced a particular feature.
What I did to find the above is this:

   1. Look at git-branch.sh and notice that there is this line:

    echo >&2 "usage: $(basename $0)"' [-d <branch>] | [<branch> [start-point]]

   Make an educated guess that this line, especially the
   "[-d <branch>]" part, must have changed when the feature was
   added (that is, pre-modification file would not have had "[-d
   <branch>]" in it, but post-modification file would).

   2. Find such a change with pickaxe (-S):

    $ git whatchanged -S'[-d <branch>]' git-branch.sh

By mentioning this, I do not mean to say that you could have
figuired this out yourself -- the above sequence is useful for
somebody who knows the code already to do archaeology; IOW you
still need to know what to look for, so the above procedure
would not have helped at all even if you knew about pickaxe.

> Do these also flush any related object files?  Or do I need git-fsck still?

The latter.  I think there should be a general description in
the tutorial to advice the user to run git-fsck-objects every
once in a while, while mentioning that there is no need to do it
too often -- disk space is cheap and the time you spend waiting
for fsck-objects to finish tends to be more expensive.

Re: openbsd version?

[Sven Verdoolaege]

On Mon, Oct 10, 2005 at 01:30:15PM -0700, Junio C Hamano wrote:
> Removing from the tip of non-current branch:
> 
> $ git update-ref mybranch mybranch^
> 

I think you mean 

$ git-update-ref refs/heads/mybranch mybranch^

Which reminds me... try this:

bash-3.00$ git-init-db 
defaulting to local storage area
bash-3.00$ touch a
bash-3.00$ git-update-index --add a
bash-3.00$ git commit -m 'a'
Committing initial tree 496d6428b9cf92981dc9495211e6e1120fb6f2ba
bash-3.00$ touch b
bash-3.00$ git-update-index --add b
bash-3.00$ git commit -m 'b'
bash-3.00$ git checkout -b branch
bash-3.00$ git-update-ref master master^
bash-3.00$ git checkout master
bash-3.00$ git-status
#
# Updated but not checked in:
#   (will commit)
#
#       deleted:  b
#

(Hint: there are now two masters)

skimo

Re: openbsd version?

[Junio C Hamano]

Sven Verdoolaege <skimo@kotnet.org> writes:

> I think you mean 
>
> $ git-update-ref refs/heads/mybranch mybranch^

Of course you are right.  Thanks.

Re: openbsd version?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Sven Verdoolaege <skimo@kotnet.org> writes:
>
>> I think you mean 
>>
>> $ git-update-ref refs/heads/mybranch mybranch^
>
> Of course you are right.  Thanks.

And I am an idiot.  I did that myself again, and ended up
wasting 30 minutes or so, scratching my head.

Maybe there should be a safety measure built into git-update-ref
that says single-level name (i.e. not starting with refs/) gets
warning unless all uppercase or something silly like that to
protect idiots like myself.  Hmmm.

Re: openbsd version?

[Sven Verdoolaege]

On Thu, Oct 13, 2005 at 12:47:26AM -0700, Junio C Hamano wrote:
> Maybe there should be a safety measure built into git-update-ref
> that says single-level name (i.e. not starting with refs/) gets
> warning unless all uppercase or something silly like that to
> protect idiots like myself.  Hmmm.

How about checking whether the name also exists with a certain
prefix instead ?
Otherwise you'll also disallow updating ORIG_HEAD and stuff.

skimo