* [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] 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
* 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
* 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: 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
* 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: 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: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
* [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
* 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
* 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
* 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
* [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: [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
* 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: 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: 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: [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: [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: 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
* 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: Rebase/cherry-picking idea
From: Wincent Colaiuta @ 2007-11-28 10:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <7v1waa7lcv.fsf@gitster.siamese.dyndns.org>
El 28/11/2007, a las 10:47, Junio C Hamano escribió:
> I think _GIT_FOO vs GIT_FOO is an important detail, not at all a
> bikeshed color, to make things consistent. "export VAR=VAL" also is a
> valid concern (you said in a separate message you only know about
> bash,
> and I later asked people if they use shells that get affected with it
> but we happily run otherwise. I personally do not think the latter
> is a
> problem, but since somebody already raised it as a potential issue, it
> gave us a good chance to hear from people on minority platforms, if
> only
> to build confidence in us to use that POSIX form.
I'm still a little concerned that nobody commented when I pointed out
that export VAR=VAL is used elsewhere in Git, especially in git-
clone.sh, which is very commonly-used porcelain. Is it a problem?
> If these details (I do not think the overridability is a minor detail,
> though) look like bikeshedding to you, that is somewhat sad. You seem
> to be very capable of producing usable code, but these details
> (consistency and flexibility) matter for longer term stability, and I
> would really want to see capable people pay attention to such details,
> especially I sometimes fail to do so myself.
I think the *key* difference between our patches was the refactoring
that you did (extracting into a separate function and at the same time
making the entire message customizable rather than just the end). I
think that's easily explained by the fact that as a new contributor I
am pretty much always going to err on the side of the most minimal
change possible (minimum number of lines, and changes kept as local as
possible), even if it isn't the best or most well-engineered one. Your
patch is more invasive, but it's better too, and I think it's more
invasive precisely because your knowledge of the codebase and your
track record gives you the confidence to make non-minimal changes when
you think they're better. With time I imagine I'll evolve away from
such defensive, minimal patches as the one I sent.
Cheers,
Wincent
^ permalink raw reply
* Re: Rebase/cherry-picking idea
From: Junio C Hamano @ 2007-11-28 9:47 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Johannes Sixt, Benoit Sigoure,
Git Mailing List
In-Reply-To: <50645A3B-C5F0-4A99-A2B8-AD9251024244@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> The problem in this case was that my patch didn't receive any
> meaningful feedback (ie. suggestions for improvement), only a lot of
> bikeshed stuff about whether the environment variable should have an
> underscore prefix or not, whether or not I should use "export FOO=..."
> or not etc. So I didn't know what was necessary in order to get it
> accepted.
I do not think that is the case.
I think _GIT_FOO vs GIT_FOO is an important detail, not at all a
bikeshed color, to make things consistent. "export VAR=VAL" also is a
valid concern (you said in a separate message you only know about bash,
and I later asked people if they use shells that get affected with it
but we happily run otherwise. I personally do not think the latter is a
problem, but since somebody already raised it as a potential issue, it
gave us a good chance to hear from people on minority platforms, if only
to build confidence in us to use that POSIX form.
Maybe it is just me, but I think my suggestion to replace not just "git
commit" part but also "git add" part is also an important design issue.
In any case, after a discussion, sending out a readily applyable patch
would help to make sure we reached a reasonable consensus; it makes it
easier for other people to try out your proposed draft of the consensus
without waiting for me or anybody else and give positive feedback.
The difference between the variant I posted and your revised one I see
are:
* As discussed, we have precedence like GITHEAD_* and GIT_REFLOG_ACTION
that are used purely for inter-tool communication without the leading
underscore, so I followed them for consistency.
* The part of the message that is overridable is made wider; that way,
we can later choose to have "git rebase --continue" do the final "git
add -u" step, just like we made "git rebase --skip" to run "git reset
--hard", without changing revert/cherry-pick,as I explained in the
comment to my patch.
* I made the help-message creation into a separate function. This is
just a minor detail, but I think it is good for readability.
* I am setting and exporting the help environment near the beginning of
rebase--interactive just once; again I think this is more readable.
But other than that, the basic idea is the same and is all yours.
If these details (I do not think the overridability is a minor detail,
though) look like bikeshedding to you, that is somewhat sad. You seem
to be very capable of producing usable code, but these details
(consistency and flexibility) matter for longer term stability, and I
would really want to see capable people pay attention to such details,
especially I sometimes fail to do so myself.
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-11-28 9:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711271512g790364e0ka4839b2be9fd4935@mail.gmail.com>
On 2007-11-27 18:12:49 -0500, Jon Smirl wrote:
> 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.
Unless it has a bug, the only thing "stg repair" will do is
* create some new applied patches out of commits reachable from HEAD
* mark some applied patches as unapplied
* mark some unapplied patches as applied
in order to make sure that the applied patches are precisely those
that are reachable from HEAD, and that the sequence of applied patches
doesn't have "holes" in it (that is, commits that aren't patches).
In particular, it should not ever modify your existing patches, and it
will never move the branch head. Just resetting the branch head to
wherever you want it to be (and then running repair again) should fix
literally all problems.
> This is way too easy to do. One simple mistype of 'git' for 'stg'
> and you're in a mess.
You're right, this is not user friendly. A pre-rebase hook sounds like
a reasonable idea.
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".
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Rollback of git commands
From: Karl Hasselström @ 2007-11-28 9:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711271733r6f280618pbb14095aebba3309@mail.gmail.com>
On 2007-11-27 20:33:27 -0500, Jon Smirl wrote:
> 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.
How exactly did repair mess up? Did it crash, produce a broken result,
an unreasonable but technically valid result, or just not the result
you wanted?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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