* Re: [PATCH] gitweb: make search form generate pathinfo-style URLs
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Petr Baudis, Jakub Narebski, Luben Tuikov
In-Reply-To: <1183402981.2664.10.camel@mattlaptop2>
Matt McCutchen <hashproduct@gmail.com> writes:
> I sent this patch four days ago but no one has commented or done
> anything about it. Please clue me in: is this typical, or did I do
> something wrong or do I need to do something else?
Yes, it sometimes happens to patches to some areas. No, you did
not do anything wrong as far as I can see. Yes, sending this
kind of reminder out is exactly what is needed.
I have three recent patches from you on gitweb in my patch
queue.
Subject: [PATCH] gitweb: snapshot cleanups & support for offering multiple
formats
Date: Thu, 28 Jun 2007 14:02:13 -0400
Message-ID: <1183053733.6108.0.camel@mattlaptop2>
Subject: [PATCH] gitweb: make search form generate pathinfo-style URLs
Date: Thu, 28 Jun 2007 14:57:07 -0400
Message-ID: <1183057027.6108.4.camel@mattlaptop2>
Subject: [PATCH] gitweb: make "No commits" in project list gray, not bold
green
Date: Thu, 28 Jun 2007 18:15:22 -0400
Message-ID: <1183068922.6108.8.camel@mattlaptop2>
There are people whom I consider "gitweb folks", who are more
familiar with, and more importantly who are more interested in,
gitweb than I am. Having good "subsystem people" makes gitweb a
lower-priority area to myself, and for these patches it made
even so that nobody commented on them.
I should have asked Ack/Nack/Comments from gitweb folks much
earlier, but was a bit too loaded with the day job. Sorry about
that.
So, gitweb folks, what do you think about these patches?
^ permalink raw reply
* Re: [PATCH] git-stash: Make "save" the default operation again
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King,
しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0707021215120.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Mon, Jul 02, 2007 at 11:44:29AM +0100, Johannes Schindelin wrote:
>>
>> > So, neither "list" nor "apply" are ase often used in practice as
>> > "save". The manpage already reflects that, so change the script to the
>> > better.
>>
>> I have to admit that I don't really care all that much, so I'll let you
>> guys duke it out.
>
> I do have to admit that I do care. Especially since my alias is no longer
> working (having the same name as a git program).
Ok, two votes from long-timer Dscho and original poster Nana are
sufficient for me to change my mind.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-fsck: add --lost-found option
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707021751380.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this option, dangling objects are not only reported, but also
> written to .git/lost-found/commit/ or .git/lost-found/other/.
>
> This obsoletes git-lost-found.
I haven't had chance to look at the code yet; this is only about
the design.
I think adding --lost-found to fsck is a wonderful idea. I also
think deprecating lost-found and removing it in the longer term
is a good idea.
Please do not do that in a single patch. This patch is at least
talking about three timeframes.
1. git-fsck learns --lost-found
The patch adds that to the code and the documentation.
Then it is commented on, perhaps updated, and matures.
2. git-lost-found is marked as "deprecated"
This patch adds "deprecated" warning to the documentation.
3. git-lost-found is removed.
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: linux, git
In-Reply-To: <Pine.LNX.4.64.0707022207420.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 2 Jul 2007, linux@horizon.com wrote:
>
>> $ git branch temp tags/v2.6.22-rc6
>> $ git fetch . tags/v2.6.22-rc7:temp
> ...
> No. It is perfectly sane to fetch a tag, and to store it.
Yes, but not to a branch.
Anything under refs/heads/ should point at a commit and if we
allowed a tag to be pointed at, you probably can argue that is a
bug.
^ permalink raw reply
* Re: [PATCH] Make git-prune submodule aware (and fix a SEGFAULT in the process)
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Linus Torvalds
In-Reply-To: <200707021356.58553.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> ...
> The fix made by this patch is to not blindly call lookup_blob() in
> reachable.c's add_cache_refs(), and instead skip any index entries that
> are S_ISGITLINK().
Thanks, both of you. Will go to 'maint' hopefully tonight (if I
can shake the day job off early enough today, that is).
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Sam Vilain @ 2007-07-02 23:19 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jason Sewall, Junio C Hamano, git
In-Reply-To: <20070702221639.GB20597@thunk.org>
Theodore Tso wrote:
> OK, so I've hacked together the following emacs-lisp snippet, which I
> propose would go in contrib/use-ediff-instead.el. If placed in your
> .emacs.el file, it will cause you to use ediff instead of emerge when
> you call "git mergetool". It does so by replacing the two functions
> emerge-files-command and emerge-files-with-ancestor-comand with ones
> that patch the necessary ediff hooks, and then calling the ediff
> package instead of the emerge package.
>
> With this .el file, no changes are needed to git-mergetool.sh. Does
> this meet your needs?
>
> - Ted
>
> ;; use-ediff-instead.el
[...]
Thanks for that, it mostly works, however it doesn't seem to notice if I
abort without making the merge complete (on emacs21). In my smartmerge
script (http://utsl.gen.nz/scripts/smartmerge) I detect this condition
based on the presence of merge markers, possibly dubious but pragmatic.
I still don't really understand why having to save the merged buffer and
exit is such a huge issue. Already I have to select "-t emerge" to get
emerge. I would have thought it would be better to just make the other
mode available, and let the user figure it out.
Sam.
^ permalink raw reply
* Re: [PATCH] git-fsck: add --lost-found option
From: Johannes Schindelin @ 2007-07-02 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabuewgdb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 2 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > With this option, dangling objects are not only reported, but also
> > written to .git/lost-found/commit/ or .git/lost-found/other/.
> >
> > This obsoletes git-lost-found.
>
> [...]
>
> Please do not do that in a single patch. This patch is at least
> talking about three timeframes.
Right. My fault.
> 1. git-fsck learns --lost-found
> The patch adds that to the code and the documentation.
> Then it is commented on, perhaps updated, and matures.
>
> 2. git-lost-found is marked as "deprecated"
> This patch adds "deprecated" warning to the documentation.
How about combining these two, and give a big
WARNING: 'git lost-found' is deprecated.
WARNING: Use 'git fsck --lost-found' instead
whenever lost-found is called?
> 3. git-lost-found is removed.
Yes, that can wait.
What is more important before doing 1&2 for real is this: lost-found ATM
calls 'git-fsck --full --no-reflogs'. The patch does not force these two
options when called with '--lost-found'. I would really appreciate
opinions on this issue, and will gladly re-prepare a patch accordingly.
Ciao,
Dscho
^ permalink raw reply
* Re: challenges using fast-import and svn
From: David Frech @ 2007-07-02 23:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070702222400.GB4495@spearce.org>
On 7/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> David Frech <nimblemachines@gmail.com> wrote:
> > However, there are issues. I don't currently track branch copies
> > correctly, so branches start out with no history, rather than the with
> > the history of the branch they are copied from; and handling deletes
> > is tricky.
>
> Branches are easy to create from the right branch in fast-import,
> but its hard with the SVN dump file to know where it starts from.
>
> One trick folks have used in the past is to assign a mark in
> fast-import for each SVN revision. Marks are very cheap and make
> it easy to reference a commit in a from command when you need to
> make a new branch. You can just use the SVN revision number you
> get from the SVN dump file.
I think I know how to do this. I'm already using marks for each commit.
> > Here is the problem: if a file or directory is deleted in svn, the
> > dumpfile shows simply this:
> >
> > Node-path: trunk/project/file-or-directory
> > Node-action: delete
> >
> > In the case of a file, I can simply feed a "D" command to fast-import;
> > but if I'm deleting a whole directory, my code knows nothing about
> > what files exist in that directory. Is fast-import smart about this?
> > Will it barf if given a directory argument rather than a file for "D"
> > commands?
>
> I just read the code again. You can delete an entire subdirectory
> just by sending a D command for that subdirectory, assuming you
> don't end the name with a '/'. So you should be able to just do:
>
> D file-or-directory
>
> and whatever file-or-directory is, it goes away. If you were to
> send a trailing '/':
>
> D file-or-directory/
>
> its likely bad things will happen because fast-import will try to
> remove the file or directory named "" (yes, empty string) in the
> subdirectory called "file-or-directory" but leave the subdirectory.
This is great! I'll update the code and see what happens...
> So I guess this means a documentation update for the D command
> would be a good idea?
Sounds good to me. Right now it really implies "this only works on files".
Thanks for the snappy reply, and thanks again for writing fast-import!
It was a pleasure to use.
> --
> Shawn.
>
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: Johannes Schindelin @ 2007-07-02 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git
In-Reply-To: <7v4pkmwgda.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 2 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 2 Jul 2007, linux@horizon.com wrote:
> >
> >> $ git branch temp tags/v2.6.22-rc6
> >> $ git fetch . tags/v2.6.22-rc7:temp
> > ...
> > No. It is perfectly sane to fetch a tag, and to store it.
>
> Yes, but not to a branch.
Ooops. I forgot to write that (as the "No" at the beginning suggests...).
Thank you,
Dscho
^ permalink raw reply
* Re: [PATCH] git-fsck: add --lost-found option
From: Junio C Hamano @ 2007-07-03 0:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707030018120.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> WARNING: 'git lost-found' is deprecated.
> WARNING: Use 'git fsck --lost-found' instead
>
> whenever lost-found is called?
I agree that would be a sensible second step after the result of
the first step matures.
>> 3. git-lost-found is removed.
>
> Yes, that can wait.
>
> What is more important before doing 1&2 for real is this: lost-found ATM
> calls 'git-fsck --full --no-reflogs'. The patch does not force these two
> options when called with '--lost-found'. I would really appreciate
> opinions on this issue, and will gladly re-prepare a patch accordingly.
I think I am not following you; do you mean --lost-found does
not imply these two? I am not sure if there is any benefit of
being able to do --lost-found without --full nor --no-reflogs.
^ permalink raw reply
* Re: why does git perpetually complain about include/asm-blackfin/macros.h?
From: Bryan Wu @ 2007-07-03 0:28 UTC (permalink / raw)
To: Marco Roeland
Cc: Jesper Juhl, Jeff Garzik, Robert P. J. Day,
Linux Kernel Mailing List, Git Mailing List, Linus Torvalds
In-Reply-To: <20070702142430.GA10400@fiberbit.xs4all.nl>
On Mon, 2007-07-02 at 16:24 +0200, Marco Roeland wrote:
> On Monday July 2nd 2007 at 15:58 Jesper Juhl wrote:
>
> > [obnoxious zero sized file include/asm-blackfin/macros.h that gets
> > zapped by toolchains and resurrected again by git]
> >
> > I've seen that as well, but in my case doing a
> > $ git reset --hard master
> > fixed it.
>
> Dangerous, as it may overwrite local changes you have! A simple "git
> checkout include/asm-blackfin/macros.h" is much safer in this case.
>
> In git commit df30b11 this file got redundant. Perhaps because a normal
> patch was applied, instead of with git, the file didn't get deleted from
> the repository but truncated to size zero. Not strictly wrong perse, but
> for the Linux repository highly unusual (and the only one at that).
>
> Your toolchain perhaps deletes files with zero size after cleaning up or
> something. Git then notices that you deleted this file.
>
> Perhaps someone can apply something like the following to finally fix
> this up:
>
> commit 7d98740800f3d9ad2428afa8c677be9573a51b7b
> Author: Marco Roeland <marco.roeland@xs4all.nl>
> Date: Mon Jul 2 16:19:49 2007 +0200
>
> Blackfin arch: remove zero-sized include/asm-blackfin/macros.h
>
> This file accidentally got truncated instead of deleted in commit df30b11.
>
> Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
>
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
> -
Thanks, Applied to the blackfin-2.6.git tree for Linus pull.
- Bryan
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-03 0:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: git, quilt-dev
In-Reply-To: <20070702145601.a0dcef0f.akpm@linux-foundation.org>
On Mon, 2 Jul 2007, Andrew Morton wrote:
>
> I'm afraid indenting the changelog with leading spaces doesn't help -
> patch(1) still tries to apply the diff.
Oh wow. I didn't believe you, so I decided to test.
I shouldn't have doubted you.
That also explains why it reacted to that 53c700 even though it wasn't at
the beginning of a line.
That really is a piece of crap.
People who think that basic programs like "patch" should DWIM stuff like
that are incompetent. Yes, I can see how it can be "convenient", but
dammit, whoever added that convenince feature really is a total moron.
At the very least it should be off by default, and controlled by some flag
(ie "patch --dwim"). As it is, it's on by default, and I don't see any way
at all to disable it (not in the man-page, and not googling the source
with google code-search).
That's just incredibly broken.
I guess I shouldn't be surprised. The whole "things should be convenient,
not safe" approach is shown by the default high fuzz-factor too. But at
least that one you can disable.
It's positively microsoftian to make programs blindly be "convenient",
with no thinking about what that means for security and safety of the end
result.
So I would suggest that in quilt and other systems, you either:
- strip all headers manually
- forget about "patch", and use "git-apply" instead that does things
right and doesn't screw up like this (and can do rename diffs etc too).
I guess the second choice generally isn't an option, but dammit,
"git-apply" really is the better program here.
Linus
^ permalink raw reply
* [PATCH] git-fsck: add --lost-found option
From: Johannes Schindelin @ 2007-07-03 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps3auz5y.fsf@assigned-by-dhcp.cox.net>
With this option, dangling objects are not only reported, but also
written to .git/lost-found/commit/ or .git/lost-found/other/. This
option implies '--full' and '--no-reflogs'.
'git fsck --lost-found' is meant as a replacement for git-lost-found.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Step 1.
Documentation/git-fsck.txt | 6 +++++-
builtin-fsck.c | 22 ++++++++++++++++++++++
t/t1420-lost-found.sh | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 1 deletions(-)
create mode 100755 t/t1420-lost-found.sh
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 234c22f..08512e0 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [<object>*]
+ [--full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
@@ -64,6 +64,10 @@ index file and all SHA1 references in .git/refs/* as heads.
--verbose::
Be chatty.
+--lost-found::
+ Write dangling refs into .git/commit/ or .git/other/, depending
+ on type.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 944a496..a6ef65e 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -20,6 +20,7 @@ static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
static int errors_found;
+static int write_lost_and_found;
static int verbose;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
@@ -138,6 +139,21 @@ static void check_unreachable_object(struct object *obj)
if (!obj->used) {
printf("dangling %s %s\n", typename(obj->type),
sha1_to_hex(obj->sha1));
+ if (write_lost_and_found) {
+ char *filename = git_path("lost-found/%s/%s",
+ obj->type == OBJ_COMMIT ? "commit" : "other",
+ sha1_to_hex(obj->sha1));
+ FILE *f;
+
+ if (safe_create_leading_directories(filename)) {
+ error("Could not create lost-found");
+ return;
+ }
+ if (!(f = fopen(filename, "w")))
+ die("Could not open %s", filename);
+ fprintf(f, "%s\n", sha1_to_hex(obj->sha1));
+ fclose(f);
+ }
return;
}
@@ -685,6 +701,12 @@ int cmd_fsck(int argc, char **argv, const char *prefix)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--lost-found")) {
+ check_full = 1;
+ include_reflogs = 0;
+ write_lost_and_found = 1;
+ continue;
+ }
if (*arg == '-')
usage(fsck_usage);
}
diff --git a/t/t1420-lost-found.sh b/t/t1420-lost-found.sh
new file mode 100755
index 0000000..dc9e402
--- /dev/null
+++ b/t/t1420-lost-found.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='Test fsck --lost-found'
+. ./test-lib.sh
+
+test_expect_success setup '
+ git config core.logAllRefUpdates 0 &&
+ : > file1 &&
+ git add file1 &&
+ test_tick &&
+ git commit -m initial &&
+ echo 1 > file1 &&
+ echo 2 > file2 &&
+ git add file1 file2 &&
+ test_tick &&
+ git commit -m second &&
+ echo 3 > file3 &&
+ git add file3
+'
+
+test_expect_success 'lost and found something' '
+ git rev-parse HEAD > lost-commit &&
+ git rev-parse :file3 > lost-other &&
+ test_tick &&
+ git reset --hard HEAD^ &&
+ git fsck --lost-found &&
+ test 2 = $(ls .git/lost-found/*/* | wc -l) &&
+ test -f .git/lost-found/commit/$(cat lost-commit) &&
+ test -f .git/lost-found/other/$(cat lost-other)
+'
+
+test_done
--
1.5.2.2.3296.g5753c-dirty
^ permalink raw reply related
* Re: [PATCH] Blackfin arch: include/asm-blackfin/macros.h die die die
From: Bryan Wu @ 2007-07-03 0:39 UTC (permalink / raw)
To: Marco Roeland
Cc: Alex Riesen, Jeff Garzik, Jesper Juhl, Robert P. J. Day,
Linux Kernel Mailing List, Git Mailing List, Linus Torvalds
In-Reply-To: <20070702150915.GC10400@fiberbit.xs4all.nl>
On Mon, 2007-07-02 at 17:09 +0200, Marco Roeland wrote:
> This file accidentally got truncated instead of deleted in commit df30b11.
> Doing a "make distclean" or "make mrproper" deletes this file because of
> its zero size. Git then sees this as an uncommitted local change.
>
> Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
> ---
> 0 files changed, 0 insertions(+), 0 deletions(-)
> delete mode 100644 include/asm-blackfin/macros.h
>
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
Thanks already in blackfin-2.6.git tree for Linus pull
Acked by: Bryan Wu <bryan.wu@analog.com>
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-03 1:09 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jason Sewall, Junio C Hamano, git
In-Reply-To: <46898815.6030607@vilain.net>
On Tue, Jul 03, 2007 at 11:19:49AM +1200, Sam Vilain wrote:
> Thanks for that, it mostly works, however it doesn't seem to notice if I
> abort without making the merge complete (on emacs21). In my smartmerge
> script (http://utsl.gen.nz/scripts/smartmerge) I detect this condition
> based on the presence of merge markers, possibly dubious but pragmatic.
Hmm, well, here's a way of fixing it. (See attached, below.) It adds
a new command 'x', which when you hit it in the ediff control window,
exits with a error status of '1', indicating that the merge has
failed. This is something which emerge, kdiff3, tkdiff, et. al all
support; but which ediff doesn't.
> I still don't really understand why having to save the merged buffer and
> exit is such a huge issue. Already I have to select "-t emerge" to get
> emerge. I would have thought it would be better to just make the other
> mode available, and let the user figure it out.
I'm just exploring alternatives. Basically, it just seems interesting
that ediff has a lot of nice features, but also has some incredibly
user-hostile features. The first time I tried using ediff, I indeed
tried saving the buffer and exiting it. That's when I discovered that
after I changed the focus to the merge window and saved it, when I
tried typing ^X^C, the exit failed with the error message "Attempt to
delete a surrogate minibuffer frame". That's the sort of thing that
will cause non-elisp programmers to run screaming off into the
distance.
So if you are going to save the merge the buffer and exit, you *have*
to use the 'q' command, and endure the loads of stupid questions
issued by ediff, OR, you can discover that ^X^C in the ediff control
window doesn't actually cause emacs to exit, but it does make the
ediff control window go away. (Which is another insane bit of ediff's
UI design... why should ^X^C do something completely different in the
ediff control window?!?)
So yeah, we can add ediff as an optional support that people have to
explicitly request, but quite frankly, having played with it, I don't
know why anyone would use it without a huge number of fix ups, which
is why I was trying to make ediff actually be usable for someone who
doesn't mind typing ^X^C twice, for no good reason, after figuring out
that this illogical thing is what you actually need to do to exit
ediff. (I actually read the help text first, so I got treated to the
really annoying ediff-quit behavior before I figured out the double
^X^C trick.)
- Ted
;; use-ediff-instead.el
;;
;; This emacs lisp snippet should be placed in your .emacs.el file in
;; order to use the ediff package instead of emerge for git-mergetool.
;; Ediff has more whiz-bang features, but unfortunately it doesn't
;; integrate well with shell scripts that try to invoke ediff from an
;; emacs shell invocation. This script tries to address these problems.
(defun ediff-write-merge-buffer ()
(let ((file ediff-merge-store-file))
(set-buffer ediff-buffer-C)
(write-region (point-min) (point-max) file)
(message "Merge buffer saved in: %s" file)
(set-buffer-modified-p nil)
(sit-for 1)))
(defun ediff-abort ()
"Abort the ediff session without a non-zero exit status"
(interactive)
(kill-emacs 1))
(defun ediff-setup-abort ()
(define-key ediff-mode-map "x" 'ediff-abort))
(defun emerge-files-command ()
(let ((file-a (nth 0 command-line-args-left))
(file-b (nth 1 command-line-args-left))
(file-out (nth 2 command-line-args-left)))
(setq command-line-args-left (nthcdr 3 command-line-args-left))
(setq ediff-quit-hook 'kill-emacs
ediff-quit-merge-hook 'ediff-write-merge-buffer
ediff-keymap-setup-hook 'ediff-setup-abort)
(ediff-merge-files file-a file-b nil file-out)))
(defun emerge-files-with-ancestor-command ()
(let (file-a file-b file-anc file-out)
;; check for a -a flag, for filemerge compatibility
(if (string= (car command-line-args-left) "-a")
;; arguments are "-a ancestor file-a file-b file-out"
(progn
(setq file-a (nth 2 command-line-args-left))
(setq file-b (nth 3 command-line-args-left))
(setq file-anc (nth 1 command-line-args-left))
(setq file-out (nth 4 command-line-args-left))
(setq command-line-args-left (nthcdr 5 command-line-args-left)))
;; arguments are "file-a file-b ancestor file-out"
(setq file-a (nth 0 command-line-args-left))
(setq file-b (nth 1 command-line-args-left))
(setq file-anc (nth 2 command-line-args-left))
(setq file-out (nth 3 command-line-args-left))
(setq command-line-args-left (nthcdr 4 command-line-args-left)))
(setq ediff-quit-hook 'kill-emacs
ediff-quit-merge-hook 'ediff-write-merge-buffer
ediff-keymap-setup-hook 'ediff-setup-abort)
(ediff-merge-files-with-ancestor file-a file-b file-anc nil file-out)))
;; End of use-ediff-instead.el
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Theodore Tso @ 2007-07-03 1:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vr6nqwgdi.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 02, 2007 at 04:11:21PM -0700, Junio C Hamano wrote:
> > Such a point exists, I agree, but I would draw after $* and $1/$2/$3
> > interpolation. There is a lot more value that gets added with
> > positional arguments support, and it makes git aliases more usable on
> > platforms such as Windows where scripting capability is much more
> > limited.
>
> That actually sounds sensible, but you could alias
>
> !sh -c 'command $2 $1 $3'
>
> to reorder the parameters, couldn't you?
Um, how would that work on the Windows platform?
(I'm assuming here that we are trying to support Windows better, since
there are projects such as Mozilla, and MySQL that care very much
about first class Windows support. We could say this isn't important
enough, and that would be fine; but I wanted to at least raise the
question.)
- Ted
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Johannes Schindelin @ 2007-07-03 1:37 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, git
In-Reply-To: <20070703011429.GB5322@thunk.org>
Hi,
On Mon, 2 Jul 2007, Theodore Tso wrote:
> On Mon, Jul 02, 2007 at 04:11:21PM -0700, Junio C Hamano wrote:
> > > Such a point exists, I agree, but I would draw after $* and $1/$2/$3
> > > interpolation. There is a lot more value that gets added with
> > > positional arguments support, and it makes git aliases more usable on
> > > platforms such as Windows where scripting capability is much more
> > > limited.
> >
> > That actually sounds sensible, but you could alias
> >
> > !sh -c 'command $2 $1 $3'
> >
> > to reorder the parameters, couldn't you?
>
> Um, how would that work on the Windows platform?
>
> (I'm assuming here that we are trying to support Windows better, since
> there are projects such as Mozilla, and MySQL that care very much
> about first class Windows support. We could say this isn't important
> enough, and that would be fine; but I wanted to at least raise the
> question.)
Windows support for those people unwilling to use cygwin amounts to
anything, but a command line interface. Since aliases are _bound_ to
the command line, I do not really get your point here.
In my view of things, for Windows support it is first of all important to
get rid of the dependency on bash in the core parts. Then we should
continue on the work Han-Wen did with his gub, and produce a proper
Windows-clicky-style installer which installs git-gui with a proper
Windows Start Menu item. But of course, then we should brace ourselves for
a lot of clueless^Winterested users.
Ciao,
Dscho
^ permalink raw reply
* How to create & switch to a branch after changes have already been made?
From: Patrick Doyle @ 2007-07-03 2:18 UTC (permalink / raw)
To: git
Suppose, hypothetically speaking, one were a long time user of CVS who
converted to subversion in the last 18 months or so, and who never
really understood branches and merging because the syntax was so
obtuse and because the projects this hypothetical person had worked
were short lived enough that (s)he never really needed to create a
branch.
Now suppose this hypothetical person was working on a new project,
decided to use git as the project's version control system, got
halfway through changing a bunch of files, wanted to commit them as
they were, since they worked, but were ugly as sin, and wanted to
clean them up before committing them back to the main line of
development.
I would tell that hypothetical person, "Gee, it sounds like a branch
is exactly what you need here". Unfortunately I don't know how to
tell the person to do the equivalent of a "svn switch" when the local
repository has been modified.
$ git branch newbranch
that works, but
$ git checkout newbranch
complains that an untracked file would be overwritten by the merge
(since one of the things that this hypothetical person may have done
would have been to do a "git mv somefile someotherfile").
What would you suggest I say to this person other than "get in the
habit of creating a new branch _any_ time you start something new".
--wpd
^ permalink raw reply
* Re: How to create & switch to a branch after changes have already been made?
From: Patrick Doyle @ 2007-07-03 2:49 UTC (permalink / raw)
To: git
In-Reply-To: <e2a1d0aa0707021918mb335856j278b3128203a793a@mail.gmail.com>
Hmmm...
One thing I might tell the hypothetical person is to temporarily
delete or rename the new version of "somefile", so that the merge
could complete with problems, and then recreate or rename it back.
That would probably allow the hypothetical person to continue his/her
work.
--wpd
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Nicolas Pitre @ 2007-07-03 2:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Yann Dirson, Git Mailing List
In-Reply-To: <7vsl8894tc.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> Your patch _closes the door_ for us to implement overriding
> aliases later if we wanted to; we would need to go back to the
> scripts and say "git --no-alias xyzzy" again.
I think such aliases would be evil. Closing the door on them is most
certainly a good thing IMHO.
Nicolas
^ permalink raw reply
* Re: How to create & switch to a branch after changes have already been made?
From: linux @ 2007-07-03 3:05 UTC (permalink / raw)
To: wpdster; +Cc: git
The magic you're looking for is "git checkout -b <branch>"
You can do that even with uncommitted changes hanging around.
Because you don't specify a commit to check out, it just "checks out
the HEAD again", which does nothing. The only thing left is the
part that creates and switches to a new branch.
Now, if you've already created the branch, you can either do:
git checkout <newbranch>
which, since <newbranch> equals HEAD, just switches the HEAD symlink
without actually changing the checked-out commit.
Or, if you want to be really low-level,
git-update-ref HEAD <newbranch>
Which is the underlying tool that git checkout uses.
It bypasses all the safety checkes, but it might be easiest to understand.
Now, if you've already committed, you can just do:
git checkout -b <newbranch>
git branch -f <oldbranch> HEAD^
Admittedly, I sometimes with for a "git commit -b <branch>" shortcut.
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: linux @ 2007-07-03 3:23 UTC (permalink / raw)
To: Johannes.Schindelin, linux; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707022207420.4071@racer.site>
> Why not do 'git branch temp v2.6.22-rc7' to begin with? Or even better:
> git checkout -b temp v2.6.22-rc7.
In my case, it was the "master" branch; I couldn't remember if I'd done
any hacking on it. But I used the branch name "temp" while demonstrating
how to recreate the problem.
> But in any case, you should know that there is no floating tag in git, and
> therefore, by storing it in the "branch" temp, you doom that branch to
> not be able to be committed to.
I just wanted to fast-forward my master to -rc7, like the git-merge-ff
utility that's been floating around.
> What you should have done, of course, is
>
> $ git checkout temp
> $ git merge v2.6.22-rc7
But if I'd have changes to my master, I would have examined them and
either rebased them or assigned a branch name. It was just a way to
either do what I wanted or get an error message, all in one step.
>> $ git checkout temp
>> $ (make minor change)
>> $ git commit -a
>> fatal: 087ea061253277de2b27e82d8572a386835a1b7e is not a valid 'commit' object
>>
>> git-fetch does odd things when handed a tag rather than a commit.
> No. It is perfectly sane to fetch a tag, and to store it.
I suppose, but should the result be put in the "refs/heads" directory?
And until git-merge-ff is available, what's the recommended way to
"advance master to tag <foo>, but only if that wouldn't lose anything?"
^ permalink raw reply
* Re: [PATCH] Documentation: quote {non-attributes} for asciidoc
From: Jeff King @ 2007-07-03 3:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070702052459.GA2365@coredump.intra.peff.net>
On Mon, Jul 02, 2007 at 01:24:59AM -0400, Jeff King wrote:
> Documentation/git-branch.txt | 2 +-
> Documentation/git-checkout.txt | 2 +-
> Documentation/git-receive-pack.txt | 10 +++++-----
> Documentation/git-rev-list.txt | 4 ++--
> Documentation/git-stash.txt | 8 ++++----
> 5 files changed, 13 insertions(+), 13 deletions(-)
I should have noted: this change is on top of next (due to the git-stash
corrections), but I think the rest of it should go into master ASAP, as
it makes some of the documentation very difficult to read. It should be
trivial to split, but let me know if you want me to resend as two
patches.
-Peff
^ permalink raw reply
* Re: [PATCH] git-repack: generational repacking (and example hook script)
From: Nicolas Pitre @ 2007-07-03 3:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <1183193782608-git-send-email-sam.vilain@catalyst.net.nz>
On Sat, 30 Jun 2007, Sam Vilain wrote:
> Add an option to git-repack that makes the repack run suitable for
> running very often. The idea is that packs get given a "generation",
> and that the number of packs in each generation (except the last one)
> is bounded.
Please explain again why this should be useful and is worth the
complexity it brings along. Last time this was discussed I wasn't
convinced at all, and I'm still not convinced this time either.
Nicolas
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Junio C Hamano @ 2007-07-03 3:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Yann Dirson, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707022253580.26459@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sat, 30 Jun 2007, Junio C Hamano wrote:
>
>> Your patch _closes the door_ for us to implement overriding
>> aliases later if we wanted to; we would need to go back to the
>> scripts and say "git --no-alias xyzzy" again.
>
> I think such aliases would be evil. Closing the door on them is most
> certainly a good thing IMHO.
Ok.
Now my 'next' is coming very close to 'master' while preparing
for 1.5.3-rc0, it may be a good time to apply Linus's magic.
^ 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