* StGit hooks
From: Karl Hasselström @ 2007-11-28 10:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <20071128093403.GB12977@diana.vm.bytemark.co.uk>
On 2007-11-28 10:34:03 +0100, Karl Hasselström wrote:
> It would also be convenient with a post-commit hook that turns new
> commits into patches automatically. And gives "git commit --amend"
> the semantics of "stg refresh".
Hmm, so what I'd want for this is a hook that gets called every time a
branch ref is updated (after the update), preferably with the ref name
and its old and new values as arguments (but as long as I get the ref
name, I guess I could just ask git for the sha1s?). Is there such a
hook? I poked around a bit, but couldn't find any.
For extra points, I'd like to know what operation caused the ref
update. I'd want to do different things depending on whether the user
did a "commit" or "commit --amend", for example. I could use a
heuristic, but I'd rather not if there's a way to know for sure. (Hmm.
It looks like the reflog messages could be used here. Are they stable
enough?)
Also, if StGit is to set up hooks automatically (commit hooks,
pre-rebase hooks, whatever), it'd be nice to not have to worry about
overwriting any existing hooks the user might have. But git currently
allows only one hook script per hook, right?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Rollback of git commands
From: Jon Smirl @ 2007-11-28 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmyszb39s.fsf@gitster.siamese.dyndns.org>
On 11/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > Could a rollback log be implemented in git? It would make things way
> > easier when you screw something up. You'd only roll back things that
> > impacted the object store, not things like checkout.
>
> The object store is append only, and if you disregard SHA-1 collisions,
> I do not think there is much you can gain from being able to roll back
> only object store.
>
> For example, you would want to be able to roll back where your 'master'
> branch was pointing at before you started that botched operation. That
> is not in the object store at all (we have reflogs for that).
>
> Another example, you might have done quite an elaborate interactive add
> to stage only some changes to a path, but then accidentally said "git
> add" that path to stage the whole thing. You may say "oops, that state
> was only in the index and now it is lost." The blob that records the
> staged content _DOES_ exist in the object store in such a case so it is
> not lost --- there is nothing to roll back. What you lost is a pointer
> into the object store (we do not have anything like reflog for
> individual index entry --- not that I would suggest adding one).
>
> Creating a blob that records all of .git/config, output from
> for-each-ref, output from "symbolic-ref HEAD" and output from ls-files
> -s every time you run _any_ git operation, and restore the state when
> you want to, would conceptually work, as you suggest, but I am not sure
> how practical it would be, performancewise, spacewise, and
> semanticswise.
I'm only looking for a command that would rollback the effect of
changes to the object store (you don't have to remove the objects).
Losing complex staging would be ok since it can be recreated.
Let's take my recent problem as an example. I typed 'git rebase
linus/master' instead of 'stg rebase linus/master'. Then I typed 'stg
repair'. The repair failed and left me in a mess. Both of these are
easy to rollback except for the fact that stg has stored a bunch of
state in .git/*.
After doing the commands I located my last commit before the rebase
and edited master back to it. But my system was still messed up since
moving master got me out of sync with the state stg stored in .git/*.
The 'stg repair' command had changed the stored state.
Instead lets store the contents of .git/* (minus the data itself) as
objects. Then commit a new object after each command. Now rollback can
be accomplished by walking back this chain off commits. Rollback would
wipe out any staging, and effectively reset the working tree to match
the point rolled back to. I don't think we need to capture the entire
state of 'ls-file -s' to achieve this.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Junio C Hamano @ 2007-11-28 1:19 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071127211730.GA11861@midwinter.com>
How does this interact with the "pretend to have fetched back
immediately" supported by modern git-push?
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Junio C Hamano @ 2007-11-28 1:13 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Nguyễn Thái Ngoc Duy, git
In-Reply-To: <20071128000731.GD9174@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
>>
>> > Both configure and make-only ways should work now
>>
>> I thought your plan was to put the non-porcelain into the libexecdir only?
>
> I had the impression that deprecating the dash notation for /all/ use was
> approved some time ago. Though I don't want to search through the list
> archives this late in the night to check it.
Yes. Moving the dash-form commands out of end user's PATH was something
distros and users have been allowed to do since forever, and strictly
speaking, using dash form from the command line was already deprecated
at that point.
If your script runs git-foo without first asking "git --exec-path" and
prepending it to the path, your script would not find git-foo if the
installation uses gitexecdir that is not on the usual $PATH, either.
I essentially just said that your patch is unnecessary, but at the same
time, your patch does not go far enough. As Nico earlier pointed out,
we ship a sample rpm spec, which would also need to be updated. We do
not ship a sample debian/rules anymore, thank $DEITY ;-)
Also, because we do not remove existing files from the installation
target directory when we do "make install", the commit log message
should carry a big fat warning that says "remove old installation of git
from your $(bindir) when you try this," for people who build from the
source, and we need to repeat the deprecation notice in bold red letters
in the Release Notes for perhaps git 1.6.0.
In case somebody is thinking about 36e5e70e0f40 (Start deprecating
"git-command" in favor of "git command"), that is a somewhat different
issue. What Linus suggested is not installing git-foo link for built-in
commands _anywhere_ on the filesystem. Not just "out of user's PATH".
That is not deprecating dash form but removing the support for it. We
need to give ample time for users to adjust to such a change.
^ permalink raw reply
* Re: Rollback of git commands
From: Junio C Hamano @ 2007-11-28 0:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711271523p3be94010jac9c79e6b95f010d@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> Could a rollback log be implemented in git? It would make things way
> easier when you screw something up. You'd only roll back things that
> impacted the object store, not things like checkout.
The object store is append only, and if you disregard SHA-1 collisions,
I do not think there is much you can gain from being able to roll back
only object store.
For example, you would want to be able to roll back where your 'master'
branch was pointing at before you started that botched operation. That
is not in the object store at all (we have reflogs for that).
Another example, you might have done quite an elaborate interactive add
to stage only some changes to a path, but then accidentally said "git
add" that path to stage the whole thing. You may say "oops, that state
was only in the index and now it is lost." The blob that records the
staged content _DOES_ exist in the object store in such a case so it is
not lost --- there is nothing to roll back. What you lost is a pointer
into the object store (we do not have anything like reflog for
individual index entry --- not that I would suggest adding one).
Creating a blob that records all of .git/config, output from
for-each-ref, output from "symbolic-ref HEAD" and output from ls-files
-s every time you run _any_ git operation, and restore the state when
you want to, would conceptually work, as you suggest, but I am not sure
how practical it would be, performancewise, spacewise, and
semanticswise.
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Junio C Hamano @ 2007-11-28 0:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?
The pre-rebase hook has been there since early Feb 2006.
^ permalink raw reply
* Re: [PATCH] Teach 'git pull' the '--rebase' option
From: Junio C Hamano @ 2007-11-28 0:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0710261047450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
> I do not want to go into _that_ many details here, since the place to look
> for it is git-rebase.txt. Probably I should have done that in the first
> place.
>
> So how about this instead:
>
> \--rebase::
> Instead of a merge, perform a rebase after fetching.
> *NOTE:* This is a potentially _dangerous_ mode of operation.
> It rewrites history, which does not bode well when you
> published that history already. Do _not_ use this option
> unless you have read gitlink:git-rebase[1] carefully.
>
> Hmm?
Okay.
^ permalink raw reply
* Re: [PATCH] Move all dashed form git commands to libexecdir
From: Jan Hudec @ 2007-11-28 0:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0711271617350.27959@racer.site>
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:
>
> > Both configure and make-only ways should work now
>
> I thought your plan was to put the non-porcelain into the libexecdir only?
I had the impression that deprecating the dash notation for /all/ use was
approved some time ago. Though I don't want to search through the list
archives this late in the night to check it.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)
From: Jakub Narebski @ 2007-11-27 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711271136050.27959@racer.site>
Johannes Schindelin wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>
>> Actually I might revisit this XUL concept using an HTTP server and AJAX.
>> I could actually link the damn HTTP server against libgit.a (Junio will
>> hate me). If the server dies XUL can notice it and simply restart it.
>
> But if you can restart the HTTP server via XUL, you can start other git
> programs directly.
>
> What you'd have to do is (urgh) write a wrapper via start_command()
> which would recognize that the second process die()d.
>
> All in all, I think if you want to switch from Tcl/Tk to another language
> for git-gui, for the sake of attracting more developers, it might be wiser
> to go Java than XUL.
Wont we get with the same problems as egit/jgit?
----
This is proposed set of questions for git-gui mini survey...
1. What language and what toolkit should git-gui be written in?
(single choice)
a. Tcl/Tk (current implementation)
b. C++/Qt
c. C/GTK+
d. Python (native)
e. Python/PyQt
f. Python/PyGTK
g. Ruby
h. Java/Swing
i. Java/SWT
j. XUL+JavaScript+CSS/XULRunner
k. other
l. no opinion
2. If you have chosen "other" in question above, what language and
toolkit should it be? C/XForms? C#/Mono? C/wxWidgets? XAML+Silverlight?
GTK2-Perl? C/OpenGL? ;-)
3. Do you contribute to git-gui?
Yes/No
4. If git-gui would use other language/toolkit, would you contribute?
Yes/No
5. What languages and what toolkits you are proficient with (to send
patches)?
(multiple choice)
a. Tcl/Tk (current implementation)
b. C++/Qt
c. C/GTK+
d. Python (native)
e. Python/PyQt
f. Python/PyGTK
g. Ruby
h. Java/Swing
i. Java/SWT
j. XUL+JavaScript+CSS/XULRunner
k. other
l. N/A
6. What other?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: If you would write git from scratch now, what would you change?
From: Jan Hudec @ 2007-11-27 23:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: Andy Parkins, git
In-Reply-To: <e5bfff550711270515t2a7bc80ege92442c30bf6aebe@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On Tue, Nov 27, 2007 at 14:15:21 +0100, Marco Costalba wrote:
> On Nov 27, 2007 9:45 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> > Marco Costalba wrote:
> >
> > > But...wait...Qt would require...(I'm scared to say!)... that awful,
> > > painful, hopeless thing called C++. Probably you didn't mean what you
> > > said ;-)
> >
> > Actually although I like C++, that's not the reason, the reason is that Qt
> > is a significantly (IMHO) better toolkit than Tk. It's more cross platform
> > and looks a lot nicer. The fact that it's C++ is neither here nor there.
> >
>
> Actually there exist a Python bindings for Qt if you prefer.
I tried to write something in them and got a bit burned. Qt has it's
idea of memory management (delete children with parent) and the bindings
don't protect from accessing pointers to objects deleted this way, which can
cause rather hard to debug crashes.
Gtk seems to be much better for use from various scripting languages.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Jakub Narebski @ 2007-11-27 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711271127440.27959@racer.site>
Johannes Schindelin wrote:
> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:
>> I think this should be prefixed by fast-import patch to teach it
>> something like "encoding N" as a subcommand of commit, so that you can
>> feed data in a non UTF-8 encoding and get it to include the proper
>> encoding header in the commit object it creates. That way a pipeline
>> like the above really does create a duplicate repository, with the same
>> commit SHA-1s, even if the commits weren't in UTF-8.
>
> IMHO it's not worth that hassle. People who want to use fast-import
> usually want something fast which works, and not bother with specifying
> encodings.
Well, when I am converting some repository which uses legacy encoding
(not utf-8), I'd like to use this git feature of specifying encoding;
actually, to be generic, it could be any header which would be added to
all created commit objects.
Yes, I could reencode commit messages...
P.S. One nice use of proposed (at one time) 'note' header would be to
save revision identifier from the version control system you import
(CVS revision number, Subversion sequential revision number, etc.).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Rollback of git commands
From: Jon Smirl @ 2007-11-27 23:23 UTC (permalink / raw)
To: Git Mailing List
Could a rollback log be implemented in git? It would make things way
easier when you screw something up.You'd only roll back things that
impacted the object store, not things like checkout.
stg is also starting to store significant state in the .git directory.
It may be better to move this state into a git object. That would
allow the state history to be tracked and rollback be implemented.
The same logic can be applied to moving all tracking information in
the .git directory into objects. You then just need to track a single
SHA1 pointing to the .git config info in the object db.
Rollback in the object store is simple, just move the SHA1 in the
config files back to where it was before the action was done. What we
are missing is a way to rollback the config files.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-11-27 23:24 UTC (permalink / raw)
To: gitster; +Cc: git, Robin Rosenberg
In-Reply-To: <7vmyt0edso.fsf@gitster.siamese.dyndns.org>
This patch makes it possible to drag files and directories from
a graphical browser and drop them onto a shell and feed them
to common git operations without editing away the path to the
root of the work tree.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
setup.c | 19 +++++++++++++++++
t/t3904-abspatharg.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+), 0 deletions(-)
create mode 100755 t/t3904-abspatharg.sh
diff --git a/setup.c b/setup.c
index f512ea0..ffc30bf 100644
--- a/setup.c
+++ b/setup.c
@@ -7,6 +7,25 @@ static int inside_work_tree = -1;
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
+ const char *work_tree = get_git_work_tree();
+ if (is_absolute_path(path) && work_tree) {
+ int n = strlen(work_tree);
+ if (!strncmp(path, work_tree, n) && (path[n] == '/' || !path[n])) {
+ if (path[n])
+ path += n + 1;
+ else
+ path += n;
+
+ if (prefix && !strncmp(path, prefix, len - 1)) {
+ if (path[len - 1] == '/')
+ path += len;
+ else
+ if (!path[len - 1])
+ path += len - 1;
+ }
+ }
+ }
+
for (;;) {
char c;
if (*path != '.')
diff --git a/t/t3904-abspatharg.sh b/t/t3904-abspatharg.sh
new file mode 100755
index 0000000..cd4a52e
--- /dev/null
+++ b/t/t3904-abspatharg.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+#
+# Copyright (C) 2007 Robin Rosenberg
+#
+
+test_description='Test absolute filename arguments to various git
+commands. Absolute arguments pointing to a location within the git
+work tree should behave the same as relative arguments. '
+
+. ./test-lib.sh
+
+test_expect_success 'add files using absolute path names' '
+echo a >afile &&
+echo b >bfile &&
+git-add afile &&
+git-add "$(pwd)/bfile" &&
+test "afile bfile" = "$(echo $(git ls-files))"
+mkdir x &&
+cd x &&
+echo c >cfile &&
+echo d >dfile &&
+git-add cfile &&
+git-add "$(pwd)" &&
+cd .. &&
+test "afile bfile x/cfile x/dfile" = "$(echo $(git ls-files))" &&
+git ls-files x >f1 &&
+git ls-files "$(pwd)/x" >f2 &&
+diff f1 f2
+'
+
+test_expect_success 'commit using absolute path names' '
+git commit -m "foo" &&
+echo aa >>bfile &&
+git commit -m "bb" "$(pwd)/bfile"
+'
+
+test_expect_success 'log using absolute path names' '
+git log afile >f1.txt &&
+git log "$(pwd)/afile" >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'blame using absolute path names' '
+git blame afile >f1.txt &&
+git blame "$(pwd)/afile" >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_expect_success 'diff using absolute path names' '
+git diff HEAD^ -- "$(pwd)/afile" >f1.txt &&
+git diff HEAD^ -- afile >f2.txt &&
+diff f1.txt f2.txt
+'
+
+test_done
--
1.5.3.5.1.gb2df9
^ permalink raw reply related
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-11-27 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyt0edso.fsf@gitster.siamese.dyndns.org>
tisdag 27 november 2007 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
[...]
> > const char *orig = path;
>
> Decl after statement.
Stupid C..
>
> I do not think there is fundamental reason to object to this change, as
> long as the prefixing is done to the path that is trying to name a path
> in the working tree.
>
> Also some codepath that does not require any work tree may want to call
> prefix_path(). I do not know what would happen in such a case.
ok, I'll add a test for whether we have a work tree.
> Although I didn't look at all the callers, I think the caller from
> config.c is not talking about a path in the work tree, and not all users
> of config.c need to have work-tree.
Oh dear. That wasn't on master when I looked. That one seems to be the only "other"
use and it is wrapped inside an if (!absolute_path()) tests so my magic does not conflict
there.
-- robin
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-11-27 23:12 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com>
On 11/27/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair" put all my patches are still empty.
>
> What's the easiest way to recover?
I recovered, which wasn't too bad since I had exported the stack about
an hour earlier. I played around trying to recover the tree for a
while and then gave up and whacked it. I used my export and then I
extracted the last hours worth of changes from the old tree.
As Jakub pointed out to me "git reset --hard $(cat
.git/patches/<branch>/orig-base)" would have recovered from the rebase
command. But I had already typed 'stg repair' which compounded the
mess.
> Can we add a check in "git rebase" so that it will refuse to run if
> stg is active?
This is way too easy to do. One simple mistype of 'git' for 'stg' and
you're in a mess.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Robin Rosenberg @ 2007-11-27 23:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <474BD90C.5020102@viscovery.net>
tisdag 27 november 2007 skrev Johannes Sixt:
> Robin Rosenberg schrieb:
> > +test_expect_success 'add files using absolute path names' '
> > +echo a >afile &&
> > +echo b >bfile &&
> > +git-add afile &&
> > +git-add $(pwd)/bfile &&
>
> Please use "$(pwd)/bfile" (d-quotes) throughout. Otherwise the test would
> fail if conducted in a directory with spaces.
AFAIK, None of the tests works in directories with spaces. But I'll fix it, just in case, so
noone can blame /me/ for the tests breaking in /my home/. I cannot verify it because
the testing infrastructure breaks before the actual tests start executing.
-- robin
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jakub Narebski @ 2007-11-27 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <9e4733910711271417l32ed9a77p9915aa34a780665b@mail.gmail.com>
Jon Smirl wrote:
> My fingers are too trained in doing "git rebase linus/master" instead
> of "stg rebase linus/master". This has resulting in me losing my patch
> stack again. I updated stg to the current version and tried "stg
> repair" put all my patches are still empty.
>
> What's the easiest way to recover?
git reset --hard $(cat .git/patches/<branch>/orig-base)
or perhaps "git reset --hard ORIG_HEAD"; with new rebase working on
detached head "git reset --hard @{1}".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* stgit: lost all my patches again
From: Jon Smirl @ 2007-11-27 22:17 UTC (permalink / raw)
To: Git Mailing List
My fingers are too trained in doing "git rebase linus/master" instead
of "stg rebase linus/master". This has resulting in me losing my patch
stack again. I updated stg to the current version and tried "stg
repair" put all my patches are still empty.
What's the easiest way to recover?
Can we add a check in "git rebase" so that it will refuse to run if
stg is active?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] git-gui: Improve the application icon on Windows.
From: Steffen Prohaska @ 2007-11-27 22:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Shawn O. Pearce
In-Reply-To: <200711272147.22511.johannes.sixt@telecom.at>
On Nov 27, 2007, at 9:47 PM, Johannes Sixt wrote:
> On Tuesday 27 November 2007 16:40, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 27 Nov 2007, Johannes Sixt wrote:
>>> Previusly, there was only a 16x16 image, which looked very
>>> distorted.
>>> Here we add a 32x32 version, and also make the image sharper.
>>>
>>> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
>>> ---
>>> I'm by far not an artist, but improving the previous version
>>> was not difficult at all. ;)
>>
>> Why did you not just use the svg contained in msysGit?
>
> Because I cannot find one?
>
> $ GIT_PAGER=cat git grep -i svg 4msysgit/devel
> 4msysgit/devel:attr.c: * attributes, e.g. "*.svg
> merge=special-...
http://msysgit.googlecode.com/files/gitlogo.svg
Steffen
^ permalink raw reply
* Re: [PATCH] Do not generate full commit log message if it not going to be used
From: Alex Riesen @ 2007-11-27 21:47 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Junio C Hamano, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <20071127214425.GA3156@steel.home>
Alex Riesen, Tue, Nov 27, 2007 22:44:25 +0100:
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -367,6 +367,30 @@ static int prepare_log_message(const char *index_file, const char *prefix)
>
> strbuf_release(&sb);
>
> + if (no_edit) {
> + static const char *argv[] = { NULL, "HEAD", NULL };
> + struct rev_info rev;
> + unsigned char sha1[40];
> + int is_initial;
is_initial is left over from "development process". Well, from
stealing out of wt-status.c
^ permalink raw reply
* [PATCH] Do not generate full commit log message if it not going to be used
From: Alex Riesen @ 2007-11-27 21:44 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Junio C Hamano, Johannes Schindelin,
Kristian Høgsberg
In-Reply-To: <81b0412b0711271018m6419b076n269a0175494fac84@mail.gmail.com>
Like when it is already specified through -C, -F or -m to git-commit.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Tue, Nov 27, 2007 19:18:56 +0100:
> On 27/11/2007, Junio C Hamano <gitster@pobox.com> wrote:
> > ... When no_edit is in effect, I think these two places can
> > be replaced with an equivalent of "diff-index --cached HEAD --" (which
> > should not hit the work tree at all) to see if there is anything to be
> > committed. For initial commit the check would obviously be "is the
> > index empty?" instead.
>
> This is of course very useful optimization, and will speed up things
> everywhere (and especially here).
Could not stop myself. Hopefully didn't beat anyone to it :)
Almost all code shamelessly stolen from builtin-diff-index.c.
Builds, runs, passes all the tests. That !active_nr is
micro-optimization, but a nice one: clearly don't reread.
Preprocessor trickery in DIFF_OPT_* macros is disgusting, it breaks
Vim word completion and trying to use many flags in one expression
looks just ugly. What was wrong is inline functions?
builtin-commit.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index a35881e..8167ce4 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -367,6 +367,30 @@ static int prepare_log_message(const char *index_file, const char *prefix)
strbuf_release(&sb);
+ if (no_edit) {
+ static const char *argv[] = { NULL, "HEAD", NULL };
+ struct rev_info rev;
+ unsigned char sha1[40];
+ int is_initial;
+
+ fclose(fp);
+
+ if (!active_nr && read_cache() < 0)
+ die("Cannot read index");
+
+ if (get_sha1("HEAD", sha1) != 0)
+ return !!active_nr;
+
+ init_revisions(&rev, "");
+ rev.abbrev = 0;
+ (void)setup_revisions(2, argv, &rev, NULL);
+ DIFF_OPT_SET(&rev.diffopt, QUIET);
+ DIFF_OPT_SET(&rev.diffopt, EXIT_WITH_STATUS);
+ (void)run_diff_index(&rev, 1 /* cached */);
+
+ return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
+ }
+
if (in_merge && !no_edit)
fprintf(fp,
"#\n"
--
1.5.3.6.1006.g08f2
^ permalink raw reply related
* Re: [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-27 21:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fii1od$d38$1@ger.gmane.org>
On Nov 27, 2007, at 1:21 PM, Jakub Narebski wrote:
>> +The hook may optionally choose to update the ref on its own, e.g.,
>> +if it needs to modify incoming revisions in some way. If it updates
>> +the ref, it should exit with a status of 100.
>
> Why 100, and not for example 127, 128 or -1?
Because those seemed much more likely to be used by existing hook
scripts to denote an error condition, and I wanted to reduce the
chance that this would break existing scripts.
-Steve
^ permalink raw reply
* Re: [PATCH] Allow update hooks to update refs on their own
From: Jakub Narebski @ 2007-11-27 21:21 UTC (permalink / raw)
To: git
In-Reply-To: <20071127211730.GA11861@midwinter.com>
Steven Grimm wrote:
> +The hook may optionally choose to update the ref on its own, e.g.,
> +if it needs to modify incoming revisions in some way. If it updates
> +the ref, it should exit with a status of 100.
Why 100, and not for example 127, 128 or -1?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Allow update hooks to update refs on their own
From: Steven Grimm @ 2007-11-27 21:17 UTC (permalink / raw)
To: git
This is useful in cases where a hook needs to modify an incoming commit
in some way, e.g., adding an annotation to the commit message, noting
the location of output from a profiling tool, or committing to an svn
repository using git-svn.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
I did this to support a bridge between svn and git. The idea is
that the people who use git can do "git push" to publish their
changes, and if they've pushed to certain branches, the changes
will get transparently committed to svn using git-svn.
The git users therefore can operate in a totally git-centric
environment. (This is a step toward transitioning my company
away from svn entirely: get people used to a native git environment
with no direct svn interactions.)
One problem is that git-svn wants to rewrite history to add its
git-svn-id: lines, which means that when the update hook returns
after doing the git-svn dcommit, HEAD is already pointed at the
updated commit. Without this change or something like it,
receive-pack bombs out because HEAD has moved, and the push
appears to fail. This patch addresses that particular problem.
There are other issues with the history rewriting, but this
change is hopefully useful on its own for cases like the ones
listed in the commit message.
Documentation/git-receive-pack.txt | 8 +++-
receive-pack.c | 68 +++++++++++++++++++++++-------------
2 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index 2633d94..115ae97 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -74,8 +74,12 @@ Note that the hook is called before the refname is updated,
so either sha1-old is 0\{40} (meaning there is no such ref yet),
or it should match what is recorded in refname.
-The hook should exit with non-zero status if it wants to disallow
-updating the named ref. Otherwise it should exit with zero.
+The hook may optionally choose to update the ref on its own, e.g.,
+if it needs to modify incoming revisions in some way. If it updates
+the ref, it should exit with a status of 100. The hook should exit
+with a status between 1 and 99 if it wants to disallow updating the
+named ref. Otherwise it should exit with zero, and the ref will be
+updated automatically.
Successful execution (a zero exit status) of this hook does not
ensure the ref will actually be updated, it is only a prerequisite.
diff --git a/receive-pack.c b/receive-pack.c
index 38e35c0..19162ec 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -18,6 +18,9 @@ static int report_status;
static char capabilities[] = " report-status delete-refs ";
static int capabilities_sent;
+/* Update hook exit code: hook has updated ref on its own */
+#define EXIT_CODE_REF_UPDATED 100
+
static int receive_pack_config(const char *var, const char *value)
{
if (strcmp(var, "receive.denynonfastforwards") == 0) {
@@ -70,8 +73,11 @@ static struct command *commands;
static const char pre_receive_hook[] = "hooks/pre-receive";
static const char post_receive_hook[] = "hooks/post-receive";
-static int hook_status(int code, const char *hook_name)
+static int hook_status(int code, const char *hook_name, int ok_start)
{
+ if (ok_start && -code >= ok_start)
+ return -code;
+
switch (code) {
case 0:
return 0;
@@ -121,7 +127,7 @@ static int run_hook(const char *hook_name)
code = start_command(&proc);
if (code)
- return hook_status(code, hook_name);
+ return hook_status(code, hook_name, 0);
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string) {
size_t n = snprintf(buf, sizeof(buf), "%s %s %s\n",
@@ -132,7 +138,7 @@ static int run_hook(const char *hook_name)
break;
}
}
- return hook_status(finish_command(&proc), hook_name);
+ return hook_status(finish_command(&proc), hook_name, 0);
}
static int run_update_hook(struct command *cmd)
@@ -155,7 +161,8 @@ static int run_update_hook(struct command *cmd)
proc.no_stdin = 1;
proc.stdout_to_stderr = 1;
- return hook_status(run_command(&proc), update_hook);
+ return hook_status(run_command(&proc), update_hook,
+ EXIT_CODE_REF_UPDATED);
}
static const char *update(struct command *cmd)
@@ -194,32 +201,45 @@ static const char *update(struct command *cmd)
return "non-fast forward";
}
}
- if (run_update_hook(cmd)) {
- error("hook declined to update %s", name);
- return "hook declined";
- }
-
- if (is_null_sha1(new_sha1)) {
- if (delete_ref(name, old_sha1)) {
- error("failed to delete %s", name);
- return "failed to delete";
+ switch (run_update_hook(cmd)) {
+ case 0:
+ if (is_null_sha1(new_sha1)) {
+ if (delete_ref(name, old_sha1)) {
+ error("failed to delete %s", name);
+ return "failed to delete";
+ }
+ fprintf(stderr, "%s: %s -> deleted\n", name,
+ sha1_to_hex(old_sha1));
}
- fprintf(stderr, "%s: %s -> deleted\n", name,
- sha1_to_hex(old_sha1));
- return NULL; /* good */
- }
- else {
- lock = lock_any_ref_for_update(name, old_sha1, 0);
- if (!lock) {
- error("failed to lock %s", name);
- return "failed to lock";
+ else {
+ lock = lock_any_ref_for_update(name, old_sha1, 0);
+ if (!lock) {
+ error("failed to lock %s", name);
+ return "failed to lock";
+ }
+ if (write_ref_sha1(lock, new_sha1, "push")) {
+ return "failed to write"; /* error() already called */
+ }
+ fprintf(stderr, "%s: %s -> %s\n", name,
+ sha1_to_hex(old_sha1), sha1_to_hex(new_sha1));
}
- if (write_ref_sha1(lock, new_sha1, "push")) {
- return "failed to write"; /* error() already called */
+ return NULL; /* good */
+
+ case EXIT_CODE_REF_UPDATED:
+ /* hook has taken care of updating ref, which means it
+ might be a different revision than we think. */
+ if (! resolve_ref(name, new_sha1, 1, NULL)) {
+ error("can't resolve ref %s after hook updated it",
+ name);
+ return "ref not resolvable";
}
fprintf(stderr, "%s: %s -> %s\n", name,
sha1_to_hex(old_sha1), sha1_to_hex(new_sha1));
return NULL; /* good */
+
+ default:
+ error("hook declined to update %s", name);
+ return "hook declined";
}
}
--
1.5.3.6.862.g7acd00-dirty
^ permalink raw reply related
* Re: Removing old data without disturbing tree?
From: David Brown @ 2007-11-27 21:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git
In-Reply-To: <alpine.LFD.0.99999.0711271459520.9605@xanadu.home>
On Tue, Nov 27, 2007 at 03:06:45PM -0500, Nicolas Pitre wrote:
>On Tue, 27 Nov 2007, David Brown wrote:
>
>> An upstream tree I'm mirroring with git-p4 has decided to start checking
>> in large tarballs (150MB) periodically. It's basically a prebuild version
>> of some firmware needed to run the rest of the software.
>>
>> Git doesn't seem to have any problem with these tarballs (and is using a
>> lot less space than P4), but I have a feeling we might start running into
>> problems when things get real big. Does anyone have experience with packs
>> growing beyong several GB?
>
>It should just work. It was tested with artificial data sets but that's
>about it.
>
>Now if those tarballs are actually multiple revisions of the same
>package, you might consider storing them uncompressed and let Git delta
>compress them against each other which will produce an even more
>significant space saving.
I did manage to talk them into leaving them uncompressed. But, they are
large, and don't seem to delta compress all that well. Maybe as more come,
the compression will be better.
I guess this will be a good test case... It will probably take months or
even a year or so for the repo to get up to several GB.
David
^ 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