* 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] 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-mergetool: add support for ediff
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jason Sewall, Sam Vilain, git
In-Reply-To: <20070702144800.GA4720@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Jul 01, 2007 at 09:49:10PM -0700, Junio C Hamano wrote:
>> The reason I personally use emacsclient is not about the
>> start-up delay, but with the access to existing buffers,
>> keyboard macros, Gnus buffers, ... IOW the access to the
>> "session" while editing. I suspect people with long running
>> Emacs session use emacsclient for that reason.
>
> Sure, but do you need access to existing buffers, keyboard, macros,
> etc., if you're simply firing up an emacs to handle a merge conflict?
>
> If the goal is just to run a merge application, then firing up a
> separate process makes a lot more sense.
Existing buffers may help somewhat as I am likely to have that
already loaded, but other than that probably not.
> In my mind it's on the hairy edge. Alternatively we just never use
> ediff by default, and assume that either expert users can hack their
> .emacs.el file to have the right overrides will use ediff, or who are
> willing to put up with ediff's user-hostile approach to quitting an
> merge session.
I think that is sane.
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Junio C Hamano @ 2007-07-02 23:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <20070702160810.GD4720@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Mon, Jul 02, 2007 at 04:55:24PM +0100, Johannes Schindelin wrote:
>> > But what if you don't want the argument passed at the end of the
>> > alias, but somewhere else? I suspect the better answer would be to
>> > support $* and $1, $2, $3, et. al interpolation, no? It was on my
>> > list of things to do when I had a spare moment, but I never got around
>> > to it.
>>
>> There is a point where you do not want to complicate git, but rather write
>> a script. This is such a point IMHO.
>
> 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?
^ permalink raw reply
* Re: [PATCH] git-stash: fix usage string
From: Johannes Schindelin @ 2007-07-02 22:56 UTC (permalink / raw)
To: しらいしななこ; +Cc: GIT
In-Reply-To: <20070624192216.6117@nanako3.bluebottle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 168 bytes --]
Hi,
On Tue, 3 Jul 2007, しらいしななこ wrote:
> I do not know if my opinion matters much [...]
It does! After all, code talks, and you wrote it.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-stash: fix usage string
From: しらいしななこ @ 2007-07-02 22:41 UTC (permalink / raw)
To: GIT
The command requires an explicit "save" subcommand, but the usage string
does not talk about it.
This matches the usage string with the SYNOPSIS string in the documentation.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
---
I do not know if my opinion matters much but I think it is nicer to save a
new stash without a subcommand than to list existing stash data.
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 18d3322..62f9f7a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -1,7 +1,7 @@
#!/bin/sh
# Copyright (c) 2007, Nanako Shiraishi
-USAGE='[ | list | show | apply | clear]'
+USAGE='(save | list | show [<stash>] | apply [<stash>] | clear)'
. git-sh-setup
require_work_tree
--
1.5.2
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Find out how you can get spam free email.
http://www.bluebottle.com
^ permalink raw reply related
* Re: git Intall problem: cannot stat `lib/tclIndex'
From: Shawn O. Pearce @ 2007-07-02 22:30 UTC (permalink / raw)
To: free cycle; +Cc: git
In-Reply-To: <594387.97825.qm@web56006.mail.re3.yahoo.com>
free cycle <freecycler23@yahoo.com> wrote:
> I’m trying to install git and I have run the following steps:
>
> make configure
> ./configure --prefix=/p/tools/git
> make all
> make install
>
> Everything works OK up until the “make install” step at which point I get the following error:
>
> install -m644 lib/tclIndex '/p/nhm/rtl/tools/git/share//git-gui/lib'
>
> install: cannot stat `lib/tclIndex': No such file or directory
Sounds like you are trying to build a version of Git that doesn't
gracefully fallback when tclsh isn't available. So I'm guessing
you don't have a tclsh in your $PATH, and that is why git-gui could
not create its lib/tclIndex.
Hmmph. Even as far back as Git 1.5.2 git-gui used a fallback for
its lib/tclIndex when tclsh wasn't available or working properly.
We're currently on 1.5.2.3 (just released).
Please consider upgrading to the latest stable Git (1.5.2.3 or
1.5.2.2 if the .3 isn't available on your mirror of choice yet).
--
Shawn.
^ permalink raw reply
* Re: challenges using fast-import and svn
From: Shawn O. Pearce @ 2007-07-02 22:24 UTC (permalink / raw)
To: David Frech; +Cc: git
In-Reply-To: <7154c5c60707021226k3a7b82fcl7558cfc66d61dde@mail.gmail.com>
David Frech <nimblemachines@gmail.com> wrote:
> So I wrote, in Lua, a parser for the (terrible) svn dump file format
> that feeds commands into fast-import. The parser took a day and a half
> to write; the fast-import backend took about an hour. ;-)
Heh. That's about what most folks say. ;-)
> 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.
> 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.
Another option is you can replace a tree with a file at any point in
time, without first deleting it. So you could also just overwrite
the entire subdirectory with an empty file via the M command, then
delete the file. But that shouldn't be necessary as the D command
should already do exactly what you want it to do. Internally
the "replace entire directory with single file" is the same
implementation as the "delete entire directory" implementation...
So I guess this means a documentation update for the D command
would be a good idea?
> I could cache the directory contents in my code, but isn't that partly
> what fast-import is good for?
Yes. fast-import is really quite good at helping you do Git side
of the equation. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-02 22:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jason Sewall, Junio C Hamano, git
In-Reply-To: <20070702215859.GA20597@thunk.org>
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
;;
;; 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.
(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 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-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-merge-files-with-ancestor file-a file-b file-anc nil file-out)))
;; End of use-ediff-instead.el
^ permalink raw reply
* git Intall problem: cannot stat `lib/tclIndex'
From: free cycle @ 2007-07-02 22:16 UTC (permalink / raw)
To: git
Apologies in advance.. I’m not experienced at installing SW packages
and I could not find anything in the FAQs about this…
I’m trying to install git and I have run the following steps:
make configure
./configure --prefix=/p/tools/git
make all
make install
Everything works OK up until the “make install” step at which point I get the following error:
... stuff deleted
install -d -m755 '/p/nhm/rtl/tools/git/share//git-gui/lib'
install -m644 lib/tclIndex '/p/nhm/rtl/tools/git/share//git-gui/lib'
install: cannot stat `lib/tclIndex': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/nfs/site/disks/nhm.work.658/testing/git/git-gui'
make: *** [install] Error 2
=======
Note: it works OK if I don’t try to install the gui.. and I have been able to setup
a git repo and I ran through the git tutorial (no gui required).
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Theodore Tso @ 2007-07-02 21:58 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jason Sewall, Junio C Hamano, git
In-Reply-To: <46896EF2.70006@vilain.net>
On Tue, Jul 03, 2007 at 09:32:34AM +1200, Sam Vilain wrote:
> > Unfortunately, it's not enough. Ediff doesn't have an "abort" command
> > which returns a non-zero exit status, and when you use the "quit"
> > command, it asks you a series of obnoxious questions:
> >
> > Quit this Ediff session? (y or n)
> > File /usr/projects/git/test/testfile.c exists, overwrite? (y or n)
> > Merge buffer saved in /usr/projects/git/test/testfile.c
> > <delay for 3 annoying seconds>
> > Merge buffer saved. Now kill the buffer? (y or n)
>
> Yeah, I normally just save the merged buffer and quit. This skips all that.
>
> But I will add your little snippet to my .emacs :)
You probably don't want to just add that snippet to your .emacs, since
it changes the ediff 'quit' command to always cause emacs to
immediately exit, and that's probably not the right thing if you are
starting ediff from an emacs session.
The correct fix would involve stealing code from emerge's
emerge-merge-files-command function to parse the arguments from the
command-line --- and in fact, probably the simplest way of fixing
things for folks would be to write replacement emerge-*-command
functions which call ediff after patching the ediff hooks in the
emacs-lisp fragment I sent above.
In fact, maybe that's the right approach. I don't think we want to
ship emacs lisp files which git-mergetool depends upon, but what if we
instead ship some emacs lisp code in the contrib directory which a
user could slip into their .emacs file which replaces the two
emerge-*-command functions which ones that call ediff instead?
That way we don't have all of this complexity added into git-mergetool.
- Ted
^ permalink raw reply
* Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-02 21:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, quilt-dev
In-Reply-To: <alpine.LFD.0.98.0707021436300.9434@woody.linux-foundation.org>
On Mon, 2 Jul 2007 14:40:36 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 2 Jul 2007, Andrew Morton wrote:
> >
> > Thing is, changelog-followed-by-diff is a fairly standard format used by
> > quilt and other such toys.
>
> Sure. And if a tool ends up eating the changelog as a diff, then that tool
> is broken. I really do think that this is a "patch" bug - I really don't
> think that that was a valid traditional diff with the four spaces at the
> head of the line.
>
> Of course, if the changelog-followed-by-diff doesn't have any indentation
> or escaping at all, the changelog entry itself *could* actually have a
> real unified diff in it, and the tool would be unable to tell where the
> actual patch starts.
erk, yes, sometimes people do like to quote a hunk of diff in the changelog
and yes, hell doth break loose.
> But at least "git show" and friends indent the changelog on purpose,
> exactly so that there is never any chance that there could be any real
> ambiguity, and this really was a "patch" bug as far as I can tell.
> Happily, one that is easy to work around, by just telling patch to always
> consider the patch a unified diff.
I'm afraid indenting the changelog with leading spaces doesn't help -
patch(1) still tries to apply the diff.
I guess quilt-and-friends could (should) strip away all text prior to the
first ^--- before feeding to patch(1). That would reliably remove all
git changelog text.
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-02 21:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: git, quilt-dev
In-Reply-To: <20070702142557.eba61ccd.akpm@linux-foundation.org>
On Mon, 2 Jul 2007, Andrew Morton wrote:
>
> Thing is, changelog-followed-by-diff is a fairly standard format used by
> quilt and other such toys.
Sure. And if a tool ends up eating the changelog as a diff, then that tool
is broken. I really do think that this is a "patch" bug - I really don't
think that that was a valid traditional diff with the four spaces at the
head of the line.
Of course, if the changelog-followed-by-diff doesn't have any indentation
or escaping at all, the changelog entry itself *could* actually have a
real unified diff in it, and the tool would be unable to tell where the
actual patch starts.
But at least "git show" and friends indent the changelog on purpose,
exactly so that there is never any chance that there could be any real
ambiguity, and this really was a "patch" bug as far as I can tell.
Happily, one that is easy to work around, by just telling patch to always
consider the patch a unified diff.
Linus
^ permalink raw reply
* [StGIT PATCH] Recognize refs under remotes/ as parent branch on stack creation.
From: Yann Dirson @ 2007-07-02 21:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Also remove the "relaxed" parentbranch detecting logic (accepting
anything with an embedded slash as a parent branch name), which was
never invoked because of a bug, and looks like a bad idea anyway.
Better add sensible namespaces when we feel a need for them, rather
than accepting anything by default, with potentially unwanted results.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/branch.py | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/stgit/commands/branch.py b/stgit/commands/branch.py
index c22e143..e45bcee 100644
--- a/stgit/commands/branch.py
+++ b/stgit/commands/branch.py
@@ -122,27 +122,36 @@ def func(parser, options, args):
tree_id = None
if len(args) >= 2:
+ parentbranch = None
try:
- if git.rev_parse(args[1]) == git.rev_parse('refs/heads/' + args[1]):
- # we are for sure referring to a branch
- parentbranch = 'refs/heads/' + args[1]
- out.info('Recording "%s" as parent branch' % parentbranch)
- elif git.rev_parse(args[1]) and re.search('/', args[1]):
- # FIXME: should the test be more strict ?
- parentbranch = args[1]
- else:
- # Note: this includes refs to StGIT patches
- out.info('Don\'t know how to determine parent branch'
- ' from "%s"' % args[1])
- parentbranch = None
+ branchpoint = git.rev_parse(args[1])
+
+ # first, look for branchpoint in well-known branch namespaces
+ for namespace in ('refs/heads/', 'remotes/'):
+ # check if branchpoint exists in namespace
+ try:
+ maybehead = git.rev_parse(namespace + args[1])
+ except git.GitException:
+ maybehead = None
+
+ # check if git resolved branchpoint to this namespace
+ if maybehead and branchpoint == maybehead:
+ # we are for sure referring to a branch
+ parentbranch = namespace + args[1]
+
except git.GitException:
# should use a more specific exception to catch only
# non-git refs ?
out.info('Don\'t know how to determine parent branch'
' from "%s"' % args[1])
- parentbranch = None
- tree_id = git_id(args[1])
+ tree_id = branchpoint or git_id(args[1])
+
+ if parentbranch:
+ out.info('Recording "%s" as parent branch' % parentbranch)
+ else:
+ out.info('Don\'t know how to determine parent branch'
+ ' from "%s"' % args[1])
else:
# branch stack off current branch
parentbranch = git.get_head_file()
^ permalink raw reply related
* Re: [PATCH] git-mergetool: add support for ediff
From: Sam Vilain @ 2007-07-02 21:32 UTC (permalink / raw)
To: Theodore Tso; +Cc: Jason Sewall, Junio C Hamano, git
In-Reply-To: <20070702020401.GD28917@thunk.org>
Theodore Tso wrote:
> After looking at ediff, it is definitely the more polished and
> featureful compared to emerge --- except in one critical area, which
> is calling as a mergeing tool from a shell script or command line.
[...]
> emacs --eval "(ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" nil \"$path\")"
>
> Unfortunately, it's not enough. Ediff doesn't have an "abort" command
> which returns a non-zero exit status, and when you use the "quit"
> command, it asks you a series of obnoxious questions:
>
> Quit this Ediff session? (y or n)
> File /usr/projects/git/test/testfile.c exists, overwrite? (y or n)
> Merge buffer saved in /usr/projects/git/test/testfile.c
> <delay for 3 annoying seconds>
> Merge buffer saved. Now kill the buffer? (y or n)
Yeah, I normally just save the merged buffer and quit. This skips all that.
But I will add your little snippet to my .emacs :)
Sam.
^ permalink raw reply
* Re: being nice to patch(1)
From: Andrew Morton @ 2007-07-02 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, quilt-dev
In-Reply-To: <alpine.LFD.0.98.0707021409510.9434@woody.linux-foundation.org>
On Mon, 2 Jul 2007 14:16:16 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 2 Jul 2007, Andrew Morton wrote:
> >
> > James's current git-scsi-misc has this commit in it:
> >
> > commit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b
> > Author: Kars de Jong <jongk@linux-m68k.org>
> > Date: Sun Jun 17 14:47:08 2007 +0200
> >
> > [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI
> >
> > New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the
> > 53c700 SCSI core.
> >
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
> >
> >
> > When one pulls that diff out of git with `git-show' or whatever, it doesn't
> > work - patch(1) has a heart attack over the "53c700":
>
> There's really nothing git can do about this, this is a patch oddity about
> the free-form message. A really strange one too, because the line is
> literally four spaces followed by the 53c700, and the thing is, that's not
> even a valid olf-fashioned patch (_without_ the four spaces, I could see
> that "patch" might think that it's a really old ed-
>
> I think you have two options:
>
> - tell patch to take it as a unified diff:
>
> git show | patch -p1 -u
>
> should work, since patch won't be trying to figure out what kind of
> diff it is, and won't think that the 53c700 is some kind of odd ed
> script.
yup, `patch -u' fixes it up.
> - suppress the free-form messages, by using (for example)
>
> git show --pretty=oneline | patch -p1
>
> and now "patch" doesn't get any random commit message except for the
> first line (which always starts with the SHA1) and hopefully cannot
> _possibly_ interpret that to be some strange patch format.
>
> Or, of course, just use "git-apply" instead of patch to apply the thing.
>
Thing is, changelog-followed-by-diff is a fairly standard format used by
quilt and other such toys.
Hopefully quilt is using -u so it won't encounter this oddity.
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Christian Jaeger @ 2007-07-02 21:20 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070702204051.GP7730@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson wrote:
> On Mon, Jul 02, 2007 at 10:23:00PM +0200, Christian Jaeger wrote:
>
>> I don't per se require undo actions. I just don't understand why git-rm
>> refuses to remove the file from the index, even if I didn't commit it.
>>
>
> I'd say it does so, so you won't loose any uncommitted changes without
> knowing it - and "git add -f" is available when you have checked that
> you indeed want to discard that data.
>
I'm really realising that
git-rm $file # where $file *has* been committed previously
does remove *and* unlink the file. (cg-rm does unlink only with the -f
flag, as said.)
So there's no -f flag in normal git-rm usage. It thus has a different
meaning, namely "force the operation pair of removing from index and
unlinking", not "force this operation also onto the checked out files"
as is the case with cogito.
So I now understand better why they invented the -f flag to git-rm for
the case you're mentioning above and why the hint doesn't warn about
it's danger, since git-rm is always dangerous. (Ok, as is "rm" without
the "-i"; I just found it normal that cogito behaved like my "-i" setup.)
Regarding the issue of "lost files" because they have been created,
added, and removed again before committing: as far as I remember this
has never happened to me with cogito. I commit often, so if I add a file
or a few, in most cases I commit just this fact (that they have been
added), before doing more fancy stuff. I'm maybe used to thinking in
database terms, work that isn't committed is lost. So if I create a file
and add it, in my brain the "attention, uncommitted work" flag is on,
and it usually doesn't happen that I later erroneously think the work
has been committed when in fact it isn't. (I can always check with a
quick cg-status (which shows the files as "A", which makes them stand
out better than in the git-status output)).
Just before writing this mail I had a case where I wanted to remove a
file from versioning control, but keep it on disk (I used git-rm and
that's how I learned that it really also unlinks the local file without
asking(*)). Note that this has not been an undo action; the file has
been committed previously.
(* thanks to git-reset I could get it back of course)
>
> That is, "git rm" will only ever remove the file without asking, when
> it is safe do so, in that you can retrieve your file from history.
(Well it's not safe if you want to remove the file *from the index* and
naively mis-use the -f flag as suggested by the hint.)
> Or
> do you think of another way, in which more safety would be needed ?
>
I think we have just two different points in our view where we think
safety matters.
Regarding the man pages: yes the git-rm man page is fine, and it's nice
to see the manuals are improving. As noted I came from cogito, and
didn't expect git to behave so different with the same named (but
different purpose) options, so I didn't read the man pages (I've been in
irc and asked there, where someone suggested to bring this to the list;
I'm too tired today to think further about it and will try to read more
docs and hope I'll get to understand the git philosophies more).
Christian.
^ permalink raw reply
* Re: being nice to patch(1)
From: Linus Torvalds @ 2007-07-02 21:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20070702125450.28228edd.akpm@linux-foundation.org>
On Mon, 2 Jul 2007, Andrew Morton wrote:
>
> James's current git-scsi-misc has this commit in it:
>
> commit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b
> Author: Kars de Jong <jongk@linux-m68k.org>
> Date: Sun Jun 17 14:47:08 2007 +0200
>
> [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI
>
> New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the
> 53c700 SCSI core.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
>
>
> When one pulls that diff out of git with `git-show' or whatever, it doesn't
> work - patch(1) has a heart attack over the "53c700":
There's really nothing git can do about this, this is a patch oddity about
the free-form message. A really strange one too, because the line is
literally four spaces followed by the 53c700, and the thing is, that's not
even a valid olf-fashioned patch (_without_ the four spaces, I could see
that "patch" might think that it's a really old ed-
I think you have two options:
- tell patch to take it as a unified diff:
git show | patch -p1 -u
should work, since patch won't be trying to figure out what kind of
diff it is, and won't think that the 53c700 is some kind of odd ed
script.
- suppress the free-form messages, by using (for example)
git show --pretty=oneline | patch -p1
and now "patch" doesn't get any random commit message except for the
first line (which always starts with the SHA1) and hopefully cannot
_possibly_ interpret that to be some strange patch format.
Or, of course, just use "git-apply" instead of patch to apply the thing.
Linus
^ permalink raw reply
* Re: git-fetch will leave a ref pointing to a tag
From: Johannes Schindelin @ 2007-07-02 21:14 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20070702194437.19202.qmail@science.horizon.com>
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
Why not do 'git branch temp v2.6.22-rc7' to begin with? Or even better:
git checkout -b temp v2.6.22-rc7.
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.
What you should have done, of course, is
$ git checkout temp
$ git merge v2.6.22-rc7
> $ 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.
> Also, should "git checkout" have complained?
Maybe. Dunno.
Ciao,
Dscho
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Johannes Schindelin @ 2007-07-02 21:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Yann Dirson, Christian Jaeger, git
In-Reply-To: <vpq7ipittl2.fsf@bauges.imag.fr>
Hi,
On Mon, 2 Jul 2007, Matthieu Moy wrote:
> Defaulting to --cached would be an obvious way to avoid data-loss. _At
> least_, mentionning --cached in the error message in case of staged
> changes would be a considerable step forward.
>
> At the moment, the non-expert user will have difficulties to unversion
> the file without deleting it. I just see it as
>
> $ git rm foo
> error: 'foo' has changes staged in the index
> (hint: to hang yourself, try -f)
> $ _
What's so wrong with our man pages? You know, there have been man hours
invested in them, and they are exclusively meant for consumption by people
who do not know about the usage of the commands...
Hth,
Dscho
^ permalink raw reply
* Re: Bug: segfault during git-prune
From: Linus Torvalds @ 2007-07-02 21:01 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200707021425.38367.andyparkins@gmail.com>
On Mon, 2 Jul 2007, Andy Parkins wrote:
>
> I've pushed it out as-is as a bug fix patch now; and will happilly make the
> above change on top. However, I've not understood what all the parameters
> are for in the process_XXXX() functions:
Yeah, never mind, your patch is fine. The process_xxx() parameters are
really only there so that process_tree() can generate the proper path and
names, and they are passed to process_blob/gitlink() just to make all the
processing look the same.
But it's nonsensical to do for the case of the index (although you could
pass a NULL path and the name from the index), and we haven't created the
object array there, so just ignore my suggestion - your original patch is
fine.
Linus
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Matthieu Moy @ 2007-07-02 20:54 UTC (permalink / raw)
To: Yann Dirson; +Cc: Christian Jaeger, git
In-Reply-To: <20070702204051.GP7730@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> That is, "git rm" will only ever remove the file without asking, when
> it is safe do so, in that you can retrieve your file from history. Or
> do you think of another way, in which more safety would be needed ?
Defaulting to --cached would be an obvious way to avoid data-loss.
_At least_, mentionning --cached in the error message in case of
staged changes would be a considerable step forward.
At the moment, the non-expert user will have difficulties to unversion
the file without deleting it. I just see it as
$ git rm foo
error: 'foo' has changes staged in the index
(hint: to hang yourself, try -f)
$ _
--
Matthieu
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Yann Dirson @ 2007-07-02 20:40 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git
In-Reply-To: <46895EA4.5040803@jaeger.mine.nu>
On Mon, Jul 02, 2007 at 10:23:00PM +0200, Christian Jaeger wrote:
> I don't per se require undo actions. I just don't understand why git-rm
> refuses to remove the file from the index, even if I didn't commit it.
I'd say it does so, so you won't loose any uncommitted changes without
knowing it - and "git add -f" is available when you have checked that
you indeed want to discard that data.
> The index is just an intermediate record of the changes in my
> understandings, and the rm action would also be intermediate until it's
> being committed. And a non-committed action being deleted shouldn't need
> a special confirmation from me, especially not one which is consisting
> of a combination of two flags (of which one is a destructive one).
It already works as such: it will warn you if you have already staged
the file in the index, but it has not been committed, in which case
the data would be lost as well:
$ echo foo > bar
/tmp/test$ git rm bar
fatal: pathspec 'bar' did not match any files
/tmp/test$ git add bar
/tmp/test$ git rm bar
error: 'bar' has changes staged in the index (hint: try -f)
That is, "git rm" will only ever remove the file without asking, when
it is safe do so, in that you can retrieve your file from history. Or
do you think of another way, in which more safety would be needed ?
Best regards,
--
Yann
^ permalink raw reply
* pushing a project started in git back to a subversion repository...
From: Patrick Doyle @ 2007-07-02 20:29 UTC (permalink / raw)
To: git
Well, I think I've parsed through the documentation and tips enough to
finally produce a script that does what I want it to do... and that
was: "I started a project, tracking the revisions with git, and I want
to track the changes and revisions on our company Subversion server."
Here is what I did:
1) packed up the existing git repository with "git-pack-objects"
$ git-rev-list master | git-pack-objects --revs --stdout > ../mypack
2) Used git-rev-list to find the name of first and last commits in my repo.
*** 1st question: ****
I can use
$ git-rev-list -n 1 master
to get the most recent commit. Is there a similar shortcut to get the
very first commit? (I used used "tail -1" to get the last line out of
git-rev-list
3) Cloned the SVN repository, which I had previously created with an
empty directory into which I wanted to import my new project
$ git-svn clone url://path/to/repo/topdir
4) unpacked the packfile into the new .git repo
$ cd topdir
$ git-unpack-objects < ../mypack
5) Created a .git/info/grafts file with the first commit from my old
.git repo grafted onto the single (empty directory) commit of this new
repo
$ echo XXX YYY > .git/info/grafts
6) Here's the scary part -- I overwrote .git/refs/heads/master with
the last commit from my old repo, so now "master" points to a chain of
commits going back to the beginning of time in the old repo and now
grafted onto the empty directory commit of my new repo.
**** 2nd question: ****
How many of you cringed when I said I did this? If so, why?
7) Fetched the files into my empy directory
$ git checkout
8) And committed them back to the SVN repo:
$ git-svn dcommit
**** Last question: ****
What happened to all of those objects I imported from the pack file?
I can still see them in the .git/objects/*/* directories, but they
don't show up in git-ls-revs. git-fsck doesn't report any errors.
git-gc seems like it packs them up -- I get 193 objects packed into
the pack file compared to 167 in a fresh clone of the (newly updated)
svn reposistory
I'm also curious what experts would think of my fumbling efforts to
transfer this git-managed project into a git/svn-managed project,
maintaining the initial history. Did I go tremendously out of my way
to do something that was a one-line command?
--wpd
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Christian Jaeger @ 2007-07-02 20:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070702194237.GN7730@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson wrote:
> On Mon, Jul 02, 2007 at 08:09:37PM +0200, Christian Jaeger wrote:
>
>> Why so complicated? Why not just make git-rm without options behave like
>> cg-rm? (Or at the very least, I'd change the hint to say "try -f --cached".)
>>
>
> It is probably a matter of taste. Personally, I am really upset by
> this behaviour that cvs, cogito, stgit and others share, which forces
> me to issue 2 commands to really delete a file from version control
> and from the filesystem.
>
It doesn't force you to issue 2 commands: the -f option to cg-rm unlinks
the file for you. So you only have to type an additional "-f".
Yes it's probably (partly) a matter of taste: in my bash startup files I
have mv aliased to mv -i and rm to rm -i, so that it asks me whether I'm
sure to delete or overwrite a file. If I know in advance that I'm sure,
I just type "rm -f $file", which then expands to "rm -i -f $file" where
the -f overrides the -i. cg-rm -f just fits very well into this scheme
(the only difference being that "cg-rm $file" doesn't explicitely ask me
whether I also want the file to be unlinked). (BTW note that usually for
removing a file I use a "trash" (or shorter alias "tra") command, which
moves it to a trash can instead of deleting; so I use "tra $file" by
default, and only for big files or when I'm sure I immediately want to
delete them, I use rm, and then if the paths are clear I add the -f
flag, if not (like globbing involved), I don't add the -f and thus am
asked for confirmation.)
If I could alias the git-rm command so that the default action is the
reverse of git-add and adding an -f flag removes it from disk, that
would be fine for me.
> Do you really need to undo an add more often than you need to remove a
> file from version-control ? It may be worth, however, to make things
> easier. Maybe "git add --undo foo" would be a solution ?
This doesn't sound very intuitive to me (and I couldn't fix it with an
alias).
I don't per se require undo actions. I just don't understand why git-rm
refuses to remove the file from the index, even if I didn't commit it.
The index is just an intermediate record of the changes in my
understandings, and the rm action would also be intermediate until it's
being committed. And a non-committed action being deleted shouldn't need
a special confirmation from me, especially not one which is consisting
of a combination of two flags (of which one is a destructive one).
Christian.
^ 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