* [ANNOUNCE] TortoiseGit 0.4.1.0 release
From: Frank Li @ 2009-03-05 15:10 UTC (permalink / raw)
To: tortoisegit-dev, tortoisegit-users, git, tortoisegit-announce
TortoiseGit 0.3.3 released.
http://code.google.com/p/tortoisegit/downloads/list
Features:
*Full Overlay Icon Support.
Show "Conflict, ignore file, untracked file, modified, Add, staged"
icon according to file status.
*Rebase Support.
Support "Pick" "Sqaush" "Edit" and "Skip" commit when
rebase branch.
Support abort.
*Combine Multi-commits to one commit.
Combine continous commits to one commit. The limition is the only
single line(no merge point) above combined commit.
*Cherry Pick multi commits.
User can use multi commits at log dialog and then choose cherry pick
these. Cherry Pick dialog guide you finish whole work.
Support "Pick" "Squash" "Edit" and "Skip" commits.
*First x64 version.
*Support version "browse" at switch, export, new branch/tag and merge dialogs.
*Add context menu item "Revert" at Commit dialog File List.
*Show bold font for HEAD at log dialog.
*Add "Whole Project" checkbox at commit dialog
*First Version Help Document.
Bug Fix:
*Fix issue 36, Push not working if no remote branch is specified
*Default UnCheck untrack file at commit dialog
*Issue 40: Commit from subfolder shows unversioned files in parent
*Fix diff problem when filenames have embedded spaces
*Fix Issue 24,45, Commit results not in window with scroll bars
*Fix for win2k context menu icons
*Fix Issue 46, The about window title still displays TortoiseSVN
*Fix Issue 37, When the file name contains Chinese char, Diff doesn't work.
*Fix Issue 28, "Add" status icon overlay is not correct.
*Fixed x64 build of TortoiseProc crashed due to
received unexpected messages
*Fix tag to head when *force* check box checked
*Add Git document to help
Known Issue:
*Git clone can't support git protocol. SSH need enable
TortoisePLink
as SSH client. User should use setting dialog network
page to setup
TortoisePLink as SSH client.
*Git clone can't capture TortoisePLink output. So there are no
progress info during download from remote repository.
*64bit setup package can not auto installed MFC 9.0
and ATL 9.0 Redistribute package.
Work around: install MFC 9.0 and ATL 9.0 redistribute
package before install 64bit tortoisegit.
^ permalink raw reply
* Re: How to ignore a modified file?
From: Sverre Rabbelier @ 2009-03-05 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Quim K Holland, dealmaker, git
In-Reply-To: <7v4oy82rt4.fsf@gitster.siamese.dyndns.org>
Heya,
On Thu, Mar 5, 2009 at 11:21, Junio C Hamano <gitster@pobox.com> wrote:
> Yours didn't *ignore* changes, but staged (and would result in a later
> commit) a different change to these paths, namely removal of them.
You are of course right, thank you for pointing it out.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* 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
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