* Re: Updated Kernel Hacker's guide to git
From: Francis Moreau @ 2006-12-22 9:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jay Cliburn, git, Jeff Garzik
In-Reply-To: <Pine.LNX.4.64.0612211013500.3394@woody.osdl.org>
Linus Torvalds wrote:
>
> In short, for git diff (and ONLY) git diff, all of these are the same:
>
> git diff a..b
> git diff a b
> git diff b ^a
>
I think this part is really confusing. For a new comer, saying that:
git diff a b == git diff a..b
is really not intuitive. Maybe just because adding a new symbol ".."
in git diff command line means (for me) that we're doing a special
diff. I would never thought by my own that ".." means a simple "to".
> [ ADDITIONALLY git diff _also_ has a magic special case of
>
> git diff a b ^c
>
> which actually means the same as "git diff c..a" (and "b" is
> totally ignored). That may sound strange, but it's because the
> expression "a...b" means "b a --not $(git-merge-base a b)", and so what
> you actually WANT is that if you do
>
> git diff a...b
>
> you should get "diff from merge-base to b", so when "a...b" expands to
> "b a ^merge-base", then git understands that if it gets that stange
> command line with THREE commits, and one of them is negated, you really
> wanted the diff from the negated one to the first one ]
>
> It basically all boils down to:
>
> "git diff" is special
>
but this very special part of git diff is also not documented at all
when reading the manual of git-diff... Maybe it can be reached by
others manuals ?
> exactly because unlike almost ALL other git commands, "git diff" does not
> work on a _list_ of commits, it only works on two end-points. That means
> that the "list operations" actually end up meaning something else for git
> diff than they do for "git log" and friends.
>
I think I got your point now: git-diff only works on two end-points.
Why not making it less special as follow:
git diff a b
git diff b ^a
These two diff commands are the same. They do a diff between a and b
end-points (maybe commits is better there since we don't add one more
keyword). It's similar to diff command. For me it's quite intuitive.
git diff a..b
Ok now the command syntax is more special (maybe simply because
traditional diff() does not have a similar syntax, it's really
specific to git). "git log" and friends have a similar syntax and they
do work on a list of commits. For consistency sake, make this commad
works on commit list too. Therefore this command would end up doing
exactly the same thing like "git diff a...b"
git diff a...b
No more need of this special syntax.
What do you think ?
thanks
--
Francis
^ permalink raw reply
* Re: [PATCH] hooks/commit-msg: add example to add Signed-off-by line to message
From: Andy Parkins @ 2006-12-22 9:28 UTC (permalink / raw)
To: git
In-Reply-To: <7v64c47abv.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 December 22 05:45, Junio C Hamano wrote:
> I suspect this sed script is quite wrong. Did you test it?
I plead not guilty; cut and pasted from Johannes. In it's defence; I've been
using it since he gave it to me without trouble. My patch is wrapping it a
little differently, but the sed is certainly the same.
Amazingly it does work though...
> * quoting with dq means you are losing one level of backslash
> to the shell and sed is not seeing them.
Unusual. It doesn't seem to apply to non-recognised escapes:
$ echo "\1\(\)\+$/"
\1\(\)\+$/
> * one-or-more regexp '+' is typically not found in sed.
Seems to be in mine (GNU sed version 4.1.5).
$ echo "xxxxxx" | sed -n 's/\(x\+\)$/MATCH/p'
MATCH
> off that new change as well, I think. So checking the last
> instance of the existing signed-off-by line, ignoring earlier
> ones, may be more preferrable.
Accepted.
Notwithstanding the fact that it seems to be working for me; I'll fix the
problems you highlight and re-patch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-22 9:25 UTC (permalink / raw)
To: git
I guess I'll need to push another maintenance release out soon,
if only to fix the manual pages.
On the 'master' front there are a handful more topics pushed out
from 'next'. I still need to apply the __FREEBSD__ fix yet, but
otherwise we should be able to start calming things down.
* The 'maint' branch has these fixes since the last announcement.
Johannes Schindelin (1):
diff --check: fix off by one error
Junio C Hamano (1):
spurious .sp in manpages
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: convert to using Git.pm
git-svn: remove support for the svn command-line client
git-svn: rename 'commit' command to 'set-tree'
Johannes Schindelin (5):
Introduce GIT_TEMPLATE_DIR
diff --check: fix off by one error
Use git-merge-file in git-merge-one-file, too
git-tag: support -F <file> option
git-reset --hard: tell the user what the HEAD was reset to
Josef Weidendorfer (1):
Move "no merge candidate" warning into git-pull
Junio C Hamano (22):
git-clone: use wildcard specification for tracking branches
git-pull: refuse default merge without branch.*.merge
git-clone: lose the artificial "first" fetch refspec
git-clone: lose the traditional 'no-separate-remote' layout
rev-list --left-right
Teach all of log family --left-right output.
Make left-right automatic.
fix testsuite: make sure they use templates freshly built from the source
Teach git-branch to delete tracking branches with -r -d
blame: -b (blame.blankboundary) and --root (blame.showroot)
Revert "fix testsuite: make sure they use templates freshly
built from the source"
Do not create $GIT_DIR/remotes/ directory anymore.
Use preprocessor constants for environment variable names.
Revert "Make left-right automatic."
git-add: error out when given no arguments.
spurious .sp in manpages
compat/inet_ntop: do not use u_int
diff documentation: mostly talk about <commit>
Revert "git-pull: refuse default merge without branch.*.merge"
parse-remote: mark all refs not for merge only when fetching more
than one
_XOPEN_SOURCE problem also exists on FreeBSD
commit-tree: do not overflow MAXPARENT
Quy Tonthat (2):
git-branch -d: do not stop at the first failure.
Documentation/git-branch: new -r to delete remote-tracking branches.
Shawn Pearce (3):
Suggest 'add' in am/revert/cherry-pick.
Rename imap-send's internal info/warn functions.
Introduce a global level warn() function.
Terje Sten Bjerkseth (1):
Fix system header problems on Mac OS X
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jesper Juhl @ 2006-12-22 8:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <4589F9B1.2020405@garzik.org>
On 21/12/06, Jeff Garzik <jeff@garzik.org> wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
>
Very nice.
A bit on how to revert a commit and how to rebase a branch would make
it even nicer :)
Thank you for a very good document, Jeff.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Alex Riesen @ 2006-12-22 8:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612220318320.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Fri, Dec 22, 2006 03:19:21 +0100:
>
> If the cache tree is not up-to-date, it will be updated first. So, now
>
> $ git show :Documentation/
>
> will in effect show what files/directories are in the index' version
> of the directory Documentation. The three commands
>
> $ git show :./
> $ git show :.
> $ git show :
>
> are all equivalent and show the index' idea of the root directory.
That is a bit unexpected if you're not in the root directory of
repository, but in some subdir of the working directory.
Why root? Why not the current directory relative to root?
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Andy Parkins @ 2006-12-22 8:41 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre
In-Reply-To: <Pine.LNX.4.64.0612211555210.18171@xanadu.home>
On Thursday 2006 December 21 22:17, Nicolas Pitre wrote:
Sorry Alan; I thought it was your bug - it wasn't...
> $ git branch -r
> * master
> origin/HEAD
> origin/html
> origin/maint
> origin/man
> origin/master
> origin/next
> origin/pu
> origin/todo
I'm trying to track down why "master" is being shown in this case"; would it
be possible to show me the output of
$ tree .git/refs/heads .git/refs/remotes
As I am having trouble reproducing this error.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Andy Parkins @ 2006-12-22 8:39 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alan Chandler
In-Reply-To: <7vfyb85ojf.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 December 22 08:21, Junio C Hamano wrote:
> Heh, sounds like you spotted a bug -- patches welcome (or I'll
> fix it myself if I get around to it before everybody else).
> Thanks.
I can't reproduce this bug. I tried having an identically named branch in
both remotes and heads. Output was fine. I don't like to say "impossible",
but it certainly seems that
This from append_ref():
} else if (!strncmp(refname, "refs/remotes/", 13)) {
kind = REF_REMOTE_BRANCH;
and this from print_ref_list():
if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
!strcmp(ref_list.list[i].name, head)) {
c = '*';
Make it almost inconceivable that a remote branch is being starred, or that a
local branch is making it into the "-r" output.
Alan: could you show a tree of your .git/refs/heads and your .git/refs/remotes
for the repository that is displaying this error?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply
* Re: git-svn throwing assertion on old svn tracking branch
From: Eric Wong @ 2006-12-22 8:38 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: git
In-Reply-To: <20061222021613.GB9595@hermes>
Nicolas Vilz <niv@iaglans.de> wrote:
> On Fri, Dec 22, 2006 at 02:35:10AM +0100, Nicolas Vilz wrote:
> > On Wed, Dec 20, 2006 at 05:05:20PM -0800, Eric Wong wrote:
> > > Nicolas Vilz <niv@iaglans.de> wrote:
> [...]
> > beneath there is svn, version 1.4.2 (r22196) ... on that repository is
> > Subversion version 1.1.4 (r13838).
>
> i should ammend, that the same error message comes, when i want to
> dcommit something in this repository...
Weird, so you have the SVN:: libraries installed? (dcommit requires it).
Is the repository you're tracking public? If so, I'd like to have a
look...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Junio C Hamano @ 2006-12-22 8:37 UTC (permalink / raw)
To: Marco Roeland
Cc: Terje Sten Bjerkseth, Randal L. Schwartz, Linus Torvalds,
Rocco Rutte, git
In-Reply-To: <20061222075142.GA9595@fiberbit.xs4all.nl>
Marco Roeland <marco.roeland@xs4all.nl> writes:
> On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:
>
>> Personally, I think hiding interfaces such as strXXX and memXXX
>> based on _XOPEN_SOURCE level is already a bug in the system
>> header implementation. The symbols that begin with str are
>> already reserved by the standard and I do not see any point
>> in the system headers to try avoiding namespace contamination.
>>
>> But we are not in the business of fixing the system headers.
>
> ;-)
>
> Perhaps the idea behind this might be that it allows you to easier
> develop software that really only uses interfaces strictly defined in
> some "standards" to be always available on compliant platforms. That's
> all I could think of why you ever would want to do it like this yes.
(offtopic) Yeah, but my point was that ANSI C reserves _all_
symbols that begin with str ("Names reserved for expansion"),
not just a specific set of functions like strcmp, strcpy, etc.,
so if a program tries to be compliant with it, it cannot use,
for example, strncasecmp (was that the symbol we had trouble
with?) for its own purpose anyway -- which means the system
header implementation should not have to worry about namespace
pollution. I do not see any reason for them to hide
strncasecmp, for example.
> On Apple compiling git works fine both with and without
> _XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
> _XOPEN_SOURCE define which restricts functionality to some predefined
> set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
> remove it. So I thought it might be best to keep as much symbols as
> possible to be the same for all platforms for future expandibility.
>
> Probably FreeBSD behaves the same with respect to
> _XOPEN_SOURCE_EXTENDED. Will check later today.
Ok, thanks.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Andy Parkins @ 2006-12-22 8:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vvek492q1.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 December 22 00:46, Junio C Hamano wrote:
> You can always say "git log refs/heads/next" even though you are
> allowed to say "git log next". Maybe we should remove that
> shorthand to make it consistent? I think not.
On a related subject - I'd like to remove all the "refs/" literals from git.
All refs are always under "refs/", so prefixing everything with refs/ is just
noise.
The place that makes it stand out that this is wrong is (I think) found in
refs.c (excuse my abuse of syntax):
int for_each_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/", fn, 0, cb_data);
int for_each_tag_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/tags/", fn, 10, cb_data);
int for_each_branch_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/heads/", fn, 11, cb_data);
int for_each_remote_ref(each_ref_fn fn, void *cb_data)
return do_for_each_ref("refs/remotes/", fn, 13, cb_data);
What's significant is that it is only for_each_ref() that hands the prefix
back. The change I'd like to make is
return do_for_each_ref("refs/", fn, 5, cb_data);
Obviously, this will imply a lot of changes everywhere else; so I didn't want
to dive into it without mentioning it here first.
Is this a sensible thing to want to do?
As I'm talking about code cleanups, I'd also like to change all variables
called "sha1" to "hash" (or similar). The point being that the variables
hold hashes not sha1's.
I don't say that the above are serious problems, I just like cleaning code :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Jakub Narebski @ 2006-12-22 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm9g7duz.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> (1) Why is this needed?
Probably for completeness.
> (2) What does this do when the index is unmerged?
I think it should show "git ls-files --unmerged --abbrev", perhaps...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Shawn Pearce @ 2006-12-22 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodpw5ors.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Just because the commit has not been pruned does not mean that a blob
> > or tree referenced by that commit has not been pruned.
>
> True. How about this?
Yea, that's a good way to deal with it. Ack'd.
--
Shawn.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Jakub Narebski @ 2006-12-22 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> And it is not just limited to adding the contents of a path that
> happened to be told git for the first time. Adding the contents
> of a path that was known to git also happens only when it is in
> a presentable good state. So running "git diff" and not seeing
> what I added before is a GOOD THING.
If I remember correctly the idea behind "intent to add" was to show
only that file was added (e.g. the "new file" line from extended diff
header) in "git diff" when file was added and not modified
(and no changes to "git diff HEAD").
Although I'm not sure if this wouldn't screw some use cases which
include something like "git diff > some-temporary-file"...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2006-12-22 8:21 UTC (permalink / raw)
To: Alan Chandler; +Cc: git, Nicolas Pitre
In-Reply-To: <200612220750.49644.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> And according to the man page git branch -r should print ONLY the remote
> branches
Heh, sounds like you spotted a bug -- patches welcome (or I'll
fix it myself if I get around to it before everybody else).
Thanks.
>> > $ git checkout origin/next
>> > git checkout: to checkout the requested commit you need to specify
>> > a name for a new branch which is created and switched
>
> What about the error message saying that origin/next is read only.
> Something like
>
> git-checkout: the requested commit is on a remote read only branch. You
> need to specify a new local branch with the -b option to proceed.
I agree that explicitly suggesting the use of -b is a good idea,
but your wording is a bit too specific; after all you might do
$ H=`git-rev-parse origin/next`
$ git checkout $H
and there is not enough information to say "is on a remote read
only branch". We could do that with more specific hacks in
git-checkout; patches welcome.
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Junio C Hamano @ 2006-12-22 8:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061222005606.GA14773@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Just because the commit has not been pruned does not mean that a blob
> or tree referenced by that commit has not been pruned.
True. How about this?
---
builtin-reflog.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index d4f7353..4097c32 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -3,7 +3,7 @@
#include "commit.h"
#include "refs.h"
#include "dir.h"
-#include <time.h>
+#include "tree-walk.h"
struct expire_reflog_cb {
FILE *newlog;
@@ -13,13 +13,50 @@ struct expire_reflog_cb {
unsigned long expire_unreachable;
};
+static int tree_is_complete(const unsigned char *sha1)
+{
+ struct tree_desc desc;
+ void *buf;
+ char type[20];
+
+ buf = read_sha1_file(sha1, type, &desc.size);
+ if (!buf)
+ return 0;
+ desc.buf = buf;
+ while (desc.size) {
+ const unsigned char *elem;
+ const char *name;
+ unsigned mode;
+
+ elem = tree_entry_extract(&desc, &name, &mode);
+ if (!has_sha1_file(elem) ||
+ (S_ISDIR(mode) && !tree_is_complete(elem))) {
+ free(buf);
+ return 0;
+ }
+ update_tree_entry(&desc);
+ }
+ free(buf);
+ return 1;
+}
+
static int keep_entry(struct commit **it, unsigned char *sha1)
{
+ struct commit *commit;
+
*it = NULL;
if (is_null_sha1(sha1))
return 1;
- *it = lookup_commit_reference_gently(sha1, 1);
- return (*it != NULL);
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return 0;
+
+ /* Make sure everything in this commit exists. */
+ parse_object(commit->object.sha1);
+ if (!tree_is_complete(commit->tree->object.sha1))
+ return 0;
+ *it = commit;
+ return 1;
}
static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
^ permalink raw reply related
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Marco Roeland @ 2006-12-22 8:04 UTC (permalink / raw)
To: Kyle Moffett
Cc: Martin Langhoff, Randal L. Schwartz, Linus Torvalds,
Nicolas Pitre, git
In-Reply-To: <991F50E2-2C98-4710-84C5-3D7348E00B64@mac.com>
On Thursday December 21st 2006 at 20:44 Kyle Moffett wrote:
> I've actually also seen filesystem operation latency double or triple
> if you start trying to do operations from multiple threads at once.
> Suddenly the already dog-slow single-CPU operations start bouncing
> caches and the Mac OS X mostly-whole-of-BSD-BKL across CPUs and it
> just crawls. I can definitely see the local disk IO taking 100x
> longer than the network I/O, especially with an 8-megabit internet link.
The mmap() implementation on Mac OS X ate 85% percent of system time on
the old version for git-index-pack. Of that time nearly all was spent on
some Mach locking function. So yes the BKL like locking inside the Mach
message passing seems to be the big culprit, perhaps Andy Tanenbaum can
explain this on LCA 2007. <ducks>
As most developers now run multicore CPU's we notice these differences
even better now! ;-)
--
Marco Roeland
^ permalink raw reply
* Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Marco Roeland @ 2006-12-22 7:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Roeland, Terje Sten Bjerkseth, Randal L. Schwartz,
Linus Torvalds, Rocco Rutte, git
In-Reply-To: <7v64c492fv.fsf@assigned-by-dhcp.cox.net>
On Thursday December 21st 2006 at 16:52 Junio C Hamano wrote:
> Personally, I think hiding interfaces such as strXXX and memXXX
> based on _XOPEN_SOURCE level is already a bug in the system
> header implementation. The symbols that begin with str are
> already reserved by the standard and I do not see any point
> in the system headers to try avoiding namespace contamination.
>
> But we are not in the business of fixing the system headers.
;-)
Perhaps the idea behind this might be that it allows you to easier
develop software that really only uses interfaces strictly defined in
some "standards" to be always available on compliant platforms. That's
all I could think of why you ever would want to do it like this yes.
> Two and half questions.
>
> #0.5 Have you checked the tip of 'master' that has Terje's
> patch? It was reported to work yesterday and that is what
> was committed already.
For some reason a normal "pull" didn't show this one here yet. But I can
see it by merging. The commit "c902c9a" that I now see from Terje does
indeed work here. At any rate that one alone doesn't fix the (same)
FreeBSD issue as reported by Rocco Rutte who sent in an almost identical
patch but with the __FreeBSD__ define.
> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I
> do not run a Mac). If MaxOS is derived from FreeBSD, does
> it by chance define __FreeBSD as well?
As far as I know __APPLE__ is the preferred way of finding out we're
running for a Darwin target. Someone mentioned that __APPLE_CC__ was not
introduced until Apple OS X 10.4. It's value here ('5367') is the build
version of the Apple gcc compiler, doesn't seem very standardized. The
__APPLE__ macro is defined as '1'.
Unfortunately no there is _not_ any "BSD" like macro defined here, so no
__FreeBSD or something. And interesting enough we already know that
OpenBSD specifically needs the _XOPEN_SOURCE define. Anyone out there
with a NetBSD box so we can fix that as well? ;-)
> #2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
> Mac, but yours doesn't. Is there a reason that you would
> want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD
> and Mac behave well with it defined?
On Apple compiling git works fine both with and without
_XOPEN_SOURCES_EXTENDED. But looking in the headers, in contrast to the
_XOPEN_SOURCE define which restricts functionality to some predefined
set, the _XOPEN_SOURCES_EXTENDED only adds functionality and doesn't
remove it. So I thought it might be best to keep as much symbols as
possible to be the same for all platforms for future expandibility.
Probably FreeBSD behaves the same with respect to
_XOPEN_SOURCE_EXTENDED. Will check later today.
I don't know if the "Apple Public Source License" allows me to put the
Darwin system headers in a publicly accessable place, so I won't do
that, but if people are interested I can of course privately provide the
system headers and predefined symbols for anyone interested.
--
Marco Roeland
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Alan Chandler @ 2006-12-22 7:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre
In-Reply-To: <7vd56cam66.fsf@assigned-by-dhcp.cox.net>
On Thursday 21 December 2006 23:01, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > [ Hmmm... there used to be many more (remote) branches before.
> > Where are they? Looking into .git/refs I see a remote/ directory
> > and all remote branches are there. But I'm cheating now because a
> > newbie might not even think of looking there.
> >
> > Ah? there is -a and -r options to git-branch. Fair enough. ]
Added snipped content back in
>>
>> $ git branch -r
>> * master
>> origin/HEAD
>> origin/html
>> origin/maint
>> origin/man
>> origin/master
>> origin/next
>> origin/pu
>> origin/todo
And according to the man page git branch -r should print ONLY the remote
branches
>
> A newbie might not even expect to see "many more branches"
> because there is no "before" for him.
>
> > $ git checkout origin/next
> > git checkout: to checkout the requested commit you need to specify
> > a name for a new branch which is created and switched
What about the error message saying that origin/next is read only.
Something like
git-checkout: the requested commit is on a remote read only branch. You
need to specify a new local branch with the -b option to proceed.
> > to
> >
> > [ Hmmmmmmmm.... /me stares at the message wondering.
> > I just want to _see_ and maybe _install_ the code from "next". ]
>
> Rewording to suggest "checkout -b newbranchname origin/next",
> perhaps?
>
> > $ git checkout -b local_next origin/next
>
> "git checkout -b next origin/next" should work just fine, I
> think.
>
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Rocco Rutte @ 2006-12-22 6:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v64c492fv.fsf@assigned-by-dhcp.cox.net>
Hi,
* Junio C Hamano [06-12-21 16:52:52 -0800] wrote:
>Marco Roeland <marco.roeland@xs4all.nl> writes:
>> We want our symbols "avilable" so lets not use _XOPEN_SOURCE on Darwin!
>Personally, I think hiding interfaces such as strXXX and memXXX
>based on _XOPEN_SOURCE level is already a bug in the system
>header implementation. The symbols that begin with str are
>already reserved by the standard and I do not see any point
>in the system headers to try avoiding namespace contamination.
Well, it depends, I'd say. Different strXXX functions may be introduced
by different versions of standards and with _POSIX_C_SOURCE one can, for
example, define to be compile for a specific standard version only.
>Two and half questions.
> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I
> do not run a Mac). If MaxOS is derived from FreeBSD, does
> it by chance define __FreeBSD as well?
> #2 Terje's patch excludes _XOPEN_SOURCE_EXTENDED as well on a
> Mac, but yours doesn't. Is there a reason that you would
> want '#define _XOPEN_SOURCE_EXTENDED 1'? Do both FreeBSD
> and Mac behave well with it defined?
First of all, the combined patch posted is wrong since __FreeBSD doesn't
work on FreeBSD, but __FreeBSD__ does.
Second, a grep over the FreeBSD headers in /usr/include shows that
_XOPEN_SOURCE_EXTENDED only affects 2 curses header files, so it's safe
to exclude it, i.e. define it for FreeBSD.
bye, Rocco
--
:wq!
^ permalink raw reply
* Re: [PATCH] git-tag: support -F <file> option
From: Shawn Pearce @ 2006-12-22 6:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Han-Wen Nienhuys, git
In-Reply-To: <7vvek45svl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > + if test "$#" = "0"; then
> > + die "error: option -F needs an argument"
> > + exit 2
> > + ;;
>
> I know it was copied from Han-Wen's aabd7693, but was this
> somehow to catch the case where die can fail???
What, you haven't heard of the /bin/resurrection shell?
Apparently one of its features is it can sometimes make die return
successfully, even days after the initial call. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-tag: support -F <file> option
From: Junio C Hamano @ 2006-12-22 6:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Han-Wen Nienhuys, git
In-Reply-To: <Pine.LNX.4.63.0612211512160.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This imitates the behaviour of git-commit.
>
> Noticed by Han-Wen Nienhuys.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ok, but what the **** is "die ...; exit 2" sequence?
> @@ -45,6 +45,17 @@ do
> message_given=1
> fi
> ;;
> + -F)
> + annotate=1
> + shift
> + if test "$#" = "0"; then
> + die "error: option -F needs an argument"
> + exit 2
> + else
> + message="$(cat "$1")"
> + message_given=1
> + fi
> + ;;
I know it was copied from Han-Wen's aabd7693, but was this
somehow to catch the case where die can fail???
^ permalink raw reply
* Re: warning merge message
From: Junio C Hamano @ 2006-12-22 6:00 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, Josef Weidendorfer
In-Reply-To: <7vr6us92m2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> Can we please eliminate this message:
>> Warning: No merge candidate found because value of config option
>> "branch.master.merge" does not match any remote branch fetched.
>
> The above message was meant only for "git pull", but was leaked
> even when you did "git fetch"; it was a bug and was corrected
> already (hopefully).
Gaah... it turns out that it was not fixed properly.
Let's do this until we figure out what the correct fix would be.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index ea7511e..871c08f 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -141,8 +141,7 @@ canon_refs_list_for_fetch () {
curr_branch=$(git-symbolic-ref HEAD | \
sed -e 's|^refs/heads/||')
merge_branches=$(git-repo-config \
- --get-all "branch.${curr_branch}.merge") ||
- merge_branches=.this.would.never.match.any.ref.
+ --get-all "branch.${curr_branch}.merge")
fi
set x $(expand_refs_wildcard "$@")
shift
^ permalink raw reply related
* Re: [PATCH] hooks/commit-msg: add example to add Signed-off-by line to message
From: Junio C Hamano @ 2006-12-22 5:45 UTC (permalink / raw)
To: git
In-Reply-To: <200612210924.17357.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> +# Uncomment the below to add a Signed-off-by line to the message.
> +#SOB=$(git var GIT_AUTHOR_IDENT | \
> +# sed -n "s/^\(.*\) [0-9]\+ [-+][0-9]\+$/Signed-off-by: \1/p")
> +#grep -qs "^$SOB" "$1" || echo "$SOB" >> "$1"
I suspect this sed script is quite wrong. Did you test it?
* quoting with dq means you are losing one level of backslash
to the shell and sed is not seeing them.
* one-or-more regexp '+' is typically not found in sed.
Also if this is meant to also handle cases where somebody
commits a patch received from an e-mail chain that multiple
people signed off their own changes to the patch, your name may
already appear earlier in the chain of existing Signed-off-by:
lines to sign off an earlier edition of the patch, but what you
are committing now would include your own changes you just made
on top of what all these people did, and you would want to sign
off that new change as well, I think. So checking the last
instance of the existing signed-off-by line, ignoring earlier
ones, may be more preferrable.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Shawn Pearce @ 2006-12-22 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, Peter Baumann, git
In-Reply-To: <7vfyb87bxg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> And it is not just limited to adding the contents of a path that
> happened to be told git for the first time. Adding the contents
> of a path that was known to git also happens only when it is in
> a presentable good state. So running "git diff" and not seeing
> what I added before is a GOOD THING.
Yes!
Sadly it has taken me 12 months of working with Git to get
comfortable enough with that concept.
Actually it clicked once I realized that 'update-index' was actually
creating the blobs in the ODB and not 'write-tree'. Prior to that
"click" going off in my grey matter I always felt that Git screwed
up when I did:
$ vi foo.c
$ git update-index foo.c
$ git diff
# what the ? where are my changes?
I now make quite heavy use of the index even when hacking on code,
and not just during merges. But I wasn't like that just 5 months
ago...
--
Shawn.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Junio C Hamano @ 2006-12-22 5:10 UTC (permalink / raw)
To: Carl Worth; +Cc: Peter Baumann, git
In-Reply-To: <87d56cirs8.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I complained about this when I first encountered git, and back then I
> said what I thought I wanted was "git diff HEAD" by default. I was
> totally wrong, since diff from the index is so obviously correct for
> resolving a conflict. Junio even responded to my complaints by
> providing a new "git status -v -a" but frankly I've never used
> it.
I guess my responding to whatever you said was wasted effort,
and if you do not like "git add" this time, I should not be
surprised. That's kind of sad ;-).
Jokes aside.
I do not remember who advocated for making "git status" the
preview of "git commit" to happen. Was that also you? I wonder
how many people use this form:
git status -v path1 path2...
Because if even somebody who wanted to have "commit preview" in
"git status" does not use it for that intended purpose, I think
we can reuse the good command name for something more useful,
such as "git explain".
> I'd really like "git diff" to be what I want more often.
Running diff with index is what I do almost all the time. I
think "more often" is different from person to person, but if
"git diff" says nothing on a file that I know I added (and you
cannot argue you do not remember it was a new file here --- you
know you added it and that is why you are complaining about not
seeing it), I'd be happy that I did not accidentally edited it
to munge what I added -- because I add a file only when it is in
a presentable, good state, in a good enough shape to take a
snapshot (not necessarily good enough to commit, though).
And it is not just limited to adding the contents of a path that
happened to be told git for the first time. Adding the contents
of a path that was known to git also happens only when it is in
a presentable good state. So running "git diff" and not seeing
what I added before is a GOOD THING.
> So I suppose I could implement the "add path without updating content"
> I want by doing something like:
>
> mv file file.tmp
> touch file
> git update-index --add file
> mv file.tmp file
>
> There. That gives me the result I want without breaking any git
> internals, (since I'm just building a new operation on top of existing
> git primitives).
Sure, what you want is "git add --no-add newfile", and I can
understand that mode of operation if you are always going to
commit with "git commit -a". Maybe we can have a config
variable that makes "commit -a" and "add --no-add" the default
for these two commands, and we do not have to change anything
else.
One minor detail I wonder about is what mode bits would you give
to that placeholder entry.
> I think the best would be:
>
> git update-index --all
>
> which would still allow room for:
>
> git add --all
Wasn't it you who said "all" is ambiguous (all known to git vs
all in this directory)?
^ 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