openbsd version?

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?

On Mon, Oct 10, 2005 at 09:12:34AM -0700, Randal L. Schwartz wrote:

You need to compile with

$ gmake NO_STRCASESTR=Indeed

Peter

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

Either do

	make NO_STRCASESTR=1 ..

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

		Linus

Linus Torvalds <torvalds@osdl.org> writes:

Thanks; this has been resolved underwater.

Junio> Linus Torvalds <torvalds@osdl.org> writes:

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?

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

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

$ git branch -d mybranch

Removing from the tip of the current branch:

$ git reset HEAD^

Removing from the tip of non-current branch:

$ git update-ref mybranch mybranch^

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.

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?

Hi,

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

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

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 wrote:

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

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.

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

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*

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

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.

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.

On Mon, Oct 10, 2005 at 01:30:15PM -0700, Junio C Hamano wrote:

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

Sven Verdoolaege <skimo@kotnet.org> writes:

Of course you are right.  Thanks.

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

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.

On Thu, Oct 13, 2005 at 12:47:26AM -0700, Junio C Hamano wrote:

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

skimo