* git cat-file blob does not convert crlf
From: Quim K. Holland @ 2008-11-26 19:34 UTC (permalink / raw)
To: git
I think git is buggy.
I wanted to discard the changes I made to my file by checking out a copy from the last commit, so I said
% git cat-file blob HEAD:my-file >my-file
But this does not respect core.autocrlf and the file becomes one long line.
Also it feels stupid that I have to say my-file twice at the command prompt.
^ permalink raw reply
* [PATCH] git-p4: fix keyword-expansion regex
From: Pete Wyckoff @ 2008-11-26 18:52 UTC (permalink / raw)
To: git
This text:
my $dir = $File::Find::dir;
return if ($dir !~ m,$options->{dirpat}$,);
was improperly converted to:
my $dir = $File$dir !~ m,$options->{dirpat}$,);
by the keyword identifier expansion code. Add a \n
to make sure the regex doesn't go across end-of-line
boundaries.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9b04ca5..09317af 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1005,7 +1005,7 @@ class P4Sync(Command):
if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
--
1.5.6.5
^ permalink raw reply related
* Re: format-patch problem when using relative
From: Nikola Knežević @ 2008-11-26 18:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081126180154.GA7584@coredump.intra.peff.net>
On 26 Nov 2008, at 19:01 , Jeff King wrote:
> So I think what you really want is:
>
> git format-patch --relative=click click/master myclick -- click
>
> to limit the path pruning to the 'click' directory.
Yes, that did the trick. Also, when I think about it, it makes sense -
do checks relative to a path, but prune using path.
Thanks,
Nikola
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-26 18:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811260931030.14328@xanadu.home>
Nicolas Pitre, Wed, Nov 26, 2008 15:33:51 +0100:
> On Wed, 26 Nov 2008, Alex Riesen wrote:
> > 2008/11/19 Nicolas Pitre <nico@cam.org>:
> > > I'm looking at it now. I'm therefore revoking my earlier ACK as well
> > > (better keep that test case alive).
> > >
> >
> > Any news here?
>
> Yes: my hard disk crashed a couple hours after I mentioned this, so most
> of my time has been spent on recovery since then. I'll come back to it
> eventually.
Heh... Good luck!
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-26 18:19 UTC (permalink / raw)
To: Git List
In-Reply-To: <20081120185628.GA25604@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Joey Hess wrote:
> Note that in both occasions that I've seen this failure, it has not been
> due to a missing directory, or bad permissions
Actually, it was due to bad permissions. :-) Once git was fixed to
actually say that, I figured out where to look to fix them.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 18:06 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492D0295.6060808@morey-chaisemartin.com>
Nicolas,
There is also at least two commands that I used often that are missing
to me:
$ git checkout -b branch_name branch_point
Which is equivalent to:
$ git branch branch_name branch_point
$ git checkout branch_name
The other missing command is:
$ git add [-p|-i]
Very important to create a set tightly related commits out of a dirty tree.
Maybe also adding a note about aliases:
$ git config --global alias.co checkout
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: format-patch problem when using relative
From: Jeff King @ 2008-11-26 18:01 UTC (permalink / raw)
To: Nikola Knežević; +Cc: git
In-Reply-To: <17081052-4480-4971-9F38-BD5C48087379@gmail.com>
On Wed, Nov 26, 2008 at 05:12:02PM +0100, Nikola Knežević wrote:
> git format-patch -o patches -n --relative=click click/master myclick
>
> This produced a bunch of files in patches directory, most of which are
> empty. When I tried this --stdout, I had something like this:
Hmm. It seems that there is no history pruning done with --relative, so
you will still end up with commits that make no changes. However, this
is intentional. See cd676a51:
diff --relative: output paths as relative to the current subdirectory
[...]
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
So I think what you really want is:
git format-patch --relative=click click/master myclick -- click
to limit the path pruning to the 'click' directory.
-Peff
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 17:59 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492D0295.6060808@morey-chaisemartin.com>
Nicolas,
You said that the form git-<cmd> version is deprecated. That's true. But
in the suit of the document you use only git-<cmd>. This is not working
anymore with recent Git version. I would recommend using only the "git
<cmd>" form.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 17:55 UTC (permalink / raw)
To: Johan Herland; +Cc: git, devel, Jean-Francois Veillette
In-Reply-To: <200811260955.57421.johan@herland.net>
Johan,
You said that the form git-<cmd> version is deprecated. That's true. But
in the suit of the document you use only git-<cmd>. This is not working
anymore with recent Git version. I would recommend using only the "git
<cmd>" form.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-26 17:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>
On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>> fails after squashing about 600 commits. Still investigating.
>
> 1500... wow.
>
> The best idea would probably be to just "edit" the first, delete the rest
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
> the command line (when git rebase stops after the "edit" command).
That worked, thanks! My original repo:
A -- B -- ... --- D --- E --- ...
where E and the rest of the commits (there are branches and merges in
there) are the ones that I need to preserve, but all the commits
between B and D can be squashed (~1500 of them). So I created a
branch:
A -- B -- ... --- D
then squashed the commits using the technique you described above, so
now I have:
A -- BD --
and now I would like to append "E -- ..." to it -- is there any way to
do that? I tried rebase, but that destroys all the branches and merges
and those are necessary to reproduce the fast-export bug.
>
> rebase -i was _never_ meant for such _massive_ interactions; that's just
> too much for a shell script.
In fact, I think it would work, but there is probably another bug,
that I am hitting, maybe due to whitespace problems --- in the
original repository, the patches are linear, but when I create a
branch before the failing patch and then cherry-pick it (that should
work), it fails and creates conflicts. The same behavior is with git
rebase. So I'll investigate more and report it in a separate thread,
as it is not related to fast-export.
Ondrej
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: David Brown @ 2008-11-26 17:15 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Nanako Shiraishi, git
In-Reply-To: <20081126133422.GA1761@coredump.intra.peff.net>
On Wed, Nov 26, 2008 at 08:34:23AM -0500, Jeff King wrote:
>> or to make the separation more evident:
>>
>> [master d9a5491] foo: bar
>
>Out of those suggestions, I find only the final one aesthetically
>acceptable. Nobody else has weighed in, so maybe they don't care. Or
>maybe they are just on vacation due to the (American) holiday.
Color certainly works well in the cases where that is available.
Otherwise, I prefer the above solution.
David
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 17:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Ondrej Certik, Git Mailing List, Fabian Seoane
In-Reply-To: <492D7CF5.1020202@drmicha.warpmail.net>
Hi,
On Wed, 26 Nov 2008, Michael J Gruber wrote:
> Looking at the source I suspect that fast-export fails to denote
> parenthood in the case of yet unmarked parents (last for-loop of
> handle_commit() in builtin_fast_export.c). But I don't really know that
> code at all.
I strongly doubt so. Noticed the use of has_unshown_parent(commit) in
both cases before calling handle_commit()?
In any case, here is a script that I wrote _long_ time ago, to be able to
reconstruct history from the output of "git rev-list --all --parents".
Maybe this helps you in reconstructing something that is handled
incorrectly by fast-export | fast-import, but is lighter than a full-blown
repository.
-- snip --
#!/bin/sh
# Given the output of git-rev-list, this reconstructs the DAG of the
history
i=0
tac | while read rev parents; do
let i=$i+1
echo $i > a1
git add a1
tree=$(git write-tree)
parents="$(for parent in $parents
do
echo -n "-p $(git rev-parse sp-$parent) "
done)"
commit=$(echo "$rev $i" | git commit-tree $tree $parents)
git tag sp-$rev $commit
done
-- snap --
Ciao,
Dscho
--
|
Ceci n'est pas une pipe
^ permalink raw reply
* [PATCH] t9129-git-svn-i18n-commitencoding: Make compare_svn_head_with() compatible with OSX sed
From: Marcel Koeppen @ 2008-11-26 16:51 UTC (permalink / raw)
To: gitster; +Cc: git
The sed call used in compare_svn_head_with() uses the + quantifier, which
is not supported in the OSX version of sed. It is replaced by the
equivalent \{1,\}.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
---
t/t9129-git-svn-i18n-commitencoding.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9129-git-svn-i18n-commitencoding.sh b/t/t9129-git-svn-i18n-commitencoding.sh
index 2848e46..938b7fe 100755
--- a/t/t9129-git-svn-i18n-commitencoding.sh
+++ b/t/t9129-git-svn-i18n-commitencoding.sh
@@ -16,7 +16,7 @@ compare_git_head_with () {
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
- sed -e 1,3d -e "/^-\+\$/d" >current &&
+ sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
--
1.6.0.4.771.gef3b3.dirty
^ permalink raw reply related
* Re: git fast-export | git fast-import doesn't work
From: Michael J Gruber @ 2008-11-26 16:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ondrej Certik, Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 26.11.2008 17:40:
> Hi,
>
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>> fails after squashing about 600 commits. Still investigating.
>
> 1500... wow.
>
> The best idea would probably be to just "edit" the first, delete the rest
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
> the command line (when git rebase stops after the "edit" command).
>
> rebase -i was _never_ meant for such _massive_ interactions; that's just
> too much for a shell script.
Or chop the DAG with grafts.
Removing the tags one by one I noticed that for several of them, removal
of the tag increases the number of commits on the connected DAG
component containing master (in the ex/imported repo), and that one
reaches the correct number with still a few tags left in there. Yet, the
topology is wrong in several places; I think all of them can be
attributed to missing parent info (which even creates new roots in some
places).
Looking at the source I suspect that fast-export fails to denote
parenthood in the case of yet unmarked parents (last for-loop of
handle_commit() in builtin_fast_export.c). But I don't really know that
code at all.
Michael
P.S.: That git repo itself is a product of
hg-fast-export|git-fast-import, right?
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Sixt @ 2008-11-26 16:35 UTC (permalink / raw)
To: Ondrej Certik
Cc: Michael J Gruber, Johannes Schindelin, Git Mailing List,
Fabian Seoane
In-Reply-To: <85b5c3130811260750y2e24436ye2426ccfc2f66071@mail.gmail.com>
Ondrej Certik schrieb:
> I am also trying to make the example simpler. I tried to squash the
> first uninteresting ~1500 commits into one, but "git rebase -i"
> uterrly fails after squashing about 600 commits. Still investigating.
Don't use rebase. Set a graft and rewrite the history:
$ echo $(git rev-parse HEAD) $(git rev-parse HEAD~1500) >> \
.git/info/grafts
Assuming "first 1500" means the "most recent 1500" commits. But you get
the idea. You can truncate history as well by omitting the second SHA1.
It's very convenient to keep gitk open and File->Reload after each graft
that you set.
When you're done with setting grafts:
$ git filter-branch -f --tag-name-filter cat -- --all
(You are doing this on a copy of your repository, don't you?)
-- Hannes
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 16:40 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811260750y2e24436ye2426ccfc2f66071@mail.gmail.com>
Hi,
On Wed, 26 Nov 2008, Ondrej Certik wrote:
> I am also trying to make the example simpler. I tried to squash the
> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
> fails after squashing about 600 commits. Still investigating.
1500... wow.
The best idea would probably be to just "edit" the first, delete the rest
of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
the command line (when git rebase stops after the "edit" command).
rebase -i was _never_ meant for such _massive_ interactions; that's just
too much for a shell script.
Ciao,
Dscho
^ permalink raw reply
* Re: French git user
From: Hannu Koivisto @ 2008-11-26 16:22 UTC (permalink / raw)
To: Johan Herland; +Cc: devel, git
In-Reply-To: <200811261123.56317.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Wednesday 26 November 2008, Nicolas Morey-Chaisemartin wrote:
>> Yes I say in french that git-foo is deprecated.
>> However I'm still using it in the following slides because people
>> have directly the good command to look at the man.
>> I know it's not really consistent but asI'd rahter keep it that way
>> and insist while presenting it, it should only be used for man pages.
>
> The man pages are also accessible _without_ using the "git-foo" form,
> either by doing "git foo --help" or "git help foo". I'd suggest using
> the "git foo" form, and using "git help foo" instead of "man git-foo".
Depending on the audience, one might want to mention that if you
are using a modern version of zsh as your shell and have activated
its run-help function (see
http://zsh.dotsrc.org/Doc/Release/zsh_24.html#SEC218), you can just
say
git foo -bar <M-h>
and you'll get git-foo manual page. When you exit man, you'll get
your command line back just like it was when you hit M-h. I think
it handles even "echo dum ; git foo <M-h>" kind of cases. You
can't live without it once you have tried it. Or the completion
with descriptions for options etc.
--
Hannu
^ permalink raw reply
* format-patch problem when using relative
From: Nikola Knežević @ 2008-11-26 16:12 UTC (permalink / raw)
To: git
Hi,
I have a subdirectory in my top-level directory, which I merged using
subtree strategy. I want to send my patches upstream, so I did
something like:
git format-patch -o patches -n --relative=click click/master myclick
This produced a bunch of files in patches directory, most of which are
empty. When I tried this --stdout, I had something like this:
[PATCH 8725/8846]
[PATCH 8726/8846]
[PATCH 8750/8846]
..
[PATCH 8845/8846]
So, it seems that format-patch was counting all patches, but only
printing the interesting ones.
I'm running git 1.6.0.1 on FreeBSD7/amd64.
PS. Please CC me, since I'm not on the list.
Cheers,
Nikola
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-26 15:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Git Mailing List, Fabian Seoane
In-Reply-To: <492D6CC3.2050408@drmicha.warpmail.net>
On Wed, Nov 26, 2008 at 4:35 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ondrej Certik venit, vidit, dixit 26.11.2008 11:18:
>> On Wed, Nov 26, 2008 at 10:35 AM, Ondrej Certik <ondrej@certik.cz> wrote:
>>> On Wed, Nov 26, 2008 at 1:14 AM, Johannes Schindelin
>>> <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Tue, 25 Nov 2008, Ondrej Certik wrote:
>>>>
>>>>> I would like to export our whole git repository to patches, and then
>>>>> reconstruct it again from scratch. Following the man page of "git
>>>>> fast-export":
>>>>>
>>>>> [...]
>>>>>
>>>>> However, the repository is very different to the original one. It
>>>>> contains only 191 patches:
>>>> Can you try again with a Git version that contains the commit
>>>> 2075ffb5(fast-export: use an unsorted string list for extra_refs)?
>>> I tried the next branch:
>>>
>>> $ git --version
>>> git version 1.6.0.4.1060.g9433b
>>>
>>> that contains the 2075ffb5 patch. I haven't observed any change ---
>>> the "git log" still only shows 191 commits (git log --all shows
>>> everything).
>>
>> I deleted all tags and then fast-exported and imported, now all the
>> commits show in "git log", however, the patches are wrongly connected.
>> Basically, both repositories are identical (including hashes) up to
>> this commit:
>>
>> d717177d4 (fixed downloads instructions in the README and a typo)
>>
>> However, the original repo (sympy-full-history-20081023) contains 3
>> children at this commit:
>
> There's some nice 3 way branching and double 2 way merging going on. I
> cut out the interesting part of the graph, making d717177d4 and
> 6e869485f parentless. The resulting mini DAG is reproduced correctly by
> export|import, even with -M -C.
I am also trying to make the example simpler. I tried to squash the
first uninteresting ~1500 commits into one, but "git rebase -i"
uterrly fails after squashing about 600 commits. Still investigating.
Ondrej
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Michael J Gruber @ 2008-11-26 15:35 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Johannes Schindelin, Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811260218s7529914eyb56a05ec1ca34b8f@mail.gmail.com>
Ondrej Certik venit, vidit, dixit 26.11.2008 11:18:
> On Wed, Nov 26, 2008 at 10:35 AM, Ondrej Certik <ondrej@certik.cz> wrote:
>> On Wed, Nov 26, 2008 at 1:14 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> Hi,
>>>
>>> On Tue, 25 Nov 2008, Ondrej Certik wrote:
>>>
>>>> I would like to export our whole git repository to patches, and then
>>>> reconstruct it again from scratch. Following the man page of "git
>>>> fast-export":
>>>>
>>>> [...]
>>>>
>>>> However, the repository is very different to the original one. It
>>>> contains only 191 patches:
>>> Can you try again with a Git version that contains the commit
>>> 2075ffb5(fast-export: use an unsorted string list for extra_refs)?
>> I tried the next branch:
>>
>> $ git --version
>> git version 1.6.0.4.1060.g9433b
>>
>> that contains the 2075ffb5 patch. I haven't observed any change ---
>> the "git log" still only shows 191 commits (git log --all shows
>> everything).
>
> I deleted all tags and then fast-exported and imported, now all the
> commits show in "git log", however, the patches are wrongly connected.
> Basically, both repositories are identical (including hashes) up to
> this commit:
>
> d717177d4 (fixed downloads instructions in the README and a typo)
>
> However, the original repo (sympy-full-history-20081023) contains 3
> children at this commit:
There's some nice 3 way branching and double 2 way merging going on. I
cut out the interesting part of the graph, making d717177d4 and
6e869485f parentless. The resulting mini DAG is reproduced correctly by
export|import, even with -M -C.
Michael
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Jakub Narebski @ 2008-11-26 15:07 UTC (permalink / raw)
To: git
In-Reply-To: <20081126133422.GA1761@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 26, 2008 at 01:06:34AM +0100, Santi Béjar wrote:
>
>> Maybe just use the output of "git branch -v":
>>
>> master d9a5491 foo: bar
>>
>> or even literally:
>>
>> * master d9a5491 [ahead 1] foo: bar
>>
>> or to make the separation more evident:
>>
>> [master d9a5491] foo: bar
>
> Out of those suggestions, I find only the final one aesthetically
> acceptable. Nobody else has weighed in, so maybe they don't care. Or
> maybe they are just on vacation due to the (American) holiday.
+1 for the last one.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Nicolas Pitre @ 2008-11-26 14:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0811260518o52adb107tbddafb324e7fd97b@mail.gmail.com>
On Wed, 26 Nov 2008, Alex Riesen wrote:
> 2008/11/19 Nicolas Pitre <nico@cam.org>:
> > On Wed, 19 Nov 2008, Johannes Sixt wrote:
> >> Alex Riesen schrieb:
> >> > 2008/11/19 Nicolas Pitre <nico@cam.org>:
> >> >> On Wed, 19 Nov 2008, Johannes Sixt wrote:
> >> >>> The work-around is to write the repacked objects to a file of a different
> >> >>> name, and replace the original after git-pack-objects has terminated.
> >> >>>
> >> >>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> >> >> Acked-by: Nicolas Pitre <nico@cam.org>
> >> >
> >> > Are you sure? Will it work in a real repository? Were noone does
> >> > rename the previous pack files into packtmp-something?
> >>
> >> Oh, the patch only works around the failure in the test case. In a real
> >> repository there is usually no problem because the destination pack file
> >> does not exist.
> >>
> >> The unusual case is where you do this:
> >>
> >> $ git rev-list -10 HEAD | git pack-objects foobar
> >>
> >> twice in a row: In this case the second invocation fails on Windows
> >> because the destination pack file already exists *and* is open. But not
> >> even git-repack does this even if it is called twice. OTOH, the test case
> >> *does* exactly this.
> >
> > OK.... Well, despite my earlier assertion, I think the above should be a
> > valid operation.
> >
> > I'm looking at it now. I'm therefore revoking my earlier ACK as well
> > (better keep that test case alive).
> >
>
> Any news here?
Yes: my hard disk crashed a couple hours after I mentioned this, so most
of my time has been spent on recovery since then. I'll come back to it
eventually.
Nicolas
^ permalink raw reply
* Re: French git user
From: Jean-Francois Veillette @ 2008-11-26 14:16 UTC (permalink / raw)
To: devel; +Cc: Johan Herland, git
In-Reply-To: <492D1779.8040807@morey-chaisemartin.com>
I've quickly read the document.
Many thanks Nicolas !
- jfv
Le 08-11-26 à 04:31, Nicolas Morey-Chaisemartin a écrit :
> Johan Herland a écrit :
>> On Wednesday 26 November 2008, Nicolas Morey-Chaisemartin wrote:
>>
>>> I've been allowed to share my presentation:
>>> http://nicolas.morey-chaisemartin.com/git_tuto.pdf
>>>
>>> Please send me any feedback, I'm always glad to imrpove my work.
>>>
>>
>> I have no knowledge of French, but on page 15 the command
>> "git-commit --append" is mentioned. There is no "--append"
>> option. I'm guessing the "--amend" option is meant instead.
>>
>> Also, the very next command is "git-revert COMIT_ID".
>> "COMIT_ID" should probably have an extra "M".
>>
>> Finally, on page 11, you say something about "git foo" vs.
>> "git-foo" (hopefully that the "git-foo" form is deprecated),
>> but in the rest of the presentation you use a mix of "git foo"
>> and "git-foo" (mostly "git-foo"). This seems inconsistent.
>>
>>
>> Have fun! :)
>>
>> ...Johan
>>
>>
>
>
> Thanks, good catch.
> Yes I say in french that git-foo is deprecated.
> However I'm still using it in the following slides because people have
> directly the good command to look at the man.
> I know it's not really consistent but asI'd rahter keep it that way
> and
> insist while presenting it, it should only be used for man pages.
>
> I added your vchanged and updated the pdf.
>
> Thanks
>
> Nicolas
> --
> 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: Unable to clone empty repositories remotely
From: Hannu Koivisto @ 2008-11-26 13:13 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660811251333u583468e0ma2846796ca9df68d@mail.gmail.com>
"Christian MICHON" <christian.michon@gmail.com> writes:
> On Tue, Nov 25, 2008 at 10:05 PM, Hannu Koivisto <azure@iki.fi> wrote:
>> Greetings,
>>
>> mkdir test
>> cd test
>> git init --bare --shared=group
>> cd ..
>> git clone test test2
>>
>> works, though clone says it cannot checkout, which is expected.
>> This is nevertheless very useful when you create a shared
>> repository for a new project; you can then create a personal clone
>> and start adding stuff to it. If, however, you normally work on
>> another machine and want to have your personal clone there
>> (i.e. git clone ssh://therepomachine/somewhere/test), cloning
>> doesn't work at all (tested with git 1.6.0.3.525.ge32c2 in Cygwin):
>>
>> Initialized empty Git repository in /cygdrive/c/temp/test/.git/
>> fatal: no matching remote head
>>
>> This behaviour isn't documented by either git-init(1) or
>> git-clone(1). I think it would be very convenient if this worked
>> for the reasons mentioned above. I'm sure you could create your
>> personal repository with git init and then git remote add the
>> shared repository to it but that's much more difficult.
>>
>> --
>> Hannu
>>
>> --
>> 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
>>
>
> how about creating at least 1 empty commit before any cloning ?
>
> wouldn't this solve the problem ?
No, it wouldn't. I don't doubt that there are workarounds - I
mentioned one possibility myself. Admittedly your workaround may
be more convenient than mine, but it's still a workaround.
Now that I think of it, I wonder if one could go one step further
in shared repository creation usability and make it possible to do
that git init step remotely as well (I mean, directly with a
one-step git command instead of ssh host "cd /repos ; mkdir foo ;
cd foo; git init ..."). Since git init doesn't take non-option
arguments, I suppose it could be extended to accept ssh (and file)
urls for this purpose? And maybe an option to create a
corresponding local clone at the same time.
--
Hannu
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Jeff King @ 2008-11-26 13:34 UTC (permalink / raw)
To: Santi Béjar; +Cc: Nanako Shiraishi, git
In-Reply-To: <adf1fd3d0811251606t7f49eb84y53075427859bd26a@mail.gmail.com>
On Wed, Nov 26, 2008 at 01:06:34AM +0100, Santi Béjar wrote:
> Maybe just use the output of "git branch -v":
>
> master d9a5491 foo: bar
>
> or even literally:
>
> * master d9a5491 [ahead 1] foo: bar
>
> or to make the separation more evident:
>
> [master d9a5491] foo: bar
Out of those suggestions, I find only the final one aesthetically
acceptable. Nobody else has weighed in, so maybe they don't care. Or
maybe they are just on vacation due to the (American) holiday.
-Peff
^ 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