* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 16:28 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707191715000.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Here a short description, which you should read until you understand
> it and then leave me alone:
>
> To add a directory to the tracked content, you have to _mark_ it as
> tracked. So that when you remove the _real_ content of the
> directory, Git will not remove it.
Correct. That is what my proposal is about.
> Alas, we already have such a marker. It is called ".gitignore", and
> has been ignored by _you_. There is _nothing_ wrong, from a
> technical standpoint, to call this marker ".gitignore", and it is
> _also_ not wrong to put this marker into the file system _in
> addition_ to the index.
Uh, then the directories are no longer empty.
> So go and add your directories via that marker, and _be done with
> it_.
But one is not done before running
find -name .gitignore -delete
and then the next recursive add will remove the .gitignore "markers".
The idea of "." is to have a marker that does _not_ appear in the work
directory.
--
David Kastrup
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Brian Gernhardt @ 2007-07-19 16:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707191715000.14781@racer.site>
On Jul 19, 2007, at 12:17 PM, Johannes Schindelin wrote:
> Alas, we already have such a marker. It is called ".gitignore",
> and has
> been ignored by _you_. There is _nothing_ wrong, from a technical
> standpoint, to call this marker ".gitignore", and it is _also_ not
> wrong
> to put this marker into the file system _in addition_ to the index.
>
> So go and add your directories via that marker, and _be done with it_.
But this alters the content of the directory away from what I want it
to be, namely empty. You aren't addressing the concept of tracking
an empty directory, you're just saying you won't do it.
~~ Brian
^ permalink raw reply
* Re: [REVISED PATCH 2/6] Introduce commit notes
From: Linus Torvalds @ 2007-07-19 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Alberto Bertogli, git, Johan Herland
In-Reply-To: <7vfy3l3rj0.fsf@assigned-by-dhcp.cox.net>
On Wed, 18 Jul 2007, Junio C Hamano wrote:
>
> Another anchoring clue you seem not to be exploiting fully is
> that the ASCII part must match "^[1-7][0-7]{4,5} " (mode bytes).
I did that on purpose.
The SHA1 *can* contain those characters too, so that's not really useful
to us, and the only special character really is the NUL character (which
is the only one cannot exists in the ASCII part - old-style trees can
contain '/' too, although that's going away).
Also, the mode bytes may not be visible: if we start in a long filename,
we'll never have looked at the mode bytes, but if we see a NUL character
after having seen 20 non-NUL characters (long filename), we already know
we got it. So I don't think we can even usefully use the other knowledge
of the format of the ASCII part (other than to know it doesn't contain
NUL's).
Of course, we can (and should) verify that the tree entry we find is
valid, and *then* it makes sense to check the rules for the ASCII part.
But that's only after we have already found the place.
> I was suggesting to have a specialized parser only to read such
> tree objects that are "abused" to represent notes. You can
> cheaply validate that these trees are of expected shape.
Sure. That said, I'm less interested in the notes than I am in the cost fo
"git blame", and that could be optimized by having some special code in
"tree_entry_interesting()" to find the tree entries using binary search.
The special code would trigger only for:
- large trees
- "opt->nr_paths == 1"
but the latter case is the one that matters for blame in the first place,
so..
Linus
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Johannes Schindelin @ 2007-07-19 17:30 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <CC669745-4434-478E-9A24-E474071578C6@silverinsanity.com>
Hi,
On Thu, 19 Jul 2007, Brian Gernhardt wrote:
> On Jul 19, 2007, at 12:17 PM, Johannes Schindelin wrote:
>
> > Alas, we already have such a marker. It is called ".gitignore", and has
> > been ignored by _you_. There is _nothing_ wrong, from a technical
> > standpoint, to call this marker ".gitignore", and it is _also_ not wrong
> > to put this marker into the file system _in addition_ to the index.
> >
> > So go and add your directories via that marker, and _be done with it_.
>
> But this alters the content of the directory away from what I want it to be,
> namely empty. You aren't addressing the concept of tracking an empty
> directory, you're just saying you won't do it.
OMG last time I checked, my _empty_ directory contained "." and "..".
What do I do now?
Really,
Dscho
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Brett Schwarz @ 2007-07-19 17:33 UTC (permalink / raw)
To: Christian Stimming, git; +Cc: Paul Mackerras, Shawn O. Pearce
This is a good idea. However, I assume the _ proc is just sugar. It might be better to follow a more "standard" way for this, and just import the msgcat namespace, and then you can just use [mc]. For example:
package require msgcat
namespace import ::msgcat::*
.
.
.
.mbar add cascade -label [mc Repository] -menu .mbar.repository
Also, if the message catalogs are in a common location, then it might be worth looking into having gitk utilize these msg catalogs as well.
Thanks,
--brett
p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able to convert -text and -label switches to use msgcat...it might be worth looking into, instead of manually editing git-gui/gitk
----- Original Message ----
From: Christian Stimming <stimming@tuhh.de>
To: git@vger.kernel.org
Sent: Thursday, July 19, 2007 3:56:57 AM
Subject: [PATCH] Internationalization of git-gui
This is an initial patch of how internationalization (i18n) in git
could be done, starting with the git-gui application (because I need
that one in German to convince my workplace of switching to git).
Does this implementation look okay? If yes, I'd happily i18n'ize the
rest of git-gui and provide a full German translation as well.
Thanks,
Christian Stimming
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
^ permalink raw reply
* Re: [PATCH] Proposal for git-svn
From: Benoit SIGOURE @ 2007-07-19 17:41 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070719042255.GA17433@muzzle>
[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]
On Jul 19, 2007, at 6:22 AM, Eric Wong wrote:
> Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>> Hello,
>>
>> I'm importing many SVN repositories in Git and I ran across a
>> problem:
>> ufloat.h has mode 120000but is not a link
>>
>> I've read the code and checked-out the revision where the problem
>> occured and it turns out that some stupid user commited a broken
>> symlink and I think that's where the problem came from. I'm
>> proposing the following trivial change to let git-svn clone continue
>> its work:
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index 01c3904..a82baf4 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -2555,8 +2555,8 @@ sub close_file {
>> sysseek($fh, 0, 0) or croak $!;
>> if ($fb->{mode_b} == 120000) {
>> sysread($fh, my $buf, 5) == 5 or croak $!;
>> - $buf eq 'link ' or die "$path has mode
>> 120000",
>> - "but is not a link\n";
>> + $buf eq 'link ' or warn "$path has mode
>> 120000",
>> + " but is not a link
>> \n";
>> }
>> defined(my $pid = open my $out,'-|') or die "Can't
>> fork: $!\n";
>> if (!$pid) {
>>
>> (I also added a whitespace because "120000but" does not look good :D)
>> I checked out the problematic revision in git and I see the broken
>> symlink just like in SVN so I assume this change is correct.
>
> Very strange. Since $buf didn't have the string "link " in it, did it
> have a path name in it? If so, the sysread() would've advanced the
> $fh
> offset by 5 bytes; causing an even more broken symlink to be added
> by git.
>
> Would the following be more correct?
>
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -2552,9 +2552,15 @@ sub close_file {
> }
> sysseek($fh, 0, 0) or croak $!;
> if ($fb->{mode_b} == 120000) {
> - sysread($fh, my $buf, 5) == 5 or croak $!;
> - $buf eq 'link ' or die "$path has mode 120000",
> - "but is not a link\n";
> + eval {
> + sysread($fh, my $buf, 5) == 5 or croak $!;
> + $buf eq 'link ' or die "$path has mode 120000",
> + " but is not a link";
> + };
> + if ($@) {
> + warn "$@\n";
> + sysseek($fh, 0, 0) or croak $!;
> + }
> }
> defined(my $pid = open my $out,'-|') or die "Can't fork: $!\n";
> if (!$pid) {
>
It does look more correct though I don't get the same sha1 sums with
your patch.
Actually here is what happens:
At revision N, b0rken symlinks are added in the SVN repos. Up to
this revision, I get the same sha1 sums.
At N+1, the symlinks are removed from the SVN, and sha1 sums start to
differ, for some reason.
I expected them to be either identical all the way through or to
differ at N, but not at N+1.
In both cases the repository seem usable and I couldn't notice any
other difference than the sha1 sums.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [REVISED PATCH 2/6] Introduce commit notes
From: Linus Torvalds @ 2007-07-19 17:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Alberto Bertogli, git, Johan Herland
In-Reply-To: <7vodi83fg7.fsf@assigned-by-dhcp.cox.net>
On Thu, 19 Jul 2007, Junio C Hamano wrote:
> > ...
> > But the real problem of this approach of course is that this is
> > not reliable and can get a false match. You can find your
> > beginning NUL in the SHA-1 part of one entry, and terminating
> > NUL later in the SHA-1 part of next entry, and you will never
> > notice.
[ I didn't react to this in your first email, because I thought you were
talking about your "use the rules for the ASCII part", and thought you
talked about how *that* was not reliable and can get a false match). But
it seems that you were actually talking about the NUL character test ]
Nope, wrong.
Why? Because there must always be a NUL *between* different SHA1's.
There's *always* a NUL character that precedes a SHA1. So when you have
two NUL characters (with no other NUL's between them), you *know* that
they cannot be from two different SHA1's. If the first one was from an
earlier SHA1, then the second one is *guaranteed* to be the one that
happens *before* the next SHA1.
See?
You really have two, and only two cases:
- NUL's that are within 20 bytes of each other: you don't know anything
about them. It might be that they are both within the *same* SHA1, or
the first one was the one that separated the ASCII part from the SHA1,
or the first one was a NUL in the previous SHA1 and the second one was
the NUL after the ASCII part.
So two NUL's in the same 21-byte region are not reliable (ie less than
20 bytes in *between* them). They tell you nothing, and you must just
ignore them.
- NUL's that are more than 20 bytes apart: the second NUL is *guaranteed*
to be the start of the next SHA1.
They cannot be part of the same "NUL + sha1", and thus the first NUL
*must* be from a previous SHA1 (or the NUL that preceded it). And that
means that the second NUL *must* be the NUL that precedes the next
SHA1.
So there is *no* ambiguity what-so-ever. It's not about guessing, and it's
not about "luck". If you don't find two NUL bytes separated by more than
20 bytes, you start the linear search.
> In other words, if you are really really *really* unlucky, not
> only you might end up being fooled by random byte sequences in
> SHA-1 part of the tree object, you would not even notice that
> you have to fall back on the linear search.
Wrong. Either you find a guanteed rigth place, or you ran out of the
buffer and know you have to fall back on the linear search.
No fooled.
> I've long time ago concluded that if we care about reliability
> (and we do very much), a bisectable tree without breaking
> backward compatibility is impossible.
No. You concluded incorrectly. I'm pretty damn sure the current tree
format is perfectly fine. It's dense, it's nice and linear, and it's
easily bisectable.
Linus
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-19 17:47 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.070719 1829530.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 19 Jul 2007, Brian Gernhardt wrote:
>
>> On Jul 19, 2007, at 12:17 PM, Johannes Schindelin wrote:
>>
>> > Alas, we already have such a marker. It is called ".gitignore", and has
>> > been ignored by _you_. There is _nothing_ wrong, from a technical
>> > standpoint, to call this marker ".gitignore", and it is _also_ not wrong
>> > to put this marker into the file system _in addition_ to the index.
>> >
>> > So go and add your directories via that marker, and _be done with it_.
>>
>> But this alters the content of the directory away from what I want it to be,
>> namely empty. You aren't addressing the concept of tracking an empty
>> directory, you're just saying you won't do it.
>
> OMG last time I checked, my _empty_ directory contained "." and "..".
> What do I do now?
If you have a suitable Solaris system, you could try
sudo unlink .
sudo unlink ..
and have a chance that this will work until the next file system
check.
I don't think that adding tracking of ".." would be easy to implement
in git, but I seem to remember that somebody recently proposed a plan
of at least tracking "." which would seem better than nothing and
possibly more useful than "sudo unlink .".
All the best,
--
David Kastrup
^ permalink raw reply
* Re: [REVISED PATCH 2/6] Introduce commit notes
From: Linus Torvalds @ 2007-07-19 17:50 UTC (permalink / raw)
To: Olivier Galibert
Cc: Johannes Schindelin, Junio C Hamano, Alberto Bertogli, git,
Johan Herland
In-Reply-To: <20070719103436.GA9143@dspnet.fr.eu.org>
On Thu, 19 Jul 2007, Olivier Galibert wrote:
> On Wed, Jul 18, 2007 at 08:28:27PM -0700, Linus Torvalds wrote:
> > And yes, the "search for zero bytes" is not *guaranteed* to find any
> > beginning at all, if you have lots of short names, *and* lots of zero
> > bytes in the SHA1's. But while short names may be common, zero bytes in
> > SHA1's are not so much (since you should expect to see a very even
> > distribution of bytes, and as such most SHA1's by far should have no zero
> > bytes at all!)
>
> The probability of a sha1 to have a zero is approximatively 0.075.
> That's 1 in 13, more or less.
Sure. And since we handle it fine even when it does happen, we don't care.
In fact, since we only need 20 non-zero bytes in between zeroes to know
that it's ok, and since the ASCII part is already 7 bytes of "mode +
space" plus <n> bytes of actual name (let's say that names average to be
about 8 characters - which is low: in the kernel it seems to be about 10.5
characters), we can say that the ASCII part of a tree tends to be about 15
characters.
So in order to be unlucky, it's not enough for the previous SHA1 to have a
NUL character in it, it actually has to be in the last five bytes of the
SHA1 - so now we're talking something like a 1:50 chance.
And with longer names, it matters even less (to the point where it
matters not at all if all filenames are >= 14 characters in length).
So we can be unlucky, but it's fairly rare, and when it happens, at worst
we'll just need to scan to the next entry (and if we're *really* unlucky
and it keeps happening until we scan until the end, we'll have to do the
linear search).
The point being that you always get the right answer, and the likelihood
that you have to do something slow to get that rigth answer is really
really low.
Linus
^ permalink raw reply
* [PATCH] Add git-sh-setup::set_editor()
From: Adam Roben @ 2007-07-19 18:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Shindelin, Adam Roben
In-Reply-To: <Pine.LNX.4.64.0707191053230.14781@racer.site>
This function can be used to set the GIT_EDITOR variable to the user's
preferred editor.
Signed-off-by: Adam Roben <aroben@apple.com>
---
On Jul 19, 2007, at 2:54 AM, Johannes Schindelin wrote:
> Now with so many commands in the lot, how about putting the code into
> git-sh-setup, into a function "get_editor()"?
Here you go. I didn't add anything similar for git-send-email.perl since that
is the only case we have in perl of invoking the editor right now, and I wasn't
sure of a good place to add such a function.
git-am.sh | 3 ++-
git-commit.sh | 6 +++---
git-rebase--interactive.sh | 3 ++-
git-sh-setup.sh | 5 +++++
git-tag.sh | 3 ++-
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 3a651ae..a5de0a1 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -7,6 +7,7 @@ USAGE='[--signoff] [--dotest=<dir>] [--utf8 | --no-utf8] [--binary] [--3way]
or, when resuming [--skip | --resolved]'
. git-sh-setup
set_reflog_action am
+set_editor
require_work_tree
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -364,7 +365,7 @@ do
[yY]*) action=yes ;;
[aA]*) action=yes interactive= ;;
[nN]*) action=skip ;;
- [eE]*) "$(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}})" "$dotest/final-commit"
+ [eE]*) "$GIT_EDITOR" "$dotest/final-commit"
action=again ;;
[vV]*) action=again
LESS=-S ${PAGER:-less} "$dotest/patch" ;;
diff --git a/git-commit.sh b/git-commit.sh
index 72e4cf0..9adb03c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -6,6 +6,7 @@
USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
+set_editor
require_work_tree
git rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
@@ -544,8 +545,7 @@ fi
case "$no_edit" in
'')
- commit_editor=$(git config core.editor || echo ${VISUAL:-$EDITOR})
- case "$commit_editor,$TERM" in
+ case "$GIT_EDITOR,$TERM" in
,dumb)
echo >&2 "Terminal is dumb but core.editor, VISUAL, and EDITOR"
echo >&2 "are undefined. Please supply the commit log message"
@@ -556,7 +556,7 @@ case "$no_edit" in
esac
git-var GIT_AUTHOR_IDENT > /dev/null || die
git-var GIT_COMMITTER_IDENT > /dev/null || die
- ${commit_editor:-vi} "$GIT_DIR/COMMIT_EDITMSG"
+ $GIT_EDITOR "$GIT_DIR/COMMIT_EDITMSG"
;;
esac
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 2e15abb..32d1f53 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -15,6 +15,7 @@ USAGE='(--continue | --abort | --skip | [--preserve-merges] [--verbose]
. git-sh-setup
require_work_tree
+set_editor
DOTEST="$GIT_DIR/.dotest-merge"
TODO="$DOTEST"/todo
@@ -414,7 +415,7 @@ EOF
die_abort "Nothing to do"
cp "$TODO" "$TODO".backup
- $(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}}) "$TODO" ||
+ $GIT_EDITOR "$TODO" ||
die "Could not execute editor"
test -z "$(grep -ve '^$' -e '^#' < $TODO)" &&
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 4ed07e9..f43ab33 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -28,6 +28,11 @@ set_reflog_action() {
fi
}
+set_editor() {
+ GIT_EDITOR=$(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}})
+ export GIT_EDITOR
+}
+
is_bare_repository () {
git rev-parse --is-bare-repository
}
diff --git a/git-tag.sh b/git-tag.sh
index 9aa30b4..0a6f2e7 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -4,6 +4,7 @@
USAGE='[-n [<num>]] -l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+set_editor
message_given=
annotate=
@@ -177,7 +178,7 @@ if [ "$annotate" ]; then
( echo "#"
echo "# Write a tag message"
echo "#" ) > "$GIT_DIR"/TAG_EDITMSG
- $(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}}) "$GIT_DIR"/TAG_EDITMSG || exit
+ $GIT_EDITOR "$GIT_DIR"/TAG_EDITMSG || exit
else
printf '%s\n' "$message" >"$GIT_DIR"/TAG_EDITMSG
fi
--
1.5.3.rc2.20.g8e32-dirty
^ permalink raw reply related
* Re: [PATCH] Document how to tell git to not launch a pager
From: Linus Torvalds @ 2007-07-19 18:29 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ir8gbo0a.fsf@lola.quinscape.zz>
On Thu, 19 Jul 2007, David Kastrup wrote:
>
> Is that the reason why users of screen get punished by default?
No, the reason users of screen get punished is that we just think they are
fun to torment.
Just use GIT_PAGER=cat, and be happy. In fact, I'd suggest not using
screen at all (what a piece of horrid crap), but some people have trouble
letting go.
Linus
^ permalink raw reply
* Re: [PATCH guilt] Handles slashes in branch names
From: Josef Sipek @ 2007-07-19 18:44 UTC (permalink / raw)
To: Eric Lesh; +Cc: Joseph Jeff Sipek, Git mailing list
In-Reply-To: <87y7hctf6o.fsf@hubert.paunchy.net>
On Thu, Jul 19, 2007 at 11:35:11AM -0700, Eric Lesh wrote:
> When a branch name has a slash and autotagging is enabled, guilt barfs
> when updating the stack tags. Escape the branch name in the tags to
> allow this to work.
...
> - git-rev-parse HEAD > "$GIT_DIR/refs/tags/${branch}_top"
> - head -1 < $applied | cut -d: -f1 > "$GIT_DIR/refs/tags/${branch}_bottom"
> - git-rev-parse $(head -1 < $applied | cut -d: -f1)^ > "$GIT_DIR/refs/tags/${branch}_base"
> + git-rev-parse HEAD > "$GIT_DIR/refs/tags/${newbranch}_top"
> + head -1 < $applied | cut -d: -f1 > "$GIT_DIR/refs/tags/${newbranch}_bottom"
> + git-rev-parse $(head -1 < $applied | cut -d: -f1)^ > "$GIT_DIR/refs/tags/${newbranch}_base"
Why mangle the branch name when we can do:
mkdir -p `basename $GIT_DIR/refs/tags/${branch}_top`
git-rev-parse ....
Sure, it is ugly, but it preserves the branch name. Am I missing something?
Josef 'Jeff' Sipek.
--
A computer without Microsoft is like chocolate cake without mustard.
^ permalink raw reply
* Re: [PATCH] Add git-sh-setup::set_editor()
From: Johannes Schindelin @ 2007-07-19 18:46 UTC (permalink / raw)
To: Adam Roben; +Cc: git, Junio C Hamano
In-Reply-To: <11848694482569-git-send-email-aroben@apple.com>
Hi,
On Thu, 19 Jul 2007, Adam Roben wrote:
> This function can be used to set the GIT_EDITOR variable to the user's
> preferred editor.
Much nicer, thank you.
However,
> - commit_editor=$(git config core.editor || echo ${VISUAL:-$EDITOR})
> - case "$commit_editor,$TERM" in
> + case "$GIT_EDITOR,$TERM" in
> ,dumb)
This can no longer happen, since ...
> +set_editor() {
> + GIT_EDITOR=$(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}})
> + export GIT_EDITOR
> +}
... "vi" is the last resort, not "", right?
So I guess you just want to drag that test and warning into git-sh-setup
(where I think it has a better home anyway).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document how to tell git to not launch a pager
From: Nikolai Weibull @ 2007-07-19 18:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, git
In-Reply-To: <alpine.LFD.0.999.0707191128040.27353@woody.linux-foundation.org>
On 7/19/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> In fact, I'd suggest not using screen at all (what a piece of horrid crap),
> but some people have trouble letting go.
I don't want to start a holy war here, but what's wrong with screen?
And what should we be embracing instead?
nikolai
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Karl Fogel @ 2007-07-20 3:51 UTC (permalink / raw)
To: Markus Schiltknecht
Cc: Martin Langhoff, esr, Michael Haggerty, Julian Phillips, git, dev
In-Reply-To: <469F52BF.8050300@bluegap.ch>
Markus Schiltknecht <markus@bluegap.ch> writes:
> Sure, we certainly need a meta format of some sort (not a full blown
> VCS, agreed, but somehow we need to represent commits, tags and
> branches). And IMO, the subversion based format is not a good one,
> because it treats branches and tags very different from most other
> systems (and from what it should be from a users perspective: an
> atomic operation).
Huh? I don't understand what you're saying about atomicity here.
^ permalink raw reply
* Re: [PATCH] Document how to tell git to not launch a pager
From: Linus Torvalds @ 2007-07-19 19:14 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: David Kastrup, git
In-Reply-To: <dbfc82860707191151w3e9571fcu60d113cba6c2f6dd@mail.gmail.com>
On Thu, 19 Jul 2007, Nikolai Weibull wrote:
>
> I don't want to start a holy war here, but what's wrong with screen?
I actually like screen as a way to keep connections around. But the whole
multiplexing is wrong, wrong, wrong. It violates the "do one thing, and do
it well" thing. It makes screen do two things, and do them really badly as
a result.
So the "session" part makes sense. It's a worthy reason to use screen.
And the "window manager" part is kind of a funny hack, but let's face it,
you can do better by using separate windows.
And the multiplexor could have been done (and historically _has_ been
done) better, by not limiting it to terminal sessions.
But the *combination* of all three is just evil and stupid. And the choice
of ctrl-A as the default command sequence (can you even override it? Don't
know, don't care) is just insanity.
It's somewhat sad that screen has made some better projects not as
successful.
- multiplexing. I used better programs back in the 90's to multiplex
arbitrary sessions over a single terminal pipe (not just terminal
windows). I forget the name, because these days, everybody has real
networking, and you'd generally use ssh tunnelling for it and
ssh-agent. But screen was never very good at it.
- "window manager". Quite frankly, I've never needed it. I doubt many
people do. graphical environments and virtual terminals are better. And
if you really want a virtual terminal on a single terminal, thinking
that it should be mixed up with all the other things screen does is
just nasty.
- for session management and moving things around: I think this is the
main reason people still use screen. It's a worthy use, but I think
it's sad how it's mixed up with the bad features of screen. There was a
"detach" program (or something similar) at some point that did just
that part of screen. But screen is just widely enough spread that
people are used to it, and I don't think it went anywhere.
IOW, I think screen sucks because it tries to do totally independent
things, and then mixes them up in nasty ways, and for historical reasons
uses a bad break character too.
Oh, well.
Linus
^ permalink raw reply
* [PATCH guilt] Handles slashes in branch names
From: Eric Lesh @ 2007-07-19 19:17 UTC (permalink / raw)
To: Josef Sipek; +Cc: Git mailing list
In-Reply-To: <20070719184418.GA22463@filer.fsl.cs.sunysb.edu>
When a branch name has a slash and autotagging is enabled, guilt barfs
when updating the stack tags. Make these branch names work.
Also allow guilt to create the patches directory for these branches.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> Why mangle the branch name when we can do:
>
> mkdir -p `basename $GIT_DIR/refs/tags/${branch}_top`
> git-rev-parse ....
>
> Sure, it is ugly, but it preserves the branch name. Am I missing something?
>
Yours is a lot less ugly than mine was.
guilt | 1 +
guilt-init | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/guilt b/guilt
index 214def4..c913bd6 100755
--- a/guilt
+++ b/guilt
@@ -338,6 +338,7 @@ update_stack_tags()
# there are patches applied, therefore we must get the top,
# bottom and base hashes, and update the tags
+ mkdir -p `dirname $GIT_DIR/refs/tags/${branch}_top`
git-rev-parse HEAD > "$GIT_DIR/refs/tags/${branch}_top"
head -1 < $applied | cut -d: -f1 > "$GIT_DIR/refs/tags/${branch}_bottom"
git-rev-parse $(head -1 < $applied | cut -d: -f1)^ > "$GIT_DIR/refs/tags/${branch}_base"
diff --git a/guilt-init b/guilt-init
index ffe2434..9136f89 100755
--- a/guilt-init
+++ b/guilt-init
@@ -24,7 +24,7 @@ if [ -d "$GUILT_DIR/$branch" ]; then
fi
[ ! -d "$GUILT_DIR" ] && mkdir $GUILT_DIR
-mkdir $GUILT_DIR/$branch
+mkdir -p $GUILT_DIR/$branch
touch $GUILT_DIR/$branch/series
touch $GUILT_DIR/$branch/status
--
1.5.2
^ permalink raw reply related
* Re: CVS -> SVN -> Git
From: Simon 'corecode' Schubert @ 2007-07-19 19:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: esr, Michael Haggerty, Julian Phillips, git, dev
In-Reply-To: <46a038f90707151805j454b57fbvb4d7ed526e1e64ce@mail.gmail.com>
[sorry for jumping in so late, didn't read git@vger for a while]
Martin Langhoff wrote:
> On 7/15/07, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Not quite. I'm suggesting it's an appropriate lingua franca for
>> centralized
>> VCSes with branching, e.g. everything pre-Arch.
I do not think Eric is right here. You will allways lose information when converting CVS to svn, and if it is just the uncertainty, the non-atomicity. This is also information (hidden one, though).
> That's a huge goal that gets in the way of waht we want to do here: we
> are trying to save time, not embark on some huge mission.
>
> cvs2svn has all the "wtf-did-cvs-mean-by-that" algorithms that are
> very hard to write and maintain, and it seems to be the best one at
> that. Of course, it also writes SVN repos -- but I'm sure that's the
> easiest part.
True. However, cvs2svn has many assumptions (or at least has had when I last checked) which are targeted to svn, and unsuitable for a generic system (tags + branches).
> We don't need no meta VCS for any of this.
Yes. I've already done what people want, it is not called cvs2xxx, but fromcvs [1]. I don't think it is necessary to define an output format. Of course, that's possible, but limiting yourself to a file format means you're losing flexibility, which is needed for efficient, correct and fast repository conversion.
cheers
simon
[1] http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: [PATCH] Add git-sh-setup::set_editor()
From: David Kastrup @ 2007-07-19 19:26 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0707191944560.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 19 Jul 2007, Adam Roben wrote:
>
>> This function can be used to set the GIT_EDITOR variable to the user's
>> preferred editor.
>
> Much nicer, thank you.
>
> However,
>
>> - commit_editor=$(git config core.editor || echo ${VISUAL:-$EDITOR})
>> - case "$commit_editor,$TERM" in
>> + case "$GIT_EDITOR,$TERM" in
>> ,dumb)
>
> This can no longer happen, since ...
>
>> +set_editor() {
>> + GIT_EDITOR=$(git config core.editor || echo ${VISUAL:-${EDITOR:-vi}})
>> + export GIT_EDITOR
>> +}
Strictly speaking it can happen when git has an empty string for
core.editor configured. Not that the behavior chosen in this case
would make any sense, but just for the record...
--
David Kastrup
^ permalink raw reply
* Re: [PATCH (REVISED)] Add core.editor configuration variable
From: Nicolas Pitre @ 2007-07-19 19:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin, Adam Roben, Junio C Hamano
In-Reply-To: <200707191523.42086.andyparkins@gmail.com>
On Thu, 19 Jul 2007, Andy Parkins wrote:
> On Thursday 2007 July 19, Johannes Schindelin wrote:
> > And how would having "core.pager" but "porcelain.editor" be easier to
> > remember? Nah, not really.
>
> If there is no difference, then do you object so strongly?
If anything I think it is core.pager which is a misnommer. A pager is
certainly more porcelainish. by nature.
Given that core.pager already exists, I think it would be yet another
mistake to put editor in a different section separate from pager.
IMHO both of them should have been user.pager and user.editor.
Nicolas
^ permalink raw reply
* [PATCH guilt] Handles slashes in branch names
From: Eric Lesh @ 2007-07-19 18:35 UTC (permalink / raw)
To: Joseph Jeff Sipek; +Cc: Git mailing list
When a branch name has a slash and autotagging is enabled, guilt barfs
when updating the stack tags. Escape the branch name in the tags to
allow this to work.
Also allow guilt to create the patches directory for these branches.
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
guilt | 15 +++++++++------
guilt-init | 2 +-
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/guilt b/guilt
index 214def4..9e4789a 100755
--- a/guilt
+++ b/guilt
@@ -334,20 +334,23 @@ update_stack_tags()
return 0
fi
+ # handle branches with slashes
+ newbranch=`echo $branch | sed -e 's,\/,-,'`
+
if [ `wc -l < $applied` -gt 0 ]; then
# there are patches applied, therefore we must get the top,
# bottom and base hashes, and update the tags
- git-rev-parse HEAD > "$GIT_DIR/refs/tags/${branch}_top"
- head -1 < $applied | cut -d: -f1 > "$GIT_DIR/refs/tags/${branch}_bottom"
- git-rev-parse $(head -1 < $applied | cut -d: -f1)^ > "$GIT_DIR/refs/tags/${branch}_base"
+ git-rev-parse HEAD > "$GIT_DIR/refs/tags/${newbranch}_top"
+ head -1 < $applied | cut -d: -f1 > "$GIT_DIR/refs/tags/${newbranch}_bottom"
+ git-rev-parse $(head -1 < $applied | cut -d: -f1)^ > "$GIT_DIR/refs/tags/${newbranch}_base"
else
# there are no patches applied, therefore we must remove the
# tags to old top, bottom, and base
- rm -f "$GIT_DIR/refs/tags/${branch}_top"
- rm -f "$GIT_DIR/refs/tags/${branch}_bottom"
- rm -f "$GIT_DIR/refs/tags/${branch}_base"
+ rm -f "$GIT_DIR/refs/tags/${newbranch}_top"
+ rm -f "$GIT_DIR/refs/tags/${newbranch}_bottom"
+ rm -f "$GIT_DIR/refs/tags/${newbranch}_base"
fi
}
diff --git a/guilt-init b/guilt-init
index ffe2434..9136f89 100755
--- a/guilt-init
+++ b/guilt-init
@@ -24,7 +24,7 @@ if [ -d "$GUILT_DIR/$branch" ]; then
fi
[ ! -d "$GUILT_DIR" ] && mkdir $GUILT_DIR
-mkdir $GUILT_DIR/$branch
+mkdir -p $GUILT_DIR/$branch
touch $GUILT_DIR/$branch/series
touch $GUILT_DIR/$branch/status
--
1.5.2
^ permalink raw reply related
* Re: [PATCH (REVISED)] Add core.editor configuration variable
From: Nicolas Pitre @ 2007-07-19 19:32 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Andy Parkins, git, Adam Roben, Junio C Hamano
In-Reply-To: <95E642DA-F848-4398-9D9D-52B03A235887@silverinsanity.com>
On Thu, 19 Jul 2007, Brian Gernhardt wrote:
> For many people commit is more "core" to their git usage than write-tree and
> commit-tree. At this point, it's less an extra layer porcelain and more the
> standard interface. It's a result of the wonderful attempts to make git more
> user friendly.
>
> As far as [core] being only for plumbing, I disagree with that premise as
> well. Any option that is used across many of the git commands is a core
> (meaning central) option.
That pov certainly makes sense to me.
Nicolas
^ permalink raw reply
* Re: [PATCH] Document how to tell git to not launch a pager
From: Matthieu Moy @ 2007-07-19 19:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nikolai Weibull, David Kastrup, git
In-Reply-To: <alpine.LFD.0.999.0707191155100.27353@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But the *combination* of all three is just evil and stupid. And the choice
> of ctrl-A as the default command sequence (can you even override it? Don't
> know, don't care) is just insanity.
Yes, you can. For example, I have
escape ^oo
in my ~/.screenrc, and the control command is C-o, and I can do a real
C-o by doing C-o o.
That said, I rarely use screen, just to launch a long command at work
and get the result from home later.
--
Matthieu
^ permalink raw reply
* Re: [PATCH guilt] Handles slashes in branch names
From: Josef Sipek @ 2007-07-19 19:35 UTC (permalink / raw)
To: Eric Lesh; +Cc: Git mailing list
In-Reply-To: <87r6n4td8y.fsf@hubert.paunchy.net>
On Thu, Jul 19, 2007 at 12:17:01PM -0700, Eric Lesh wrote:
> When a branch name has a slash and autotagging is enabled, guilt barfs
> when updating the stack tags. Make these branch names work.
>
> Also allow guilt to create the patches directory for these branches.
>
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
Applied. I just added quotes around the mkdir -p in guilt in case someone
likes to have whitespace in their branch names.
Thanks,
Josef 'Jeff' Sipek.
--
Real Programmers consider "what you see is what you get" to be just as bad a
concept in Text Editors as it is in women. No, the Real Programmer wants a
"you asked for it, you got it" text editor -- complicated, cryptic,
powerful, unforgiving, dangerous.
^ permalink raw reply
* Re: CVS -> SVN -> Git
From: Simon 'corecode' Schubert @ 2007-07-19 19:15 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707131541140.11423@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> Has anyone managed to succssfully import a Subversion repository that
> was initially imported from CVS using cvs2svn using fast-import?
>
> It looks like cvs2svn has created a rather big mess. It has created
> single commits that change files in more than one branch and/or tag. It
> also creates tags using more than one commit. Now I come to try and
> import the Subversion history into git and I'm having trouble creating a
> sensible stream to feed into fast-import.
Did you try first converting the old CVS repo to git and then adding the svn changes? That might give you much better results.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ 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