* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Wincent Colaiuta @ 2007-11-30 9:19 UTC (permalink / raw)
To: Kevin Leung; +Cc: Mike Hommey, Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <e66701d40711300109nc43f3efyb33e591af15a060b@mail.gmail.com>
El 30/11/2007, a las 10:09, Kevin Leung escribió:
> On Nov 30, 2007 4:41 PM, Mike Hommey <mh@glandium.org> wrote:
>> Still, 'git stash' alone should *do* the stash.
>
> How about `git stash' still does the stash, and `git stash llist'
> exits with usage message? And if you want to save the stash with name,
> you can only do it with `git stash save name_of_stash'.
That's probably the way it should have been all along.
>
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Kevin Leung @ 2007-11-30 9:09 UTC (permalink / raw)
To: Mike Hommey; +Cc: Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <20071130084131.GA29668@glandium.org>
On Nov 30, 2007 4:41 PM, Mike Hommey <mh@glandium.org> wrote:
> Still, 'git stash' alone should *do* the stash.
>
How about `git stash' still does the stash, and `git stash llist'
exits with usage message? And if you want to save the stash with name,
you can only do it with `git stash save name_of_stash'.
Kevin Leung
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Mike Hommey @ 2007-11-30 8:41 UTC (permalink / raw)
To: Kevin Leung; +Cc: Git ML, Junio C Hamano, Nanako Shiraishi
In-Reply-To: <e66701d40711300016v15700deft3d262d75a9055aca@mail.gmail.com>
On Fri, Nov 30, 2007 at 04:16:34PM +0800, Kevin Leung <kevinlsk@gmail.com> wrote:
> The current git-stash behaviour is very error prone to typos. For example,
> if you typed "git-stash llist", git-stash would thought that you wanted to
> save to a stash named "llist", but in fact, you meant "git-stash list".
Still, 'git stash' alone should *do* the stash.
Mike
^ permalink raw reply
* [PATCH] git-stash: Display help message if git-stash is run without sub-commands
From: Kevin Leung @ 2007-11-30 8:16 UTC (permalink / raw)
To: Git ML, Junio C Hamano, Nanako Shiraishi
The current git-stash behaviour is very error prone to typos. For example,
if you typed "git-stash llist", git-stash would thought that you wanted to
save to a stash named "llist", but in fact, you meant "git-stash list".
Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
---
git-stash.sh | 15 ++++++---------
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 77c9421..dbb8894 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2007, Nanako Shiraishi
-USAGE='[ | list | show | apply | clear]'
+USAGE='[ save | list | show | apply | clear ]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -195,6 +195,10 @@ show)
shift
show_stash "$@"
;;
+save)
+ shift
+ save_stash "$@" && git-reset --hard
+ ;;
apply)
shift
apply_stash "$@"
@@ -202,14 +206,7 @@ apply)
clear)
clear_stash
;;
-help | usage)
- usage
- ;;
*)
- if test $# -gt 0 && test "$1" = save
- then
- shift
- fi
- save_stash "$*" && git-reset --hard
+ usage
;;
esac
--
1.5.3.6.36.g38762
^ permalink raw reply related
* Re: importing bk into git
From: Andreas Ericsson @ 2007-11-30 7:59 UTC (permalink / raw)
To: christoph.duelli; +Cc: git
In-Reply-To: <200711292232.03352.christoph.duelli@gmx.de>
Christoph wrote:
> I am trying to import a BitKeeper repo into a (new) git repo.
>
> I am trying with the script bk2git.py that I found on the web.
> This does not quite work - I fear script is no longer working with the current
> git release. (I am using the current git release.)
>
> If I have understood the script correctly, it does repeated bk checkouts and
> imports the updates the git repo diff of the (next) checkout etc.
>
> It seems this script tries to do so by settings environment vars
> GIT_OBJECT_DIRECTORY and GIT_INDEX_FILE
> to point at the git repo.
>
> The bk checkout are done at a temp. dir (tmp_dir).
>
>
> The following lines fail
> os.system("cd %s; git-ls-files --deleted | xargs
> git-update-cache --remove" % tmp_dir)
>
> with: fatal: Not a git repository
> xargs: git-update-cache: No such file or directory
>
You may have better luck using "git update-index" instead of
git-update-cache. If that doesn't work, try finding out which
version of git the importer script was written against and try
using that version of git for the import.
If you run into problems while using a newer git on the
imported repository that'll be a different discussion.
> The problem seems to be that the script cd's into the temp dir (which is not a
> git repo) and the git-ls-files fails to find a git repo there.
> I think the issue might be that an earlier version of git was perhaps able to
> find the repo by means of the env. vars mentioned above.
>
It should still do this, afaik, although it's probably better
to just use GIT_DIR nowadays.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Wincent Colaiuta @ 2007-11-30 7:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Nguyen Thai Ngoc Duy, Jan Hudec,
Johannes Schindelin, git
In-Reply-To: <7vd4tsvfvk.fsf@gitster.siamese.dyndns.org>
El 29/11/2007, a las 23:36, Junio C Hamano escribió:
> If people are really serious about reducing the number of commands in
> the path, I would expect fixes and bugreports saying "I am setting
> gitexecdir different from bindir in _my_ installation when I build
> git,
> and here are the things that does not work if I do so". Within the
> span
> of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I
> do not think there was a single such report or patch, other than the
> message from Nguyen that started this thread.
One reason why there have been no reports is probably because 99% of
people have never heard of gitexecdir nor know what it does.
$ git grep gitexecdir | awk -F : '{print $1}' | uniq
Makefile
config.mak.in
git-gui/Makefile
git-gui/macosx/AppMain.tcl
git.c
Try googling for "site:git.or.cz gitexecdir"
Basically, seems the only way you could know about it is if you've
heard it mentioned on this mailing list and decided to study the
Makefile.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Andreas Ericsson @ 2007-11-30 7:18 UTC (permalink / raw)
To: Jeff King
Cc: Nicolas Pitre, Junio C Hamano, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130011748.GC11683@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:
>
>>> My point is that (2) is already implemented for every program (shell or
>>> no) which understands filename completion, and there is a proposal for
>>> taking it away. I would consider that, except I haven't see any claimed
>>> advantages except that the hardlinks are awful under Windows.
>> Weren't enough complaints about Git having waaaaaaaaaaay too many
>> commands? Didn't those complaints come about often enough already?
>>
>> $ git-[tab]
>> Display all 135 possibilities? (y or n)
>
> Go back and read the thread to which you are responding. I am _not_
> arguing against moving those commands to $(libexecdir) where no sane
> user will ever see them. That change addresses the issue you are talking
> about.
>
> I _am_ arguing against removing them entirely, for those of us who want
> to go to the trouble of enabling this (by putting a non-standard entry
> into our PATH). Because the issue you are talking about will already
> have been dealt with, it is no longer a compelling reason to remove the
> hardlinks entirely.
>
> The only reason I have heard to remove them entirely is that Windows
> doesn't properly support hardlinks, which I addressed in my other mails
> (and to which I have seen no rebuttal).
>
It would provide a ui inconsistency between platforms. Several people
pointed that out. It's decidedly a Bad Thing.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Adding Git to Better SCM Initiative : Comparison
From: Alex Riesen @ 2007-11-30 7:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Robin Rosenberg
In-Reply-To: <200711300118.28145.jnareb@gmail.com>
Jakub Narebski, Fri, Nov 30, 2007 01:18:27 +0100:
> >> <s id="mercurial">
> >> Excellent. Uses HTTP or ssh. Remote access also
> >> works safely without locks over read-only network
>
> By the way, can Git be used with repository on lockless network
> filesystem? (Although with distributed SCM it perhaps be better
> to just use many distributed repositories...). How does it work
> with repository available via SMBFS / CIFS or NFS?
Works fine. CIFS/SMBFS is slow as hell when hosted on windows, but I
figure it is not problem of Git.
^ permalink raw reply
* StGit kha/experimental branch updated
From: Karl Hasselström @ 2007-11-30 6:49 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
I've fixed a handful of minor problems in the "new infrastructure"
series, and added one new patch at the end of David's series that
might be a tad controversial: the removal of "stg resolved".
The reason for removing it are simply that "git add" and "git
mergetool" can do the same job, and I think it's a bad idea to make
StGit's command set any bigger than necessary. If it ain't about
patches, we should leave the job to git (and if we feel that git does
a suboptimal job, we should fix git).
-+-
The following changes since commit 8d2b87ac26d01c7110d911aefea8988ca5a9b183:
Karl Hasselström (1):
Make "stg repair" help text more helpful
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
David Kågedal (9):
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Karl Hasselström (20):
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
"stg status --reset" is not needed anymore
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
Remove "stg resolved"
New StGit core infrastructure: repository operations
Write metadata files used by the old infrastructure
Upgrade older stacks to newest version
Let "stg clean" use the new infrastructure
Add "stg coalesce"
Let "stg applied" and "stg unapplied" use the new infrastructure
Teach the new infrastructure about the index and worktree
Let "stg clean" use the new transaction primitives
Let "stg goto" use the new infrastructure
Convert "stg uncommit" to the new infrastructure
New infrastructure: Make sure that the branch is initialized
Documentation/stg-cp.txt | 63 -------
Documentation/stg.txt | 2 -
Documentation/tutorial.txt | 31 ++--
contrib/stgit-completion.bash | 4 +-
examples/gitconfig | 19 +--
setup.py | 2 +-
stgit/commands/add.py | 44 -----
stgit/commands/applied.py | 27 ++--
stgit/commands/clean.py | 49 ++----
stgit/commands/coalesce.py | 112 ++++++++++++
stgit/commands/common.py | 35 ++--
stgit/commands/copy.py | 45 -----
stgit/commands/goto.py | 52 ++----
stgit/commands/pick.py | 2 +-
stgit/commands/resolved.py | 94 ----------
stgit/commands/rm.py | 48 -----
stgit/commands/status.py | 31 ++--
stgit/commands/sync.py | 1 -
stgit/commands/unapplied.py | 23 ++--
stgit/commands/uncommit.py | 79 ++++-----
stgit/config.py | 1 -
stgit/git.py | 72 +++++----
stgit/gitmergeonefile.py | 97 +----------
stgit/lib/__init__.py | 18 ++
stgit/lib/git.py | 383 +++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 171 ++++++++++++++++++
stgit/lib/stackupgrade.py | 98 +++++++++++
stgit/lib/transaction.py | 195 +++++++++++++++++++++
stgit/main.py | 10 +-
stgit/run.py | 3 +
stgit/stack.py | 151 +++-------------
stgit/utils.py | 24 +++
t/t0002-status.sh | 13 +-
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 4 +-
t/t1203-push-conflict.sh | 70 ++++++++
t/t1204-pop-keep.sh | 2 +-
t/t1205-push-subdir.sh | 8 +-
t/t1300-uncommit.sh | 4 +-
t/t1301-repair.sh | 2 +-
t/t1400-patch-history.sh | 4 +-
t/t1500-float.sh | 14 +-
t/t1600-delete-one.sh | 12 +-
t/t1601-delete-many.sh | 2 +-
t/t1700-goto-top.sh | 2 +-
t/t2000-sync.sh | 12 +-
t/t2100-pull-policy-fetch.sh | 4 +-
t/t2101-pull-policy-pull.sh | 4 +-
t/t2102-pull-policy-rebase.sh | 4 +-
t/t2300-refresh-subdir.sh | 2 +-
t/t2600-coalesce.sh | 31 ++++
51 files changed, 1373 insertions(+), 809 deletions(-)
delete mode 100644 Documentation/stg-cp.txt
delete mode 100644 stgit/commands/add.py
create mode 100644 stgit/commands/coalesce.py
delete mode 100644 stgit/commands/copy.py
delete mode 100644 stgit/commands/resolved.py
delete mode 100644 stgit/commands/rm.py
create mode 100644 stgit/lib/__init__.py
create mode 100644 stgit/lib/git.py
create mode 100644 stgit/lib/stack.py
create mode 100644 stgit/lib/stackupgrade.py
create mode 100644 stgit/lib/transaction.py
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t2600-coalesce.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH] Make "stg repair" help text more helpful
From: Karl Hasselström @ 2007-11-30 6:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Jon Smirl
In-Reply-To: <20071128164113.GA20749@diana.vm.bytemark.co.uk>
Specifically, point out that if messing up the branch with git
commands was a mistake, the user should run "git reset", not "stg
repair".
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Is this an improvement?
stgit/commands/common.py | 4 +--
stgit/commands/repair.py | 63 ++++++++++++++++++++++++++++------------------
2 files changed, 41 insertions(+), 26 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 6318cdd..bf804e6 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -114,8 +114,8 @@ def check_head_top_equal(crt_series):
if not crt_series.head_top_equal():
raise CmdException(
"""HEAD and top are not the same. This can happen if you
- modify a branch with git. The "repair" command can
- fix this situation.""")
+ modify a branch with git. "stg repair --help" explains
+ more about what to do next.""")
def check_conflicts():
if os.path.exists(os.path.join(basedir.get(), 'conflicts')):
diff --git a/stgit/commands/repair.py b/stgit/commands/repair.py
index c36db07..aa34792 100644
--- a/stgit/commands/repair.py
+++ b/stgit/commands/repair.py
@@ -26,32 +26,47 @@ from stgit.out import *
from stgit.run import *
from stgit import stack, git
-help = 'StGit-ify any git commits made on top of your StGit stack'
+help = 'Fix StGit metadata if branch was modified with git commands'
usage = """%prog [options]
-"repair" will repair three kinds of inconsistencies in your StGit
-stack, all of them caused by using plain git commands on the branch:
-
- 1. If you have made regular git commits on top of your stack of
- StGit patches, "repair" converts them to StGit patches,
- preserving their contents.
-
- 2. Merge commits cannot become patches; if you have committed a
- merge on top of your stack, "repair" will simply mark all
- patches below the merge unapplied, since they are no longer
- reachable. If this is not what you want, use "git reset" to get
- rid of the merge and run "repair" again.
-
- 3. The applied patches are supposed to be precisely those that are
- reachable from the branch head. If you have used e.g. "git reset"
- to move the head, some applied patches may no longer be
- reachable, and some unapplied patches may have become reachable.
- "repair" will correct the appliedness of such patches.
-
-Note that these are "inconsistencies", not "errors"; furthermore,
-"repair" will repair them reliably. As long as you are satisfied
-with the way "repair" handles them, you have no reason to avoid
-causing them in the first place if that is convenient for you."""
+If you modify an StGit stack (branch) with some git commands -- such
+as commit, pull, merge, and rebase -- you will leave the StGit
+metadata in an inconsistent state. In that situation, you have two
+options:
+
+ 1. Use "git reset" or similar to undo the effect of the git
+ command(s).
+
+ 2. Use "stg repair". This will fix up the StGit metadata to
+ accomodate the modifications to the branch. Specifically, it will
+ do the following:
+
+ * If you have made regular git commits on top of your stack of
+ StGit patches, "stg repair" makes new StGit patches out of
+ them, preserving their contents.
+
+ * However, merge commits cannot become patches; if you have
+ committed a merge on top of your stack, "repair" will simply
+ mark all patches below the merge unapplied, since they are no
+ longer reachable. If this is not what you want, use "git
+ reset" to get rid of the merge and run "stg repair" again.
+
+ * The applied patches are supposed to be precisely those that
+ are reachable from the branch head. If you have used e.g.
+ "git reset" to move the head, some applied patches may no
+ longer be reachable, and some unapplied patches may have
+ become reachable. "stg repair" will correct the appliedness
+ of such patches.
+
+ "stg repair" will fix these inconsistencies reliably, so as long
+ as you like what it does, you have no reason to avoid causing
+ them in the first place. For example, you might find it
+ convenient to make commits with a graphical tool and then have
+ "stg repair" make proper patches of the commits.
+
+NOTE: If using git commands on the stack was a mistake, running "stg
+repair" is _not_ what you want. In that case, what you want is option
+(1) above."""
directory = DirectoryGotoToplevel()
options = []
^ permalink raw reply related
* Re: Some git performance measurements..
From: Steffen Prohaska @ 2007-11-30 6:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0711292131350.9605@xanadu.home>
On Nov 30, 2007, at 3:40 AM, Nicolas Pitre wrote:
> On Thu, 29 Nov 2007, Linus Torvalds wrote:
>
>> On Fri, 30 Nov 2007, Jakub Narebski wrote:
>>>
>>> Isn't there a better way to do this sorting? What is needed here is
>>> (stable) _bucket_ sort / _pigeonhole_ sort (or counting sort), which
>>> is O(n); quicksort is perhaps simpler to use, but I'm not sure if
>>> faster in this situation.
>
> That particular sort takes under a second here with the Linux repo.
> Pretty insignificant compared to the time required to repack.
Brian Downing measured horrid performance of qsort on Windows
2000 [1]. qsort seems to show worst case behaviour.
This resulted in a patch replacing Window's qsort implementation
for the mingw port [2].
[1] http://thread.gmane.org/gmane.comp.version-control.msysgit/1084
[2] http://thread.gmane.org/gmane.comp.version-control.msysgit/1086
Avoiding qsort would even be better. I'm not sure, though,
if the particular qsort call that triggered the current
discussion, is the very same qsort call that Brian was hit by.
I'm only claiming that in general avoiding qsort on Windows
is a good idea.
Steffen
^ permalink raw reply
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-11-30 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <7v3auos4yi.fsf@gitster.siamese.dyndns.org>
On Thu, 29 Nov 2007, Junio C Hamano wrote:
>
> I am hoping that "probably 10s of those 17s" can actually be measured
> with the patch I sent out last night. Has anybody took a look at it?
Sorry, I missed it. But I just did timings.
Your patch helps
git read-tree -m -u --exclude-per-directory=.gitignore HEAD HEAD
timings enormously, and it's now down to 3s for me (which is the same
speed as it is without any per-directory-excludes). That's a big
improvement from the ~10s I see without your patch (I've repacked my
tree, I have to admit that I don't even know if it's the new or the old
older, but I can state that 7s for me was just those .gitignore files).
Sadly, the full "git checkout" itself is not actually improved, due to the
git update-index --refresh
there, which will end up populating the whole directory cache anyway.
I wonder why I didn't see that as the expensive operation when I timed
"git checkout". Probably because I narrowed down on the "git read-tree" as
the operation that actually accesses the pack-file and the object
directory, while the "git update-index" never touches the actual objects.
Anyway, I think your patch is great. It just doesn't help the full case of
a "git checkout", only the read-tree portion of it ;(
As to partitioning the data according to types:
> When I do archaeology, I think I often run blame first to see which
> change made the block of text into the current shape first, and then run
> a path limited "git log -p" either starting or ending at that revision.
> In that workflow, the initial blame may get slower with the new layout,
> but I suspect it would help by speeding up the latter "git log -p" step.
I really cannot convince myself one way or the other. I have a suspicion
that sometimes it helps to have objects (regardless of type) close to each
other, and sometimes it helps to have the trees packed densely. A lot of
operations *do* work on both blobs and trees (a *raw* diff doesn't, but
they are fairly rare), so this is not at all clear-cut like the commit
case.
So sorting the commits together is a no-brainer, since a lot of really
important ops only look at them. But blobs and trees? The numbers
certainly go both ways, and I suspect we are probably better off not
messing with the sort order unless we have some unambiguous real results.
Oh, well. I was hoping that I'd have a number of cases that showed good
improvements, with perhaps the bulk of it not showing much difference at
all. But while I saw the good improvements, the very first try at "git
blame" also showed quite worse numbers, so I think we should consider it
an interesting idea, but probably shelve it.
Linus
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Steffen Prohaska @ 2007-11-30 5:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Junio C Hamano, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.9999.0711291821220.8458@woody.linux-foundation.org>
On Nov 30, 2007, at 3:29 AM, Linus Torvalds wrote:
> So I just think that the whole idiotic complaint that some people have
> (that whole "git-<tab><tab>" shows "Display all 144 possibilities?"
> and
> people are somehow using that as an argument that git is "complex")
> should
> be something we strive to undo. I think the complaint is insane
> (because
> the answer is "well, nobody forces you to _use_ all the power and
> scripts
> we give you!"), but still, it's a complaint, so let's just assume
> the user
> is right, and try to fix it.
>
> So when you do "git-<tab><tab>" it should just beep at you and not
> show
> anything at all by default. And when you do "git <tab><tab>", we
> should
> make sure that the bash expansion (or zsh or whatever) shows a nice
> collection of common plumbing, not soemthing really scary.
What will happen to gitk?
Shouldn't it be included in the nice collection? gitk is
an essential command. Then, following your reasoning,
"git <tab><tab>" should recommend it, no?
Note, "git gui" already works. gitk would really be the last
git "command" that can't be accessed through "git <command>"
Steffen
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Steffen Prohaska @ 2007-11-30 5:42 UTC (permalink / raw)
To: Jeff King
Cc: Nicolas Pitre, Junio C Hamano, Linus Torvalds,
Johannes Schindelin, Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130011748.GC11683@coredump.intra.peff.net>
On Nov 30, 2007, at 2:17 AM, Jeff King wrote:
>
> The only reason I have heard to remove them entirely is that Windows
> doesn't properly support hardlinks, which I addressed in my other
> mails
> (and to which I have seen no rebuttal).
We don't have a problem with hardlinks for git-* commands in
msysgit. The msysgit installer already creates hardlinks if
installing on NTFS. On non-NTFS partitions, though, it needs
to copy the files.
Note, this doesn't mean we love hardlinks in msysgit. Actually,
msys does _not_ support them in its Unix emulation layer. So,
for daily work git does not have hardlinks. For examples, the
test script skip all hardlink related tests. The installer
handles hardlinks using the Windows API directly and not using
the Unix emulation layer.
We already have a setup that supports exporting only git and
gitk to the a Windows Command Prompt (not the bash that comes
with msysgit). If you choose this setup, a directory that
contains only these two commands will be added to the system
wide PATH. We use this indirection to hide all the the Unix
tools that are included in msysgit (and needed by git) from
the Windows Command Prompt.
Steffen
^ permalink raw reply
* Re: Some git performance measurements..
From: Junio C Hamano @ 2007-11-30 5:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711290945060.8458@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Umm. See my earlier numbers. For "git checkout" with cold cache, the
> *bulk* of the time is actually the ".gitignore" file lookups, so if you
> see a three-second improvement out of 17s, it may not look spectacular,
> but considering that probably 10s of those 17s were something *else* going
> on, I suspect that if you really did just a plain "git checkout", you
> actually *do* have a spectacular improvement of roughly 7s -> 4s!
I am hoping that "probably 10s of those 17s" can actually be measured
with the patch I sent out last night. Has anybody took a look at it?
Partitioning the pack data by object type shifts the tradeoffs from the
current "the data in the same tree are mostly together, except commits
are treated differently because rev walk is done quite often" layout.
Because we do not ever look at blob objects while pruning the history
(unless the -Spickaxe option is used, I think), partitioned layout would
optimize ancestry walking even more than the current packfile layout.
On the other hand, any operation that wants to look at the contents are
penalized. A two-tree diff that inspects the contents (e.g. fuzzy
renames and pickaxe) needs to read from the tree section to find which
blob to compare with which other blob, and and then needs to seek to the
blob section to actually read the contents, while the current layout
tends to group both trees and blobs that belong to the same tree
together. It is natural that blame is penalized by the new layout,
mostly because it needs to grab two blobs to compare from parent-child
pair, but also because it needs to find two-tree diffs for parent-child
pair it traverses whenever it needs to follow across renames (that is,
when it sees there is no corresponding path in the parent). I would
expect to see similar slowdown from grep which wants to inspect blobs
that are in the same tree.
When I do archaeology, I think I often run blame first to see which
change made the block of text into the current shape first, and then run
a path limited "git log -p" either starting or ending at that revision.
In that workflow, the initial blame may get slower with the new layout,
but I suspect it would help by speeding up the latter "git log -p" step.
^ permalink raw reply
* Re: [PATCH] git-cvsserver runs hooks/post-receive
From: Michael Witten @ 2007-11-30 4:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7v3aup291c.fsf@gitster.siamese.dyndns.org>
On 28 Nov 2007, at 7:24:31 PM, Junio C Hamano wrote:
> Michael Witten <mfwitten@mit.edu> writes:
>
>> git-cvsserver just did the following:
>> (1) run hooks/update
>> (2) commit if hooks/update passed
>>
>> This commit simply adds:
>> (3) run hooks/post-receive
>>
>> Also, there are a few grammar cleanups and
>> consistency improvements.
>
> I gave only a very cursory look; looks Ok to me. This makes me wonder
> if post-update wants to run as well.
Seems like post-receive is supposed to supersede post-update anyhow,
so might as well leave post-update out at this point?
In any case, I haven't taken a thorough look at how git-cvsserver works,
but it seems to duplicate a lot of git-receive-pack.
How about turning git-cvsserver into a true middleman, so that it
constructs
a 'temporary git working tree' and then does a real git-push into the
final
git repository.
Because git-cvsserver would be using git-send-pack to do the pushing,
it could
push to yet another server. How cool is that!
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 2:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff King, Junio C Hamano, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.9999.0711291821220.8458@woody.linux-foundation.org>
On Thu, 29 Nov 2007, Linus Torvalds wrote:
> Yes. I meant that we might as well keep all the git-xyz forms around, but
> _only_ in the libexec directory (and make sure that the libexec directory
> by default is *not* a binary directory), so that they'd normally not be
> visible.
>
> So then, people who want to use the old-fashioned git-xyz forms, because
> they just really hate white-space or whatever, could choose to do one of
> two things:
> - either just change the default libexec directory to be the same as the
> binary install directory, and have all the git-xyz things in the same
> place they've always been.
> - or just add $(gitlibexec) into their path.
>
> but the default (which is what 99% of all people use) would be to not
> show them. I also think that it makes sense to avoid wasting diskspace
> with duplicate files, so in situations where you don't have hardlinks,
> just don't install the git-xyz files at all by default (and again, maybe
> we can have a option to the installer to do it for people who really are
> very attached to the git-xyz format, and prefer to waste even a lot of
> disk on it)
>
> So I just think that the whole idiotic complaint that some people have
> (that whole "git-<tab><tab>" shows "Display all 144 possibilities?" and
> people are somehow using that as an argument that git is "complex") should
> be something we strive to undo. I think the complaint is insane (because
> the answer is "well, nobody forces you to _use_ all the power and scripts
> we give you!"), but still, it's a complaint, so let's just assume the user
> is right, and try to fix it.
Absolutely!
And despite Junio's appearance of some cowardliness on this issue :-)
I think we should have this right now instead of later. Like Junio said
himself, this was planned for a while already, and poorly maintained
external scripts are already failing due to other reasons anyway.
Nicolas
^ permalink raw reply
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-11-30 2:54 UTC (permalink / raw)
To: Jakub Narebski, Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291812530.8458@woody.linux-foundation.org>
On Thu, 29 Nov 2007, Linus Torvalds wrote:
>
> Something like the appended (untested!
Ok, tested now. It does seem to work. The page fault trace for the
pack-file shows that we now get basically perfect IO patterns for my "git
checkout" testcase, and while I'm not sure that's necessarily a test-case
that really deserves this kind of attention, it's certainly potentially
interesting.
To check the performance impact of this, though, you'd need to pack the
same repository two different ways - with this kind of sorting change and
without - and then test different cold-cache timings for things like "git
blame" etc that might care.
The timing of the commands itself could be done with either a pre-change
or post-change version of git, it's only the resulting order in the
pack-file that matters.
My very unscientific tests says that "git read-tree" is speed up by the
change (from 5.2s to 3.3s, so it's quite noticeable), but "git blame"
slows down (from 8.7s to 12.9s, so that's quite noticeable too). But as
Jakub pointed out, the cold-cache numbers do fluctuate a lot, and while
they were reasonably stable over runs, the "git blame" numbers in
particular probably depend a fair amount on whether the file is commonly
changed or not.
Anybody interested in trying to do something more scientific?
Linus
^ permalink raw reply
* Re: Some git performance measurements..
From: Nicolas Pitre @ 2007-11-30 2:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291812530.8458@woody.linux-foundation.org>
On Thu, 29 Nov 2007, Linus Torvalds wrote:
> On Fri, 30 Nov 2007, Jakub Narebski wrote:
> >
> > Isn't there a better way to do this sorting? What is needed here is
> > (stable) _bucket_ sort / _pigeonhole_ sort (or counting sort), which
> > is O(n); quicksort is perhaps simpler to use, but I'm not sure if
> > faster in this situation.
That particular sort takes under a second here with the Linux repo.
Pretty insignificant compared to the time required to repack.
> Actually, I doubt you need to do any sorting at all: what would be easiest
> would be to simply change "traverse_commit_list()" to use different lists
> for different object types, and just output them in type order (semi-sane
> order choice: commits first, then tags, then trees, and finally blobs).
Yes! That's what I thought initially, but since list-objects.c is
completely unknown territory to me, I sorted them in pack-object.c
instead, out of pure laziness.
Nicolas
^ permalink raw reply
* Re: Some git performance measurements..
From: Jakub Narebski @ 2007-11-30 2:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711291812530.8458@woody.linux-foundation.org>
On Fri, 30 Nov 2007, Linus Torvalds wrote:
>
> On Fri, 30 Nov 2007, Jakub Narebski wrote:
>>
>> Isn't there a better way to do this sorting? What is needed here is
>> (stable) _bucket_ sort / _pigeonhole_ sort (or counting sort), which
>> is O(n); quicksort is perhaps simpler to use, but I'm not sure if
>> faster in this situation.
>
> Actually, I doubt you need to do any sorting at all: what would be easiest
> would be to simply change "traverse_commit_list()" to use different lists
> for different object types, and just output them in type order (semi-sane
> order choice: commits first, then tags, then trees, and finally blobs).
>
> Ta-daa! All done! Magic! No sorting required, because all the objects got
> output in the right order without any extra sort phase!
Actually this algorithm has the fancy name of "pigeonhole sort" algorithm,
and is a subcase (special case) of bucket sort. Well, sort of, as there
is no final sorted list, only output in "sorted" order.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Linus Torvalds @ 2007-11-30 2:29 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Jan Hudec, git
In-Reply-To: <20071130005852.GA12224@coredump.intra.peff.net>
On Thu, 29 Nov 2007, Jeff King wrote:
>
> I thought Linus' point was that moving the subcommands was sufficient
> for dealing with the consistency issue (i.e., all scripts would move to
> "git foo" and only those people who really wanted to would put the
> dashed forms in their path).
Yes. I meant that we might as well keep all the git-xyz forms around, but
_only_ in the libexec directory (and make sure that the libexec directory
by default is *not* a binary directory), so that they'd normally not be
visible.
So then, people who want to use the old-fashioned git-xyz forms, because
they just really hate white-space or whatever, could choose to do one of
two things:
- either just change the default libexec directory to be the same as the
binary install directory, and have all the git-xyz things in the same
place they've always been.
- or just add $(gitlibexec) into their path.
but the default (which is what 99% of all people use) would be to not
show them. I also think that it makes sense to avoid wasting diskspace
with duplicate files, so in situations where you don't have hardlinks,
just don't install the git-xyz files at all by default (and again, maybe
we can have a option to the installer to do it for people who really are
very attached to the git-xyz format, and prefer to waste even a lot of
disk on it)
So I just think that the whole idiotic complaint that some people have
(that whole "git-<tab><tab>" shows "Display all 144 possibilities?" and
people are somehow using that as an argument that git is "complex") should
be something we strive to undo. I think the complaint is insane (because
the answer is "well, nobody forces you to _use_ all the power and scripts
we give you!"), but still, it's a complaint, so let's just assume the user
is right, and try to fix it.
So when you do "git-<tab><tab>" it should just beep at you and not show
anything at all by default. And when you do "git <tab><tab>", we should
make sure that the bash expansion (or zsh or whatever) shows a nice
collection of common plumbing, not soemthing really scary.
Linus
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Nicolas Pitre @ 2007-11-30 2:27 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <474F72B7.9000305@gmail.com>
On Thu, 29 Nov 2007, A Large Angry SCM wrote:
> Nicolas Pitre wrote:
> > On Thu, 29 Nov 2007, A Large Angry SCM wrote:
> >
> > > Again, there needs to remain support in the Makefile to install the
> > > "dashed"
> > > versions of the commands for those that want it; and be able to set
> > > gitexecdir=$(binder) without editing the Makefile.
> >
> > Well, if you want a "non standard" installation, maybe you just can edit a
> > line or two in the Makefile?
>
> Why do you object to a "install-dashed" Makefile target?
As long as it is not the default I don't object.
Nicolas
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: A Large Angry SCM @ 2007-11-30 2:23 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Junio C Hamano, Linus Torvalds, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <20071130015315.GA13369@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Nov 29, 2007 at 08:33:39PM -0500, Nicolas Pitre wrote:
>
>> So what you want is for the dashed hardlinks to exist _inside_ the
>> libexec directory, even if most people won't "see" them due to that
>> libexec directory not being in the shell path, right?
>>
>> If that is what you mean then I personally don't care at all.
>
> That is exactly what I mean.
And that also works for me when I set libexec=$(bindir).
^ permalink raw reply
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-11-30 2:21 UTC (permalink / raw)
To: Jakub Narebski, Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <finmvm$da8$1@ger.gmane.org>
On Fri, 30 Nov 2007, Jakub Narebski wrote:
>
> Isn't there a better way to do this sorting? What is needed here is
> (stable) _bucket_ sort / _pigeonhole_ sort (or counting sort), which
> is O(n); quicksort is perhaps simpler to use, but I'm not sure if
> faster in this situation.
Actually, I doubt you need to do any sorting at all: what would be easiest
would be to simply change "traverse_commit_list()" to use different lists
for different object types, and just output them in type order (semi-sane
order choice: commits first, then tags, then trees, and finally blobs).
Ta-daa! All done! Magic! No sorting required, because all the objects got
output in the right order without any extra sort phase!
Something like the appended (untested! lots of! exclamation marks!
Really!)
Linus
---
list-objects.c | 36 ++++++++++++++++++++++--------------
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index 4ef58e7..a046f37 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -49,7 +49,6 @@ static void process_blob(struct rev_info *revs,
*/
static void process_gitlink(struct rev_info *revs,
const unsigned char *sha1,
- struct object_array *p,
struct name_path *path,
const char *name)
{
@@ -58,7 +57,8 @@ static void process_gitlink(struct rev_info *revs,
static void process_tree(struct rev_info *revs,
struct tree *tree,
- struct object_array *p,
+ struct object_array *trees,
+ struct object_array *blobs,
struct name_path *path,
const char *name)
{
@@ -75,7 +75,7 @@ static void process_tree(struct rev_info *revs,
die("bad tree object %s", sha1_to_hex(obj->sha1));
obj->flags |= SEEN;
name = xstrdup(name);
- add_object(obj, p, path, name);
+ add_object(obj, trees, path, name);
me.up = path;
me.elem = name;
me.elem_len = strlen(name);
@@ -86,14 +86,14 @@ static void process_tree(struct rev_info *revs,
if (S_ISDIR(entry.mode))
process_tree(revs,
lookup_tree(entry.sha1),
- p, &me, entry.path);
+ trees, blobs, &me, entry.path);
else if (S_ISGITLINK(entry.mode))
process_gitlink(revs, entry.sha1,
- p, &me, entry.path);
+ &me, entry.path);
else
process_blob(revs,
lookup_blob(entry.sha1),
- p, &me, entry.path);
+ blobs, &me, entry.path);
}
free(tree->buffer);
tree->buffer = NULL;
@@ -138,10 +138,12 @@ void traverse_commit_list(struct rev_info *revs,
{
int i;
struct commit *commit;
- struct object_array objects = { 0, 0, NULL };
+ struct object_array tags = { 0, 0, NULL };
+ struct object_array trees = { 0, 0, NULL };
+ struct object_array blobs = { 0, 0, NULL };
while ((commit = get_revision(revs)) != NULL) {
- process_tree(revs, commit->tree, &objects, NULL, "");
+ process_tree(revs, commit->tree, &trees, &blobs, NULL, "");
show_commit(commit);
}
for (i = 0; i < revs->pending.nr; i++) {
@@ -152,25 +154,31 @@ void traverse_commit_list(struct rev_info *revs,
continue;
if (obj->type == OBJ_TAG) {
obj->flags |= SEEN;
- add_object_array(obj, name, &objects);
+ add_object_array(obj, name, &tags);
continue;
}
if (obj->type == OBJ_TREE) {
- process_tree(revs, (struct tree *)obj, &objects,
+ process_tree(revs, (struct tree *)obj, &trees, &blobs,
NULL, name);
continue;
}
if (obj->type == OBJ_BLOB) {
- process_blob(revs, (struct blob *)obj, &objects,
+ process_blob(revs, (struct blob *)obj, &blobs,
NULL, name);
continue;
}
die("unknown pending object %s (%s)",
sha1_to_hex(obj->sha1), name);
}
- for (i = 0; i < objects.nr; i++)
- show_object(&objects.objects[i]);
- free(objects.objects);
+ for (i = 0; i < tags.nr; i++)
+ show_object(&tags.objects[i]);
+ for (i = 0; i < trees.nr; i++)
+ show_object(&trees.objects[i]);
+ for (i = 0; i < blobs.nr; i++)
+ show_object(&blobs.objects[i]);
+ free(tags.objects);
+ free(trees.objects);
+ free(blobs.objects);
if (revs->pending.nr) {
free(revs->pending.objects);
revs->pending.nr = 0;
^ permalink raw reply related
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: A Large Angry SCM @ 2007-11-30 2:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Linus Torvalds, Jeff King, Johannes Schindelin,
Nguyen Thai Ngoc Duy, Jan Hudec, git
In-Reply-To: <alpine.LFD.0.99999.0711291959510.9605@xanadu.home>
Nicolas Pitre wrote:
> On Thu, 29 Nov 2007, A Large Angry SCM wrote:
>
>> Again, there needs to remain support in the Makefile to install the "dashed"
>> versions of the commands for those that want it; and be able to set
>> gitexecdir=$(binder) without editing the Makefile.
>
> Well, if you want a "non standard" installation, maybe you just can edit
> a line or two in the Makefile?
Why do you object to a "install-dashed" Makefile target?
^ 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