* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 11:43 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <a1bbc6950708030258h16a6514kf5c637af13874fb7@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> Johannes, please add me as a user to this Google project and I'll
> upload the files.
Done.
> The changes that I've made:
> * removed .git in /git directory to save space
> * installed gdb
> * applied my Vista fix
> * made self-extracting .rar archive
>
> Tatal size is 19+4 MB.
With Vista fix you mean both adding the USE_MINGW_ACCESS define and
copying cc1.exe to /bin?
And have you tried a 7-zip LZMA self extracting file? I guess it is
smaller: for the moment I have two files there, totalling 30.2M. 15M of
which is the virtually uncompressible pack file in .git/. Which leaves...
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 11:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0708030436q50322fbbne3a793d693e9f0e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
>>> Even if it installs ok under Wine, git may not work properly
>>> because a bug in dup2() not duplicating to 0-2 and some others
>>> that I think only affect tests. So get XP if you can or prepare
>>> to fix Wine along the way.
>> Yeah, I wasn't going to use it under Wine actually. Just wanted
>> to see if I could get it building there, to ease automated
>> packaging later. However, I've given up on it, due to a perl
>> issue, which might be caused by the issue you describe.
>
> You could cross-compile it. You'll need a cross toolchain, zlib
> stuff and a good config.mak (I can send you one if you have trouble
> with it).
I would definitely be interested in your config.mak file!
Thanks!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 11:37 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marius Storm-Olsen, git
In-Reply-To: <fcaeb9bf0708030417y39f84db2lb0b202af57d8fccb@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Nguyen Thai Ngoc Duy wrote:
> On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > > I finally broke down, waiting for the sourceforge project to get
> > > granted. In the meantime, I registered a project at
> > >
> > > http://code.google.com/p/msysgit/
> > >
> > > (WARNING: temporary only!)
> > >
> > > Would you believe that Google code has a restriction to 20MB per
> > > file, and 100MB in total, and you cannot remove files? The same
> > > Google that gives you 1TB mail space and counting? Yes, it is
> > > ludicrous.
> > >
> > > Anyway, you can get a complete Development environment in 3 files
> > > (because one would be too large), and... oh well, just read what is
> > > written on the website if you're really interested.
> >
> > Great effort Johannes!
> > The package work perfectly on XP.
> > I'm trying to get it to work under Wine, but it (Wine) is not playing
> > nice with me at the moment. (The whole system barfs of "Access Denied"
> > and other things. Grrr)
>
> Even if it installs ok under Wine, git may not work properly because a
> bug in dup2() not duplicating to 0-2 and some others that I think only
> affect tests. So get XP if you can or prepare to fix Wine along the
> way.
I do not have XP. So I very much would appreciate any work done on Wine.
As it happens, I have a hanging rxvt now (still investigating what causes
it; ever since wine-0.9.30-466-gb0e9d7e it stopped working for me).
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Nguyen Thai Ngoc Duy @ 2007-08-03 11:36 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, git
In-Reply-To: <46B31181.5020007@trolltech.com>
On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> >> Great effort Johannes! The package work perfectly on XP. I'm
> >> trying to get it to work under Wine, but it (Wine) is not playing
> >> nice with me at the moment. (The whole system barfs of "Access
> >> Denied" and other things. Grrr)
> >
> > Even if it installs ok under Wine, git may not work properly
> > because a bug in dup2() not duplicating to 0-2 and some others that
> > I think only affect tests. So get XP if you can or prepare to fix
> > Wine along the way.
>
> Yeah, I wasn't going to use it under Wine actually. Just wanted to see
> if I could get it building there, to ease automated packaging later.
> However, I've given up on it, due to a perl issue, which might be
> caused by the issue you describe.
You could cross-compile it. You'll need a cross toolchain, zlib stuff
and a good config.mak (I can send you one if you have trouble with
it).
--
Duy
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 11:29 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0708030417y39f84db2lb0b202af57d8fccb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
>> Great effort Johannes! The package work perfectly on XP. I'm
>> trying to get it to work under Wine, but it (Wine) is not playing
>> nice with me at the moment. (The whole system barfs of "Access
>> Denied" and other things. Grrr)
>
> Even if it installs ok under Wine, git may not work properly
> because a bug in dup2() not duplicating to 0-2 and some others that
> I think only affect tests. So get XP if you can or prepare to fix
> Wine along the way.
Yeah, I wasn't going to use it under Wine actually. Just wanted to see
if I could get it building there, to ease automated packaging later.
However, I've given up on it, due to a perl issue, which might be
caused by the issue you describe.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Nguyen Thai Ngoc Duy @ 2007-08-03 11:17 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, git
In-Reply-To: <46B2D547.6050406@trolltech.com>
On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > I finally broke down, waiting for the sourceforge project to get
> > granted. In the meantime, I registered a project at
> >
> > http://code.google.com/p/msysgit/
> >
> > (WARNING: temporary only!)
> >
> > Would you believe that Google code has a restriction to 20MB per
> > file, and 100MB in total, and you cannot remove files? The same
> > Google that gives you 1TB mail space and counting? Yes, it is
> > ludicrous.
> >
> > Anyway, you can get a complete Development environment in 3 files
> > (because one would be too large), and... oh well, just read what is
> > written on the website if you're really interested.
>
> Great effort Johannes!
> The package work perfectly on XP.
> I'm trying to get it to work under Wine, but it (Wine) is not playing
> nice with me at the moment. (The whole system barfs of "Access Denied"
> and other things. Grrr)
Even if it installs ok under Wine, git may not work properly because a
bug in dup2() not duplicating to 0-2 and some others that I think only
affect tests. So get XP if you can or prepare to fix Wine along the
way.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Johannes Schindelin @ 2007-08-03 10:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Jean-Fran?ois Veillette, Matthieu Moy, git
In-Reply-To: <7v3az1qgdg.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 2 Aug 2007, Junio C Hamano wrote:
> Steven Grimm <koreth@midwinter.com> writes:
>
> > Okay, enough arguing about whether the empty diff lines are
> > useful or not -- here's a patch to get rid of them.
>
> I do not think this addresses anything but -p (i.e. textual
> diff) output. If we _were_ to really do this, I think the patch
> I sent earlier today, with possible improvements I suggested,
> would be a better direction to go.
But I'd really think that what should be done (if anything has to be done
at all) is to introduce a config variable which triggers the same logic in
git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Dmitry Kakurin @ 2007-08-03 9:58 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, git
In-Reply-To: <46B2D4D9.4020103@trolltech.com>
Fair enough.
Johannes, please add me as a user to this Google project and I'll
upload the files.
The changes that I've made:
* removed .git in /git directory to save space
* installed gdb
* applied my Vista fix
* made self-extracting .rar archive
Tatal size is 19+4 MB.
- Dmitry
On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> Dmitry Kakurin said the following on 03.08.2007 08:56:
> > Great job! Because finding and installing MSys, MinGW and dependencies was not trivial at all.
> > I have 2 suggestions for this package:
> > 1. Remove git repository from it. It will make a download much smaller (~20MB smaller) and include the minimum git functionality to
> > pull mingw git from the server (may be even automatically on first startup).
> > 2. Add gdb. Not much could be done without it.
> >
> > With this package (+gdb) it took me about an hour to figure out why git is broken on Vista (this includes learning how to use gdb
> > :-). So you should expect much higher level of participation on the Windows side.
> >
> > P.S. If package becomes sufficiently small for a single file, try to remove 7zip dependency (use WinZip instead). The easier the
> > installation the better.
>
> Heh, why don't you try to do this yourself? Johannes as kind enough to
> go out of his way to actually do all that he has already.
> Seems like you feel strongly for it, so it shouldn't be too much
> effort for you. If you provide Johannes with a link to a package of
> which you speak, I'm sure he'll happily upload it to the google
> project page.
>
> --
> .marius
>
>
>
^ permalink raw reply
* [PATCH] git-gui: Added support for OS X right click
From: Väinö Järvelä @ 2007-08-03 9:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
OS X sends Button-2 on a "real" right click, such as with a three
button mouse, or by using the two-finger trackpad click.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
---
git-gui.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 2c7eb3c..29a790e 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1348,6 +1348,9 @@ unset i
proc bind_button3 {w cmd} {
bind $w <Any-Button-3> $cmd
if {[is_MacOSX]} {
+ # Mac OS X sends Button-2 on right click through three-button mouse,
+ # or through trackpad right-clicking (two-finger touch + click).
+ bind $w <Any-Button-2> $cmd
bind $w <Control-Button-1> $cmd
}
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] git-commit.sh: Shell script cleanup
From: Junio C Hamano @ 2007-08-03 9:18 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86odhphtp9.fsf@lola.quinscape.zz>
Very nice...
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-03 9:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, Matthieu Moy, git
In-Reply-To: <20070803084010.GM20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> I do not make partial commits myself, so
>> distinction between staged and unstaged are not something I am
>> usually interested in.
>
> I never used to either. Then git-gui got really useful at showing
> the distinction and I started using the index for a staging ground.
I guess we are saying the same thing. I do use index for
staging large-ish changes. I simply do not care about the
staged/not-staged distinction in the sense that "I still haven't
staged these, that's good because these do not belong to the
commit I am going to make next".
Output from "git diff" being truly empty is the cue that such a
large-ish worktree change is ready to be committed, and the
final "git diff --cached" would give me the full picture. A
small-ish change won't make "git diff" in the middle empty, but
checking the final "git diff --cached" before committing is the
same.
^ permalink raw reply
* Re: [PATCH] gitweb: Provide RSS feeds for file history
From: Jakub Narebski @ 2007-08-03 9:10 UTC (permalink / raw)
To: Steven Walter; +Cc: git, Robert Fitzsimons
In-Reply-To: <20070803020555.GB8593@dervierte>
Steven Walter wrote:
Nak. Explanation below. Corrected patch will follow.
> If git_feed is provided a file name, it ought to show only the history
> affecting that file. The title was already being set correctly, but all
> commits from history were being shown anyway.
This is a bug introduced while changing gitweb (among others git_feed
subroutine) to use parse_commits, in commit b6093a5c. Earlier it worked.
So the explanation (in commit message) is not full.
By the way it affects not only RSS but also Atom feeds.
Documentation/SubmittingPatches:
Checklist (and a short version for the impatient):
Commits:
[...]
- if you want your work included in git.git, add a
"Signed-off-by: Your Name <your@email.com>" line to the
commit message (or just use the option "-s" when
committing) to confirm that you agree to the Developer's
Certificate of Origin
> ---
> gitweb/gitweb.perl | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 498b936..26932a4 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -611,6 +611,7 @@ sub href(%) {
> my %mapping = @mapping;
>
> $params{'project'} = $project unless exists $params{'project'};
> + $params{'file_name'} = $file_name unless exists $params{'file_name'};
>
> my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> if ($use_pathinfo) {
This is a big, intrusive change. It makes 'file_name' default argument,
unless overriden. While it made sense for 'project' parameter, as almost
all URLs in gitweb needed it, more than half URLs does not need 'file_name'
parameter. And some of those URLs are present in a views which do use
'file_name'.
If you wanted alternative URLs for a feed preserve 'file_name' parameter,
do it explicitely.
> @@ -5365,7 +5366,7 @@ sub git_feed {
>
> # log/feed of current (HEAD) branch, log of given branch, history of file/directory
> my $head = $hash || 'HEAD';
> - my @commitlist = parse_commits($head, 150);
> + my @commitlist = parse_commits($head, 150, 0, "--full-history", $file_name);
>
> my %latest_commit;
> my %latest_date;
I'd rather not use "--full-history" for feeds. We use it in the 'history'
view for backward compatibility reasons; I'd rather leave it for extra
options in the feed.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-commit.sh: Shell script cleanup
From: David Kastrup @ 2007-08-02 11:40 UTC (permalink / raw)
To: git
This moves "shift" out of the argument processing "case". It also
replaces quite a bit of expr calls with ${parameter#word} constructs,
and uses ${parameter:+word} for avoiding conditionals where possible.
Signed-off-by: David Kastrup <dak@gnu.org>
---
git-commit.sh | 72 +++++++++++---------------------------------------------
1 files changed, 14 insertions(+), 58 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index d7e7028..7d5c8f9 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -97,101 +97,71 @@ do
no_edit=t
log_given=t$log_given
logfile="$1"
- shift
;;
-F*|-f*)
no_edit=t
log_given=t$log_given
- logfile=`expr "z$1" : 'z-[Ff]\(.*\)'`
- shift
+ logfile="${1#-?}"
;;
--F=*|--f=*|--fi=*|--fil=*|--file=*)
no_edit=t
log_given=t$log_given
- logfile=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- shift
+ logfile="${1#*=}"
;;
-a|--a|--al|--all)
all=t
- shift
;;
--au=*|--aut=*|--auth=*|--autho=*|--author=*)
- force_author=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- shift
+ force_author="${1#*=}"
;;
--au|--aut|--auth|--autho|--author)
case "$#" in 1) usage ;; esac
shift
force_author="$1"
- shift
;;
-e|--e|--ed|--edi|--edit)
edit_flag=t
- shift
;;
-i|--i|--in|--inc|--incl|--inclu|--includ|--include)
also=t
- shift
;;
--int|--inte|--inter|--intera|--interac|--interact|--interacti|\
--interactiv|--interactive)
interactive=t
- shift
;;
-o|--o|--on|--onl|--only)
only=t
- shift
;;
-m|--m|--me|--mes|--mess|--messa|--messag|--message)
case "$#" in 1) usage ;; esac
shift
log_given=m$log_given
- if test "$log_message" = ''
- then
- log_message="$1"
- else
- log_message="$log_message
+ log_message="${log_message:+${log_message}
-$1"
- fi
+}$1"
no_edit=t
- shift
;;
-m*)
log_given=m$log_given
- if test "$log_message" = ''
- then
- log_message=`expr "z$1" : 'z-m\(.*\)'`
- else
- log_message="$log_message
+ log_message="${log_message:+${log_message}
-`expr "z$1" : 'z-m\(.*\)'`"
- fi
+}${1#-m}"
no_edit=t
- shift
;;
--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
log_given=m$log_given
- if test "$log_message" = ''
- then
- log_message=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- else
- log_message="$log_message
+ log_message="${log_message:+${log_message}
-`expr "z$1" : 'zq-[^=]*=\(.*\)'`"
- fi
+}${1#*=}"
no_edit=t
- shift
;;
-n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|\
--no-verify)
verify=
- shift
;;
--a|--am|--ame|--amen|--amend)
amend=t
use_commit=HEAD
- shift
;;
-c)
case "$#" in 1) usage ;; esac
@@ -199,15 +169,13 @@ $1"
log_given=t$log_given
use_commit="$1"
no_edit=
- shift
;;
--ree=*|--reed=*|--reedi=*|--reedit=*|--reedit-=*|--reedit-m=*|\
--reedit-me=*|--reedit-mes=*|--reedit-mess=*|--reedit-messa=*|\
--reedit-messag=*|--reedit-message=*)
log_given=t$log_given
- use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ use_commit="${1#*=}"
no_edit=
- shift
;;
--ree|--reed|--reedi|--reedit|--reedit-|--reedit-m|--reedit-me|\
--reedit-mes|--reedit-mess|--reedit-messa|--reedit-messag|\
@@ -217,7 +185,6 @@ $1"
log_given=t$log_given
use_commit="$1"
no_edit=
- shift
;;
-C)
case "$#" in 1) usage ;; esac
@@ -225,15 +192,13 @@ $1"
log_given=t$log_given
use_commit="$1"
no_edit=t
- shift
;;
--reu=*|--reus=*|--reuse=*|--reuse-=*|--reuse-m=*|--reuse-me=*|\
--reuse-mes=*|--reuse-mess=*|--reuse-messa=*|--reuse-messag=*|\
--reuse-message=*)
log_given=t$log_given
- use_commit=`expr "z$1" : 'z-[^=]*=\(.*\)'`
+ use_commit="${1#*=}"
no_edit=t
- shift
;;
--reu|--reus|--reuse|--reuse-|--reuse-m|--reuse-me|--reuse-mes|\
--reuse-mess|--reuse-messa|--reuse-messag|--reuse-message)
@@ -242,32 +207,26 @@ $1"
log_given=t$log_given
use_commit="$1"
no_edit=t
- shift
;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t
- shift
;;
-t|--t|--te|--tem|--temp|--templ|--templa|--templat|--template)
case "$#" in 1) usage ;; esac
shift
templatefile="$1"
no_edit=
- shift
;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t
- shift
;;
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
verbose=t
- shift
;;
-u|--u|--un|--unt|--untr|--untra|--untrac|--untrack|--untracke|\
--untracked|--untracked-|--untracked-f|--untracked-fi|--untracked-fil|\
--untracked-file|--untracked-files)
untracked_files=t
- shift
;;
--)
shift
@@ -280,6 +239,7 @@ $1"
break
;;
esac
+ shift
done
case "$edit_flag" in t) no_edit= ;; esac
@@ -437,12 +397,8 @@ esac
if test t = "$verify" && test -x "$GIT_DIR"/hooks/pre-commit
then
- if test "$TMP_INDEX"
- then
- GIT_INDEX_FILE="$TMP_INDEX" "$GIT_DIR"/hooks/pre-commit
- else
- GIT_INDEX_FILE="$USE_INDEX" "$GIT_DIR"/hooks/pre-commit
- fi || exit
+ GIT_INDEX_FILE="${TMP_INDEX:-${USE_INDEX}}" "$GIT_DIR"/hooks/pre-commit \
+ || exit
fi
if test "$log_message" != ''
--
1.5.3.rc3.129.g974f
--
David Kastrup
^ permalink raw reply related
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Matthieu Moy @ 2007-08-03 8:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708022206130.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The plan is to move to Source forget ;-) when they finally approve the
> project, or stay with Google, should they decide to lift the quota a bit.
You can also have a look at https://gna.org/ (a Savannah-like
non-commercial project hosting).
--
Matthieu
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-03 8:57 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20070803082435.GA15475@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Without making a partial commit, how would you split the
> bugfix changes from the working changes? Or do you manually
> pull the bugfix into another branch or working tree?
I typically stash the WIP away with "git diff HEAD >P.diff &&
git reset --hard" (I should learn to use "git stash" these
days), and switch to an appropriate branch for bugfix (if it is
generally applicable) or stay on the branch (if it is a fix-up
for an earlier patch for the topic) to work on the fix. Then
unstash to continue where I left off.
> In your workflow, how do you
> remind yourself that there are untracked files that need to be added? Do
> you just wait until you see the commit template at the end?
I do not leave files that need to be added untracked for a long
time. Also, I tend to be picky about making sure that (1)
things build from scratch, and that (2) "make clean" removes all
crufts. Because of this, I run "make clean" followed by "git
clean -n" more often than other people. The latter picks them
up if I forget to add them when I created them.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-03 8:41 UTC (permalink / raw)
To: git; +Cc: Robert Schiele, git
In-Reply-To: <7v3az1oyjn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Ok, seems like the sort of cleanups I proposed would not clash with
>> current git policies. I'll readily agree that the timing of their
>> adoption might not really fit with a rc4, but posting them for the
>> queue does not seem outrageous.
>
> Yeah, except that Kristian's C-rewrite of git-commit.sh may well
> jump the queue before such a patch would touch the file it
> intends to replace...
Well, since the work has already been done, I guess I might as well
post it.
With regard to C rewrites: I would hazard a guess that git's
performance might actually be improved by splitting some primitives
into even smaller C building blocks and tying them all together with
pipes (which makes shell scripts a natural container). As long as one
designs the C chunks carefully enough that no bulk processing is done
in the scripts themselves, this could actually lead to better
schedulable pieces of software. I think that most index processing
can be done in a list-merge style on sorted lists. That implies pipes
and files on input and output, and a small memory footprint. With a
good scheduler (the current Linux scheduler sucks at exploiting the
asynchronicity of pipes; this should be better with CFS), this should
make things work rather efficiently, be flexible for extension, and
make good use of multi-core systems.
We have seen a recent example on this list: hand-chaining git-ls-files
and a few other tools into a pipeline beat the pants off
builtin-add.c.
Given that portability goes down the drain if we want to use similarly
or more efficient constellations in C (multithreading and asynchronous
I/O come to mind), I would not replace shell scripts (and the
associated flexibility in extending functionality) lightly right now.
As long as the main data flow is only managed rather than processed by
the scripts, I think we would have more to gain by restructuring into
pipelineable pieces. It will still be possible to ultimately tie
those together in a single process image (with multiple threads
presumably). But that immediately takes away a lot of flexibility.
--
David Kastrup
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Shawn O. Pearce @ 2007-08-03 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Matthieu Moy, git
In-Reply-To: <7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> > On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:
> >
> >> Personally, I almost never run "git status". The command is
> >> there primarily because other systems had a command called
> >> "status", and migrant wondered why we didn't. We do not need
> >> it, and we do not have to use it.
> >
> > So what is the recommended command to summarize which files have been
> > modified, which files have been marked for commit, and which remain
> > untracked?
git-gui? ;-)
I also use the following two aliases:
[alias]
dw = diff --stat --summary
di = diff --stat --summary --cached
...
> I do not make partial commits myself, so
> distinction between staged and unstaged are not something I am
> usually interested in.
I never used to either. Then git-gui got really useful at showing
the distinction and I started using the index for a staging ground.
I almost never make partial commits, unless it is completely trivial,
e.g. a comment fixup that isn't related to what I'm really doing
but that was too darn obvious to not fix _right now_.
But I always toss things into the index when I've read through the
diff a few times and am very happy with it. I may not be done with
the overall commit, but I park the hunks into the index so I don't
have to look at them again. I use a trackball so "tossing into the
index" is really just a flick of the wrist to select the menu item
from the pop-up menu on that hunk. Quite like a toss. ;-)
I tend to test only once I have everything staged into the index and
my working directory is clean (nothing changed that isn't staged).
Its at that point that I think my change is done and I'm happy with
how the diff looks. Usually the code is correct at this point too;
but if its not I'll fix it, then commit.
So where does that leave me regarding the touched but not changed
files? Usually they just get in my way in the end. I don't much
care that I've undone the file back to what I had in the index.
It just doesn't provide any value to my workflow. It is actually
incredible rare that I cause it to happen too. Usually I won't
write the file back to disk if I'm just going to undo it.
If I do write it to disk I'm likely to stage it or at least some
hunks of it. If I later change my mind and undo those changes I'm
going to effectively stage the reverse difference. This is a very
nice hint showing me that yes in fact the older way was better.
Personally? The index is a killer feature for me. Totally.
I can't work without it anymore, it has become a total crutch to me.
You would have to pry the index from my cold dead fingers to get
me to stop using it.
Yea, that is a total about-face for me. I used to think the index
was only useful for merges. Boy was I wrong!
--
Shawn.
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Simon 'corecode' Schubert @ 2007-08-03 8:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <46B26DA8.6010102@alum.mit.edu>
Michael Haggerty wrote:
> Simon 'corecode' Schubert wrote:
>> Steffen Prohaska wrote:
>>> BTW, togit creates much more complex branching patterns than cvs2svn
>>> does. The attached file branching.png displays a small view of a
>>> branching pattern that extends downwards over a couple of screens.
>>> I checked the cvs2svn history again. It doesn't contain anything
>>> of similar complexity.
>> haha yea, there is still some issue with duplicate branch names and the
>> branchpoint. if it doesn't get the branch right, it will always "pull"
>> files from the parent branch.
>
> This sounds very much like the problem reported by Daniel Jacobowitz
> [1]. The problem is that if you create a branch A on a file, then
> create branch B from branch A before making a commit on branch A, then
> CVS doesn't record that branch A was the source of branch B. (It treats
> B as if it sprouted directly from the revision that was the *source* of
> branch A.) The same problem exists if "B" is a tag.
I think I have covered this case quite well. I believe "my" problem happens when there are files being copied manually within the repository and then branch names being changed (or just branch names being changed). However, the name change just happens only on a subset of files and branches, so you wind up with a commit which is part of two branches. Or something like that. I really should have the time to investigate this.
One elementary problem with CVS is that you can assign two branch names to the same branch. During conversion you need to choose one over the other.
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
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-03 8:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Guilhem Bonnefille, git, users
In-Reply-To: <46a038f90708021608o21480074ybcfada767afc7b04@mail.gmail.com>
Martin Langhoff wrote:
> Is there any way we can run tweak cvs2svn to run incrementals, even if
> not as fast as cvsps/git-cvsimport? The "do it remotely" part can be
> worked around in most cases.
I don't see any fundamental reason why not, but I think it would be a
significant amount of work. There are two main issues:
1. With CVS, it is possible to change things retroactively, such as
changing which version of a file is included in a tag, or adding a new
file to a tag, or changing whether a file is text vs. binary. And many
people copy and/or rename files within the CVS repository itself (to get
around CVS's inability to rename a file). This makes it look like the
file has *always* existed under the new name and *never* existed under
the old name. An incremental conversion tool would have to look
carefully for such changes and either handle them properly or complain
loudly and abort.
2. cvs2svn uses a lot of repository-wide information to make decisions
about how to group CVSItems into changesets, and a lot of these
decisions are based on heuristics. Incremental conversion would require
that the decisions made in one cvs2svn run are recorded and treated as
unalterable in subsequent runs.
This hasn't been a priority in the Subversion world, because, frankly,
what reason would a person have to stick with CVS instead of switching
to Subversion, given that (1) they are intentionally so similar in
workflow, an (2) there is no significant competition from other
centralized SCMs? But of course until the distributed SCM playing field
has been thinned out a bit, people will probably be reluctant to commit
to one or the other.
I don't expect to have time to implement incremental conversions in
cvs2svn in the near future. (I'd much rather work on output back ends
to other distributed SCMs.) But if any volunteers step forward (hint,
hint) I would be happy to help them get started and answer their
questions. I think that cvs2svn is quite hackable now, so the learning
curve is hopefully much less frightening than when I started on the
project :-)
Michael
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Jeff King @ 2007-08-03 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net>
On Fri, Aug 03, 2007 at 12:59:43AM -0700, Junio C Hamano wrote:
> On the other hand, if your workflow is "work on one thing at a
> time, and never make partial commits", then your diff tends to
> be small and more focused to begin with, and you can afford to
> care about "touched but ended up unmodified". Interestingly, it
In an ideal world, I would work that way. But often you uncover a bug in
existing code while writing new code, and you want to make that bugfix a
separate commit. I generally make a partial commit to stash the bugfix
and test it individually. Without making a partial commit, how would you
split the bugfix changes from the working changes? Or do you manually
pull the bugfix into another branch or working tree?
There is one point you didn't address from my original mail which I
would be curious to hear your take on. In your workflow, how do you
remind yourself that there are untracked files that need to be added? Do
you just wait until you see the commit template at the end?
-Peff
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Johan Herland @ 2007-08-03 8:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, David Kastrup
In-Reply-To: <7v3az1samx.fsf@assigned-by-dhcp.cox.net>
On Friday 03 August 2007, Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> * With -l, as long as the source repository is healthy, it is
> >> very likely that the recipient would be, too. Also it is
> >> very cheap. You do not get any back-up benefit.
> >
> > Oh, but one does: an overzealous prune or rm -oopswrongoption in one
> > repo does not hurt the other.
>
> That's not "back-up" benefit I was thinking about. It is more
> about protecting your data from hardware failure.
If one is serious about backing up ones repo to protect it from hardware
failure, there is not much use at all in cloning (by copy, hardlink, or
otherwise) to a different location on the _same_ filesystem. In order for a
backup to be at least marginally useful, it should be on a different disk
drive (which you hint at below), or even better; on a different
continent...
My point is as follows: One has to clone a repo onto (at least) a different
filesystem if one is serious about backup. But if one is cloning to a
different filesystem, hardlinking is no longer an option; git _has_ to make
a copy of some sort. Therefore we might as well hardlink as long as we're
on a single filesystem (since the extra copy would not be worth much,
backup-wise).
> You physically have bits in two places, preferrably on separate disk
> drives.
> And that is what you do not get from hardlinked clone.
If the two copies are on separate disk drives (i.e. separate filesystems),
you cannot make a hardlink in the first place. If the two copies are on the
same filesystem, they're not much more worth than a single copy
(backup-wise).
Given the clone-to-same-filesystem(-with-hardlink-capability) scenario
(which is the only scenario where we have the option of using hardlinks),
we have the following pros and cons when using hardlinks instead of
copying:
Pros:
- Hardlink is _much_ faster (for big repos, we're talking orders of
magnitude faster)
Cons:
- Hardlink will not leave two copies on the disk. But I'm arguing that the
additional copy will have pretty much _no_ value from a redundancy POV,
since the copy is still left on the _same_ filesystem. Some would even go
as far as to say that the second copy provides a false sense of security as
long as it is located on the same filesystem.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Junio C Hamano @ 2007-08-03 7:59 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20070803070407.GA17287@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:
>
>> Personally, I almost never run "git status". The command is
>> there primarily because other systems had a command called
>> "status", and migrant wondered why we didn't. We do not need
>> it, and we do not have to use it.
>
> So what is the recommended command to summarize which files have been
> modified, which files have been marked for commit, and which remain
> untracked?
Ok, you got me. If I need such a summary, git-status would
obviously be the choice. Although I do admit that I added the
interactive commit to support people who want to keep 30 hunks
across 10 different files in the working tree, and make a commit
using only 3 of them, I do not make partial commits myself, so
distinction between staged and unstaged are not something I am
usually interested in. If your workflow care about that
distinction, and that is a very valid and natural workflow in
git, you would find git-status and git-diff --cached more useful
than they are to me. I should not used words such as optimum.
It is just "different".
When you think about it, in such a workflow whose work tree that
does not match commits created from it, it is not very useful to
know the "touched but ended up unmodified", because (1) the
worktree changes are full of not-yet-ready changes (to the
immediate commit you are going to create) anyway, and (2) the
"touched but not modified" files may further be modified and
become modified before their changes hit a (later) commit. The
side effect that "git-status" loses that information suddenly
becomes a useful feature for such a workflow.
On the other hand, if your workflow is "work on one thing at a
time, and never make partial commits", then your diff tends to
be small and more focused to begin with, and you can afford to
care about "touched but ended up unmodified". Interestingly, it
happens to be a useful correlation that "git status", which
clears such information, is less useful command for such a
workflow.
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Junio C Hamano @ 2007-08-03 7:41 UTC (permalink / raw)
To: David Kastrup; +Cc: Robert Schiele, git
In-Reply-To: <85lkctw3sl.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Ok, seems like the sort of cleanups I proposed would not clash with
> current git policies. I'll readily agree that the timing of their
> adoption might not really fit with a rc4, but posting them for the
> queue does not seem outrageous.
Yeah, except that Kristian's C-rewrite of git-commit.sh may well
jump the queue before such a patch would touch the file it
intends to replace...
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 7:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <46B2D547.6050406@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
>> Anyway, you can get a complete Development environment in 3 files
>> (because one would be too large), and... oh well, just read what
>> is written on the website if you're really interested.
>
> Great effort Johannes! The package work perfectly on XP. I'm trying
> to get it to work under Wine, but it (Wine) is not playing nice
> with me at the moment. (The whole system barfs of "Access Denied"
> and other things. Grrr)
Actually turns out that Wine doesn't like that the sound library is
missing. So, installing libjack make it barf less..
Actually compiling in Wine now with your package, though _sooo_ much
slower than on XP :-)
Yes, I know cross-compiling is faster. But if using this package would
compile successfully on Linux too, then we only need to maintain one
MinGW setup for compiling Git on both Windows and Linux. Worth a try
at least.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix unterminated string in set_work_tree and improve error handling
From: Alex Riesen @ 2007-08-03 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <7v7iodqgg9.fsf@assigned-by-dhcp.cox.net>
On 8/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> I sense you haven't read my replacement patch (Dscho Acked it).
I did. I had to pay attention to what I read, though. Sorry.
^ 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