* [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: [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
* 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: 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: 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
* 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: 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
* 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 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: 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
* [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: [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
* 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: 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: 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: 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: 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: 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: 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: summaries in git add --patch
From: William Pursell @ 2008-11-28 4:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqq8adsf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>
>> Stage this hunk [y,n,a,l,d,k,K,j,J,e,?]? l
>> '*' indicates current hunk. '+' stage, '-' don't stage
>> 0+: @@ -8,9 +8,9 @@ Aani
>> 1 : @@ -48,7 +48,7 @@ abandonable
>> *2 : @@ -88,7 +88,7 @@ abaton
>> 3 : @@ -128,7 +128,7 @@ abdest
>> 4-: @@ -81192,9 +81192,9 @@ gyrous
>> 5 : @@ -234925,7 +234925,7 @@ zymotic
>> @@ -88,7 +88,7 @@ abaton
>> abator
>> abattoir
>> Abatua
>> -abature
>> +agature
>> abave
>> abaxial
>> abaxile
>
> Machines count from zero but humans count from one.
Humans should change. :) Good point.
> What is your plans to limit the output of this when there are dozens of
> hunks?
Would having git-add--interactive fork a PAGER be too drastic?
It strikes me as probably being unworkable, and a better
approach would be too only display a fixed number of lines
and not immediately display the current hunk. (In line with
your suggestion below to make it a status command.)
> A hunk can and often is quite long which would make this list scroll off
> the screen. Together with the previous point, I suspect it would be
> better to make this not part of the "Stage this one?" question, but an
> action that (1) does not do anything to the hunk we have currently focus
> on, and (2) does not move the focus after it does its thing. In other
> words, a new "status" action. I think 'S' is not taken yet although 's'
> is taken for 'split'.
I tend to use 'git add --patch' directly rather than
git add --interactive, and would prefer to be able to
access the list from there. But your point is definitely
valid and my work flow should probably change.
re: 's' vs 'S', I notice that y,n, and d are all case
insenstive, but the other commands are not. Is this
necessary/desirable?
--
William Pursell
^ permalink raw reply
* Re: timestamps not git-cloned
From: dhruva @ 2008-11-28 3:08 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87ej0wwptn.fsf@jidanni.org>
Hi,
On Fri, Nov 28, 2008 at 7:54 AM, <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. At least mention something
> about this on the git-clone man page.
I do not think there is an VCS that records timestamps. Only file
contents are tracked. Also, if you clone from systems across time
zones, what time do you expect to set on the files. IMO, it is not
practical to track timestamps.
Are you concerned of 'make' doing a complete build when you switch
branches? I guess it makes sense only in that scenario. I wish 'make'
had some feature to track changes instead of timestamps alone...
-dhruva
--
Contents reflect my personal views only!
^ permalink raw reply
* timestamps not git-cloned
From: jidanni @ 2008-11-28 2:24 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* clean the manual of unnecessary quote marks
From: jidanni @ 2008-11-28 2:09 UTC (permalink / raw)
To: git
Gentlemen, sorry to be a bore, but in
/usr/share/doc/git-doc/gitcore-tutorial.html
there are examples like
$ 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. 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...
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-11-28 2:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811272347010.30769@pacific.mpi-cbg.de>
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 thought the changes this first half of the topic implements were safe
for people who do not use this feature at all (which is the most important
thing I care about very first), and also I thought they made sense.
A bigger concern I actually have about this series is that the original
author seems to have gone quiet. I would have expected a discussion on
adding Porcelain level support after the series hit 'next' to begin, so
that the underlying feature can be made more accessible by the end users.
Also a new section to tutorial or a new addition to how-to series of
documents that describe how to work inside narrowly checked out work tree,
what the pitfalls are, etc., together with follow-up improvements of what
is already in 'next', and end user questions and reports on issues should
have come, if this is ever being used by anybody by now, but none of that
has happened.
^ permalink raw reply
* Re: [RFC PATCH 0/4] Teach git fetch to verify signed tags automatically
From: Junio C Hamano @ 2008-11-28 1:43 UTC (permalink / raw)
To: Deskin Miller; +Cc: Johannes Schindelin, git
In-Reply-To: <20081128001825.GA29662@euler>
Deskin Miller <deskinm@umich.edu> writes:
> The user didn't ask to verify, as I see it; rather, they asked git to
> *try* to verify.
If that is your argument, I really do not see any point in your patch.
They asked git to fetch, and did not say anything about trying anything
else.
^ 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