* 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
* importing from svn to git:one repo or several?
From: David Frech @ 2007-07-02 20:15 UTC (permalink / raw)
To: git
I have an svn repo with several projects in it that I want to move to git.
Does it make more sense to import it into _one_ git repo (each project
as a branch) and then push/pull/copy each branch into its own git
repo, or to do the import several times, filtering the paths from svn,
and generating a _separate_ git repo each time?
Cheers,
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* being nice to patch(1)
From: Andrew Morton @ 2007-07-02 19:54 UTC (permalink / raw)
To: git
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":
|commit f98754960a9b25057ad5f249f877b3d6fab889ce
|Author: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|Date: Mon May 14 20:25:31 2007 +0900
|
| [SCSI] hptiop: convert to use the data buffer accessors
|
| - remove the unnecessary map_single path.
|
| - convert to use the new accessors for the sg lists and the
| parameters.
|
| Jens Axboe <jens.axboe@oracle.com> did the for_each_sg cleanup.
|
| Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
| Acked-by: HighPoint Linux Team <linux@highpoint-tech.com>
| Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|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
--------------------------
File to patch:
This I assume is because ^[ ]*<number>c<number> is a magic marker for
contextual diffs.
So... if someone is feeling really, really, really bored one day, it would
be nice to teach git to somehow escape such patch-magic-patterns in the
changelog when emitting plain old patches.
^ permalink raw reply
* [StGIT PATCH] Forbid the "series --all --short" combination.
From: Yann Dirson @ 2007-07-02 19:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
That combination would otherwise simply augment with hidden patches
the display we would have with --short, which does not seem useful,
but can be confusing.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
stgit/commands/series.py | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/series.py b/stgit/commands/series.py
index 0b3efe0..9e0b0ff 100644
--- a/stgit/commands/series.py
+++ b/stgit/commands/series.py
@@ -109,6 +109,9 @@ def func(parser, options, args):
"""
global crt_series
+ if options.all and options.short:
+ raise CmdException, 'combining --all and --short is meaningless'
+
# current series patches
if options.invisible:
applied = unapplied = []
^ permalink raw reply related
* git-fetch will leave a ref pointing to a tag
From: linux @ 2007-07-02 19:44 UTC (permalink / raw)
To: git; +Cc: linux
I did this while trying to force a fast-forward merge (I wanted an
error message if I had changes to merge), and got a somewhat obscure
error message:
$ git branch temp tags/v2.6.22-rc6
$ git fetch . tags/v2.6.22-rc7:temp
$ 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.
Also, should "git checkout" have complained?
^ permalink raw reply
* Re: git-rm isn't the inverse action of git-add
From: Yann Dirson @ 2007-07-02 19:42 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git
In-Reply-To: <46893F61.5060401@jaeger.mine.nu>
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.
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 ? Not sure
we'd want to add --undo to many git commands, though. Opinions ?
Best regards,
--
Yann
^ permalink raw reply
* challenges using fast-import and svn
From: David Frech @ 2007-07-02 19:26 UTC (permalink / raw)
To: git
I have an svn repo containing several small projects that is an odd
"shape" (in terms of directories) because of its history;
git-svnimport doesn't like the directory structure, and I wasn't able
to coax it to work.
I looked around for other options, and discovered fast-import (thanks
Shawn!). I decided that the "easiest" approach would be to parse the
svn dump file and feed the commits into fast-import.
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. ;-)
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.
This last thing is my main "question" to the list, although I'm
curious if anyone else has played with svn dump files, and whether my
approach makes sense.
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 could cache the directory contents in my code, but isn't that partly
what fast-import is good for?
Any thoughts are welcome.
Cheers,
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: git packages for RHEL5 [ WAS: FC6 now has git v1.5.2.2 ]
From: Thomas Glanzmann @ 2007-07-02 19:25 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: git
In-Reply-To: <1183397303.10996.6.camel@lt21223.campus.dmacc.edu>
Hello,
> The Fedora project builds a number of packages for RHEL, including
> Git. Instructions on accessing them here:
> http://fedoraproject.org/wiki/EPEL/FAQ#howtouse
incredible nice! Thanks for pointing me to it.
Thomas
^ permalink raw reply
* Re: [PATCH] gitweb: make search form generate pathinfo-style URLs
From: Matt McCutchen @ 2007-07-02 19:03 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <1183057027.6108.4.camel@mattlaptop2>
On Thu, 2007-06-28 at 14:57 -0400, Matt McCutchen wrote:
> The search form generated traditional-style URLs with a "p=" parameter
> even when the pathinfo feature was on. This patch makes it generate
> pathinfo-style URLs when appropriate.
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?
Thanks,
Matt
^ permalink raw reply
* git-rm isn't the inverse action of git-add
From: Christian Jaeger @ 2007-07-02 18:09 UTC (permalink / raw)
To: git
Hello
I'm coming from cogito. There you can run:
cg-add $file ; cg-rm $file
and everything is as before; it adds the file to the directory
index/cache, and just removes it again from the latter.
Whereas with git,
git-add $file; git-rm $file
is giving the error
error: '..file..' has changes staged in the index (hint: try -f)
And sure enough, git rm -f $file will remove the file from the index,
but also unlink it from the directory. (Ok, I did remember that cogito's
-f option is unlinking the file, so I was cautious and didn't try it on
an important file, but still...)
Turns out that
git rm -f --cached $file
will do the same action as cg-rm $file.
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".)
Christian.
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Jan Hudec @ 2007-07-02 18:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550707010909p4eba184ekff2025fb158a4aee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]
On Sun, Jul 01, 2007 at 18:09:37 +0200, Marco Costalba wrote:
> [...]
> QGit::run() and QGit::runAsync()
> [...]
>
> A bool is the only flag returned, because error detect is done at
> lower level, in MyProcess::sendErrorMsg() in file myprocess.cpp that
> handles the low level of running an external process and is called by
> run().
>
> In case of an error MyProcess::sendErrorMsg() is called to inform the
> GUI (a popup dialog box) about the error and the stderr output
> received.
Thanks. That's the bit I didn't see in MyProcess. Ok, so I'll simply return
from the function when some of the run()s return false.
> [...]
> Hope this helps.
Thanks.
> P.S: Why 'git-commit --amend -F' it's explicitely forbidden?
The logic for preparing the commit message seems to be incompatible in
git-commit.sh for some reason and whoever wrote it fobode those flags
together instead of making it compatible. In any case, the error is reported
in git-commit.sh:291-296:
case "$log_given" in
tt*)
die "Only one of -c/-C/-F/--amend can be used." ;;
*tm*|*mt*)
die "Option -m cannot be combined with -c/-C/-F/--amend." ;;
esac
And in any case the git policy is, that frontends should not be using
porcelain commands. What I would really like to see is something between
git-commit and git-commit-tree, that would:
- run pre-commit hook
- write-tree
- commit-tree
- update-ref
- rerere
- run post-commit hook
But it does not exist and git-gui obviously does that manually, so I did it
manually as well. Now I have to test it.
The other thing that didn't work (or at least from reading the code it seems
it couldn't) is commiting merges, because when commiting merge, filename
arguments are forbidden on git-commit.
Commiting merges will require some special handling, because you have to at
least commit all files that were merged. And you can't re-create pristine
index with read-tree the way normal commit does it either.
Unfortunately I don't fully understand -- and remember the right commands for
working with it -- the multi-stage index.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Update on builtin-commit
From: Kristian Høgsberg @ 2007-07-02 17:57 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: Johannes Schindelin, git
In-Reply-To: <1183397689.10996.11.camel@lt21223.campus.dmacc.edu>
On Mon, 2007-07-02 at 12:34 -0500, Jeffrey C. Ollie wrote:
> On Mon, 2007-07-02 at 18:02 +0100, Johannes Schindelin wrote:
> >
> > Hmm. Somehow I think that the getopt solution is not so bad at all. We'd
> > need some code in compat/, but since we're GPL, and there are so many
> > GPLed getopt versions out there, I don't see any obstacle there.
>
> If we are going to make this option parser into some complex
> general-purpose option parsing library let's not re-invent the wheel.
> Let's pick one of the GPL'd option parsing libraries and make it a
> dependency of Git.
I don't have much of an opinion here; as I've said before, my goal here
is to get commit ported to C, and I specifically don't want to block on
the option parser discussion reaching consensus. One thing I do not
want to do, though, is to explode the current table driven approach into
a gazillion strcmps. Other than that I'm open to porting it to an
external getopt dependency, adding the couple of missing features
Johannes mentioned (bundling and ordering), or just keeping it local to
builtin-commit.c as is.
That said, we're debating less than 100 lines of code. Adding the
bundling of short options and some kind of ordering mechanism would add
at most 20 more lines. Is it worth taking a getopt dependency for that?
Kristian
^ permalink raw reply
* Re: [RFC] Update on builtin-commit
From: Jeffrey C. Ollie @ 2007-07-02 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Kristian Høgsberg, git
In-Reply-To: <Pine.LNX.4.64.0707021758090.4071@racer.site>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
On Mon, 2007-07-02 at 18:02 +0100, Johannes Schindelin wrote:
>
> Hmm. Somehow I think that the getopt solution is not so bad at all. We'd
> need some code in compat/, but since we're GPL, and there are so many
> GPLed getopt versions out there, I don't see any obstacle there.
If we are going to make this option parser into some complex
general-purpose option parsing library let's not re-invent the wheel.
Let's pick one of the GPL'd option parsing libraries and make it a
dependency of Git.
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git packages for RHEL5 [ WAS: FC6 now has git v1.5.2.2 ]
From: Jeffrey C. Ollie @ 2007-07-02 17:28 UTC (permalink / raw)
To: git
In-Reply-To: <20070702172049.GA1126@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Mon, 2007-07-02 at 19:20 +0200, Thomas Glanzmann wrote:
> Hello,
> has someone build git packages for RHEL5 or ever tried to do so?
The Fedora project builds a number of packages for RHEL, including Git.
Instructions on accessing them here:
http://fedoraproject.org/wiki/EPEL/FAQ#howtouse
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git packages for RHEL5 [ WAS: FC6 now has git v1.5.2.2 ]
From: Thomas Glanzmann @ 2007-07-02 17:20 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0707021009y20eb0e14n32a2c5e2abe812fe@mail.gmail.com>
Hello,
has someone build git packages for RHEL5 or ever tried to do so?
Thomas
^ permalink raw reply
* FC6 now has git v1.5.2.2
From: Patrick Doyle @ 2007-07-02 17:09 UTC (permalink / raw)
To: git
If anybody is interested...
...at least that's what the bugzilla response to my RFE bug report
implies. I'll know for certain once I get back outside of my
company's manically restrictive firewall and and do an update (which
will happen long before I figure out how to fix yum to work through
the firewall).
--wpd
---------- Forwarded message ----------
From: bugzilla@redhat.com <bugzilla@redhat.com>
Date: Jul 2, 2007 12:24 PM
Subject: [Bug 245598] RFE: Upgrade to v1.5.2.2
To: wpdster@gmail.com
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: RFE: Upgrade to v1.5.2.2
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245598
jbowes@redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |CLOSED
Resolution| |NEXTRELEASE
AssignedTo|chrisw@redhat.com |jbowes@redhat.com
------- Additional Comments From jbowes@redhat.com 2007-07-02 12:23 EST -------
Ok, built for FC6
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
^ permalink raw reply
* Re: [RFC] Update on builtin-commit
From: Johannes Schindelin @ 2007-07-02 17:02 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1183395082.30611.16.camel@hinata.boston.redhat.com>
Hi,
On Mon, 2 Jul 2007, Kristian H?gsberg wrote:
> On Mon, 2007-07-02 at 17:11 +0100, Johannes Schindelin wrote:
> > just a quick comment on the option parser:
> >
> > On most platforms, sizeof(void*)>=sizeof(int). But I would not rely on
> > that. Rather (also because it is prettier), I'd use "union".
>
> In the OPTION_INTEGER case, the 'value' void pointer points to an
> integer global that's set to the value passed. In the OPTION_NONE, it
> also points to an integer, which is set to 1 if the option is seen. So
> I'm relying on sizeof(void*) == sizeof(int*), but I'm not storing ints
> in pointers.
Ah, right.
> > Besides, your option parser loses order information, correct? IOW,
> > something like "--color --no-color --color" would confuse it.
>
> Yes, I don't record the order of options, but in the builtin-commit
> case, I don't think there are any options where that makes a difference?
That might be correct now. But why not make the option parser general
enough to (finally!) support something like "git clone -lns <directory>",
i.e. short options a la GNU? This is something that has been wanted for a
long time.
Besides, if you make the option parser not general enough to be reused in
all git programs, I wonder why bother at all? It's not like it is less
complex than a hand-rolled option parser, if it is used only once.
> In cases where order is important or we have an option that negates the
> effect of another option (your --no-color example), we could either 1)
> extend the option struct with a 'disable' name that flips the value back
> to 0 or 2) instead of just setting it to 1, record the index of the
> options passed and compare the indexes of conflicting options to see
> which one was passed last.
Hmm. Somehow I think that the getopt solution is not so bad at all. We'd
need some code in compat/, but since we're GPL, and there are so many
GPLed getopt versions out there, I don't see any obstacle there.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-fsck: add --lost-found option
From: Johannes Schindelin @ 2007-07-02 16:53 UTC (permalink / raw)
To: git, gitster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 7057 bytes --]
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.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Even adding a test script, and changing C code, this removes more
lines than it adds...
Something we might want to do, however, is to add a warning if the
user said --lost-found without --no-reflogs.
Documentation/cmd-list.perl | 1 -
Documentation/git-fsck.txt | 6 ++-
Documentation/git-lost-found.txt | 77 --------------------------------------
Makefile | 2 +-
builtin-fsck.c | 20 ++++++++++
t/t1420-lost-found.sh | 35 +++++++++++++++++
6 files changed, 61 insertions(+), 80 deletions(-)
delete mode 100644 Documentation/git-lost-found.txt
create mode 100755 t/t1420-lost-found.sh
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index f50f613..9cae338 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -123,7 +123,6 @@ git-instaweb ancillaryinterrogators
gitk mainporcelain
git-local-fetch synchingrepositories
git-log mainporcelain
-git-lost-found ancillarymanipulators
git-ls-files plumbinginterrogators
git-ls-remote plumbinginterrogators
git-ls-tree plumbinginterrogators
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/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt
deleted file mode 100644
index e48607f..0000000
--- a/Documentation/git-lost-found.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-git-lost-found(1)
-=================
-
-NAME
-----
-git-lost-found - Recover lost refs that luckily have not yet been pruned
-
-SYNOPSIS
---------
-'git-lost-found'
-
-DESCRIPTION
------------
-Finds dangling commits and tags from the object database, and
-creates refs to them in the .git/lost-found/ directory. Commits and
-tags that dereference to commits are stored in .git/lost-found/commit,
-and other objects are stored in .git/lost-found/other.
-
-
-OUTPUT
-------
-Prints to standard output the object names and one-line descriptions
-of any commits or tags found.
-
-EXAMPLE
--------
-
-Suppose you run 'git tag -f' and mistype the tag to overwrite.
-The ref to your tag is overwritten, but until you run 'git
-prune', the tag itself is still there.
-
-------------
-$ git lost-found
-[1ef2b196d909eed523d4f3c9bf54b78cdd6843c6] GIT 0.99.9c
-...
-------------
-
-Also you can use gitk to browse how any tags found relate to each
-other.
-
-------------
-$ gitk $(cd .git/lost-found/commit && echo ??*)
-------------
-
-After making sure you know which the object is the tag you are looking
-for, you can reconnect it to your regular .git/refs hierarchy.
-
-------------
-$ git cat-file -t 1ef2b196
-tag
-$ git cat-file tag 1ef2b196
-object fa41bbce8e38c67a218415de6cfa510c7e50032a
-type commit
-tag v0.99.9c
-tagger Junio C Hamano <junkio@cox.net> 1131059594 -0800
-
-GIT 0.99.9c
-
-This contains the following changes from the "master" branch, since
-...
-$ git update-ref refs/tags/not-lost-anymore 1ef2b196
-$ git rev-parse not-lost-anymore
-1ef2b196d909eed523d4f3c9bf54b78cdd6843c6
-------------
-
-Author
-------
-Written by Junio C Hamano 濱野 純 <junkio@cox.net>
-
-Documentation
---------------
-Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-
-GIT
----
-Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index d7f686a..d4633bc 100644
--- a/Makefile
+++ b/Makefile
@@ -215,7 +215,7 @@ SCRIPT_SH = \
git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh git-submodule.sh \
+ git-quiltimport.sh git-submodule.sh \
git-filter-branch.sh \
git-stash.sh
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 944a496..a530700 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,10 @@ int cmd_fsck(int argc, char **argv, const char *prefix)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--lost-found")) {
+ 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.3295.g8c6d-dirty
^ permalink raw reply related
* Re: [RFC] Update on builtin-commit
From: Kristian Høgsberg @ 2007-07-02 16:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707021709120.4071@racer.site>
On Mon, 2007-07-02 at 17:11 +0100, Johannes Schindelin wrote:
> just a quick comment on the option parser:
>
> On most platforms, sizeof(void*)>=sizeof(int). But I would not rely on
> that. Rather (also because it is prettier), I'd use "union".
In the OPTION_INTEGER case, the 'value' void pointer points to an
integer global that's set to the value passed. In the OPTION_NONE, it
also points to an integer, which is set to 1 if the option is seen. So
I'm relying on sizeof(void*) == sizeof(int*), but I'm not storing ints
in pointers.
> Besides, your option parser loses order information, correct? IOW,
> something like "--color --no-color --color" would confuse it.
Yes, I don't record the order of options, but in the builtin-commit
case, I don't think there are any options where that makes a difference?
In cases where order is important or we have an option that negates the
effect of another option (your --no-color example), we could either 1)
extend the option struct with a 'disable' name that flips the value back
to 0 or 2) instead of just setting it to 1, record the index of the
options passed and compare the indexes of conflicting options to see
which one was passed last.
Kristian
^ permalink raw reply
* [PATCH] Correctly document the name of the global excludes file configuration
From: Michael Hendricks @ 2007-07-02 16:48 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Michael Hendricks
Signed-off-by: Michael Hendricks <michael@ndrix.org>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 50503e8..1d96adf 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -275,7 +275,7 @@ You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
-core.excludeFile::
+core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
of files which are not meant to be tracked. See
--
1.5.2.2.238.g7cbf2f2
^ permalink raw reply related
* Re: t3902-quoted.sh broken on cygwin
From: Brian Gernhardt @ 2007-07-02 16:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0707020146x74f1a707na27cc3e5e16f75ad@mail.gmail.com>
On Jul 2, 2007, at 4:46 AM, Alex Riesen wrote:
> ... and I suspect it is broken on MacOSX as well.
> I suggest we disable the test completely on Cygwin/MinGW,
> and after a test of course, on MacOSX.
The only test that is broken for me (on OS X) is t9400 (9, 11,13).
t3902 goes by without a problem.
The filenames in there must use the same normalized form as OS X does
internally.
~~ Brian
^ permalink raw reply
* Re: [RFC] Update on builtin-commit
From: Johannes Schindelin @ 2007-07-02 16:11 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11833861634103-git-send-email-krh@redhat.com>
Hi,
just a quick comment on the option parser:
On most platforms, sizeof(void*)>=sizeof(int). But I would not rely on
that. Rather (also because it is prettier), I'd use "union".
Besides, your option parser loses order information, correct? IOW,
something like "--color --no-color --color" would confuse it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Theodore Tso @ 2007-07-02 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707021654450.4071@racer.site>
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.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH] Make '!' aliases more useful
From: Johannes Schindelin @ 2007-07-02 15:55 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, gitster
In-Reply-To: <20070702145549.GB4720@thunk.org>
Hi,
On Mon, 2 Jul 2007, Theodore Tso wrote:
> On Sun, Jul 01, 2007 at 10:51:58PM +0100, Johannes Schindelin wrote:
> >
> > When an alias starts with an exclamation mark, the rest is interpreted
> > as a shell command. However, all arguments passed to git used to be
> > ignored.
> >
> > Now you can have an alias like
> >
> > $ git config alias.e '!echo'
> >
> > and
> >
> > $ git e Hello World
> >
> > does what you expect it to do.
>
> 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.
Ciao,
Dscho
^ permalink raw reply
* RE: [PATCH] git-submodule: Try harder to describe the status of a submodule
From: Medve Emilian-EMMEDVE1 @ 2007-07-02 15:44 UTC (permalink / raw)
To: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E27011CFFED@az33exm24.fsl.freescale.net>
Hello Junio,
I noticed the 1.5.2.3 tag and the plans for 1.5.3-rc1 and I was
wondering when do you think you'll apply your submodule patch? Is there
any way I can help with it?
Thanks,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Medve Emilian-EMMEDVE1
Sent: Thursday, June 28, 2007 8:01 AM
To: git@vger.kernel.org
Subject: RE: [PATCH] git-submodule: Try harder to describe the status of
a submodule
Hello Junio,
Alright, let's go with your patch.
Cheers,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Wednesday, June 27, 2007 11:25 PM
To: Medve Emilian-EMMEDVE1
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-submodule: Try harder to describe the status of
a submodule
Emil Medve <Emilian.Medve@Freescale.com> writes:
> Some repositories might not use/have annotated tags (for example
repositories created with
> git-cvsimport) or might not have tags at all and could cause
git-submodule status to fail because
> git-describe might fail.
>
> This change makes git-submodule status try harder in displaying the
status of a module by
> considering lightweight tags, subsequent tags and branches.
Why are we suddenly seeing these loooooooong lines...
> +get_revname()
> +{
> + _revname=$(git-describe --tags "$1" 2>/dev/null || git-describe
--contains "$1" 2>/dev/null)
> + if test -z "$_revname" -o "$_revname" = "undefined"
> + then
> + _revname=$(git-describe --all "$1" 2>/dev/null | cut -d
/ -f2-)
> + test -z "$_revname" && _revname=undefined
> + fi
I really do not think using --all is useful. If you do not have
a tag and the rev cannot be described, what damage does it incur?
We still say "$sha1 $path" in the output anyway, and ($revname)
is only "it makes it nicer" appendix.
> @@ -155,7 +174,7 @@ modules_list()
> say "-$sha1 $path"
> continue;
> fi
> - revname=$(unset GIT_DIR && cd "$path" && git-describe
$sha1)
> + revname=$(unset GIT_DIR && cd "$path" && get_revname
$sha1)
> if git diff-files --quiet -- "$path"
> then
> say " $sha1 $path ($revname)"
In that sense, I would prefer mine much better. If a rev is
indescribable, your version would say:
" dddddddddddddddddddddddddddddddddddddddd subdir (undefined)"
while mine would have said:
" dddddddddddddddddddddddddddddddddddddddd subdir"
^ 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