* Re: Chicken/egg problem building from a 'git clone'
From: Jeff King @ 2009-03-05 12:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: John Tapsell, Git Mailing List
In-Reply-To: <vpq7i34ywjg.fsf@bauges.imag.fr>
On Thu, Mar 05, 2009 at 01:38:27PM +0100, Matthieu Moy wrote:
> >> * we have lots other files in git.git that are autogenerated (the
> >> documentation files, for example)
> >
> > I'm not aware of any auto-generated files that are checked in. Can you
> > give an example?
>
> man pages and html docs are commited, but in a separate branch. IOW,
> Junio abuses Git as a distribution mechanism, but keeps it totally
> separate from the actual sources.
OK, true; but that is a totally different mechanism, unless the proposal
is to autobuild a "this would be the release tarball" branch similar to
html and man branches.
-Peff
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Matthieu Moy @ 2009-03-05 12:38 UTC (permalink / raw)
To: Jeff King; +Cc: John Tapsell, Git Mailing List
In-Reply-To: <20090305120602.GA18717@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> * we have lots other files in git.git that are autogenerated (the
>> documentation files, for example)
>
> I'm not aware of any auto-generated files that are checked in. Can you
> give an example?
man pages and html docs are commited, but in a separate branch. IOW,
Junio abuses Git as a distribution mechanism, but keeps it totally
separate from the actual sources.
> Yes, it does. Having generated files in your source repository means:
>
> - you generate useless noise commits when those files are
> re-autogenerated
>
> - developers must make sure that they are not accidentally committing
> auto-generated cruft that have nothing to do with their actual
> changes
- You almost certainly get irrelevant conflicts when merging.
- Different developers using different autoconf versions that generate
different code for the same source make even more noise that you'd
expect ;-).
--
Matthieu
^ permalink raw reply
* Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Jonas Fonseca @ 2009-03-05 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903051204010.6524@intel-tinevez-2-302>
On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>
>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>
>> Rebased and then kicked back to 'pu' to give the author a chance to
>> rearrange if necessary. I might do some trivial squashing myself.
>
> Will do.
Although laziness should not be rewarded, this might be something that
you could squash in as well.
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -43,4 +43,4 @@ Documentation by Johannes Schindelin
GIT
---
-Part of the gitlink:git[7] suite
+Part of the linkgit:git[7] suite
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] Documentation - More examples for git bisect
From: John Tapsell @ 2009-03-05 12:36 UTC (permalink / raw)
To: git; +Cc: John Tapsell
Including passing parameters to the programs, and running more
complicated checks without requiring a seperate shell script.
Signed-off-by: John Tapsell
---
Documentation/git-bisect.txt | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 147ea38..e65c1ca 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -212,7 +212,7 @@ If you have a script that can tell if the current source code is good
or bad, you can automatically bisect using:
------------
-$ git bisect run my_script
+$ git bisect run my_script arguments
------------
Note that the "run" script (`my_script` in the above example) should
@@ -252,6 +252,13 @@ $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
$ git bisect run make # "make" builds the app
------------
+* Automatically bisect a test failure between origin and HEAD:
++
+------------
+$ git bisect start HEAD origin -- # HEAD is bad, origin is good
+$ git bisect run make test # "make test" builds and tests
+------------
+
* Automatically bisect a broken test suite:
+
------------
@@ -291,6 +298,15 @@ It's safer if both "test.sh" and "check_test_case.sh" scripts are
outside the repo to prevent interactions between the bisect, make and
test processes and the scripts.
+* Automatically bisect a broken test suite:
++
+------------
+$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
+$ git bisect run sh -c "make || exit 125; ~/check_test_case.sh"
+------------
++
+Does the same as the previous example, but on a single line.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
--
1.6.2.97.g1bcd6.dirty
^ permalink raw reply related
* Re: Chicken/egg problem building from a 'git clone'
From: Jeff King @ 2009-03-05 12:06 UTC (permalink / raw)
To: John Tapsell; +Cc: Git Mailing List
In-Reply-To: <43d8ce650903050337n48924fc3l89ef991d578f5849@mail.gmail.com>
On Thu, Mar 05, 2009 at 11:37:45AM +0000, John Tapsell wrote:
> > ./configure is a generated script. Including it in the repository is not
> > something many projects do, since one of the things developers will be
> > working on is to change how that file is generated. Including it in the
> > release tar-balls is something every project (that uses autoconf) does,
> > since those are aimed at end-users.
>
> Reason that it should be included:
>
> * configure scripts usually are included. git was the first source
> code in a long time that I've seen without one
I think you are confusing "checked into version control" with
"distributed with release tarballs". Most projects do not do the
former[1], but almost all (including git) do the latter.
This discussion is about things checked into the repository.
[1] Sorry, I don't have exact numbers, but I have never encountered this
before.
> * we have lots other files in git.git that are autogenerated (the
> documentation files, for example)
I'm not aware of any auto-generated files that are checked in. Can you
give an example?
> * people are used to being able to do "./configure; make; make install"
Right. They do it from the release tarball. Getting the version straight
from source-control usually means you have to have autoconf if you want
to run it.
> * It doesn't hurt anyone to do it.
Yes, it does. Having generated files in your source repository means:
- you generate useless noise commits when those files are
re-autogenerated
- developers must make sure that they are not accidentally committing
auto-generated cruft that have nothing to do with their actual
changes
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Johannes Sixt @ 2009-03-05 11:55 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <49AF9745.8050207@viscovery.net>
Johannes Sixt schrieb:
> Kjetil Barvik schrieb:
>> - istate->timestamp.sec = st.st_mtime;
>> -#ifdef USE_NSEC
>> + istate->timestamp.sec = (unsigned int)st.st_mtime;
>> istate->timestamp.nsec = (unsigned int)st.st_mtim.tv_nsec;
>> -#else
>> - istate->timestamp.nsec = 0;
>> -#endif
>
> Doesn't this break on systems where st_mtime is time_t and st_mtim does
> not exist?
Yes, it breaks. You can test this on Linux by commenting out these two
lines in git-compat-util.h:
diff --git a/git-compat-util.h b/git-compat-util.h
index dcf4127..ab4b615 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -44,8 +44,8 @@
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
#define _ALL_SOURCE 1
-#define _GNU_SOURCE 1
-#define _BSD_SOURCE 1
+/*#define _GNU_SOURCE 1*/
+/*#define _BSD_SOURCE 1*/
#include <unistd.h>
#include <stdio.h>
The result even passes the test suite (as long as I don't merge
kb/checkout-optim, of course).
-- Hannes
^ permalink raw reply related
* Re: Chicken/egg problem building from a 'git clone'
From: John Tapsell @ 2009-03-05 11:37 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <49AF9601.9060709@op5.se>
2009/3/5 Andreas Ericsson <ae@op5.se>:
> Joi Ellis wrote:
>>
>> On Fri, 6 Feb 2009, Junio C Hamano wrote:
>>
>>> Jeff King <peff@peff.net> writes:
>>>
>>>> Now, in this case, it was only one tweak and other responders have
>>>> already pointed him in the right direction. So just making that tweak
>>>> manually is probably the sane thing to do in this situation.
>>>>
>>>> But I wanted to point out that autoconf is not totally without value
>>>> here.
>>>
>>> I am not saying something that strong, either. If autoconf generated
>>> configure works _for you_ without hassle, great. Keep using it.
>>>
>>> The original message that started this thread was what to do when it does
>>> NOT work for you, and my point was in general it is much nicer to point
>>> at
>>> the knob to tweak from the make invocation command line (or in
>>> config.mak)
>>> than having you spend time on upgrade autoconf, generate configure and
>>> run
>>> it.
>>
>> Actually, guys, if you go back and re-read my original message, I was
>> pointing out that if you use a 'git clone' to get a build tree, THERE IS
>> NO CONFIGURE SCRIPT in the tree.
>>
>> The problem is not that the configure script does not work. I pointed
>> out in the first paragraph that the configure script in the TARBALL
>> works just fine. What I pointed out is that the build tree DOES NOT
>> PROVIDE THE CONFIGURE SCRIPT. All I asked you to do is to consider
>> adding the configure script to the repository so that it gets pushed out
>> in a clone.
>>
>>> Fanboys may say that autoconf generated configure is the greatest thing
>>> since sliced bread. But let's face it. Honestly, the track record of
>>> those people in keeping autoconf part in this project up-to-date has not
>>> been all that great. There are things that the generated configure file
>>> does not detect nor configure correctly (we had --with-expat patch, and
>>> we
>>> also saw "the trailing slash in template_dir definition in config.mak.in"
>>> discussed fairly recently). You are much better off tweaking known
>>> peculiarity of your platform in config.mak, when configure does not work
>>> out of box for you.
>>
>> I've been building and installing multi-platform *nix software on
>> various flavors for two decades now. "./configure && make && make
>> install" has been the standard build process even before GNU. The whole
>> point of
>> autoconf/configure/make tools is to eliminate the need to manually tweak
>> makefiles so that software is easily portable between platforms.
>
> ./configure is a generated script. Including it in the repository is not
> something many projects do, since one of the things developers will be
> working on is to change how that file is generated. Including it in the
> release tar-balls is something every project (that uses autoconf) does,
> since those are aimed at end-users.
Reason that it should be included:
* configure scripts usually are included. git was the first source
code in a long time that I've seen without one
* we have lots other files in git.git that are autogenerated (the
documentation files, for example)
* people are used to being able to do "./configure; make; make install"
* It doesn't hurt anyone to do it.
John
^ permalink raw reply
* Re: bisect run, was Re: More git bisect modes
From: Johannes Schindelin @ 2009-03-05 11:31 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Nanako Shiraishi, Git Mailing List
In-Reply-To: <43d8ce650903050318g6ab81e6es9869b9f526c5eb24@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 591 bytes --]
Hi,
On Thu, 5 Mar 2009, John Tapsell wrote:
> 2009/3/5 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > That reminds me of a personal gripe with "bisect run": You cannot use it
> > like this:
> >
> > $ git bisect run 'make test'
> >
> > as it interprets 'make test' as a name of an executable. That makes
> > 'bisect run' rather less useful to me.
>
> A very quick test seems to show that:
>
> $ git bisect run make test
>
> Works as you want. Maybe a quick example of this could be added to
> the man page.
Indeed, the source code agrees with you.
Thanks,
Dscho
^ permalink raw reply
* Re: bisect run, was Re: More git bisect modes
From: John Tapsell @ 2009-03-05 11:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903051207480.6524@intel-tinevez-2-302>
2009/3/5 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>
>> [...] personally I never felt the need for "run" to work without any bad
>> one, as the first few rounds would almost always end up to be a
>> debugging session of the run script for me, as in:
>>
>> ... oh, somebody broke this somewhere ...
>> ... write a validate script ...
>> $ edit runme ; chmod +x runme
>> $ ./runme
>> ... yeah, it is broken and runme script detects breakage
>> $ git checkout HEAD~200
>> $ ./runme
>> ... ok, it used to work here and runme exits Ok
>> $ git bisect good
>> $ git bisect bad @{-1}
>> $ ./runme
>> ... ok, runme script appears to be ok
>> $ git bisect run ./runme
>
> That reminds me of a personal gripe with "bisect run": You cannot use it
> like this:
>
> $ git bisect run 'make test'
>
> as it interprets 'make test' as a name of an executable. That makes
> 'bisect run' rather less useful to me.
A very quick test seems to show that:
$ git bisect run make test
Works as you want. Maybe a quick example of this could be added to
the man page.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* bisect run, was Re: More git bisect modes
From: Johannes Schindelin @ 2009-03-05 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Nanako Shiraishi, Git Mailing List
In-Reply-To: <7vvdqo1csl.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 5 Mar 2009, Junio C Hamano wrote:
> [...] personally I never felt the need for "run" to work without any bad
> one, as the first few rounds would almost always end up to be a
> debugging session of the run script for me, as in:
>
> ... oh, somebody broke this somewhere ...
> ... write a validate script ...
> $ edit runme ; chmod +x runme
> $ ./runme
> ... yeah, it is broken and runme script detects breakage
> $ git checkout HEAD~200
> $ ./runme
> ... ok, it used to work here and runme exits Ok
> $ git bisect good
> $ git bisect bad @{-1}
> $ ./runme
> ... ok, runme script appears to be ok
> $ git bisect run ./runme
That reminds me of a personal gripe with "bisect run": You cannot use it
like this:
$ git bisect run 'make test'
as it interprets 'make test' as a name of an executable. That makes
'bisect run' rather less useful to me.
Ciao,
Dscho
^ permalink raw reply
* notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Johannes Schindelin @ 2009-03-05 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpsg2sgx.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 5 Mar 2009, Junio C Hamano wrote:
> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
> - tests: fix "export var=val"
> - notes: refuse to edit notes outside refs/notes/
> - t3301: use test_must_fail instead of !
> - t3301: fix confusing quoting in test for valid notes ref
> - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
> - notes: only clean up message file when editing
> - handle empty notes gracefully
> - git notes show: test empty notes
> - git-notes: fix printing of multi-line notes
> - notes: fix core.notesRef documentation
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
>
> Rebased and then kicked back to 'pu' to give the author a chance to
> rearrange if necessary. I might do some trivial squashing myself.
Will do.
Thanks,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Jeff King @ 2009-03-05 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpsg2sgx.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 05, 2009 at 02:07:26AM -0800, Junio C Hamano wrote:
> * mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
> - Add a test of "git cvsimport"'s handling of tags and branches
> - Add some tests of git-cvsimport's handling of vendor branches
> - Test contents of entire cvsimported "master" tree contents
> - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
> - Start a library for cvsimport-related tests
>
> Tests without fixes are of dubious value. Any takers?
At the very least, I think the first 3 are nice infrastructure cleanups
that will help future tests for cvsimport. So it makes sense to me to
apply them to help future testers (otherwise, they would have to know
that these patches existed and dig them out of the list).
The final two introduce the new tests. They look fine as far as fitting
into the test infrastructure, but I have to admit that I haven't
actually looked closely at _what_ they are testing. I assumed since they
are adapted from Michael's cvs2svn tests that they are showing real
problems that he had faced there. If they are meant to show failings of
cvsps-based conversion (which is my understanding from Michael's other
messages), then I'm not even sure they _are_ fixable without a total
rewrite.
So I don't know whether it makes sense to apply them if we never plan on
fixing them. Michael said his goal was to document problems with
cvsps-based importing, and I think he has done that in a way that will
help anyone who wants to try fixing. We can help people out a little
more by carrying the tests in the tree (versus making them pull them
from the list); the downside is that it may take the test suite a little
longer to run. I don't know how much we care; it might not matter for 2
tests, but I certainly wouldn't want to 30 minutes of testing for
something that isn't fixable (and CVS tests tend to be terribly slow).
-Peff
^ permalink raw reply
* Re: [PATCH] '%S' option for pretty printing to support --source
From: Johannes Schindelin @ 2009-03-05 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Petri Hodju, Deskin Miller, git, gitster
In-Reply-To: <20090305091758.GC30445@coredump.intra.peff.net>
Hi,
On Thu, 5 Mar 2009, Jeff King wrote:
> On Thu, Mar 05, 2009 at 09:18:28AM +0200, Petri Hodju wrote:
>
> > +static void format_source(struct strbuf *sb, const struct commit *commit)
> > +{
> > + if (commit->util)
> > + strbuf_addstr(sb, (char *) commit->util);
> > +}
> > +
>
> Hmm. This is the second patch in the last few weeks to use commit->util
> to carry information for --pretty=format: (I am cc'ing Deskin Miller,
> who wrote the first).
>
> They cannot both work, obviously. So we need to do one of:
>
> - refactor the information out of commit->util to somewhere else
>
> - allow multiple commit->util users somehow (which I think is a
> potential performance problem -- the simplistic design is meant to
> avoid things like allocation overhead)
The common way to do this is to use struct decoration. I was under the
impression that --source already used that method (IIRC both --source and
struct decoration come from Linus, the latter of which having been
rejected when I submitted it as a struct object_hash patch, which would
have been a better name IMHO).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] http authentication via prompts
From: Johannes Schindelin @ 2009-03-05 10:55 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49AF25BF.5060706@gmail.com>
Hi,
Disclaimer: if you are offended by constructive criticism, or likely to
answer with insults to the comments I offer, please stop reading this mail
now (and please do not answer my mail, either). :-)
Still with me? Good. Nice to meet you.
Just for the record: responding to a patch is my strongest way of saying
that I appreciate your work.
On Wed, 4 Mar 2009, Mike Gaffney wrote:
> Currently git over http only works with a .netrc file which required
> that you store your password on the file system in plaintext. This
> commit adds to configuration options for http for a username and an
> optional password. If a http.username is set, then the .netrc file is
> ignored and the username is used instead. If a http.password is set,
> then that is used as well, otherwise the user is prompted for their
> password.
>From the subject, I would have expected a way to type in the password
instead of storing it. (Think getpass()... which would pose problems
with Windows support, of course.)
FWIW by having it in .git/config (which is most likely more world-readable
than $HOME/.netrc ever will be) does not provide any security over .netrc.
And I doubt that http.username is a good choice: what if you have multiple
http:// URLs with different usernames/passwords? So would it not make
more sense to make this remote.<name>.user and ...password?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH 2/2] make remote hangup warnings more friendly
From: Jeff King @ 2009-03-05 10:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20090304190452.GJ14365@spearce.org>
On Wed, Mar 04, 2009 at 11:04:52AM -0800, Shawn O. Pearce wrote:
> Hmm. It would be nice to clean up these messages, but I
> think the better way to do it is...
>
> > I think this would be improved somewhat with stderr processing to:
> >
> > remote: sh: bogus: command not found
>
> ... because then we can have positive proof that the remote said
> something to the user, and we tagged it as being from the remote
> side, just like we do with progress data in sideband, and then the
> user can work from that information. Any local side errors are
> very likely caused by the remote errors, so we shouldn't bother
> displaying them.
OK. I was hoping to avoid that because it's more work, but I think it is
a better path in the long run. I'll add it to do my todo list. Unless
you want to redeem yourself by working on it first. ;)
-Peff
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-05 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git
In-Reply-To: <7vtz6bdmfi.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 12:45:37AM -0800, Junio C Hamano wrote:
> Miles Bader <miles@gnu.org> writes:
>
> > I can use "git log --date=iso" to get YYYY-MM-DD format for dates, or
> > "git log --date=local" to force the dates to use my local time zone, but
> > if I use _both_ of these options together, it uses only the last one,
> > and ignores any preceding --date (even those in this case, the two
> > --date options affect orthogonal properties of dates). Is there a way
> > to get YYYY-MM-DD format dates, but in my local time-zone?
>
> No, there isn't.
>
> But this patch may help you get started.
FWIW, I think this is the wrong direction. You are working around the
lack of orthogonality in the interface by tweaking things in the
implementation. I think you are better to fix the interface, but support
--date=local for historical reasons. IOW,
git log --local-dates --date=short
with
git log --date=local
as a historical synonym for
git log --local-dates --date=default
This makes the interface simpler to understand: --date remains a
selector, and --date=local is a special case that new people don't need
to think about or understand.
-Peff
^ permalink raw reply
* Re: just curious: what influences a commit hash?
From: Matthieu Moy @ 2009-03-05 10:38 UTC (permalink / raw)
To: stoecher; +Cc: git
In-Reply-To: <20090305063632.42880@gmx.net>
stoecher@gmx.at writes:
> Hi,
>
> being new to git I did some experiments with commits looking at the hashes. What I observed:
> * The same commit (same file, same committer, same message) into
> different empty repositories (git init) gives different hashes. So I
> assume that also the time of the commit influences the hash. Is this
> intended? For what reason?
You should distinguish "commit objects" from "tree objects". You can
see the "commit" object with, for example:
$ git cat-file -p HEAD
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author Matthieu Moy <Matthieu.Moy@imag.fr> 1236249249 +0100
committer Matthieu Moy <Matthieu.Moy@imag.fr> 1236249249 +0100
foo
See: it contains a reference to the tree, possibly references to the
parents, and a timestamp. So, hashing it takes the timestamp into
account. A consequence of this is that you can not change the
timestamp for a commit without changing the "revision identifier"
(i.e. the hash of the commit object).
But the empty tree object is deterministically
4b825dc642cb6eb9a060e54bf8d69288fbee4904.
--
Matthieu
^ permalink raw reply
* Re: [RFC/PATCH 1/2] improve missing repository error message
From: Jeff King @ 2009-03-05 10:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20090304185742.GI14365@spearce.org>
On Wed, Mar 04, 2009 at 10:57:42AM -0800, Shawn O. Pearce wrote:
> > > IMHO, maybe we also should change the error message that receive-pack
> > > produces when the path its given isn't a Git repository. Its really
> > > not very human friendly to say "unable to chdir or not a git archive".
> > > Hell, we don't even call them archives, we call them repositories.
>
> I really mean to write this patch myself, I haven't done much for
> git lately. But I got sidetracked yesterday and forgot. Thank you
> for doing it for me.
I think you are OK coasting on past glory for a while longer:
$ git shortlog -ns | egrep -im2 'jeff|shawn'
1313 Shawn O. Pearce
305 Jeff King
:)
> > Perhaps this should match the local "Not a git repository: %s". I prefer
> > this text, but maybe there is value in consistency.
>
> FWIW I also prefer the text you used in the patch...
I don't know if it is worth changing the _local_ one to match this,
then. I seem to recall some discussion about that message recently.
Personally I find the "Not a git repository (or any of the parent
directories)" wording to be quite awkward.
-Peff
^ permalink raw reply
* Re: More git bisect modes
From: Junio C Hamano @ 2009-03-05 10:31 UTC (permalink / raw)
To: John Tapsell; +Cc: Nanako Shiraishi, Git Mailing List
In-Reply-To: <43d8ce650903050217m2885692dkcef08ab2a5f60082@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> 2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
>> Quoting John Tapsell <johnflux@gmail.com>:
>>
>>> * An exponential back-off. Typically I know that HEAD is broken, and
>>> I don't know when it used to work.
>>
>> I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?
>
> I believe this makes it start from the very first commit. This
> probably much further back than most people would actually want to
> start from.
> (Also there seems to be a bug here, in that 'git bisect run' requires
> you to have both a good and a bad commit. Also the man page doesn't
> document this)
Hmm, interesting. I am sure we will soon hear from Christian, but
personally I never felt the need for "run" to work without any bad one, as
the first few rounds would almost always end up to be a debugging session
of the run script for me, as in:
... oh, somebody broke this somewhere ...
... write a validate script ...
$ edit runme ; chmod +x runme
$ ./runme
... yeah, it is broken and runme script detects breakage
$ git checkout HEAD~200
$ ./runme
... ok, it used to work here and runme exits Ok
$ git bisect good
$ git bisect bad @{-1}
$ ./runme
... ok, runme script appears to be ok
$ git bisect run ./runme
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Junio C Hamano @ 2009-03-05 10:22 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090305191221.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> * jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
>> + never fallback relative times to absolute
>>
>> I think I sent out a "here is how" patch for something related to
>> --date=<format> option that may be related to this topic; I seem to have
>> lost it.
>
> Do you mean this one?
>
> http://article.gmane.org/gmane.comp.version-control.git/112033
Yup, that's the one. Thanks.
^ permalink raw reply
* Re: How to ignore a modified file?
From: Junio C Hamano @ 2009-03-05 10:21 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Quim K Holland, dealmaker, git
In-Reply-To: <fabb9a1e0903050209i1e70c8b3n69d7ade9e382b617@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Thu, Mar 5, 2009 at 09:53, Quim K Holland <qkholland@gmail.com> wrote:
>> You can run "git checkout directory".
>
> Yes, but that would destroy his changes, I do not get the impression
> that that's what he wants...
Actually, I thought the advises from you two were both horrible without
first qualifying the answers nor asking what was really wanted.
Yours didn't *ignore* changes, but staged (and would result in a later
commit) a different change to these paths, namely removal of them.
"I have these changes but I want to ignore" may mean "I didn't mean to
change them and do not care about them." and "checkout" may be the right
thing to use if that is the case.
^ permalink raw reply
* Re: More git bisect modes
From: John Tapsell @ 2009-03-05 10:17 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Git Mailing List
In-Reply-To: <20090305190542.6117@nanako3.lavabit.com>
2009/3/5 Nanako Shiraishi <nanako3@lavabit.com>:
> Quoting John Tapsell <johnflux@gmail.com>:
>
>> * An exponential back-off. Typically I know that HEAD is broken, and
>> I don't know when it used to work.
>
> I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?
I believe this makes it start from the very first commit. This
probably much further back than most people would actually want to
start from.
(Also there seems to be a bug here, in that 'git bisect run' requires
you to have both a good and a bad commit. Also the man page doesn't
document this)
John Tapsell
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Nanako Shiraishi @ 2009-03-05 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpsg2sgx.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> * jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
> + never fallback relative times to absolute
>
> I think I sent out a "here is how" patch for something related to
> --date=<format> option that may be related to this topic; I seem to have
> lost it.
Do you mean this one?
http://article.gmane.org/gmane.comp.version-control.git/112033
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: How to ignore a modified file?
From: Sverre Rabbelier @ 2009-03-05 10:09 UTC (permalink / raw)
To: Quim K Holland; +Cc: dealmaker, git
In-Reply-To: <20090305145308.6117@qkholland.gmail.com>
Heya,
On Thu, Mar 5, 2009 at 09:53, Quim K Holland <qkholland@gmail.com> wrote:
> You can run "git checkout directory".
Yes, but that would destroy his changes, I do not get the impression
that that's what he wants...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Junio C Hamano @ 2009-03-05 10:07 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
The master branch is slightly past 1.6.2, but embarrasingly enough we
already have a real commit on 'maint'.
----------------------------------------------------------------
[New Topics]
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
- cvsimport: add test illustrating a bug in cvsps
Yet more tests without fixing anything...
* jc/clone-branch-rebase (Tue Mar 3 22:29:55 2009 -0800) 1 commit
- Make git-clone respect branch.autosetuprebase
This is rewrite of a patch from Pat Notz.
* mg/maint-submodule-normalize-path (Tue Mar 3 16:08:21 2009 +0100) 2 commits
- git submodule: Fix adding of submodules at paths with ./, .. and //
- git submodule: Add test cases for git submodule add
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
- stat_tracking_info(): only count real commits
This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking. Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch. But I do not feel very strongly about it.
* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
- rebase -i: avoid 'git reset' when possible
----------------------------------------------------------------
[Will merge to 'master' soon]
* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
+ never fallback relative times to absolute
I think I sent out a "here is how" patch for something related to
--date=<format> option that may be related to this topic; I seem to have
lost it.
* js/send-email (Mon Mar 2 23:52:18 2009 -0500) 5 commits
+ send-email: add --confirm option and configuration setting
+ send-email: don't create temporary compose file until it is needed
+ send-email: --suppress-cc improvements
+ send-email: handle multiple Cc addresses when reading mbox message
+ send-email: allow send-email to run outside a repo
* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
+ rerere: remove duplicated functions
* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
+ git-add -i/-p: learn to unwrap C-quoted paths
* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
+ imap.preformattedHTML to tell Thunderbird to send non-flowed text
The patch text should be identical to Jeremy's "Virtual Patch", except
that the configuration variable was renamed per list discussion.
* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
+ Enable setting attach as the default in .gitconfig for git-format-
patch.
* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
+ Teach rebase to rebase even if upstream is up to date
* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
+ Support "\" in non-wildcard exclusion entries
* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
+ add -i: revisit hunk on editor failure
* tp/completion (Sat Feb 21 15:48:43 2009 +0100) 6 commits
+ Fixup: Add bare repository indicator for __git_ps1
+ Add bare repository indicator for __git_ps1
+ completion: More fixes to prevent unbound variable errors
+ completion: Better __git_ps1 support when not in working directory
+ completion: Use consistent if [...] convention, not "test"
+ completion: For consistency, change "git rev-parse" to __gitdir
calls
* js/branch-symref (Wed Feb 18 22:34:44 2009 -0500) 4 commits
+ add basic branch display tests
+ branch: clean up repeated strlen
+ Avoid segfault with 'git branch' when the HEAD is detached
+ builtin-branch: improve output when displaying remote branches
* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
+ builtin-branch.c: Rename branch category color names
+ Clean up use of ANSI color sequences
* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
+ valgrind: do not require valgrind 3.4.0 or newer
+ test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
+ Tests: let --valgrind imply --verbose and --tee
+ Add a script to coalesce the valgrind outputs
+ t/Makefile: provide a 'valgrind' target
+ test-lib.sh: optionally output to test-results/$TEST.out, too
+ Valgrind support: check for more than just programming errors
+ valgrind: ignore ldso and more libz errors
+ Add valgrind support in test scripts
* fc/config-editor (Sat Feb 21 02:48:54 2009 +0200) 3 commits
+ git config: trivial cleanup for editor action
+ git config: codestyle cleanups
+ config: Add new option to open an editor.
Rerolled and looked sane.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. Jakub seems to want this for gitweb.
* ns/pretty-format (Tue Feb 24 15:33:29 2009 +0200) 5 commits
+ bash completion: add --format= and --oneline options for "git log"
+ Add tests for git log --pretty, --format and --oneline.
+ Add --oneline that is a synonym to "--pretty=oneline --abbrev-
commit"
+ Give short-hands to --pretty=tformat:%formatstring
+ Add --format that is a synonym to --pretty
----------------------------------------------------------------
[Discarded]
* js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
. parse_options(): do not "increment" boolean
. clone: ignore --depth when cloning locally (implicitly --local)
. clone: do not ignore --no-local option
Jeff had a good suggestion for this series but it was tripped by
a misfeature in parse_options().
* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
. stash: --keep option just saves
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I think the code is much cleaner than the first round, but I am not
convinced it is doing the right thing in the connectivity traverser.
Independent review sorely needed.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien seems to have stalled, but
Jakub seems to be taking this over, so I'll probably discard these three
shortly.
----------------------------------------------------------------
[Actively cooking]
* kb/checkout-optim (Wed Mar 4 18:47:40 2009 +0100) 15 commits
- better introduction of GIT with USE_NSEC defined
+ write_index(): update index_state->timestamp after flushing to
disk
+ verify_uptodate(): add ce_uptodate(ce) test
+ make USE_NSEC work as expected
+ fix compile error when USE_NSEC is defined
+ check_updates(): effective removal of cache entries marked
CE_REMOVE
+ lstat_cache(): print a warning if doing ping-pong between cache
types
+ show_patch_diff(): remove a call to fstat()
+ write_entry(): use fstat() instead of lstat() when file is open
+ write_entry(): cleanup of some duplicated code
+ create_directories(): remove some memcpy() and strchr() calls
+ unlink_entry(): introduce schedule_dir_for_removal()
+ lstat_cache(): swap func(length, string) into func(string, length)
+ lstat_cache(): generalise longest_match_lstat_cache()
+ lstat_cache(): small cleanup and optimisation
* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits
- optimize compat/ memmem()
- diffcore-pickaxe: use memmem()
As always with patches from René, this is already next material.
* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
- Push to create
This was a failed weatherbaloon patch to allow creation of a new
repository from the remote side. Will discard.
* mv/parseopt-ls-files (Tue Feb 17 15:27:11 2009 +0100) 2 commits
- parse-opt: migrate builtin-ls-files.
- Turn the flags in struct dir_struct into a single variable
* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits
- git-pull: Allow --stat and --no-stat to be used with --rebase
- git-rebase: Add --stat and --no-stat for producing diffstat on
rebase
* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
- clone: run post-checkout hook when checking out
* js/remote-improvements (Wed Feb 25 03:32:28 2009 -0500) 22 commits
- builtin-remote: new show output style for push refspecs
- builtin-remote: new show output style
- remote: make guess_remote_head() use exact HEAD lookup if it is
available
- builtin-remote: add set-head subcommand
- builtin-remote: teach show to display remote HEAD
- builtin-remote: fix two inconsistencies in the output of "show
<remote>"
- builtin-remote: make get_remote_ref_states() always populate
states.tracked
- builtin-remote: rename variables and eliminate redundant function
call
- builtin-remote: remove unused code in get_ref_states
- builtin-remote: refactor duplicated cleanup code
- string-list: new for_each_string_list() function
- remote: make match_refs() not short-circuit
- remote: make match_refs() copy src ref before assigning to
peer_ref
- remote: let guess_remote_head() optionally return all matches
- remote: make copy_ref() perform a deep copy
- remote: simplify guess_remote_head()
- move locate_head() to remote.c
- move duplicated ref_newer() to remote.c
- move duplicated get_local_heads() to remote.c
- refactor find_ref_by_name() to accept const list
- add basic http clone/fetch tests
- test scripts: refactor start_httpd helper
* fc/parseopt-config (Sat Feb 21 02:49:29 2009 +0200) 11 commits
- git config: don't allow --get-color* and variable type
- git config: don't allow extra arguments for -e or -l.
- git config: don't allow multiple variable types
- git config: don't allow multiple config file locations
- git config: reorganize to use parseopt
- git config: reorganize get_color*
- git config: trivial rename in preparation for parseopt
- git_config(): not having a per-repo config file is not an error
+ git config: trivial cleanup for editor action
+ git config: codestyle cleanups
+ config: Add new option to open an editor.
* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits
- format-patch: support deep threading
- format-patch: thread as reply to cover letter even with in-reply-
to
- format-patch: track several references
- format-patch: threading test reactivation
* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
- Make git blame's date output format configurable, like git log
I think the above seven series were basically Ok; I'll hopefully have time
to re-read them and merge them to 'next'.
* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
- Add a test of "git cvsimport"'s handling of tags and branches
- Add some tests of git-cvsimport's handling of vendor branches
- Test contents of entire cvsimported "master" tree contents
- Use CVS's -f option if available (ignore user's ~/.cvsrc file)
- Start a library for cvsimport-related tests
Tests without fixes are of dubious value. Any takers?
* tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
- send-email: respect in-reply-to regardless of threading
Tests?
* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits
+ is_kept_pack(): final clean-up
+ Simplify is_kept_pack()
+ Consolidate ignore_packed logic more
+ has_sha1_kept_pack(): take "struct rev_info"
+ has_sha1_pack(): refactor "pretend these packs do not exist"
interface
+ git-repack: resist stray environment variable
This is in response to Linus's "Really slow 'git gc'" ($gmane/110743)
* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
+ Ensure proper setup of git_dir for git-hash-object
Obvious fix that can also go to 1.6.1.X
* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
- Test git-patch-id
- Test rev-list --parents/--children
- Test log --decorate
- Test fsck a bit harder
- Test log --graph
- Test diff --dirstat functionality
- Test that diff can read from stdin
- Support coverage testing with GCC/gcov
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
- git notes show: test empty notes
- git-notes: fix printing of multi-line notes
- notes: fix core.notesRef documentation
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
Rebased and then kicked back to 'pu' to give the author a chance to
rearrange if necessary. I might do some trivial squashing myself.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This was only meant as a weatherballoon to help facilitate discussion.
Will be discarded.
^ 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