* Re: git alias question
From: Michael Horowitz @ 2012-01-02 5:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Aguilar, Dave Borowitz, git, Junio C Hamano
In-Reply-To: <m3zke8e2vh.fsf@localhost.localdomain>
Nice, works perfectly! Didn't notice that was there, guess last time
I looked, I was using an older version. I see it is in the git config
man page and all now.
Thanks,
Mike
On Sat, Dec 31, 2011 at 6:30 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Michael Horowitz <michael.horowitz@ieee.org> writes:
>
> > The log operation does seem to make the most sense as the mechanism to
> > search for the results. Making it work with difftool would work...
> > Not sure if "--log" to difftool or some other options as suggested in
> > the other thread would be most consistent UI-wise as stated, but
> > either would work for me.
> >
> > On a separate note, some environment variable like GIT_PREFIX with the
> > CWD would make the alias functionality more flexible.
>
> 1f5d271 (setup: Provide GIT_PREFIX to built-ins, 2011-05-25) is
> present in v1.7.7; 7cf16a1 (handle_alias: provide GIT_PREFIX to
> !alias, 2011-04-27) is in 1.7.6
>
> --
> Jakub Narebski
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Bill Zaumen @ 2012-01-02 3:53 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git, Junio C Hamano
In-Reply-To: <4F00780C.7090801@web.de>
On Sun, 2012-01-01 at 16:13 +0100, Jens Lehmann wrote:
> Am 29.12.2011 03:50, schrieb Bill Zaumen:
> > So what about clarifying
> the docs: ...
Clarifying the docs is a good solution given that a possibly large
number of existing repositories are dependent on the current behavior.
One way of explaining it is to say that "git first appends a
'/' to the superproject's origin URL if that URL does not already
end in a '/'. Relative URLs for submodules' origin repository are
resolved relative to this modified URL." Then the reader can simply
apply the normal URL rules.
I think either is OK - it's simply a judgment call as to which
explanation is easiest for a typical git user to understand.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <4F00BAA6.9050104@tu-clausthal.de>
Following you can find my first proposal, based upon patch 1. It's only the
perl part, because I haven't checked out Peffs git_prompt patch(es) and to
avoid double work.
ATM I'm unsure about the 'username' type, but I think it's quite necessary
to make git-svn behave like git-core in case of asking for a username. A type
'userpass' (username and password in one dialog) isn't mentioned here, because
it's not necessary for the git-svn part, but we should also specify/document it
if we want to use it in the future.
Btw. happy new year! ;)
---
git-svn.perl | 24 +++++++------------
perl/Git.pm | 70 ++++++++++++++++++++++++++++++++++++++++-----------------
2 files changed, 58 insertions(+), 36 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 26d3559..54cf77f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4356,17 +4356,16 @@ sub ssl_server_trust {
map $cert_info->$_, qw(hostname valid_from valid_until
issuer_dname fingerprint);
my $choice;
-prompt:
- print STDERR $may_save ?
+ my $prompt = $may_save ?
"(R)eject, accept (t)emporarily or accept (p)ermanently? " :
"(R)eject or accept (t)emporarily? ";
- STDERR->flush;
- $choice = lc(substr(<STDIN> || 'R', 0, 1));
- if ($choice =~ /^t$/i) {
+prompt:
+ $choice = lc(substr(Git->prompt($prompt) || 'R', 0, 1));
+ if ($choice eq "t") {
$cred->may_save(undef);
- } elsif ($choice =~ /^r$/i) {
+ } elsif ($choice eq "r") {
return -1;
- } elsif ($may_save && $choice =~ /^p$/i) {
+ } elsif ($may_save && $choice eq "p") {
$cred->may_save($may_save);
} else {
goto prompt;
@@ -4378,10 +4377,7 @@ prompt:
sub ssl_client_cert {
my ($cred, $realm, $may_save, $pool) = @_;
$may_save = undef if $_no_auth_cache;
- print STDERR "Client certificate filename: ";
- STDERR->flush;
- chomp(my $filename = <STDIN>);
- $cred->cert_file($filename);
+ $cred->cert_file(Git->prompt("Client certificate filename: ", 'filename'));
$cred->may_save($may_save);
$SVN::_Core::SVN_NO_ERROR;
}
@@ -4404,9 +4400,7 @@ sub username {
if (defined $_username) {
$username = $_username;
} else {
- print STDERR "Username: ";
- STDERR->flush;
- chomp($username = <STDIN>);
+ $username = Git->prompt("Username: ", 'username');
}
$cred->username($username);
$cred->may_save($may_save);
@@ -4415,7 +4409,7 @@ sub username {
sub _read_password {
my ($prompt, $realm) = @_;
- my $password = Git->prompt($prompt);
+ my $password = Git->prompt($prompt, 'pass');
$password;
}
diff --git a/perl/Git.pm b/perl/Git.pm
index ba9a5f2..17ddf40 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -512,52 +512,80 @@ C<git --html-path>). Useful mostly only internally.
sub html_path { command_oneline('--html-path') }
-=item prompt ( PROMPT )
+=item prompt ( PROMPT , TYPE )
Query user C<PROMPT> and return answer from user.
-If an external helper is specified via GIT_ASKPASS or SSH_ASKPASS, it
-is used to interact with the user; otherwise the prompt is given to
-and the answer is read from the terminal.
+If an external helper is specified via GIT_DIALOG, GIT_ASKPASS or
+SSH_ASKPASS, it is used to interact with the user; otherwise the
+prompt is given to and the answer is read from the terminal.
+
+Possible values for C<TYPE>:
+- '' or 'text': prompt for normal text (only GIT_DIALOG)
+- 'username': prompt for username (behaves exactly as 'text', but also
+ uses *_ASKPASS)
+- 'pass': prompt for password, echoing of what is typed is disabled on
+ the terminal, GUI tool shows asterisks.
+- 'filename': prompt for a filename, GUI tool migh provide file chooser
+ (only GIT_DIALOG)
=cut
sub prompt {
- my ($self, $prompt) = _maybe_self(@_);
+ my ($self, $prompt, $type) = _maybe_self(@_);
+ $type = 'text' unless ($type);
+ my $useAskPass = ($type eq 'pass' || $type eq 'username');
my $ret;
if (!defined $ret) {
- $ret = _prompt($ENV{'GIT_ASKPASS'}, $prompt);
+ $ret = _promptgitdialog($ENV{'GIT_DIALOG'}, $prompt, $type);
}
- if (!defined $ret) {
- $ret = _prompt($ENV{'SSH_ASKPASS'}, $prompt);
+ if ($useAskPass && !defined $ret) {
+ $ret = _promptaskpass($ENV{'GIT_ASKPASS'}, $prompt);
+ }
+ if ($useAskPass && !defined $ret) {
+ $ret = _promptaskpass($ENV{'SSH_ASKPASS'}, $prompt);
}
if (!defined $ret) {
$ret = '';
print STDERR $prompt;
STDERR->flush;
- require Term::ReadKey;
- Term::ReadKey::ReadMode('noecho');
- while (defined(my $key = Term::ReadKey::ReadKey(0))) {
- last if $key =~ /[\012\015]/; # \n\r
- $ret .= $key;
+ if ($type eq 'pass') {
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('noecho');
+ while (defined(my $key = Term::ReadKey::ReadKey(0))) {
+ last if $key =~ /[\012\015]/; # \n\r
+ $ret .= $key;
+ }
+ Term::ReadKey::ReadMode('restore');
+ print STDERR "\n";
+ STDERR->flush;
+ } else {
+ chomp($ret = <STDIN>);
}
- Term::ReadKey::ReadMode('restore');
- print STDERR "\n";
- STDERR->flush;
}
return $ret;
}
-sub _prompt {
+sub _promptgitdialog {
+ my ($gitdialog, $prompt, $type) = @_;
+ return undef unless ($askpass);
+ my $ret;
+ open my $fh, "-|", $gitdialog, $type, $prompt
+ or return undef;
+ $ret = <$fh>;
+ $ret =~ s/\r?\n$//; # strip \r\n, chomp does not work on all systems (i.e. windows) as expected
+ close ($fh);
+ return $ret;
+}
+
+sub _promptaskpass {
my ($askpass, $prompt) = @_;
- unless ($askpass) {
- return undef;
- }
+ return undef unless ($askpass);
my $ret;
open my $fh, "-|", $askpass, $prompt
or return undef;
$ret = <$fh>;
- $ret =~ s/[\012\015]//g; # \n\r
+ $ret =~ s/\r?\n$//; # strip \r\n, chomp does not work on all systems (i.e. windows) as expected
close ($fh);
return $ret;
}
--
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-01 20:54 UTC (permalink / raw)
To: Tomas Carnecky, nn6eumtr; +Cc: Git List
In-Reply-To: <B375E525C4704EA8807B5A59257B690B@PhilipOakley>
From: "Philip Oakley" <philipoakley@iee.org> Sent: Sunday, January 01, 2012
6:30 PM
> From: "Tomas Carnecky" <tom@dbservice.com> Sent: Sunday, January 01, 2012
> 12:27 AM
>>On 12/31/11 8:04 PM, nn6eumtr wrote:
>>> I have a number of older projects that I want to bring into a git
>>> repository. They predate a lot of the popular scm systems, so they are
>>> primarily a collection of tarballs today.
> I'm doing a similar thing with a set of zip files. I grouped mine into
> batches for easier checking and putting on to separate branches. Planning
> your branch requirements is probably the biggest task, and will depend on
> how you hope to use the new repo.
>
<snip>
>> There is a script which will import sources from multiple tarballs,
>> creating a commit with the contents of each tarball. It's in the git
>> repository under contrib/fast-import/import-tars.perl.
> I wasn't aware of those scripts. I'll be having a look at the zip import
> script for my needs.
Is there a mechanism for either having fast-import respect a .gitignore,
or determining if a given file/path should be ignored?
My zips contain a lot of compile by-products that should be excluded from
the repo.
> My extra problem is that almost all my zips have an extra top level
> directory that changes its name for every zip (but some don't..). The TLD
> changes confuses the git rename detection if I don't remove them before
> committing. Fortunately it's an internal development project with no
> formal
> releases so creating the history is a bit of a personal project which
> doesn't affect ongoing development (which is the crunch question for
> fidelity of the repo you create).
>
>> tom
> Philip
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <7v8vlrwzw9.fsf@alter.siamese.dyndns.org>
Am 01.01.2012 10:11 schrieb Junio C Hamano:
> I do not think Peff means the dialog must ask these three items at the
> same time. The point is that other codepaths know they need to ask them
> and would benefit if they can instruct the dialog external helper to ask
> them in a single interaction. So if your callsite does not ask them
> together, it is OK. You can keep asking them separately in two dialog
> interactions.
Sure. This is possible with my proposed interface.
Two parameters should be sufficient, since we get the path to the
repository from the CWD.
TYPE: 'text' (default), 'pass', 'userpass' (username + password in one
dialog), 'filename'
PROMPT
Am I missing something?
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Sven Strickroth @ 2012-01-01 19:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Jakub Narebski
In-Reply-To: <7vpqf8z8a6.fsf@alter.siamese.dyndns.org>
Am 28.12.2011 22:38 schrieb Junio C Hamano:
> I am however not sure if the second patch in this series is a good thing
> in the current shape. For GUI users who do not have a terminal, earlier
> they couldn't respond to these questions but now they can, so in that
> narrow sense we are not going backwards.
> But for people who use *_ASKPASS and are working from the terminal, it is
> a regression to ask these non-password questions using *_ASKPASS. Most
> likely, these helpers that are designed for password entry will hide what
> is typed, and I also wouldn't be surprised if some of them have fairly low
> input-length restriction that may be shorter than a long-ish pathname that
> users might want to give as an answer, which they could do in the terminal
> based interaction but will become impossible with this patch.
I'm still for the second patch to be applied (maybe w/o the certificate
filename prompt), too, because this makes git-svn behave the save way as
git-core does (especially asking for username).
Do you think that ppl. mainly using the terminal have *_ASKPASS set?
Most GUIs I know do set it automatically.
I agree that a new interface is needed (working on a patch), but before
we hurry, we should make git-core and git-svn behave the same way.
Btw. git-svn also does not honour git-credentials.
--
Best regards,
Sven Strickroth
ClamAV, a GPL anti-virus toolkit http://www.clamav.net
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Dirk Süsserott @ 2012-01-01 19:04 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: nn6eumtr, git
In-Reply-To: <4EFFA868.50605@dbservice.com>
Am 01.01.2012 01:27 schrieb Tomas Carnecky:
> On 12/31/11 8:04 PM, nn6eumtr wrote:
>> I have a number of older projects that I want to bring into a git
>> repository. They predate a lot of the popular scm systems, so they are
>> primarily a collection of tarballs today.
>>
>> I'm fairly new to git so I have a couple questions related to this:
>>
>> - What is the best approach for bringing them in? Do I just create a
>> repository, then unpack the files, commit them, clean out the
>> directory unpack the next tarball, and repeat until everything is loaded?
>>
>> - Do I need to pay special attention to files that are renamed/removed
>> from version to version?
>>
>> - If the timestamps change on a file but the actual content does not,
>> will git treat it as a non-change once it realizes the content hasn't
>> changed?
>>
>> - Last, if after loading the repository I find another version of the
>> files that predates those I've loaded, or are intermediate between two
>> commits I've already loaded, is there a way to go say that commit B is
>> actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
>> were to visualize the commit timeline or do diffs) Or do I just reload
>> the tarballs in order to achieve this?
>
> There is a script which will import sources from multiple tarballs,
> creating a commit with the contents of each tarball. It's in the git
> repository under contrib/fast-import/import-tars.perl.
>
> tom
@tom: True. I didn't know about that script, but it should work.
@nn6eumtr: Basically your workflow is perfect. But let me give you some
explanation:
git init
foreach archive in *.tar; do
tar xf $archive
git add --all .
git commit -m "Added $archive"
# now remove everything except for the .git directory
# with regular shell commands (rm -rf *). Also remove
# any dot-files (and the tarball itself, if it's in the
# current directory).
done
Notice the '--all' switch to 'git add': Normally, 'git add .' adds all
files that match the given pattern '.', i.e. all files in the current
directory (and below, it's recursive). The '--all' switch together with
the pattern '.' adds or updates all files already known to git *AND*
adds the files not yet known *AND* removes the files that are no longer
in the working tree. That's exactly what you want.
Consider archive1.tar with files A, B, C:
git add --all . # will add A, B, and C
Now remove A, B, C, and unpack archive2.tar. Assume it has files B, C,
D. A was deleted, B was changed, C is unchanged, D is new.
git add --all . # will remove A, add B, leave C, add D.
git will notice that C hasn't changed its content (timestamp doesn't
matter).
Without the '--all' switch, git would simply add B and D.
There is no problem re-arranging the history after your import (see "git
rebase --help", especially the --interactive section), but then you
probably will have conflicts and have to resolve them. I'd suggest to
re-start the import instead.
Please note that "for archive in *.tar" will pick the tarballs in
lexicographical order. That might not be your intention.
HTH,
Dirk
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Philip Oakley @ 2012-01-01 18:30 UTC (permalink / raw)
To: Tomas Carnecky, nn6eumtr; +Cc: Git List
In-Reply-To: <4EFFA868.50605@dbservice.com>
From: "Tomas Carnecky" <tom@dbservice.com> Sent: Sunday, January 01, 2012
12:27 AM
>On 12/31/11 8:04 PM, nn6eumtr wrote:
>> I have a number of older projects that I want to bring into a git
>> repository. They predate a lot of the popular scm systems, so they are
>> primarily a collection of tarballs today.
I'm doing a similar thing with a set of zip files. I grouped mine into
batches for easier checking and putting on to separate branches. Planning
your branch requirements is probably the biggest task, and will depend on
how you hope to use the new repo.
>> I'm fairly new to git so I have a couple questions related to this:
>>
>> - What is the best approach for bringing them in? Do I just create a
>> repository, then unpack the files, commit them, clean out the
>> directory unpack the next tarball, and repeat until everything is loaded?
Essentially yes; Obviously if you have an organisation in mind then you can
introduce maintenance branches etc as you develop the import.
If it is simply to create a nice history that isn't really looked at, then a
simple linear model is OK. If you need to keep old mintenance versions and
obtain diffs with newer versions then look at the various branching models
and populate appropriately.
>>
>> - Do I need to pay special attention to files that are renamed/removed
>> from version to version?
No; It is only if you use those file dates to determine the implied date for
the commit.
>>
>> - If the timestamps change on a file but the actual content does not,
>> will git treat it as a non-change once it realizes the content hasn't
>> changed?
Correct. In fact git doesn't record the time stamps anyway. It simply
records the content, and structure, of the snapshot.
>>
>> - Last, if after loading the repository I find another version of the
>> files that predates those I've loaded, or are intermediate between two
>> commits I've already loaded, is there a way to go say that commit B is
>> actually the ancestor of commit C? (i.e. a->>c becomes a->>b->>c if you
>> were to visualize the commit timeline or do diffs) Or do I just reload
>> the tarballs in order to achieve this?
You can use 'grafts' as a mechanism to re-arrange the commit order, and/or
join partial repos, and then use git filter-branch to re-write the lot as a
single cohesive repo. But this 'hack' does re-write all the commit SHA1
values, so you should minimise the number of times that happens...
It is worth capturing your import sequence as a script so that you can wash
/ rinse / repeat as often as needed to get a result you like.
> There is a script which will import sources from multiple tarballs,
> creating a commit with the contents of each tarball. It's in the git
> repository under contrib/fast-import/import-tars.perl.
I wasn't aware of those scripts. I'll be having a look at the zip import
script for my needs.
My extra problem is that almost all my zips have an extra top level
directory that changes its name for every zip (but some don't..). The TLD
changes confuses the git rename detection if I don't remove them before
committing. Fortunately it's an internal development project with no formal
releases so creating the history is a bit of a personal project which
doesn't affect ongoing development (which is the crunch question for
fidelity of the repo you create).
> tom
Philip
^ permalink raw reply
* Re: [PATCH resend] Do not create commits whose message contains NUL
From: Drew Northup @ 2012-01-01 16:27 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111213175932.GA1663@sigill.intra.peff.net>
On Tue, 2011-12-13 at 12:59 -0500, Jeff King wrote:
> It looks like we already have a check for is_utf8, and this is not
> failing that check. I guess because is_utf8 takes a NUL-terminated
> buffer, so it simply sees the truncated result (i.e., depending on
> endianness, "foo" in utf16 is something like "f\0o\0o\0", so we check
> only "f"). We could make is_utf8 take a length parameter to be more
> accurate, and then it would catch this.
>
> However, I think that's not quite what we want. We only check is_utf8 if
> the encoding field is not set. And really, we want to reject NULs no
> matter _which_ encoding they've set, because git simply doesn't handle
> them properly.
I had already started experimenting with automatically detecting decent
UTF-16 a long while back so that compatible platforms could handle it
appropriately in terms of creating diffs and dealing with newline
munging between platforms. There is no 100% sure-fire check for UTF-16
if you don't already suspect it is possibly UTF-16. If we really want to
check for possible UTF-16 specifically I can scrape out the check I
wrote up and send it along.
The is_utf8 check was not written to detect 100% valid UTF-8 per-se. It
seems to me that it was written as part of the "is this a binary or not"
check in the add/commit path. I have thought for some time that
specifying buffer length in that whole code path would be a good idea
(but I thought that somebody else had taken up that battle while I was
busy dealing with other problems elsewhere), if for no other reason it
would force it to deal with NULs more intelligently.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Question about commit message wrapping
From: Drew Northup @ 2012-01-01 16:03 UTC (permalink / raw)
To: Sidney San Martín
Cc: Michael Haggerty, Frans Klaver, Holger Hellmuth, Andrew Ardill,
JakubNarebski, git@vger.kernel.org
In-Reply-To: <3BFBBBF6-878E-4B98-A1BB-16F841B6773D@sidneysm.com>
FWIW, I'm leaving text in this email as my mail client found it (and not
reflowing as I usually do). You can clearly see the effect of one mail
client assuming that the end display is doing all of the wrapping (I'll
not name names). When I first read the mail it looked fine because my
mail client IGNORED the inconsistencies in line wrap modes.
On Wed, 2011-12-14 at 16:04 -0500, Sidney San Martín wrote:
> On Dec 12, 2011, at 10:14 PM, Michael Haggerty wrote:
>
> > FWIW I think automatic wrapping of commit messages is a bad idea. I
> > wrap my commit messages deliberately to make them look the way I want
> > them to look. The assumption of an 80-character display has historical
> > reasons, but it is also a relatively comfortable line-width to read
> > (even on wider displays).
>
> A lot of Git repos live in heterogeneous environments. I played a little with some of the popular Git interfaces I can use on my computer. The majority of them…
>
> - compose and show commit messages in a proportional font (where the width of and formatting in "80 characters" means nothing),
In virtually all modern tools the default font is the "system default"
font, which is typically variable width. In some places I've even seen
variable pitch font rendering (I know there's a more technical term for
it, but I'm not taking the time to look it up right now) used, which is
distinct in that it makes the text easier to read when there are
potentially overlapping descenders and ascenders on adjoining lines
while leaving text without that feature unchanged in line spacing and
kerning. Try rendering ASCII-ART with that enabled!
However, it is a rare GUI tool that does not allow the user to change
the font to something more appropriate (I use fixed-width fonts for most
programming and scripting, but they are not any more helpful for reading
log messages for instance). Text-based programming tools usually just
use the console font, whatever it is--and woe be to the programmer who
switches their "console" font to something variable width. (Doing so
makes any application written with curses/ncurses in mind look very very
odd as well.)
> - don’t insert line breaks when you write a commit message (and don't provide a way to do so automatically),
Most of the "tools" I have seen that ignore all user-entered line breaks
are actually poorly written applications attempting to protect some sort
of backing database from an injection attack. Given that, many WIKI
systems typically ignore single line breaks when rendering (double line
breaks are taken to be paragraph breaks in those cases I am aware of),
so any argument about that quickly becomes moot as well. If somebody is
writing a tool that does not allow me to force multiple line breaks when
desired then so far as I am concerned their tool is broken. I don't see
a point in changing GIT as a whole because somebody writes a broken GUI
implementation.
> - do wrap commit messages when showing them.
>
> Jakub, you said that education was the answer to getting some consistency in line wrapping, but I have trouble imagining the makers of new tools using fixed-width text for anything other than code.
Remember, as soon as you think you've idiot-proofed something somebody
builds a better idiot. That's why Jakub (and many others of us) would
prefer just to tell people about the way things are intended to work and
then get out of the way and let people make their own mistakes.
> > And given that commit messages sometimes
> > contain "flowable" paragraph text, sometimes code snippets, sometimes
> > ASCII art, etc, no automatic wrapping will work correctly unless
> > everybody agrees that commit messages must be written in some specific
> > form of markup (or lightweight markup). And I can't imagine such a
> > thing ever happening.
>
> The two biggest websites I know of for talking about code, GitHub and Stack Overflow, both adopted flavors of Markdown. It is basically the formatting syntax already used for commit messages in the Git project itself (this email too), so can be formatted to look good in a specific environment (i.e. proportional fonts) and looks good by itself.
>
> (Actually, as far as I can tell commit messages are the only place GitHub doesn’t currently render user-entered text as Markdown.)
>
> I think, now and in the future, consistency will be found most easily in in Markdown-like formatting and least in 80 columns of fixed-width text.
Given that there is little consensus even between Markdown-like
formatting methods (which have in some cases been around since the
advent of movable type presses, so far as I am aware) I have to agree
with Michael here.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: Possible submodule or submodule documentation issue
From: Jens Lehmann @ 2012-01-01 15:13 UTC (permalink / raw)
To: Bill Zaumen; +Cc: git, Junio C Hamano
In-Reply-To: <1325127030.1681.35.camel@yos>
Am 29.12.2011 03:50, schrieb Bill Zaumen:
> On Wed, 2011-12-28 at 20:47 +0100, Jens Lehmann wrote:
>> Am 27.12.2011 20:24, schrieb Bill Zaumen:
>> Hmm, the documentation says "the location relative to the
>> superproject’s origin repository", not the directory containing
>> it. This means you have to use ".." first to get out of the
>> repository itself, no?
>
> The problem is that the documentation also says that "<repository>
> is the URL of the new submodule's origin repository" and the wording
> would not make sense if the superproject's origin repository was not
> also named by a URL. The rules for resolving relative URIs (a URL is
> a specific type of URI) are given in
> http://tools.ietf.org/html/rfc3986#section-5.4
> which has some examples: if you resolve ./g against http://a/b/c/d;p?q
> you get http://a/b/c/g (the rules are purely syntactic and the syntax
> does not indicate that ".../foo.git" is a directory, and even the
> slashes do not definitively indicate directories in the sense of a
> file-system directory although they often do).
Thanks for that pointer, now I understand what you expected and why.
But as this behavior is in Git since September 2007 (f31a522a2d), I
suppose changing the behavior is a no-go. So what about clarifying
the docs:
---------8<-----------
[PATCH] docs: describe behavior of relative submodule URLs
Since the relative submodule URLs have been introduced in f31a522a2d, they
do not conform to the rules for resolving relative URIs but rather to
those of relative directories.
Document that behavior.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Documentation/git-submodule.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 6ec3fef..b729649 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -79,7 +79,12 @@ to exist in the superproject. If <path> is not given, the
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject's origin
-repository. If the superproject doesn't have an origin configured
+repository (Please note that to specify a repository 'foo.git'
+which is located right next to a superproject 'bar.git', you'll
+have to use '../foo.git' instead of './foo.git' - as one might expect
+when following the rules for relative URLs - because the evaluation
+of relative URLs in Git is identical to that of relative directories).
+If the superproject doesn't have an origin configured
the superproject is its own authoritative upstream and the current
working directory is used instead.
+
--
1.7.8.GIT
^ permalink raw reply related
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Jens Lehmann @ 2012-01-01 14:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
Am 29.12.2011 23:40, schrieb Junio C Hamano:
> Antony Male <antony.male@gmail.com> writes:
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
A quick test shows that using a bare repo won't fly because without the
core.worktree setting commands that operate on the work tree can't be
run anymore inside submodules (starting with the initial checkout). If
we could teach setup to take the directory where the gitfile was found
as first guess for the git work tree it looks like we can make that
approach work. I'll see if I can come up with something here ...
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Yes, and the core.worktree setting also contains an absolute path. So
we must either make that relative too and rewrite it on every "git
submodule add" to record the possibly changed path there or make the
bare clone work with a work tree (which sounds a bit strange ;-).
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
>
> #
That broke quite some tests for me (even though I really liked
to get rid of that if ;-)
Here is a patch that solves the first part of the absolute paths
problem (passes all tests; parts of the commit message shamelessly
copied from your proposal). Then another patch can tackle the
core.worktree config setting problem to make superprojects
relocatable gain.
---------8<--------
Subject: [PATCH] submodules: always use a relative path to gitdir
Recent versions of "git submodule" maintain the submodule <name> at
<path> in the superproject using a "separate git-dir" mechanism. The
repository data for the submodule is stored in ".git/modules/<name>/"
directory of the superproject, and its working tree is created at
"<path>/" directory, with "<path>/.git" file pointing at the
".git/modules/<name>/" directory.
This is so that we can check out an older version of the superproject
that does not yet have the submodule <name> anywhere without losing
(and later having to re-clone) the submodule repository. Removing
"<path>" won't lose ".git/modules/<name>", and a different branch that
has the submodule at different location in the superproject, say
"<path2>", can create "<path2>/" and ".git" in it to point at the same
".git/modules/<name>".
When instantiating such a submodule, if ".git/modules/<name>/" does
not exist in the superproject, the submodule repository needs to be
cloned there first. Then we only need to create "<path>" directory,
point ".git/modules/<name>/" in the superproject with "<path>/.git",
and check out the working tree.
However, the current code is not structured that way. The codepath to
deal with newly cloned submodules uses "git clone --separate-git-dir"
and creates "<path>" and "<path>/.git". This can make the resulting
submodule working tree at "<path>" different from the codepath for
existing submodules. An example of such differences is that this
codepath prepares "<path>/.git" with an absolute path, while the
normal codepath uses a relative path.
Fix the latter by always writing the relative path to the git directory
in "<path>/.git". To make that work, the 'name' variable has to be set to
the value of the 'path' variable for newly added submodules.
This is only the first step to make superprojects movable again like they
were before the separate-git-dir approach was introduced. The second step
must be to either use a relative path in core.worktree too or to get rid
of that setting by using a bare repo in "./git/modules/<name>".
While at it also replace an if/else construct evaluating the presence
of the 'reference' option with a single line of bash code.
Reported-by: Antony Male <antony.male@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-submodule.sh | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 3adab93..2a93c61 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -131,6 +131,7 @@ module_clone()
gitdir=
gitdir_base=
name=$(module_name "$path" 2>/dev/null)
+ test -n "$name" || name="$path"
base_path=$(dirname "$path")
gitdir=$(git rev-parse --git-dir)
@@ -159,18 +160,15 @@ module_clone()
if test -d "$gitdir"
then
mkdir -p "$path"
- echo "gitdir: $rel_gitdir" >"$path/.git"
rm -f "$gitdir/index"
else
mkdir -p "$gitdir_base"
- if test -n "$reference"
- then
- git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
- else
- git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
- fi ||
+ git clone $quiet -n ${reference:+"$reference"} \
+ --separate-git-dir "$gitdir" "$url" "$path" ||
die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
fi
+
+ echo "gitdir: $rel_gitdir" >"$path/.git"
}
#
--
1.7.8.2.303.g78a27
^ permalink raw reply related
* git exit with error code 1
From: ashish @ 2012-01-01 14:41 UTC (permalink / raw)
To: git
Ant script to run clone
<target name="clone" description="get the latest files">
<delete includeemptydirs="true">
<filesetdir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss"
defaultexcludes="false">
<include name="**/*" />
</fileset>
</delete>
<exec executable="git"
dir="/opt/cruisecontrol-bin-2.8.4/projects/Mss/copyExample/local_copy/Mss">
<arg line="clone -o fl ssh://git@ipaddress/git/run.git Mss" />
</exec>
</target>
In my current CruiseControl setup I am running the following target:
<modificationsetquietperiod="60">
<git
localworkingcopy="${projects.dir}/${project.name}/local_copy/${project.name}/"/>
</modificationset>
Running cruisecontrol gives git exit with error code 1. I guess
modificationset is not able to find git local working copy.
Any help would be welcome and greatly appreciable .
--
View this message in context: http://git.661346.n2.nabble.com/git-exit-with-error-code-1-tp7142041p7142041.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
From: Junio C Hamano @ 2012-01-01 9:11 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <4EFDD06A.3010708@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 30.12.2011 14:54 schrieb Jeff King:
> ...
>> Username: <text input>
>> Password: <text input>
>> Remember password? [checkbox]
>>
>> I was planning to do something custom for credentials as an extension to
>> the credential helper protocol, but this could also fall under the
>> heading of a general prompt helper.
>
> This might be problematic, because (for git-svn) username and password
> are not requested together.
I do not think Peff means the dialog must ask these three items at the
same time. The point is that other codepaths know they need to ask them
and would benefit if they can instruct the dialog external helper to ask
them in a single interaction. So if your callsite does not ask them
together, it is OK. You can keep asking them separately in two dialog
interactions.
^ permalink raw reply
* Re: How to deal with historic tar-balls
From: Tomas Carnecky @ 2012-01-01 0:27 UTC (permalink / raw)
To: nn6eumtr; +Cc: git
In-Reply-To: <4EFF5CDA.5050809@gmail.com>
On 12/31/11 8:04 PM, nn6eumtr wrote:
> I have a number of older projects that I want to bring into a git
> repository. They predate a lot of the popular scm systems, so they are
> primarily a collection of tarballs today.
>
> I'm fairly new to git so I have a couple questions related to this:
>
> - What is the best approach for bringing them in? Do I just create a
> repository, then unpack the files, commit them, clean out the
> directory unpack the next tarball, and repeat until everything is loaded?
>
> - Do I need to pay special attention to files that are renamed/removed
> from version to version?
>
> - If the timestamps change on a file but the actual content does not,
> will git treat it as a non-change once it realizes the content hasn't
> changed?
>
> - Last, if after loading the repository I find another version of the
> files that predates those I've loaded, or are intermediate between two
> commits I've already loaded, is there a way to go say that commit B is
> actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
> were to visualize the commit timeline or do diffs) Or do I just reload
> the tarballs in order to achieve this?
There is a script which will import sources from multiple tarballs,
creating a commit with the contents of each tarball. It's in the git
repository under contrib/fast-import/import-tars.perl.
tom
^ permalink raw reply
* Re: git alias question
From: Jakub Narebski @ 2011-12-31 23:30 UTC (permalink / raw)
To: Michael Horowitz; +Cc: David Aguilar, Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAFLRborAuoWKxOeHtPRujSYbQPk67RCxTiVBavtWDeh-Byfa2w@mail.gmail.com>
Michael Horowitz <michael.horowitz@ieee.org> writes:
> The log operation does seem to make the most sense as the mechanism to
> search for the results. Making it work with difftool would work...
> Not sure if "--log" to difftool or some other options as suggested in
> the other thread would be most consistent UI-wise as stated, but
> either would work for me.
>
> On a separate note, some environment variable like GIT_PREFIX with the
> CWD would make the alias functionality more flexible.
1f5d271 (setup: Provide GIT_PREFIX to built-ins, 2011-05-25) is
present in v1.7.7; 7cf16a1 (handle_alias: provide GIT_PREFIX to
!alias, 2011-04-27) is in 1.7.6
--
Jakub Narebski
^ permalink raw reply
* Re: git alias question
From: Michael Horowitz @ 2011-12-31 21:31 UTC (permalink / raw)
To: David Aguilar; +Cc: Dave Borowitz, git, Junio C Hamano
In-Reply-To: <CAJDDKr5a8TB82h4ULWtamLOVu_4Fv+cGw1YfEL987gM3yM4TMg@mail.gmail.com>
The log operation does seem to make the most sense as the mechanism to
search for the results. Making it work with difftool would work...
Not sure if "--log" to difftool or some other options as suggested in
the other thread would be most consistent UI-wise as stated, but
either would work for me.
On a separate note, some environment variable like GIT_PREFIX with the
CWD would make the alias functionality more flexible.
Mike
On Thu, Dec 29, 2011 at 8:59 PM, David Aguilar <davvid@gmail.com> wrote:
>
> On Thu, Dec 29, 2011 at 9:08 AM, Dave Borowitz <dborowitz@google.com> wrote:
> > On Wed, Dec 28, 2011 at 17:27, Michael Horowitz
> > <michael.horowitz@ieee.org> wrote:
> >> ldiff = "!git diff `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > FWIW, you can also do this as:
> > ldiff = log -p -1 --format=format: --
> >
> >> ldifft = "!git difftool `git rev-list --reverse -n 2 HEAD -- $1` -- $1"
> >
> > I don't know that you can do something equivalent with difftool. I
> > suppose you could do the above with "GIT_EXTERNAL_DIFF=<some difftool
> > wrapper> git ldiff", but that's not very helpful.
>
> difftool cannot be driven by log right now. It is something we
> thought would be helpful in the past:
>
> http://thread.gmane.org/gmane.comp.version-control.git/114269/focus=114367
>
> On 2009-03-23 Junio C Hamano <gitster <at> pobox.com> wrote:
> > Perhaps we would want a convenient way for "log -p" or "show -p" to drive
> > difftool as a backend?
>
> I think that's exactly it. difftool wraps diff; a log equivalent
> would be quite helpful.
>
> One idea is for difftool to learn a "--log" option to make it wrap log
> instead. I don't know if a diff-like command having a "--log" option
> is ideal from a consistency-of-user-interface POV so I'm open to
> ideas. It is convenient, though. It does seem like difftool would be
> a good place to expose this feature.
>
> I'd be interested in the "teach log / show -p about GIT_EXTERNAL_DIFF"
> route, if that sounds like a good idea.
> --
> David
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2011-12-31 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vsjk3vw67.fsf@alter.siamese.dyndns.org>
On Thu, Dec 29, 2011 at 5:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antony Male <antony.male@gmail.com> writes:
>
>> Git submoule clone uses git clone --separate-git-dir to checkout a
>> submodule's git repository into <supermodule>/.git/modules,...
>
> This is misleading. The <superproject>/.git/modules/<name> is the location
> of the $GIT_DIR for the submodule <name>, not the location of its checkout
> at <superproject>/<path> that is outside <superproject>/.git/modules/
> hierarchy.
Yes, so I think a simple s/checkout/clone/ should fix it.
[...]
>> In the submodules scenario, neither the git repository nor the working
>> copy will be moved relative to each other. However, the supermodule may
>> be moved,...
>
> Again, who said that you are allowed to move the superproject directory in
> the first place? I would understand that it might be nicer if it could be
> moved but I haven't thought this through thoroughly yet---there may be
> other side effects from doing so, other than the relativeness of "gitdir".
Previously it was accepted practice to clone a local repo with rsync.
This method continues to work well even with submodules before
git-files became the norm. But now it breaks because of the absolute
paths.
Similarly, clones on network mounts and portable drives where absolute
paths may change from time to time or machine to machine will also
break now but worked before.
So, who said you were NOT allowed to move the superproject directory
directory in the first place? It seems natural that you should be
able to do so, especially since the submodules are all contained
within the superproject path.
>> Previously, if git submodule clone was called when the submodule's git
>> repository already existed in <supermodule>/.git/modules, it would
>> simply re-create the submodule's .git file, using a relative path.
>
> ... "to point at the existing <superproject>/.git/modules/<name>".
>
> Overall, I think I can agree with the goal, but the tone of the proposed
> commit log message rubs the reader in a wrong way to see clearly what this
> patch is proposing to do and where its merit lies. It is probably not a
> big deal, and perhaps it may be just the order of explanation.
>
> I would probably explain the goal like this if I were doing this patch,
> without triggering any need for revisionist history bias.
>
> Recent versions of "git submodule" maintain the submodule <name> at
> <path> in the superproject using a "separate git-dir" mechanism. The
> repository data for the submodule is stored in ".git/modules/<name>/"
> directory of the superproject, and its working tree is created at
> "<path>/" directory, with "<path>/.git" file pointing at the
> ".git/modules/<name>/" directory.
>
> This is so that we can check out an older version of the superproject
> that does not yet have the submodule <name> anywhere without losing
> (and later having to re-clone) the submodule repository. Removing
Revisionism nit: the real danger here is that you lose local commits.
> "<path>" won't lose ".git/modules/<name>", and a different branch that
> has the submodule at different location in the superproject, say
> "<path2>", can create "<path2>/" and ".git" in it to point at the same
> ".git/modules/<name>".
This doesn't explain why one path is absolute and one is relative.
But I don't suppose this is the place for historical documentation
anyway.
> When instantiating such a submodule, if ".git/modules/<name>/" does
> not exist in the superproject, the submodule repository needs to be
> cloned there first. Then we only need to create "<path>" directory,
> point ".git/modules/<name>/" in the superproject with "<path>/.git",
> and check out the working tree.
>
> However, the current code is not structured that way. The codepath to
> deal with newly cloned submodules uses "git clone --separate-git-dir"
> and creates "<path>" and "<path>/.git". This can make the resulting
> submodule working tree at "<path>" different from the codepath for
> existing submodules. An example of such differences is that this
> codepath prepares "<path>/.git" with an absolute path, while the
> normal codepath uses a relative path.
I had to read this three times before I understood it. There are some
minor grammatical nits in it, but also the use of nearness and use of
"path" and "codepath" to mean two unrelated things was misleading me.
Here's my attempt to clean it up:
However, the current code is not structured that way. The code to
deal with newly cloned submodules is different from the code to
checkout a workdir for existing submodules. The "newly cloned
submodule" code uses "git clone --separate-git-dir" to create
"<path>" and "<path>/.git". The "existing submodules" code
simply creates the "<path>/.git" internally, using a relative path.
This makes the resulting submodule working tree at "<path>" different
depending on which code is used. An example of such differences
is that the "newly cloned submodule" code prepares "<path>/.git"
with an absolute path, while the "existing submodules" code
prepares the same file using a relative path.
> When explained this way, the remedy is quite clear, and the change is more
> forward-looking, isn't it? If we later start doing more in the codepath
> to deal with existing submodules, your patch may break without having
> extra code to cover the "newly cloned" case, too.
> I further wonder if we can get away without using separate-git-dir option
> in this codepath, though. IOW using
>
> git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>
> might be a better solution.
You may be right about this one. I still think the addition of a
--relative-path option to 'git-checkout --separate-work-dir' could be
useful and also easier to maintain/describe.
> For example (this relates to the point I mumbled "haven't thought this
> through thoroughly yet"), doesn't the newly cloned repository have
> core.worktree that points at the working tree that records the <path>,
> which would become meaningless when a commit in the superproject that
> binds the submodule at different path <path2>?
Ooh, yes it does. Maybe that should be fixed in this case too.
Because submodule cloning with a separate work-dir is a special case
of git-files and work-dirs because we know that each is relative
(subordinate) to the superproject path. Therefore, I think in this
special-case version of the "separate work-dir" scenario, we should
use super-project-relative paths for both cases.
How do we codify this so this functionality is reliably retained by
future developers? I think moving the code into someplace more
explicit would help, but I haven't looked too deeply at the code.
> git-submodule.sh | 21 ++++++++-------------
> 1 files changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 3adab93..9a23e9d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -156,21 +156,16 @@ module_clone()
> ;;
> esac
>
> - if test -d "$gitdir"
> + if ! test -d "$gitdir"
> then
> - mkdir -p "$path"
> - echo "gitdir: $rel_gitdir" >"$path/.git"
> - rm -f "$gitdir/index"
> - else
> - mkdir -p "$gitdir_base"
> - if test -n "$reference"
> - then
> - git-clone $quiet "$reference" -n "$url" "$path" --separate-git-dir "$gitdir"
> - else
> - git-clone $quiet -n "$url" "$path" --separate-git-dir "$gitdir"
> - fi ||
> - die "$(eval_gettext "Clone of '\$url' into submodule path '\$path' failed")"
> + git clone $quiet -n ${reference:+"$reference"} \
> + --separate-git-dir "$gitdir" "$url" "$path" ||
> + die "$(eval_gettext "Clone of '\$url' for submodule '\$name' failed")
> fi
> +
> + mkdir -p "$path"
> + echo "gitdir: $rel_gitdir" >"$path/.git"
> + rm -f "$gitdir/index"
> }
Doesn't this avoid creating core.worktree in the first place? I'm ok
with that because I assume it's never used in the submodule scenario,
but I also suspect that assumption could be wrong. Any concerns?
Phil
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2011-12-31 20:31 UTC (permalink / raw)
To: Antony Male; +Cc: git, gitster, iveqy
In-Reply-To: <1325192426-10103-1-git-send-email-antony.male@gmail.com>
On Thu, Dec 29, 2011 at 4:00 PM, Antony Male <antony.male@gmail.com> wrote:
> This fixes a problem where moving a git repository with checked-out
> submodules would cause a fatal error when commands such as 'git
> submodule update' were run.
Thanks. I noticed this itch when looking at git-files a few months
ago. It bothered me, but not enough to fix it; just enough to note
it as a problem area to avoid in the future.
> An alternative patch would teach git-clone an option to control whether
> an absolute or relative path is used when --separate-git-dir is passed.
I think I like this option better. Did you look at what it would take?
Phil
^ permalink raw reply
* How to deal with historic tar-balls
From: nn6eumtr @ 2011-12-31 19:04 UTC (permalink / raw)
To: git
I have a number of older projects that I want to bring into a git
repository. They predate a lot of the popular scm systems, so they are
primarily a collection of tarballs today.
I'm fairly new to git so I have a couple questions related to this:
- What is the best approach for bringing them in? Do I just create a
repository, then unpack the files, commit them, clean out the directory
unpack the next tarball, and repeat until everything is loaded?
- Do I need to pay special attention to files that are renamed/removed
from version to version?
- If the timestamps change on a file but the actual content does not,
will git treat it as a non-change once it realizes the content hasn't
changed?
- Last, if after loading the repository I find another version of the
files that predates those I've loaded, or are intermediate between two
commits I've already loaded, is there a way to go say that commit B is
actually the ancestor of commit C? (i.e. a->c becomes a->b->c if you
were to visualize the commit timeline or do diffs) Or do I just reload
the tarballs in order to achieve this?
All replies appreciated!
^ permalink raw reply
* [PATCH] Work around sed portability issue in t8006-blame-textconv
From: Ben Walton @ 2011-12-31 13:44 UTC (permalink / raw)
To: git, gitster; +Cc: Ben Walton
In test 'blame --textconv with local changes' of t8006-blame-textconv,
using /usr/xpg4/bin/sed on Solaris as set by SANE_TOOL_PATH, an
additional newline was added to the output from the 'helper' script
driven by git attributes.
This was noted by sed with a message such as:
sed: Missing newline at end of file zero.bin.
In turn, this was triggering a fatal error from git blame:
fatal: unable to read files to diff
The git blame --textconv stdout was empty as a result of the error
condition above. This caused the test to fail because the output
value differed from the expected result.
Use perl -p -e instead of sed -e to work around this portability issue
as it will not insert the newline. This allows the git blame call to
complete at which point the output comparison is successful.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
t/t8006-blame-textconv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t8006-blame-textconv.sh b/t/t8006-blame-textconv.sh
index 4ee42f1..c3c22f7 100755
--- a/t/t8006-blame-textconv.sh
+++ b/t/t8006-blame-textconv.sh
@@ -10,7 +10,7 @@ find_blame() {
cat >helper <<'EOF'
#!/bin/sh
grep -q '^bin: ' "$1" || { echo "E: $1 is not \"binary\" file" 1>&2; exit 1; }
-sed 's/^bin: /converted: /' "$1"
+perl -p -e 's/^bin: /converted: /' "$1"
EOF
chmod +x helper
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Documentation: read-tree --prefix works with existing subtrees
From: Clemens Buchacher @ 2011-12-31 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since 34110cd4 (Make 'unpack_trees()' have a separate source and
destination index) it is no longer true that a subdirectory with
the same prefix must not exist.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
Documentation/git-read-tree.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 5375549..a43e874 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -83,11 +83,10 @@ OPTIONS
--prefix=<prefix>/::
Keep the current index contents, and read the contents
- of the named tree-ish under the directory at `<prefix>`. The
- original index file cannot have anything at the path
- `<prefix>` itself, nor anything in the `<prefix>/`
- directory. Note that the `<prefix>/` value must end
- with a slash.
+ of the named tree-ish under the directory at `<prefix>`.
+ The command will refuse to overwrite entries that already
+ existed in the original index file. Note that the `<prefix>/`
+ value must end with a slash.
--exclude-per-directory=<gitignore>::
When running the command with `-u` and `-m` options, the
--
1.7.8
^ permalink raw reply related
* [PATCHv2] stash: Don't fail if work dir contains file named 'HEAD'
From: Jonathon Mah @ 2011-12-31 0:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Thomas Rast
When performing a plain "git stash" (without --patch), git-diff would fail
with "fatal: ambiguous argument 'HEAD': both revision and filename". The
output was piped into git-update-index, masking the failed exit status.
The output is now sent to a temporary file (which is cleaned up by
existing code), and the exit status is checked. The "HEAD" arg to the
git-diff invocation has been disambiguated too, of course.
In patch mode, "git stash -p" would fail harmlessly, leaving the working
dir untouched. Interactive adding is fine, but the resulting tree was
diffed with an ambiguous 'HEAD' argument.
Use >foo (no space) when redirecting output.
In t3904, checks and operations on each file are in the order they'll
appear when interactively staging.
In t3905, fix a bug in "stash save --include-untracked -q is quiet": The
redirected stdout file was considered untracked, and so was removed from
the working directory. Use test path helper functions where appropriate.
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
---
Also contains several fixes / changes for tests. Let me know if these
would better belong separately.
git-stash.sh | 7 +++--
t/t3903-stash.sh | 24 ++++++++++++++++++
t/t3904-stash-patch.sh | 47 ++++++++++++++++++++++-------------
t/t3905-stash-include-untracked.sh | 33 +++++++++++++++++-------
4 files changed, 80 insertions(+), 31 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index c766692..fe4ab28 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -115,7 +115,8 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff --name-only -z HEAD | git update-index -z --add --remove --stdin &&
+ git diff --name-only -z HEAD -- >"$TMP-stagenames" &&
+ git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"
) ) ||
@@ -134,7 +135,7 @@ create_stash () {
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
die "$(gettext "Cannot save the current worktree state")"
- git diff-tree -p HEAD $w_tree > "$TMP-patch" &&
+ git diff-tree -p HEAD $w_tree -- >"$TMP-patch" &&
test -s "$TMP-patch" ||
die "$(gettext "No changes selected")"
@@ -491,7 +492,7 @@ drop_stash () {
die "$(eval_gettext "\${REV}: Could not drop stash entry")"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse --verify "$ref_stash@{0}" >/dev/null 2>&1 || clear_stash
}
apply_to_branch () {
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index fcdb182..dbe2ac1 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -601,4 +601,28 @@ test_expect_success 'stash apply shows status same as git status (relative to cu
test_cmp expect actual
'
+cat > expect << EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..fe0cbee
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++file-not-a-ref
+EOF
+
+test_expect_success 'stash where working directory contains "HEAD" file' '
+ git stash clear &&
+ git reset --hard &&
+ echo file-not-a-ref > HEAD &&
+ git add HEAD &&
+ test_tick &&
+ git stash &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD &&
+ test "$(git rev-parse stash^)" = "$(git rev-parse HEAD)" &&
+ git diff stash^..stash > output &&
+ test_cmp output expect
+'
+
test_done
diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
index 781fd71..70655c1 100755
--- a/t/t3904-stash-patch.sh
+++ b/t/t3904-stash-patch.sh
@@ -7,7 +7,8 @@ test_expect_success PERL 'setup' '
mkdir dir &&
echo parent > dir/foo &&
echo dummy > bar &&
- git add bar dir/foo &&
+ echo committed > HEAD &&
+ git add bar dir/foo HEAD &&
git commit -m initial &&
test_tick &&
test_commit second dir/foo head &&
@@ -17,47 +18,57 @@ test_expect_success PERL 'setup' '
save_head
'
-# note: bar sorts before dir, so the first 'n' is always to skip 'bar'
+# note: order of files with unstaged changes: HEAD bar dir/foo
test_expect_success PERL 'saying "n" does nothing' '
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state dir/foo work index &&
- (echo n; echo n) | test_must_fail git stash save -p &&
- verify_state dir/foo work index &&
- verify_saved_state bar
+ (echo n; echo n; echo n) | test_must_fail git stash save -p &&
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_saved_state bar &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash -p' '
- (echo n; echo y) | git stash save -p &&
- verify_state dir/foo head index &&
+ (echo y; echo n; echo y) | git stash save -p &&
+ verify_state HEAD committed HEADfile_index &&
verify_saved_state bar &&
+ verify_state dir/foo head index &&
git reset --hard &&
git stash apply &&
- verify_state dir/foo work head &&
- verify_state bar dummy dummy
+ verify_state HEAD HEADfile_work committed &&
+ verify_state bar dummy dummy &&
+ verify_state dir/foo work head
'
test_expect_success PERL 'git stash -p --no-keep-index' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save -p --no-keep-index &&
- verify_state dir/foo head head &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save -p --no-keep-index &&
+ verify_state HEAD committed committed &&
verify_state bar bar_work dummy &&
+ verify_state dir/foo head head &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'git stash --no-keep-index -p' '
- set_state dir/foo work index &&
+ set_state HEAD HEADfile_work HEADfile_index &&
set_state bar bar_work bar_index &&
- (echo n; echo y) | git stash save --no-keep-index -p &&
+ set_state dir/foo work index &&
+ (echo y; echo n; echo y) | git stash save --no-keep-index -p &&
+ verify_state HEAD committed committed &&
verify_state dir/foo head head &&
verify_state bar bar_work dummy &&
git reset --hard &&
git stash apply --index &&
- verify_state dir/foo work index &&
- verify_state bar dummy bar_index
+ verify_state HEAD HEADfile_work HEADfile_index &&
+ verify_state bar dummy bar_index &&
+ verify_state dir/foo work index
'
test_expect_success PERL 'none of this moved HEAD' '
diff --git a/t/t3905-stash-include-untracked.sh b/t/t3905-stash-include-untracked.sh
index ef44fb2..a5e7e6b 100755
--- a/t/t3905-stash-include-untracked.sh
+++ b/t/t3905-stash-include-untracked.sh
@@ -17,6 +17,7 @@ test_expect_success 'stash save --include-untracked some dirty working directory
echo 3 > file &&
test_tick &&
echo 1 > file2 &&
+ echo 1 > HEAD &&
mkdir untracked &&
echo untracked >untracked/untracked &&
git stash --include-untracked &&
@@ -35,6 +36,13 @@ test_expect_success 'stash save --include-untracked cleaned the untracked files'
'
cat > expect.diff <<EOF
+diff --git a/HEAD b/HEAD
+new file mode 100644
+index 0000000..d00491f
+--- /dev/null
++++ b/HEAD
+@@ -0,0 +1 @@
++1
diff --git a/file2 b/file2
new file mode 100644
index 0000000..d00491f
@@ -51,14 +59,16 @@ index 0000000..5a72eb2
+untracked
EOF
cat > expect.lstree <<EOF
+HEAD
file2
untracked
EOF
test_expect_success 'stash save --include-untracked stashed the untracked files' '
- test "!" -f file2 &&
- test ! -e untracked &&
- git diff HEAD stash^3 -- file2 untracked >actual &&
+ test_path_is_missing file2 &&
+ test_path_is_missing untracked &&
+ test_path_is_missing HEAD &&
+ git diff HEAD stash^3 -- HEAD file2 untracked >actual &&
test_cmp expect.diff actual &&
git ls-tree --name-only stash^3: >actual &&
test_cmp expect.lstree actual
@@ -75,6 +85,7 @@ git clean --force --quiet
cat > expect <<EOF
M file
+?? HEAD
?? actual
?? expect
?? file2
@@ -116,10 +127,12 @@ test_expect_success 'stash save --include-untracked dirty index got stashed' '
git reset > /dev/null
+# Must direct output somewhere where it won't be considered an untracked file
test_expect_success 'stash save --include-untracked -q is quiet' '
echo 1 > file5 &&
- git stash save --include-untracked --quiet > output.out 2>&1 &&
- test ! -s output.out
+ git stash save --include-untracked --quiet > .git/stash-output.out 2>&1 &&
+ test_line_count = 0 .git/stash-output.out &&
+ rm -f .git/stash-output.out
'
test_expect_success 'stash save --include-untracked removed files' '
@@ -133,7 +146,7 @@ rm -f expect
test_expect_success 'stash save --include-untracked removed files got stashed' '
git stash pop &&
- test ! -f file
+ test_path_is_missing file
'
cat > .gitignore <<EOF
@@ -155,14 +168,14 @@ test_expect_success 'stash save --include-untracked respects .gitignore' '
test_expect_success 'stash save -u can stash with only untracked files different' '
echo 4 > file4 &&
git stash -u &&
- test "!" -f file4
+ test_path_is_missing file4
'
test_expect_success 'stash save --all does not respect .gitignore' '
git stash -a &&
- test "!" -f ignored &&
- test "!" -e ignored.d &&
- test "!" -f .gitignore
+ test_path_is_missing ignored &&
+ test_path_is_missing ignored.d &&
+ test_path_is_missing .gitignore
'
test_expect_success 'stash save --all is stash poppable' '
--
1.7.8
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply related
* Re: [PATCH] stash: Don't fail if work dir contains file named 'HEAD'
From: Jonathon Mah @ 2011-12-31 0:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <8739c28iwh.fsf@thomas.inf.ethz.ch>
Thanks for the feedback, Thomas. I should note, this bug initially came up on #git several days ago.
I've tried to take on all your suggestions; patch v2 imminent.
On 2011-12-30, at 02:15, Thomas Rast wrote:
> Jonathon Mah <me@JonathonMah.com> writes:
>> diff --git a/t/t3904-stash-patch.sh b/t/t3904-stash-patch.sh
> [...]
>
> Other reviewers may want to read these hunks in word diff mode, where it
> is far easier to verify that the functionality tested is a superset:
>
> test_expect_success PERL 'saying "n" does nothing' '
> {+set_state HEAD HEADfile_work HEADfile_index &&+}
> set_state dir/foo work index &&
> (echo n; echo {+n; echo+} n) | test_must_fail git stash save -p &&
> verify_state [-dir/foo work index-]{+HEAD HEADfile_work HEADfile_index+} &&
> verify_saved_state bar {+&&+}
> {+ verify_state dir/foo work index+}
> '
I added a note to the message: In t3904, checks and operations on each file are in the order they'll appear when interactively staging.
That is, "echo y/n; echo y/n; ..." for the three files corresponds to the surrounding checks.
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* 1.7.7.3 wishlist: add --verbose option to git-tag
From: Jari Aalto @ 2011-12-30 23:32 UTC (permalink / raw)
To: git
In scripts it would be useful if "git tag" would provide option:
--verbose
As in script:
git tag --verbose -m "Initial import" upstream/1.0
It would also help if all commands would use similar interface. In "git
tag" case, this would meen relocating:
-v => -g, --verify-gpg
And reserve these:
-v, --verbose
Jari
^ 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