* [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Brian Gernhardt @ 2009-01-29 16:00 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
The call to "git reset --hard B1" failed on case-insensitive file
systems (such as the default settings for HFS+) because there was both
a tag "B1" and a file "b1". Adding "--" to the command makes it
clear that we mean commit B1.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
t/t3411-rebase-preserve-around-merges.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index 6533505..e544451 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -24,7 +24,7 @@ test_expect_success 'setup' '
test_commit A1 &&
test_commit B1 &&
test_commit C1 &&
- git reset --hard B1 &&
+ git reset --hard B1 -- &&
test_commit D1 &&
test_merge E1 C1 &&
test_commit F1
--
1.6.1.2.418.gd79e6.dirty
^ permalink raw reply related
* Re: [PATCH] contrib: add 'git bpush' to push to bundles
From: Santi Béjar @ 2009-01-29 16:05 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20090120064732.GA14580@glandium.org>
2009/1/20 Mike Hommey <mh@glandium.org>:
> On Tue, Jan 20, 2009 at 12:46:31AM +0100, Santi Béjar wrote:
>> 'git bpush' updates the branches in a bundle, while adding the objects
>> necessary to complete the given branches. Basically, it is a 'git
>> push' for bundles.
>
> I think it'd be better to improve git-push to support that, instead of
> adding yet another git command.
Yes, I also think it'd be better if git-push supports it, but this is
not a trivial task, and my script works now. So I think it makes sense
to add it to the *contrib* directory.
Santi
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Johannes Schindelin @ 2009-01-29 16:13 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Junio C Hamano
In-Reply-To: <1233244816-67565-1-git-send-email-benji@silverinsanity.com>
Hi,
On Thu, 29 Jan 2009, Brian Gernhardt wrote:
> The call to "git reset --hard B1" failed on case-insensitive file
> systems (such as the default settings for HFS+) because there was both
> a tag "B1" and a file "b1". Adding "--" to the command makes it
> clear that we mean commit B1.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Sigh.
ACK and thanks,
Dscho
^ permalink raw reply
* Re: diff settings
From: Ted Pavlic @ 2009-01-29 16:26 UTC (permalink / raw)
To: Keith Cascio; +Cc: Teemu Likonen, git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <497D1AB7.7000208@tedpavlic.com>
> This task is pretty easy in Mercurial because Mercurial porcelains are
> implemented as modules that are all executed through the central "hg"
> command. This isn't the case with git.
(on the other hand, having a "[defaults]" section that only applies when
commands are called via "git" might be nice. That way you can use the
"git-CMD" when you want to use CMD without the "[defaults]"... perhaps?)
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* [PATCH] Fix 'git diff --no-index' with a non-existing symlink target
From: Johannes Schindelin @ 2009-01-29 16:30 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <cover.1233246616u.git.johannes.schindelin@gmx.de>
When trying to find out mode changes, we should not access the symlink
targets using stat(); instead we use lstat() so that the diff does
not fail trying to find a non-existing symlink target.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff-no-index.c | 2 +-
t/t4011-diff-symlink.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 60ed174..0dbd9da 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -40,7 +40,7 @@ static int get_mode(const char *path, int *mode)
*mode = 0;
else if (!strcmp(path, "-"))
*mode = create_ce_mode(0666);
- else if (stat(path, &st))
+ else if (lstat(path, &st))
return error("Could not access '%s'", path);
else
*mode = st.st_mode;
diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh
index 02efeca..9055c8b 100755
--- a/t/t4011-diff-symlink.sh
+++ b/t/t4011-diff-symlink.sh
@@ -82,4 +82,11 @@ test_expect_success \
git diff-index -M -p $tree > current &&
compare_diff_patch current expected'
+test_expect_success \
+ 'diff symlinks with non-existing targets' \
+ 'ln -s narf pinky &&
+ ln -s take\ over brain &&
+ test_must_fail git diff --no-index pinky brain > output 2> output.err &&
+ grep narf output &&
+ ! grep error output.err'
test_done
--
1.6.1.2.531.g6f52
^ permalink raw reply related
* Re: diff settings
From: Johannes Schindelin @ 2009-01-29 16:33 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Keith Cascio, Teemu Likonen, git, Junio C Hamano
In-Reply-To: <4981D8AD.6000000@tedpavlic.com>
Hi,
On Thu, 29 Jan 2009, Ted Pavlic wrote:
> > This task is pretty easy in Mercurial because Mercurial porcelains are
> > implemented as modules that are all executed through the central "hg"
> > command. This isn't the case with git.
>
> (on the other hand, having a "[defaults]" section that only applies when
> commands are called via "git" might be nice. That way you can use the
> "git-CMD" when you want to use CMD without the "[defaults]"... perhaps?)
Nope, the dash form is deprecated, and once y'all out there finally do not
write it any more, we can start thinking about _not_ hardlinking the
builtins to their dashed form anymore.
Believe it or not, we already have a distinction between what is called
from scripts vs from humans: plumbing vs porcelain. So you can set the
defaults for porcelain as much as you want, but please leave plumbing
alone.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Junio C Hamano @ 2009-01-29 17:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git List, Brian Gernhardt
In-Reply-To: <1233244816-67565-1-git-send-email-benji@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> The call to "git reset --hard B1" failed on case-insensitive file
> systems (such as the default settings for HFS+) because there was both
> a tag "B1" and a file "b1". Adding "--" to the command makes it
> clear that we mean commit B1.
>
> Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> ---
> t/t3411-rebase-preserve-around-merges.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
> index 6533505..e544451 100755
> --- a/t/t3411-rebase-preserve-around-merges.sh
> +++ b/t/t3411-rebase-preserve-around-merges.sh
> @@ -24,7 +24,7 @@ test_expect_success 'setup' '
> test_commit A1 &&
> test_commit B1 &&
> test_commit C1 &&
> - git reset --hard B1 &&
> + git reset --hard B1 -- &&
> test_commit D1 &&
> test_merge E1 C1 &&
> test_commit F1
It is not just B1 that is ambiguous, even though that is the only
ambiguous one this particular test uses.
If we really wanted to care about case-folding file systems, shouldn't we
make test_commit shell function a bit more than the downcasing? How about
this patch instead?
t/test-lib.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git c/t/test-lib.sh w/t/test-lib.sh
index c1839f7..8066c25 100644
--- c/t/test-lib.sh
+++ w/t/test-lib.sh
@@ -201,7 +201,7 @@ test_tick () {
# Both <file> and <contents> default to <message>.
test_commit () {
- file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
+ file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
echo "${3-$1}" > "$file" &&
git add "$file" &&
test_tick &&
^ permalink raw reply related
* Re: [PATCH v2] http-push: refactor request url creation
From: Junio C Hamano @ 2009-01-29 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tay Ray Chuan, git
In-Reply-To: <alpine.DEB.1.00.0901291608330.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 29 Jan 2009, Tay Ray Chuan wrote:
>
>> Currently, functions that deal with objects on the remote repository have to
>> allocate and
>> do strcpys to generate the URL.
>
> That is a funny way to wrap the commit message :-)
That's format=flowed in action, isn't it?
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Johannes Schindelin @ 2009-01-29 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Brian Gernhardt
In-Reply-To: <7vocxqf2sf.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 29 Jan 2009, Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
>
> > The call to "git reset --hard B1" failed on case-insensitive file
> > systems (such as the default settings for HFS+) because there was both
> > a tag "B1" and a file "b1". Adding "--" to the command makes it
> > clear that we mean commit B1.
> >
> > Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
> > ---
> > t/t3411-rebase-preserve-around-merges.sh | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
> > index 6533505..e544451 100755
> > --- a/t/t3411-rebase-preserve-around-merges.sh
> > +++ b/t/t3411-rebase-preserve-around-merges.sh
> > @@ -24,7 +24,7 @@ test_expect_success 'setup' '
> > test_commit A1 &&
> > test_commit B1 &&
> > test_commit C1 &&
> > - git reset --hard B1 &&
> > + git reset --hard B1 -- &&
> > test_commit D1 &&
> > test_merge E1 C1 &&
> > test_commit F1
>
> It is not just B1 that is ambiguous, even though that is the only
> ambiguous one this particular test uses.
>
> If we really wanted to care about case-folding file systems, shouldn't we
> make test_commit shell function a bit more than the downcasing? How about
> this patch instead?
>
> t/test-lib.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git c/t/test-lib.sh w/t/test-lib.sh
> index c1839f7..8066c25 100644
> --- c/t/test-lib.sh
> +++ w/t/test-lib.sh
> @@ -201,7 +201,7 @@ test_tick () {
> # Both <file> and <contents> default to <message>.
>
> test_commit () {
> - file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
> + file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
Or
file=${2:-$1.file}
but I was not quite sure about the impact; I might have checked for
specific filenames.
Brian, if you would have the time to go through the tests if an automatic
filename was used, that would be smashing! (We cannot just run the tests
and look at the failures, as absence of files could be tested; I don't
remember, debugging zlib/valgrind currently turns my brain into tatties.)
Ciao,
Dscho
^ permalink raw reply
* [EGIT] Blame functionality update
From: Manuel Woelker @ 2009-01-29 17:35 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
Hi folks,
quick update about the state of blame functionality in my egit branch
at http://github.com/manuel-woelker/egit/tree/blame
Screen shot here: http://docs.google.com/View?docid=df5rvczr_3f46vd2ds
- Diff support: I changed the IDiff as suggested to work on raw bytes
and IntList's. I also yanked the Diff implementation from wicket and
adapted it for use in jgit. The diff stuff now lives in its own
package. I also added some basic tests to see if plugged diff
implementations conform to the required expectations.
- log support: I added an OriginWalk in the new log package that
traces ancestry of a file though history (including renames and
copying). This might also be neat for the history page, which does not
seem to follow renames at the moment (think "log -C -M"). This is just
a rough sketch atm. Copies are disabled right now, cause the
performance is abysmal, and the current implementation tries to trace
the ancestry of empty lines back to the triassic period. So this could
definitely be optimized. The OriginWalk itself uses RevObject (as
suggested) so it should be a little faster. The implementation
currently traces the different strands of ancestry quite naively,
possibly parsing commits multiple times. This could be improved to a
single pass walk, but this makes the algorithm a little less
straight-forward and I haven't gotten around to that.
- As a result of the the OriginWalk mentioned above, the blame
implementation has been refactored slightly, while still keeping the
basic structure.
- I hooked up the blame functionality to the UI which was easier than
anticipated. I am quite pleased with the result (see screen shot
above). The only thing that proved a little tricky was history and
annotation ruler selection listener notifying each other recursively.
For now I stopped the stack overflow by detecting that recursive call.
If anyone got a better solution just give me a shout.
Feedback, comments and criticism are welcome as always.
Cheers
- Manuel
^ permalink raw reply
* Force commit date
From: Zabre @ 2009-01-29 18:30 UTC (permalink / raw)
To: git
Hi all,
Some time ago, I used to make 7zip backups of my project directory to keep
an history of my changes. (I've kept all of them in separated 7z files) I
was then living in darkness. (Even though I tried svn but was somehow not
happy with it) Now I've found the light, and git is the best tool around
(along with Hg I guess).
I am learning git at the moment and I would like to restore all my 7zipped
backups one after the other, use meld to apply each change in the code +
directory structure and then git to commit each of them, chronologically, to
finally obtain a complete git history of my changes (I even have "commit
commentaries" in a special text file, yes I tried to do things properly with
basic tools.)
This should be feasible, but what would be very cool in this very special
case is if I could force the commit date to reflect the real date each
"commit" (read : "zip") was done with my old method in last year, and not
the date of my convertion to git.
If it is not, that's not a big deal, but I'd really like to know how to do
this, and have my different projects on a git history. (I even have one or
two "secondary branches")
There might be an option I am not aware of.
(I have seen on this forum / mailing list some people playing with dates but
it was the case of mailboxes and "git am")
http://n2.nabble.com/how-to-force-a-commit-date-matching-info-from-a-mbox---td2200613.html
Remember I'm a beginner trying to learn git, so please bear with me.
Thank you!
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240539.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Force commit date
From: Sverre Rabbelier @ 2009-01-29 18:37 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233253817209-2240539.post@n2.nabble.com>
On Thu, Jan 29, 2009 at 19:30, Zabre <427@free.fr> wrote:
> There might be an option I am not aware of.
Indeed, try 'import-tars.perl' in the /contrib directory of git.git :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 18:45 UTC (permalink / raw)
To: git
In-Reply-To: <1233253817209-2240539.post@n2.nabble.com>
I'm wondering : maybe the trick is outside git? Maybe is it possible to
specify a "forced date" at which an action (a "git commit" in this case) is
done.
Some command that would wrap around the git commit command and tell the
system "apply this, but do it as if now was 2008-08-23 06:15:34".
What do you think?
This would be very interesting to know.
(btw I'm running Linux obviously)
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240602.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* segfault when cloning over https
From: Jan Kasprzak @ 2009-01-29 18:45 UTC (permalink / raw)
To: git
Hello,
I am trying to use git for accessing the repository over https.
I can run
git clone --bare http://www.fi.muni.cz/~kas/tmp/git.git
without problems, but when I change http to https, it either segfaults
or fails with heap corruption detected:
$ git clone --bare https://www.fi.muni.cz/~kas/tmp/git.git
[...]
got f1a1aac6880f1c8f122c57c2380800ec54d10982
*** glibc detected *** git: double free or corruption (!prev): 0x00007f8455a90fe0 ***
======= Backtrace: =========
/lib64/libc.so.6[0xf8bec8]
/lib64/libc.so.6(cfree+0x76)[0xf8e486]
/lib64/libnsspem.so[0x7f845f3f2a75]
/lib64/libnsspem.so[0x7f845f3e1a56]
/lib64/libnsspem.so[0x7f845f3e71a9]
/lib64/libnsspem.so[0x7f845f3ee9c4]
/lib64/libnss3.so[0x7f846210dc4d]
/lib64/libnss3.so(PK11_CreateGenericObject+0x42)[0x7f846210ded2]
/usr/lib64/libcurl.so.4[0x14b129]
/usr/lib64/libcurl.so.4(Curl_nss_connect+0x622)[0x14b9f2]
/usr/lib64/libcurl.so.4(Curl_protocol_connect+0xd2)[0x12bd72]
/usr/lib64/libcurl.so.4[0x13efd3]
/usr/lib64/libcurl.so.4(curl_multi_perform+0x8b)[0x13f2ab]
git[0x49de9f]
git[0x49df2f]
git[0x4a0499]
git[0x4a081e]
git[0x49aa36]
git[0x494b41]
git[0x4942f3]
git[0x415674]
git[0x4041a3]
git[0x4043bc]
/lib64/libc.so.6(__libc_start_main+0xe6)[0xf32576]
git[0x403c69]
======= Memory map: ========
00110000-00157000 r-xp 00000000 08:01 113025474 /usr/lib64/libcurl.so.4.1.0
00157000-00357000 ---p 00047000 08:01 113025474 /usr/lib64/libcurl.so.4.1.0
[...]
I have tried this against various https servers hosting different
repositories, and from various distributions (including Fedora 7, Fedora 8,
and Fedora 10, all x86_64), and from various git builds (1.6.0.6 from Fedora 10,
1.6.1.2 built from the source, etc.
Does anybody see the same problem? Do you use git over https at all?
It is possible to test against this repository:
http://www.fi.muni.cz/~kas/tmp/git.git
https://www.fi.muni.cz/~kas/tmp/git.git
You will have to add the following certificate to your ca-bundle.crt
to access the repository:
-----BEGIN CERTIFICATE-----
MIICsTCCAhoCAQAwDQYJKoZIhvcNAQEEBQAwgaAxCzAJBgNVBAYTAkNaMRcwFQYD
VQQIEw5DemVjaCBSZXB1YmxpYzENMAsGA1UEBxMEQnJubzEfMB0GA1UEChMWRmFj
dWx0eSBvZiBJbmZvcm1hdGljczEMMAoGA1UECxMDQ1ZUMRowGAYDVQQDExFBZG1p
bmlzdHJhdGl2YSBGSTEeMBwGCSqGSIb3DQEJARYPdW5peEBmaS5tdW5pLmN6MB4X
DTk3MTExMDEyMDQyOVoXDTI1MDMyODEyMDQyOVowgaAxCzAJBgNVBAYTAkNaMRcw
FQYDVQQIEw5DemVjaCBSZXB1YmxpYzENMAsGA1UEBxMEQnJubzEfMB0GA1UEChMW
RmFjdWx0eSBvZiBJbmZvcm1hdGljczEMMAoGA1UECxMDQ1ZUMRowGAYDVQQDExFB
ZG1pbmlzdHJhdGl2YSBGSTEeMBwGCSqGSIb3DQEJARYPdW5peEBmaS5tdW5pLmN6
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMm0dLLgsMSwmYPZdYYDGNsdwK
04k9O5gTYk+S70+ygUsLQNL+VLYqprsfZkDelX2wea8oUkj69R8I+vF6N1E8Ubik
3c4RFqJB6tsnTJT1YplCFd7s1BZlGSEKHC3OzHYp19pnXc0IHgX404pgpmuXaq6R
Xu+D8iboFKi60ZpsVQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAD7842aqJRKlFDzk
LK8SpR8KZ/jYWSdzNrwCQfLAlAzo8wDTcC3hgnaiKHJq4ZvS9h2tnGWm+qEToQwB
oKjKyR87zaFeEWu/tNxBNPkAXfX9jdyJ5ozDTVDpFLoLEZ5ppIuh/ZDbPhjTQZrc
IFfjrlWlrKXmiH9hCSQ5R/lIlrnG
-----END CERTIFICATE-----
Please Cc: me directly, I am not a member of this list.
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>> If you find yourself arguing with Alan Cox, you’re _probably_ wrong. <<
>> --James Morris in "How and Why You Should Become a Kernel Hacker" <<
^ permalink raw reply
* Re: diff settings
From: Keith Cascio @ 2009-01-29 18:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ted Pavlic, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901291731220.3586@pacific.mpi-cbg.de>
On Thu, 29 Jan 2009, Johannes Schindelin wrote:
> we already have a distinction between what is called from scripts vs from
> humans: plumbing vs porcelain. So you can set the defaults for porcelain as
> much as you want, but please leave plumbing alone.
May we consider "git diff" Porcelain and "git diff-{files,index,tree}" plumbing?
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 18:47 UTC (permalink / raw)
To: git
In-Reply-To: <bd6139dc0901291037h46a75446occ3004d2ff58d889@mail.gmail.com>
Sverre Rabbelier-2 wrote:
>
> Indeed, try 'import-tars.perl' in the /contrib directory of git.git :).
>
Thank you Sverre, I'll have a look at this!
(sorry for my "wondering" post, I had not seen yours)
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240620.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: segfault when cloning over https
From: Daniel Stenberg @ 2009-01-29 18:46 UTC (permalink / raw)
To: Jan Kasprzak; +Cc: git
In-Reply-To: <20090129184523.GI23133@fi.muni.cz>
On Thu, 29 Jan 2009, Jan Kasprzak wrote:
> without problems, but when I change http to https, it either segfaults or
> fails with heap corruption detected:
> /lib64/libnsspem.so[0x7f845f3ee9c4]
> /lib64/libnss3.so[0x7f846210dc4d]
> /lib64/libnss3.so(PK11_CreateGenericObject+0x42)[0x7f846210ded2]
> /usr/lib64/libcurl.so.4[0x14b129]
This is a libcurl built to use a Fedora-patched NSS library for the SSL stuff.
You could try to build your own libcurl with a different SSL library to see if
that works fine, as then we could narrow this down a bit...
--
/ daniel.haxx.se
^ permalink raw reply
* Re: Force commit date
From: Markus Heidelberg @ 2009-01-29 18:55 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233254709681-2240602.post@n2.nabble.com>
Zabre, 29.01.2009:
>
> I'm wondering : maybe the trick is outside git? Maybe is it possible to
> specify a "forced date" at which an action (a "git commit" in this case) is
> done.
> Some command that would wrap around the git commit command and tell the
> system "apply this, but do it as if now was 2008-08-23 06:15:34".
man git-commit-tree
-> GIT_COMMITTER_DATE
Though only in the git-commit-tree docs, it also works with git-commit.
Maybe it should be added there, too.
Markus
^ permalink raw reply
* border-case/general git test repository
From: Johannes Gilger @ 2009-01-29 18:54 UTC (permalink / raw)
To: git
Hi,
partly because of laziness, partly out of curiosity I was wondering if
anyone had a (relatively small) test-repository lying around, that
especially stresses the output (not really the integrity of the data) of
git and all kinds of different combinations of operations.
We could really use it for GitX, as GitX parses the output of git and
everytime we think we have found/fixed a glitch in the display we
discover some new case. For example we just noticed that we didn't
detect file-mode changes, and after we implemented that we thought that,
of course, a file can change its mode and content at the same time...
and so on ;)
So things we're looking for are things that usually don't happen that
often (because of obscureness or because of convention respected by
people) but are still perfectly valid output that our/other programs
could trip over.
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <200901291955.10769.markus.heidelberg@web.de>
Markus Heidelberg wrote:
>
> man git-commit-tree
> -> GIT_COMMITTER_DATE
>
> Though only in the git-commit-tree docs, it also works with git-commit.
> Maybe it should be added there, too.
>
Thank you Markus, I'll have a look at this too !
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240702.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Force commit date
From: Daniel Barkalow @ 2009-01-29 19:10 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233255759118-2240702.post@n2.nabble.com>
On Thu, 29 Jan 2009, Zabre wrote:
> Markus Heidelberg wrote:
> >
> > man git-commit-tree
> > -> GIT_COMMITTER_DATE
> >
> > Though only in the git-commit-tree docs, it also works with git-commit.
> > Maybe it should be added there, too.
> >
>
> Thank you Markus, I'll have a look at this too !
You may want to consider whether those dates make most sense as the date
of the commit, or the date the changes were done; git tracks both of
these separately, in part because it's easy to have some work done at one
time, and only make the commit that becomes part of the official project
history much later (and these may be done by different people).
The date for the changes being done is set with GIT_AUTHOR_DATE
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] t3411: Fix test 1 for case-insensitive file systems
From: Brian Gernhardt @ 2009-01-29 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git List
In-Reply-To: <7vocxqf2sf.fsf@gitster.siamese.dyndns.org>
On Jan 29, 2009, at 12:19 PM, Junio C Hamano wrote:
> If we really wanted to care about case-folding file systems,
> shouldn't we
> make test_commit shell function a bit more than the downcasing? How
> about
> this patch instead?
That's a good point. Always good to prevent future issues.
> test_commit () {
> - file=${2:-$(echo "$1" | tr 'A-Z' 'a-z')}
> + file=${2:-$(echo "$1" | tr 'A-Z' 'a-z').t}
> echo "${3-$1}" > "$file" &&
> git add "$file" &&
> test_tick &&
Added this and ran through the tests. Works for me. :-D
Tested-by: Brian Gernhardt <benji@silverinsanity.com> (HFS+ on Mac OS
10.5.6)
^ permalink raw reply
* "git gc" removes ".git/refs/heads/master".
From: Bernd Lommerzheim @ 2009-01-29 19:31 UTC (permalink / raw)
To: git
Hi,
maybe I found a bug in git. When I execute "git gc" in my local repository,
git removes the file ".git/refs/heads/master". Is this an intended behavior
(but why?) or is that a bug?
Some commands to reproduce:
~ $ mkdir tmp; cd tmp
~/tmp $ git init
Initialized empty Git repository in /home/myuser/tmp/.git/
~/tmp $ echo "content" > a
~/tmp $ git add .
~/tmp $ git commit -a -m "first commit"
Created initial commit 0b67f33: first commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
~/tmp $ cat .git/refs/heads/master
0b67f33fff4152a912fdbe8819480b8fc1f2e990
~/tmp $ git gc
Counting objects: 3, done.
Writing objects: 100% (3/3), done.
Total 3 (delta 0), reused 0 (delta 0)
~/tmp $ cat .git/refs/heads/master
cat: .git/refs/heads/master: No such file or directory
~/tmp $ cat .git/HEAD
ref: refs/heads/master
~/tmp $
I tested this with git v1.6.0.6, v1.6.1.1 and the current master
(a34a9dbb..).
Best regards,
Bernd Lommerzheim
^ permalink raw reply
* Re: Force commit date
From: Zabre @ 2009-01-29 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0901291406000.19665@iabervon.org>
Daniel Barkalow wrote:
>
> You may want to consider whether those dates make most sense as the date
> of the commit, or the date the changes were done; git tracks both of
> these separately, in part because it's easy to have some work done at one
> time, and only make the commit that becomes part of the official project
> history much later (and these may be done by different people).
>
> The date for the changes being done is set with GIT_AUTHOR_DATE
>
Thank you Daniel, this is very interesting, having a GIT_COMMITTER_DATE and
a GIT_AUTHOR_DATE enables me to have both dates, and no need to trick the
system then.
--
View this message in context: http://n2.nabble.com/Force-commit-date-tp2240539p2240926.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: "git gc" removes ".git/refs/heads/master".
From: Johannes Schindelin @ 2009-01-29 19:50 UTC (permalink / raw)
To: Bernd Lommerzheim; +Cc: git
In-Reply-To: <83c97f59a5a5e59f908f3fc125d26adb@lunox.net>
Hi,
On Thu, 29 Jan 2009, Bernd Lommerzheim wrote:
> maybe I found a bug in git. When I execute "git gc" in my local
> repository, git removes the file ".git/refs/heads/master". Is this an
> intended behavior (but why?) or is that a bug?
No, it packs the refs. You have no business accessing files in .git/
directly :-)
Ciao,
Dscho
^ 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