* Re: timestamps not git-cloned
From: jidanni @ 2008-11-28 5:06 UTC (permalink / raw)
To: dhruvakm; +Cc: git
In-Reply-To: <e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com>
>>>>> "d" == dhruva <dhruvakm@gmail.com> writes:
d> Also, if you clone from systems across time zones, what time do you
d> expect to set on the files.
I'm just used to tar, cpio, scp -a, rsync -a, ar, etc. using 'date +%s'
seconds internally, so no timezone problem.
I hate it when I get some latest WhizBang.tgz, only to untar it to
find all the files' dates the same, when in fact the README hasn't
been touched in seven years, but you can't tell that from ls -l. I
recall some content tracker was involved.
Of course I'll allowing you to know my delicate first day impressions.
I'm sure as I grow older I will learn the difference between content
tracker and archiver.
^ permalink raw reply
* Re: timestamps not git-cloned
From: David Brown @ 2008-11-28 5:57 UTC (permalink / raw)
To: dhruva; +Cc: jidanni, git
In-Reply-To: <e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com>
On Fri, Nov 28, 2008 at 08:38:06AM +0530, dhruva wrote:
>I do not think there is an VCS that records timestamps.
Perforce does, at least optionally. But, it's model is so different,
I'm not sure it really applies here. I believe it can either be an
individual file setting, or for a whole workspace.
David
^ permalink raw reply
* Re: clean the manual of unnecessary quote marks
From: Sverre Rabbelier @ 2008-11-28 6:25 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87fxlcwqhv.fsf@jidanni.org>
On Fri, Nov 28, 2008 at 03:09, <jidanni@jidanni.org> wrote:
> $ git-cat-file "blob" 557db03
> which makes it look like the author is an expert in other things, but
> not the shell, where
> $ git-cat-file blob 557db03
> would be fine.
This I will agree with you, quoting blob is silly in this case...
>Do you really type those extra quotes when nobody else
> is looking? Same even with
> $ echo "Silly example" >example
> Let's see, Of
> $ echo Silly example >example
> $ echo Silly example>example
> $ echo Silly example > example
> I'd pick the latter...
But I don't agree here, with echo I do always write the extra quotes
when nobody is looking, I find your alternatives less clear than the
original (with the quotes).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: summaries in git add --patch
From: William Pursell @ 2008-11-28 6:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqq8adsf.fsf@gitster.siamese.dyndns.org>
Here's a new patch. Instead of displaying the summary and then
the current hunk, it implements a 'goto' command. It prints the
summary and then prompts for the index of the hunk to jump to.
By not printing the current hunk, the list should typically
stay on screen. Also, the summary is optional, so:
g -- bring up summary and prompt for index
g3 -- jump to hunk 3
commit 510edf7c28fcc571f29106e32f2570d5f2e04fc3
Author: William Pursell <bill.pursell@gmail.com>
Date: Fri Nov 28 06:22:36 2008 +0000
Implement 'g' command (goto) in add --patch
This command prints a summary of the hunks in the current
file and prompts the user for an index of the hunk to make
current.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..e6d73a0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -553,7 +553,7 @@ sub parse_diff {
for (my $i = 0; $i < @diff; $i++) {
if ($diff[$i] =~ /^@@ /) {
- push @hunk, { TEXT => [], DISPLAY => [] };
+ push @hunk, { TEXT => [], DISPLAY => [], SUMMARY => $diff[$i] };
}
push @{$hunk[-1]{TEXT}}, $diff[$i];
push @{$hunk[-1]{DISPLAY}},
@@ -685,6 +685,7 @@ sub split_hunk {
(($n_cnt != 1) ? ",$n_cnt" : '') .
" @@\n");
my $display_head = $head;
+ $hunk->{SUMMARY} = $head;
unshift @{$hunk->{TEXT}}, $head;
if ($diff_use_color) {
$display_head = colored($fraginfo_color, $head);
@@ -783,6 +784,7 @@ sub edit_hunk_loop {
$newhunk,
@{$hunk}[$ix+1..$#{$hunk}])) {
$newhunk->{DISPLAY} = [color_diff(@{$text})];
+ $newhunk->{SUMMARY} = $$text[0];
return $newhunk;
}
else {
@@ -799,6 +801,7 @@ sub help_patch_cmd {
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
+g - select a hunk to jump to
d - do not stage this hunk nor any of the remaining hunks in the file
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
@@ -836,6 +839,27 @@ sub patch_update_cmd {
}
}
+sub select_new_hunk {
+ my $ri = shift;
+ my @hunk = @_;
+ my ($i, $response);
+ print " '+' stage, '-' don't stage\n";
+ for ( $i = 0; $i < @hunk; $i++ ) {
+ my $status = " ";
+ if( defined $hunk[$i]{USE} ) {
+ $status = $hunk[$i]{USE} ? "+" : "-";
+ }
+ printf "%s%3d: %s",
+ $status,
+ $i + 1,
+ $hunk[$i]{SUMMARY};
+ }
+ printf "goto which hunk? ";
+ $response = <STDIN>;
+ chomp $response;
+ $$ri = $response - 1;
+}
+
sub patch_update_file {
my ($ix, $num);
my $path = shift;
@@ -919,7 +943,7 @@ sub patch_update_file {
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage this hunk [y/n/a/d/g$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -937,6 +961,16 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ /^g/) {
+ chomp ($line);
+ if ($line =~ /^g$/) {
+ select_new_hunk (\$ix, @hunk);
+ }
+ else {
+ $ix = (substr $line, 1) - 1;
+ }
+ next;
+ }
elsif ($line =~ /^d/i) {
while ($ix < $num) {
if (!defined $hunk[$ix]{USE}) {
--
William Pursell
^ permalink raw reply related
* Re: timestamps not git-cloned
From: Daniel Barkalow @ 2008-11-28 6:59 UTC (permalink / raw)
To: jidanni; +Cc: dhruvakm, git
In-Reply-To: <87tz9sv3rb.fsf@jidanni.org>
On Fri, 28 Nov 2008, jidanni@jidanni.org wrote:
> >>>>> "d" == dhruva <dhruvakm@gmail.com> writes:
>
> d> Also, if you clone from systems across time zones, what time do you
> d> expect to set on the files.
>
> I'm just used to tar, cpio, scp -a, rsync -a, ar, etc. using 'date +%s'
> seconds internally, so no timezone problem.
>
> I hate it when I get some latest WhizBang.tgz, only to untar it to
> find all the files' dates the same, when in fact the README hasn't
> been touched in seven years, but you can't tell that from ls -l. I
> recall some content tracker was involved.
Well, README was just touched; it wasn't on your disk at all shortly
before. This would make a big difference if, for example, you unpacked
"foo-1.0" on top of "foo-1.1" and the timestamps were from when the files
were originally created, and now all of the source files that changed are
older than the object files and the build system does nothing.
Of course, with archives, you don't unpack different versions into the
same directory, but with a version control system, you'll do it all the
time, so you really need the system to put on disk the times when those
files were last put there. If you want to know when the README you've got
is from (and a whole lot more) "git log README" will tell you, although it
won't tell you if somebody yesterday changed the README they're
distributing from some other text to a file that's been sitting on their
disk untouched for seven years.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: summaries in git add --patch
From: Junio C Hamano @ 2008-11-28 7:24 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492F92C9.7030301@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Here's a new patch. Instead of displaying the summary and then
> the current hunk, it implements a 'goto' command.
I take it that this is for discussion not for immediate inclusion.
> @@ -799,6 +801,7 @@ sub help_patch_cmd {
> y - stage this hunk
> n - do not stage this hunk
> a - stage this and all the remaining hunks in the file
> +g - select a hunk to jump to
> d - do not stage this hunk nor any of the remaining hunks in the file
> j - leave this hunk undecided, see next undecided hunk
> J - leave this hunk undecided, see next hunk
Since you took 'g' after "go to", help text should also say "go to",
instead of "jump to" for the mnemonics value, iow, to help people
remember.
> @@ -836,6 +839,27 @@ sub patch_update_cmd {
> }
> }
>
> +sub select_new_hunk {
> + my $ri = shift;
> + my @hunk = @_;
> + my ($i, $response);
> + print " '+' stage, '-' don't stage\n";
> + for ( $i = 0; $i < @hunk; $i++ ) {
> + my $status = " ";
> + if( defined $hunk[$i]{USE} ) {
> + $status = $hunk[$i]{USE} ? "+" : "-";
> + }
Style.
(1) SP between language construct and open parenthesis, as opposed to
no extra SP between function name and open parenthesis;
(2) No extra SP around what is enclosed in parentheses.
> + printf "%s%3d: %s",
> + $status,
> + $i + 1,
> + $hunk[$i]{SUMMARY};
> + }
I think this "for ()" loop part, including the comment about +/- notation,
should be separated into a function so that you can implement a separate
"l"ist command like you did in the other patch, using the same function.
> + printf "goto which hunk? ";
> + $response = <STDIN>;
> + chomp $response;
> + $$ri = $response - 1;
What happens when $response is (1) a non number, (2) outside range (both
negative and positive), or (3) EOF?
Sending ref to scalar and returning the value by assigning is a bad taste.
Why shouldn't this function just return an integer to be assigned to $ix
by the caller? If you want to use pass-by-ref to show off your Perl-fu, I
think \@hunk would be what you would want to for performance reasons.
> @@ -919,7 +943,7 @@ sub patch_update_file {
> for (@{$hunk[$ix]{DISPLAY}}) {
> print;
> }
> - print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
> + print colored $prompt_color, "Stage this hunk [y/n/a/d/g$other/?]? ";
When there is only one hunk, we do not give j nor k. Should we give g in
such a case? Why?
> @@ -937,6 +961,16 @@ sub patch_update_file {
> }
> next;
> }
> + elsif ($line =~ /^g/) {
> + chomp ($line);
> + if ($line =~ /^g$/) {
> + select_new_hunk (\$ix, @hunk);
> + }
> + else {
> + $ix = (substr $line, 1) - 1;
> + }
The same "input validation" issue exists here. it would make sense to:
- Make choose_hunk(@hunk) that calls list_hunks(@hunk) that gives the
summary, reads one line, and returns that line;
- Make the caller here to look like this:
elsif ($line =~ s/^g//) {
chomp($line);
if ($line eq '') {
$line = choose_hunk(@hunk);
}
if ($line !~ /^\d+$/) {
print STDERR "Eh '$line', what number is that?\n";
next;
} elsif (0 < $line && $line <= $num) {
$ix = $line - 1;
} else {
print STDERR "Sorry, you have only $num hunks\n";
}
}
> + next;
> + }
> elsif ($line =~ /^d/i) {
> while ($ix < $num) {
> if (!defined $hunk[$ix]{USE}) {
>
>
> --
> William Pursell
^ permalink raw reply
* Re: git fsck segmentation fault
From: Simon Hausmann @ 2008-11-28 8:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811271449500.14328@xanadu.home>
On Thursday 27 November 2008 Nicolas Pitre, wrote:
> On Thu, 27 Nov 2008, Simon Hausmann wrote:
> > On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:
> > > On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:
> > > > On Thu, 27 Nov 2008, Simon Hausmann wrote:
> > > > > Hi,
> > > > >
> > > > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a
> > > > > medium sized
> > > >
> > > > That version doesn't exist in the git repo.
> > >
> > > Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.
> > >
> > > > > (930M) repository I get a segfault.
> > > > >
> > > > > The backtrace indicates an infinite recursion. Here's the output
> > > > > from the last few lines:
> > > >
> > > > [...]
> > > >
> > > > Could you try with latest master branch please? It is more robust
> > > > against some kind of pack corruptions that could send the code into
> > > > infinite loops.
> > >
> > > Same problem with git version 1.6.0.4.790.gaa14a
> >
> > Forgot to paste the changed line numbers of the recursion:
>
> [...]
>
> Well... Your initial backtrace showed recursion in unpack_entry() which
> was rather odd in the first place. Your latest backtrace shows a loop
> in make_object() which has nothing to do what so ever with
> unpack_entry(). So the backtrace might not be really useful.
>
> I suspect you'll have to bisect git to find the issue, given that some
> old version can be found to be good. For example, does it work with
> v1.5.2.5?
Ah yes, v1.5.2.5 works! (phew, and it verified that the repo is fine)
Ok, I bisected and "git bisect run" identified the following commit as first bad
commit:
commit 271b8d25b25e49b367087440e093e755e5f35aa9
Author: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Date: Mon Feb 25 22:46:05 2008 +0100
builtin-fsck: move away from object-refs to fsck_walk
Simon
^ permalink raw reply
* Re: [StGit] Import file(s) problem
From: Karl Hasselström @ 2008-11-28 9:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Shinya Kuribayashi, git
In-Reply-To: <b0943d9e0811271406u6768f45csdb5ae775436404b8@mail.gmail.com>
On 2008-11-27 22:06:01 +0000, Catalin Marinas wrote:
> The '..' construct has special meaning in both Git and StGit meaning
> an interval of commits or patches. We'll need to reject patch names
> with '..' to avoid such errors.
I added a note to the bug database:
https://gna.org/bugs/index.php?10919
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] gitk: Updated German translation.
From: Christian Stimming @ 2008-11-28 10:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 224 bytes --]
Patch against today's master of gitk.git at git.kernel.org. Attached to
avoid whitespace problems. My last submitted patch from 2008-10-25 for
whatever reason hasn't been committed to gitk.git so far.
Regards,
Christian
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gitk-Update-German-translation.patch --]
[-- Type: text/x-diff; charset="us-ascii"; name="0001-gitk-Update-German-translation.patch", Size: 3493 bytes --]
From 627fc16459e43f5577c16851332bf02a9d40595e Mon Sep 17 00:00:00 2001
From: Christian Stimming <stimming@tuhh.de>
Date: Sat, 25 Oct 2008 13:25:35 +0200
Subject: [PATCH] gitk: Update German translation.
This takes into account the most recent po file merge. For future reference:
The German translator strongly preferes not to have po file merged by the
maintainer (thus causing tons of conflicts for already existing local translations),
but instead to run "make update-po" on his own.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
po/de.po | 51 +++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/po/de.po b/po/de.po
index c86cc2d..e0a6dee 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7,8 +7,8 @@ msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-10-18 22:03+1100\n"
-"PO-Revision-Date: 2008-05-24 22:40+0200\n"
+"POT-Creation-Date: 2008-10-25 13:18+0200\n"
+"PO-Revision-Date: 2008-10-25 13:23+0200\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
@@ -19,6 +19,14 @@ msgstr ""
msgid "Couldn't get list of unmerged files:"
msgstr "Liste der nicht-zusammengeführten Dateien nicht gefunden:"
+#: gitk:272
+msgid "Error parsing revisions:"
+msgstr "Fehler beim Laden der Versionen:"
+
+#: gitk:327
+msgid "Error executing --argscmd command:"
+msgstr "Fehler beim --argscmd Kommando:"
+
#: gitk:340
msgid "No files selected: --merge specified but no files are unmerged."
msgstr ""
@@ -283,9 +291,9 @@ msgstr "Nur diesen hervorheben"
msgid "External diff"
msgstr "Externer Vergleich"
-#: gitk:2245
+#: gitk:2255
msgid "Blame parent commit"
-msgstr ""
+msgstr "Annotieren der Elternversion"
#: gitk:2488
msgid ""
@@ -471,7 +479,33 @@ msgstr "<%s-Minus>\tSchriftgröße verkleinern"
msgid "<F5>\t\tUpdate"
msgstr "<F5>\t\tAktualisieren"
-#: gitk:3200
+#: gitk:2979
+#, tcl-format
+msgid "Error getting \"%s\" from %s:"
+msgstr "Fehler beim Holen von »%s« von »%s«:"
+
+#: gitk:3036 gitk:3045
+#, tcl-format
+msgid "Error creating temporary directory %s:"
+msgstr "Fehler beim Erzeugen eines temporären Verzeichnisses »%s«:"
+
+#: gitk:3058
+msgid "command failed:"
+msgstr "Kommando fehlgeschlagen:"
+
+#: gitk:3078
+msgid "No such commit"
+msgstr "Version nicht gefunden"
+
+#: gitk:3083
+msgid "git gui blame: command failed:"
+msgstr "git gui blame: Kommando fehlgeschlagen:"
+
+#: gitk:3092
+msgid "External diff viewer failed:"
+msgstr "Externes Vergleich-(Diff-)Programm fehlgeschlagen:"
+
+#: gitk:3210
msgid "Gitk view definition"
msgstr "Gitk Ansichten"
@@ -692,9 +726,10 @@ msgstr "Bitte geben Sie einen Namen für den neuen Zweig an."
#, tcl-format
msgid "Commit %s is already included in branch %s -- really re-apply it?"
msgstr ""
-"Version »%s« ist bereits im Zweig »%s« enthalten -- trotzdem erneut eintragen?"
+"Version »%s« ist bereits im Zweig »%s« enthalten -- trotzdem erneut "
+"eintragen?"
-#: gitk:7708
+#: gitk:7718
msgid "Cherry-picking"
msgstr "Version pflücken"
@@ -836,7 +871,7 @@ msgstr "Vergleich nur für angezeigte Pfade"
#: gitk:9414
msgid "Support per-file encodings"
-msgstr ""
+msgstr "Zeichenkodierung pro Datei ermitteln"
#: gitk:9421
msgid "External diff tool"
--
1.6.0.rc1.34.g0fe8c
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Johannes Schindelin @ 2008-11-28 11:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtz9s8uzu.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 27 Nov 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I have a strong suspicion that the narrow stuff will make the worktree
> > mess pale in comparison.
> >
> > Note that I do not have time to review this myself (which is not
> > helped at all by it being no longer a trivial single patch, but a full
> > 10 patches!), but I really have a bad feeling about this. IMO it is
> > substantially under-reviewed.
>
> Well, "a bad feeling" is not a convincing enough argument either, is it?
> What kind of bad interaction are you fearing?
I just remember the worktree stuff well enough. I had a bad gut feeling
when it was proposed, and I had a bad impression of the (IMO way too
intrusive) patch series implementing it. It was pretty buggy and affected
Git in serious ways (in order to accomodate worktree, we broke operations
in bare repositories at least once, for example).
(So no, "bad feeling" is not convincing, but it is basically a primitive
pattern matching in experiences that have not been fully analyzed, but
that turned out to be bad enough.)
I tried to fix it, but did not a very good job at it. In the meantime, I
think I know why: there is no elegant way to implement this that is
performant at the same time. (Just think of having git_dir be relative:
this is a necessity for the performance, but ugly to implement in the
presence of worktree where it may _need_ to be absolute).
To me, the narrow patch series has all the looks of becoming the same type
of nightmare:
- it is intrusive,
- it consists of a substantial number of patches (making bugs the opposite
of shallow),
- it is heavily under-reviewed,
- it _needs_ a lot of changes to be accomodated, affecting common code
paths, having all the potential to break existing workflows, and
- there is as little interest in the feature from core Git developers as
with worktree, literally guaranteeing that it will not, or only very
slowly, and probably badly, get fixed if it breaks.
And the worst part: I think that as with worktree, there has not been
enough of kicking forth and back ideas how to design the beast, so I fully
expect a subtle breakage that would require a redesign (which will be
painful, with existing users of the feature).
Maybe I am crying "wolf", but I _do_ want to caution against risking too
much, too fast, with that feature.
In other words, unless there is more interest in that feature, enough to
generate a well-understood design before a good implementation, I'd rather
see this patch series dropped.
Ciao,
Dscho
^ permalink raw reply
* Re: timestamps not git-cloned
From: Johannes Schindelin @ 2008-11-28 11:51 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87ej0wwptn.fsf@jidanni.org>
Hi,
On Fri, 28 Nov 2008, jidanni@jidanni.org wrote:
> Gentlemen, it's my first git-clone,
> $ git-clone git://git.debian.org/git/pkg-fso/files.git
> and I'm disappointed to find the timestamps of the files created are
> all now and not the date of last edit.
You are mistaken to be disappointed. Granted, to a hammer, everything
looks like a nail. But it might make more sense to be gentle, and insert
the syringe by hand. Maybe it will get less painful that way, too.
In other words, do not be surprised when a source code management tool
turns out to be lousy at recreating meta-data -- which has as much to do
with source code than a syringe with a nail.
Hth,
Dscho
^ permalink raw reply
* Re: timestamps not git-cloned
From: Robin Rosenberg @ 2008-11-28 12:58 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87ej0wwptn.fsf@jidanni.org>
fredag 28 november 2008 03:24:04 skrev jidanni@jidanni.org:
> Gentlemen, it's my first git-clone,
> $ git-clone git://git.debian.org/git/pkg-fso/files.git
> and I'm disappointed to find the timestamps of the files created are
> all now and not the date of last edit. At least mention something
> about this on the git-clone man page.
I recommend every new Git user to scan the FAQ. It's not just clone,
it's in everything git does in the file system. There is a very good
reason git behaves this way in general, although clone could be
exception, but then we would have a ton of questions about that
inconsistency.
-- robin
^ permalink raw reply
* Re: timestamps not git-cloned
From: Johannes Schindelin @ 2008-11-28 13:20 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: jidanni, git
In-Reply-To: <200811281358.24592.robin.rosenberg.lists@dewire.com>
Hi,
On Fri, 28 Nov 2008, Robin Rosenberg wrote:
> I recommend every new Git user to scan the FAQ. It's not just clone,
> it's in everything git does in the file system. There is a very good
> reason git behaves this way in general, although clone could be
> exception, but then we would have a ton of questions about that
> inconsistency.
No, clone cannot be an exception. The information is just not stored, and
for a good reason: a file's timestamp is nothing you want to commit in
source code management. It just does not make sense at all.
Ciao,
Dscho
^ permalink raw reply
* C# Git Implementation
From: JD Guzman @ 2008-11-28 13:37 UTC (permalink / raw)
To: git
Hello I am new to the list and if I am not following some kind of list
ettiquite please let me know.
I read in the archives that there was once talk of porting Git over to C#
and was wondering if anything ever came of this? I realize there were some
that didn't see the use for this but as Git is becoming more and more
popular a more native implementation of Git for windows users would be a
good endevour IMHO.
At any rate any info would be greatly appreciated.
Regards,
JD Guzman
^ permalink raw reply
* Re: C# Git Implementation
From: Reece Dunn @ 2008-11-28 13:45 UTC (permalink / raw)
To: JD Guzman; +Cc: git
In-Reply-To: <001501c9515e$66e8ac70$34ba0550$@com>
2008/11/28 JD Guzman <jd@jdguzman.com>:
> I read in the archives that there was once talk of porting Git over to C#
> and was wondering if anything ever came of this? I realize there were some
> that didn't see the use for this but as Git is becoming more and more
> popular a more native implementation of Git for windows users would be a
> good endevour IMHO.
There were several efforts made, but these have fallen by the wayside.
Since then, the mingw/msys port has made progress to the point where
git will use native calls. Most - if not all of this - has been merged
back into upstream git as of version 1.6.
Git works well on Windows and msysGit even provides a native installer
that installs the necessary companion tools and libraries.
Therefore, there is already a native version of Git for Windows that
is always up-to-date with the latest Git functionality (since it is
the same sourcecode!)
BTW: Kudos to everyone involved in the Windows port.
- Reece
^ permalink raw reply
* Re: timestamps not git-cloned
From: Peter Krefting @ 2008-11-28 14:59 UTC (permalink / raw)
To: dhruva; +Cc: jidanni, Git Mailing List
In-Reply-To: <e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com>
Hi!
dhruva:
> I do not think there is an VCS that records timestamps. Only file
> contents are tracked.
CVS sort of does. The initial checkout sets the time stamp of files to
their last *check-in* time (and you can import a file with -D to set
its commit time to the current timestamp). Updates do, however, set to
current time (to not break make and friends).
I miss this behaviour in Git, but I have learnt to live with it. I
guess it is like a difference in philosophy on what time-stamps are
supposed to record, like how UNIX "cp" sets the time of the new-born
copy to now, while DOS "copy" sets it to the old time-stamp. Coming
to Unix and Linux from DOS (via OS/2), I find "cp" behaviour weird. But
have learnt to live with it (and use "cp -a" a lot).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [StGit] Import file(s) problem
From: Shinya Kuribayashi @ 2008-11-28 15:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git
In-Reply-To: <20081128092556.GA4380@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2008-11-27 22:06:01 +0000, Catalin Marinas wrote:
>
>> The '..' construct has special meaning in both Git and StGit meaning
>> an interval of commits or patches. We'll need to reject patch names
>> with '..' to avoid such errors.
>
> I added a note to the bug database:
>
> https://gna.org/bugs/index.php?10919
Looking forward to being fixed, thanks.
Shinya
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-28 17:00 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git List
In-Reply-To: <alpine.LFD.2.00.0811271233590.2883@sys-0.hiltweb.site>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
Ian Hilt wrote:
> On Wed, 26 Nov 2008, Joey Hess wrote:
> > Joey Hess wrote:
> > > Note that in both occasions that I've seen this failure, it has not been
> > > due to a missing directory, or bad permissions
> >
> > Actually, it was due to bad permissions. :-) Once git was fixed to
> > actually say that, I figured out where to look to fix them.
>
> This is strange since write_loose_object() which calls create_tmpfile()
> checks for EPERM. Perhaps this should be done in create_tmpfile()?
errno is clobbered by the mkdir in create_tmpfile(), that's what my patch
corrects.
I suspect that in my case, mkstemp failed with EACCES, not EPERM. git
was running as a group that did not have write access to (some) object
directories.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-cvsimport: add support for cvs pserver password scrambling.
From: Dirk Hörner @ 2008-11-28 18:06 UTC (permalink / raw)
To: git
Instead of a cleartext password, the CVS pserver expects a scrambled one
in the authentication request. With this patch it is possible to import
CVS repositories only accessible via pserver and user/password.
Signed-off-by: Dirk Hoerner <dirker@gmail.com>
---
git-cvsimport.perl | 39 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e439202..593832d 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -252,7 +252,8 @@ sub conn {
}
};
}
- $pass="A" unless $pass;
+
+ $pass = $self->_scramble($pass);
my ($s, $rep);
if ($proxyhost) {
@@ -484,6 +485,42 @@ sub _fetchfile {
return $res;
}
+sub _scramble {
+ my ($self, $pass) = @_;
+ my $scrambled = "A";
+
+ return $scrambled unless $pass;
+
+ my $pass_len = length($pass);
+ my @pass_arr = split("", $pass);
+ my $i;
+
+ # from cvs/src/scramble.c
+ my @shifts = (
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 114,120, 53, 79, 96,109, 72,108, 70, 64, 76, 67,116, 74, 68, 87,
+ 111, 52, 75,119, 49, 34, 82, 81, 95, 65,112, 86,118,110,122,105,
+ 41, 57, 83, 43, 46,102, 40, 89, 38,103, 45, 50, 42,123, 91, 35,
+ 125, 55, 54, 66,124,126, 59, 47, 92, 71,115, 78, 88,107,106, 56,
+ 36,121,117,104,101,100, 69, 73, 99, 63, 94, 93, 39, 37, 61, 48,
+ 58,113, 32, 90, 44, 98, 60, 51, 33, 97, 62, 77, 84, 80, 85,223,
+ 225,216,187,166,229,189,222,188,141,249,148,200,184,136,248,190,
+ 199,170,181,204,138,232,218,183,255,234,220,247,213,203,226,193,
+ 174,172,228,252,217,201,131,230,197,211,145,238,161,179,160,212,
+ 207,221,254,173,202,146,224,151,140,196,205,130,135,133,143,246,
+ 192,159,244,239,185,168,215,144,139,165,180,157,147,186,214,176,
+ 227,231,219,169,175,156,206,198,129,164,150,210,154,177,134,127,
+ 182,128,158,208,162,132,167,209,149,241,153,251,237,236,171,195,
+ 243,233,253,240,194,250,191,155,142,137,245,235,163,242,178,152
+ );
+
+ for ($i = 0; $i < $pass_len; $i++) {
+ $scrambled .= pack("C", $shifts[ord($pass_arr[$i])]);
+ }
+
+ return $scrambled;
+}
package main;
--
1.6.0.4.837.gae258
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Shawn O. Pearce @ 2008-11-28 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0811281225040.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 27 Nov 2008, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > I have a strong suspicion that the narrow stuff will make the worktree
> > > mess pale in comparison.
> > >
> > > Note that I do not have time to review this myself (which is not
> > > helped at all by it being no longer a trivial single patch, but a full
> > > 10 patches!), but I really have a bad feeling about this. IMO it is
> > > substantially under-reviewed.
> >
> > Well, "a bad feeling" is not a convincing enough argument either, is it?
> > What kind of bad interaction are you fearing?
...
> And the worst part: I think that as with worktree, there has not been
> enough of kicking forth and back ideas how to design the beast, so I fully
> expect a subtle breakage that would require a redesign (which will be
> painful, with existing users of the feature).
>
> Maybe I am crying "wolf", but I _do_ want to caution against risking too
> much, too fast, with that feature.
>
> In other words, unless there is more interest in that feature, enough to
> generate a well-understood design before a good implementation, I'd rather
> see this patch series dropped.
Ack. I agree with every remark made by Dscho, and also want to cry "wolf".
I haven't had time to read the patch series. Its big and intrusive
and I just don't need the feature.
But I feel like if it were in fact merged I'll fall over some bug
in it sometime soon and be forced to stop and debug it. Heck at
the least I'll have to go back to JGit's index code and implement
the new file format. That shouldn't cause git.git's development to
stop, but I am whining (a little) about the file format change. ;-)
--
Shawn.
^ permalink raw reply
* [PATCHv2 0/2] fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-28 20:39 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
This is v2 of the gitweb feature check fix patch, which has now been
split into into a code patch and cleanup patch.
The first patch introduces git_get_feature() to clearly distinguish the
feature retrieval from the boolean feature check (which is kept at
git_check_feature()). The new function is used where appropriate.
The second patch cleans up use of git_check_feature(): since the
function now returns a boolean instead of an array, the often-used
construct
my ($somevar) = git_check_feature('somefeat');
although still valid, becomes a rather clumsy stylistic choice, as it
introduces an unnecessary ambiguity. Make it clear that we're now
dealing with scalars by using scalar assignment.
Giuseppe Bilotta (2):
gitweb: fixes to gitweb feature check code
gitweb: clean up git_check_feature() calls
gitweb/gitweb.perl | 52 +++++++++++++++++++++++++++++++++++-----------------
1 files changed, 35 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCHv2 1/2] gitweb: fixes to gitweb feature check code
From: Giuseppe Bilotta @ 2008-11-28 20:39 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227904793-1821-1-git-send-email-giuseppe.bilotta@gmail.com>
The gitweb_check_feature routine was being used for two different
purposes: retrieving the actual feature value (such as the list of
snapshot formats or the list of additional actions), and to check if a
feature was enabled.
For the latter use, since all features return an array, it led to either
clumsy code or subtle bugs, with disabled features appearing enabled
because (0) evaluates to 1.
We fix these bugs, and simplify the code, by separating feature (list)
value retrieval (gitweb_get_feature) from boolean feature check (i.e.
retrieving the first/only item in the feature value list). Usage of
gitweb_check_feature is replaced by gitweb_get_feature where
appropriate.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 26 ++++++++++++++++++++++----
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..128d7ad 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -190,7 +190,9 @@ our %feature = (
# if there is no 'sub' key (no feature-sub), then feature cannot be
# overriden
#
- # use gitweb_check_feature(<feature>) to check if <feature> is enabled
+ # use gitweb_get_feature(<feature>) to retrieve the <feature> value
+ # (an array) or gitweb_check_feature(<feature>) to check if <feature>
+ # is enabled
# Enable the 'blame' blob view, showing the last commit that modified
# each line in the file. This can be very CPU-intensive.
@@ -329,7 +331,8 @@ our %feature = (
'default' => [0]},
);
-sub gitweb_check_feature {
+# retrieve the value of a given feature, as an array
+sub gitweb_get_feature {
my ($name) = @_;
return unless exists $feature{$name};
my ($sub, $override, @defaults) = (
@@ -344,6 +347,21 @@ sub gitweb_check_feature {
return $sub->(@defaults);
}
+# check if a given feature is enabled or not, returning the first (and only)
+# value of the feature. Comfort code, allowing the use of
+# my $bool_feat = gitweb_check_feature('bool_feat');
+# or
+# gitweb_check_feature('bool_feat') or somecode;
+# instead of
+# my ($bool_feat) = gitweb_git_feature('bool_feat');
+# or
+# (gitweb_check_feature('bool_feat'))[0] or somecode;
+# respectively
+sub gitweb_check_feature {
+ return (gitweb_get_feature(@_))[0];
+}
+
+
sub feature_blame {
my ($val) = git_get_project_config('blame', '--bool');
@@ -767,7 +785,7 @@ our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# list of supported snapshot formats
-our @snapshot_fmts = gitweb_check_feature('snapshot');
+our @snapshot_fmts = gitweb_get_feature('snapshot');
@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
# dispatch
@@ -3084,7 +3102,7 @@ sub git_print_page_nav {
$arg{'tree'}{'hash'} = $treehead if defined $treehead;
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
- my @actions = gitweb_check_feature('actions');
+ my @actions = gitweb_get_feature('actions');
my %repl = (
'%' => '%',
'n' => $project, # project name
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 2/2] gitweb: clean up git_check_feature() calls
From: Giuseppe Bilotta @ 2008-11-28 20:39 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1227904793-1821-2-git-send-email-giuseppe.bilotta@gmail.com>
Since git_check_feature now returns a scalar, the parentheses around the
variables initialized from git_check_feature() are not needed.
We remove them for stylistic consistency and to prevent unnecessary
ambiguity in the code.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 128d7ad..b0d00ea 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -828,7 +828,7 @@ sub href (%) {
}
}
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
@@ -2119,7 +2119,7 @@ sub git_get_projects_list {
$filter ||= '';
$filter =~ s/\.git$//;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
@@ -2965,7 +2965,7 @@ EOF
}
print "</div>\n";
- my ($have_search) = gitweb_check_feature('search');
+ my $have_search = gitweb_check_feature('search');
if (defined $project && $have_search) {
if (!defined $searchtext) {
$searchtext = "";
@@ -2979,7 +2979,7 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my ($use_pathinfo) = gitweb_check_feature('pathinfo');
+ my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
$action .= "/".esc_url($project);
}
@@ -3472,7 +3472,7 @@ sub is_patch_split {
sub git_difftree_body {
my ($difftree, $hash, @parents) = @_;
my ($parent) = $parents[0];
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
print "<div class=\"list_head\">\n";
if ($#{$difftree} > 10) {
print(($#{$difftree} + 1) . " files changed:\n");
@@ -3986,7 +3986,7 @@ sub git_project_list_body {
# actually uses global variable $project
my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
my @projects = fill_project_list_info($projlist, $check_forks);
$order ||= $default_projects_order;
@@ -4446,7 +4446,7 @@ sub git_summary {
my @taglist = git_get_tags_list(16);
my @headlist = git_get_heads_list(16);
my @forklist;
- my ($check_forks) = gitweb_check_feature('forks');
+ my $check_forks = gitweb_check_feature('forks');
if ($check_forks) {
@forklist = git_get_projects_list($project);
@@ -4475,7 +4475,7 @@ sub git_summary {
}
# Tag cloud
- my $show_ctags = (gitweb_check_feature('ctags'))[0];
+ my $show_ctags = gitweb_check_feature('ctags');
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
@@ -4765,7 +4765,7 @@ sub git_blob {
$expires = "+1d";
}
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(500, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
@@ -4858,7 +4858,7 @@ sub git_tree {
my $ref = format_ref_marker($refs, $hash_base);
git_header_html();
my $basedir = '';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
my @views_nav = ();
if (defined $file_name) {
@@ -5856,7 +5856,7 @@ insensitive).</p>
<dt><b>commit</b></dt>
<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
EOT
- my ($have_grep) = gitweb_check_feature('grep');
+ my $have_grep = gitweb_check_feature('grep');
if ($have_grep) {
print <<EOT;
<dt><b>grep</b></dt>
@@ -5873,7 +5873,7 @@ EOT
<dt><b>committer</b></dt>
<dd>Name and e-mail of the committer and date of commit will be scanned for the given pattern.</dd>
EOT
- my ($have_pickaxe) = gitweb_check_feature('pickaxe');
+ my $have_pickaxe = gitweb_check_feature('pickaxe');
if ($have_pickaxe) {
print <<EOT;
<dt><b>pickaxe</b></dt>
@@ -5925,7 +5925,7 @@ sub git_shortlog {
sub git_feed {
my $format = shift || 'atom';
- my ($have_blame) = gitweb_check_feature('blame');
+ my $have_blame = gitweb_check_feature('blame');
# Atom: http://www.atomenabled.org/developers/syndication/
# RSS: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
--
1.5.6.5
^ permalink raw reply related
* Removing part of the history
From: Samuel Lucas Vaz de Mello @ 2008-11-28 21:23 UTC (permalink / raw)
To: git
Hi All,
I have a repository with code imported from CVS.
I first imported from CVS using git 1.5.6 and we started to develop in git branches.
I run cvsimport periodically and merged the changes from CVS (legacy developers) to our git branches.
After some time, I realized that the import was broken, upgraded to git 1.6 and reimported the data.
Now the imported data seems to be correct and I finished with a history tree like this:
(our branch1) X--Y--Z
merges> / \
(our branch2) J--K--L--M--N--O--P
merges> / / /
(cvs old) ...A--B--C--D--E /
merges> /
(cvs new) ...A'-B'-C'-D'-E'-F'
There is any way to get rid of the (broken) cvs-old tree?
I've tried to rebase, but the commits from A' and A are different, it tries to reapply all history in CVS.
I've tried to checkout a point before our changes start (B') and then, using a script, cherry-pick all commits up to HEAD that are not in cvs-old branch. This approach didn't handled well merges between our branches (K-L-M and X-Y).
The history from the beginning up to the point where our changes started (...A--B) is quite large, so it would be nice for us to get rid of it.
Any suggestion on how to handle this?
Thank you,
- Samuel
^ permalink raw reply
* Re: Removing part of the history
From: Miklos Vajna @ 2008-11-28 21:34 UTC (permalink / raw)
To: Samuel Lucas Vaz de Mello; +Cc: git
In-Reply-To: <49306150.6010701@datacom.ind.br>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Fri, Nov 28, 2008 at 07:23:28PM -0200, Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br> wrote:
> There is any way to get rid of the (broken) cvs-old tree?
>
> I've tried to rebase, but the commits from A' and A are different, it
> tries to reapply all history in CVS.
Have you tried git rebase --onto?
> I've tried to checkout a point before our changes start (B') and then,
> using a script, cherry-pick all commits up to HEAD that are not in
> cvs-old branch. This approach didn't handled well merges between our
> branches (K-L-M and X-Y).
git rebase --preserve-merges is probably what you are searching for.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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