* Re: Feedback outside of the user survey
From: Jeff King @ 2008-10-16 10:28 UTC (permalink / raw)
To: Richard Hartmann; +Cc: git
In-Reply-To: <2d460de70810160319r4bed8643g884508cdeba772@mail.gmail.com>
On Thu, Oct 16, 2008 at 12:19:36PM +0200, Richard Hartmann wrote:
> 1) A table/An overview along the lines of "So, you are used to
> foo and that is how you do it in git."
> For example "What is the equivalent of svn co" (yes, that is an
> easy one ;). This should not be limited to things git can do.
How about:
Git - SVN Crash Course
http://git.or.cz/course/svn.html
> 2) A use case repository. "So you want to merge two
> branches", etc. This would be a good place to explain the
> different ways git offers to do stuff, as well.
How about:
Git User's Manual
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
(though I do think a user-contributed "recipe" database might be useful.
Maybe such a thing even exists already and I don't know about it).
> 3) A tutorial. It does not even have to be as sophisticated
> as vimtutor. A simple text file specifying steps to do stuff
> would be enough.
How about:
The Git Tutorial
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
Is there something about these that doesn't meet your criteria? Or did
you not know about them (in which case, maybe we need to be more
prominently pointing to them)?
-Peff
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-16 10:30 UTC (permalink / raw)
To: Pedro Melo; +Cc: Lars Hoss, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <524C98C8-C3A5-4501-932A-2F0ACDE2886A@simplicidade.org>
Hi!
I've cloned git this morning in order to try a build from this.
But chances are small that it will make a difference. Because from
the portfile I can see that macports just downloads 1.6.0.2 release
and builds it without any special patches or configure options.
As I said before, 1.5.6 works fine for me. But why 1.6.0.2 does not
work on my box - I don't know yet. Since Pedro uses a case-insensitive
volume as well, the problem seems not be related to sensitve/insensitive.
Now that I have a git clone on my box I might try bisect as well.
Yours,
Lars
> On Oct 15, 2008, at 3:51 PM, Lars Hoss wrote:
>
>>> Works for me on Leopard
>>>
>>> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
>>> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
>>> Vienna:a pieter$ git st
>>> # On branch master
>>> # Changes to be committed:
>>> # (use "git reset HEAD <file>..." to unstage)
>>> #
>>> # new file: .gitmodules
>>> # new file: gitx
>>> #
>>> Vienna:a pieter$ git --version
>>> git version 1.6.0.2.415.gf9137
>>
>> My git version "1.6.0.2" says:
>>
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # new file: .gitmodules
>> # new file: lib
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # lib/
>> git --version
>> git version 1.6.0.2
>>
>> Git was build from macports.
>
> hmms.. Really, I know about fink and Macports and all others, but I'm
> using Mac OS X since version 10.1 (when compiling OSS software was
> near impossible due to Apple decisions) and I've always had better
> results with compiling my own than using any of those OSS repositories.
>
> I understand the appeal, it seems easier, but I would recommend that
> you compile yourself the software packages you depend on.
>
> Regarding git, I saw a git-build.sh script floating around. If you
> cannot find it, you might want to try my own recipe
> (http://tinyurl.com/4ayze6
> ). I compile git master every day (cron) and thats the one I use on my
> main machine.
>
> Best regards,
> --
> Pedro Melo
> Blog: http://www.simplicidade.org/notes/
> XMPP ID: melo@simplicidade.org
> Use XMPP!
>
>
>
^ permalink raw reply
* Re: --diff-filter=T does not list x changes
From: Jeff King @ 2008-10-16 10:22 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <871vyhbsys.fsf@cup.kalibalik.dk>
On Wed, Oct 15, 2008 at 08:42:35PM +0200, Anders Melchiorsen wrote:
> From documentation, I would expect --diff-filter to list changes in
> the execute bit, but it does not. I hear on #git that this is
> intended, though I still do not know how to filter on the execute bit.
> Is it impossible?
Looking at the code, I think it's impossible, and one would have to add
a new --diff-filter letter. However, at the very least, the
documentation should clarify this situation. The --diff-filter
explanation says:
Select only files [...] have their type (mode) changed (T) [...]
which to me indicates that your test case should work.
-Peff
^ permalink raw reply
* Feedback outside of the user survey
From: Richard Hartmann @ 2008-10-16 10:19 UTC (permalink / raw)
To: git
Hi all,
unfortunately, I did not know there was a survey, so I did not
participate in it.
I still want to give some feedback from my experiences with
git.
From browsing the results [1] of said survey, I see one
request being made a lot of times. It's basically my main
gripe with git, as well :)
git can do a lot of things, but, as a new user, you are never
quite sure where to start. Docs are geared towards advanced
users (which is fine), but there is no easy entry point (which
is bad).
I would suggest three approaches to fix this:
1) A table/An overview along the lines of "So, you are used to
foo and that is how you do it in git."
For example "What is the equivalent of svn co" (yes, that is an
easy one ;). This should not be limited to things git can do.
svn's ability to pull a subdirectory, which is, ttbomk, lacking
in git, should be included, as well. I am sure there are other
examples [2].
2) A use case repository. "So you want to merge two
branches", etc. This would be a good place to explain the
different ways git offers to do stuff, as well.
3) A tutorial. It does not even have to be as sophisticated
as vimtutor. A simple text file specifying steps to do stuff
would be enough.
Thanks,
Richard
[1] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.33.1.7.1
[2] http://www.survs.com/app/2/wo/7OeqmUsbjaDuuaLsOCLeSg/0.0.9.3.3.0.1.3.14.1.7.1
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Jeff King @ 2008-10-16 10:08 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, git, Arjen Laarhoven, Shawn O. Pearce,
Mike Ralphson
In-Reply-To: <bsftmRx17krWBpVlulipoJEO1fWsD0hZfF3HOZcajX6GV66RKW8W6A@cipher.nrlssc.navy.mil>
On Wed, Oct 15, 2008 at 10:35:30AM -0500, Brandon Casey wrote:
> 2) Do we want to stick with compat/regex on
>
> Darwin: Arjen
> FreeBSD: Jeff
> AIX: Mike
>
> now that the builtin funcname patterns have been converted to Extended
> Regular Expressions?
t4018 passes without compat/regex on FreeBSD. Is that a sufficient test?
-Peff
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-10-16 9:49 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Scott Chacon, Wincent Colaiuta, git
In-Reply-To: <20081016184239.6117@nanako3.lavabit.com>
On Thu, Oct 16, 2008 at 06:42:39PM +0900, Nanako Shiraishi wrote:
> Quoting Petr Baudis <pasky@suse.cz>:
> > On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
> >> I do wish that there wasn't this 'us vs them' mentality on this list,
> >> though. I think GitHub is doing some good things for the community,
> >> and I also think that 'the community' is bigger than this list.
> >
> > I think this last sentence is where we differ - for (most of?) us the
> > Git developers, 'the community' pretty much _is_ this list (with the IRC
> > channel as its casual extension).
>
> Curiously, whenever somebody says "git-scm.com is the official git homepage", you are not involved in the discussion. Could you share your position on this issue with the rest of the "community"?
To possibly save Junio some archives digging, he did share his
position in the original thread at
http://thread.gmane.org/gmane.comp.version-control.git/90079/focus=90167
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:49 UTC (permalink / raw)
To: Lars Hoss; +Cc: Richard Bubel, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <c84d2f2498509bfb916c060317892998.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 4:21 PM, Lars Hoss wrote:
> Ok, this might be the difference. I am pretty sure my
> filesystem is not case-sensitive (default?).
> At least "mkdir Foo" fails when "foo" exists.
My filesystem is Mac OS Extended (Journaled) case-insensitive like
yours, and submodules work.
Best regards,
>
>
> Yours,
> Lars
>
>> Hi,
>>
>> On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>>
>>>> Works for me on Leopard
>>>> [...]
>>>> Vienna:a pieter$ git --version
>>>> git version 1.6.0.2.415.gf9137
>>>
>>> My git version "1.6.0.2" says:
>>>
>>> # On branch master
>>> [...]
>>> git --version
>>> git version 1.6.0.2
>>>
>>> Git was build from macports.
>>
>>
>> works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
>> deviates from the default, it might be worth mentioning that the
>> filesystem in use here is the case-sensitive version of HFS+.
>>
>> Best Regards,
>> Richard
>>
>
>
> --
> 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
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:48 UTC (permalink / raw)
To: Lars Hoss; +Cc: Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
On Oct 15, 2008, at 3:51 PM, Lars Hoss wrote:
>> Works for me on Leopard
>>
>> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
>> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
>> Vienna:a pieter$ git st
>> # On branch master
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>> #
>> # new file: .gitmodules
>> # new file: gitx
>> #
>> Vienna:a pieter$ git --version
>> git version 1.6.0.2.415.gf9137
>
> My git version "1.6.0.2" says:
>
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: lib
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # lib/
> git --version
> git version 1.6.0.2
>
> Git was build from macports.
hmms.. Really, I know about fink and Macports and all others, but I'm
using Mac OS X since version 10.1 (when compiling OSS software was
near impossible due to Apple decisions) and I've always had better
results with compiling my own than using any of those OSS repositories.
I understand the appeal, it seems easier, but I would recommend that
you compile yourself the software packages you depend on.
Regarding git, I saw a git-build.sh script floating around. If you
cannot find it, you might want to try my own recipe (http://tinyurl.com/4ayze6
). I compile git master every day (cron) and thats the one I use on my
main machine.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: git-scm.com
From: Nanako Shiraishi @ 2008-10-16 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Scott Chacon, Wincent Colaiuta, git
In-Reply-To: <20081015172543.GX10544@machine.or.cz>
Quoting Petr Baudis <pasky@suse.cz>:
> On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
>> I do wish that there wasn't this 'us vs them' mentality on this list,
>> though. I think GitHub is doing some good things for the community,
>> and I also think that 'the community' is bigger than this list.
>
> I think this last sentence is where we differ - for (most of?) us the
> Git developers, 'the community' pretty much _is_ this list (with the IRC
> channel as its casual extension).
Curiously, whenever somebody says "git-scm.com is the official git homepage", you are not involved in the discussion. Could you share your position on this issue with the rest of the "community"?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pedro Melo @ 2008-10-16 9:43 UTC (permalink / raw)
To: Lars Hoss; +Cc: git
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 1:07 PM, Lars Hoss wrote:
> Greetings all,
>
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
I'm using 1.6.0.2.526.g5c283 on Leopard with lots of submodules
without any problems at all.
I was going to reply to your original message but it slipped my mind
(commuting et al).
Can you provide a sequence of commands that demonstrate the problem so
that I can try?
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-16 9:32 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Linus Torvalds, david, git
In-Reply-To: <4d8e3fd30810160142x36860354ka30375e3d21438ae@mail.gmail.com>
On Thu, 16 Oct 2008 10:42:13 +0200 "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> wrote:
> On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >> On Wed, 15 Oct 2008, Andrew Morton wrote:
> [...]
> >> Is "git checkout -f" part of the scripting? Or "git reset --hard"?
> >
> > well, this script has been hacked on so many times I'm not sure what
> > it does any more.
> >
> > Presently the main generate-a-diff function is
> >
>
> Hi Andrew,
> I was wondering whether you could share the scripts you built on top of git,
> you might get some useful suggestions from this list and they could be
> inspiration for further improvement in GIT (it just happened with this
> thread ;-)
oh gee, you don't want to look. It should all be in
http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
But really it's just the one script, pull-git-patches, below. That
thing's been hacked around so much that I daren't breathe on it.
Fortunately as long as Stephen Rothwell is producing linux-next I don't
have much need for it any more.
#!/bin/sh
GIT_TREE=/usr/src/git26
PULL=/usr/src/pull
git_header()
{
tree="$1"
echo GIT $(cat .git/refs/heads/$tree) $(cat .git/branches/$tree)
echo
}
# maybe use git clean -dqfx
doit()
{
tree=$1
upstream=$2
cd $GIT_TREE
git checkout -f "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
{
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
git diff --patch-with-stat ORIG_HEAD
} >$PULL/$tree.patch
{
echo DESC
echo $tree.patch
echo EDESC
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
} >$PULL/$tree.txt
git reset --hard "$upstream"
}
do_one()
{
tree=$1
upstream=$2
if [ ! -e $PULL/$tree.patch ]
then
echo "*** doing $tree, based on $upstream"
git branch -D $tree
doit $tree $upstream
else
echo skipping $tree
fi
}
mkdir -p $PULL
if [ $1"x" = "-x" ]
then
exit
fi
cd $GIT_TREE
git checkout -f master
cd /usr/src
if [ $# == 0 ]
then
trees=/usr/src/git-trees
else
trees="$1"
fi
if [ $# == 2 ]
then
do_one $1 $2
else
while read x
do
if echo $x | grep '^#.*' > /dev/null
then
true
else
do_one $x
fi
done < $trees
fi
^ permalink raw reply
* git-svn and svnsync
From: Andriy Gapon @ 2008-10-16 8:07 UTC (permalink / raw)
To: git
I did the following:
1. mirror svn repository using svnsync
2. clone the mirror with git-svn --use-svnsync-props and some tweaking[*]
3. run git svn info in the clone
4. get error "Unable to determine upstream SVN information from working
tree history"
git svn log and git svn rebase do not work either.
git log does work.
I have git version 1.6.0.2 (from FreeBSD ports).
[*] About the tweaking - I manually massaged config file to get the
branches I was interested in, so .git/config is this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
useSvnsyncProps = 1
url = file:///system/devel/svn/base
fetch = head:refs/remotes/trunk
fetch = stable/6:refs/remotes/stable_6
fetch = stable/7:refs/remotes/stable_7
fetch = releng/6.3:refs/remotes/releng_6_3
fetch = releng/6.4:refs/remotes/releng_6_4
fetch = releng/7.0:refs/remotes/releng_7_0
fetch = release/6.3.0:refs/remotes/release_6_3_0
fetch = release/7.0.0:refs/remotes/release_7_0_0
This is .git/svn/.metadata:
; This file is used internally by git-svn
; You should not have to edit it
[svn-remote "svn"]
reposRoot = file:///system/devel/svn/base
uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
svnsync-uuid = ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
svnsync-url = svn://svn.freebsd.org/base
So you can see the original svn repository URL.
git log reports svn info like the following:
git-svn-id: svn://svn.freebsd.org/base/stable/7@183898
ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
It seems that the problem is that the code in find_by_url() and/or
read_all_remotes() subroutines (in git-svn.perl) are not aware of
svnsync and do not realize an URL in logs and URL in svn-remote are
different.
BTW, I see that there is some special svm logic in read_all_remotes.
Thank you very much for any help in advance.
--
Andriy Gapon
^ permalink raw reply
* Re: Untracked working tree files
From: Paolo Ciarrocchi @ 2008-10-16 8:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, david, git
In-Reply-To: <20081015132309.76d3cc28.akpm@linux-foundation.org>
On Wed, Oct 15, 2008 at 10:23 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Wed, 15 Oct 2008, Andrew Morton wrote:
[...]
>> Is "git checkout -f" part of the scripting? Or "git reset --hard"?
>
> well, this script has been hacked on so many times I'm not sure what
> it does any more.
>
> Presently the main generate-a-diff function is
>
Hi Andrew,
I was wondering whether you could share the scripts you built on top of git,
you might get some useful suggestions from this list and they could be
inspiration for further improvement in GIT (it just happened with this
thread ;-)
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: [PATCH] parse-opt: migrate builtin-checkout-index.
From: Pierre Habouzit @ 2008-10-16 8:23 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1224111343-17433-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
On Wed, Oct 15, 2008 at 10:55:43PM +0000, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> NOTE: I introduced the force/quiet/not_new helper variables because they
> are originally bitfields, so passing their address is not possible. One
> could say that introducing helper functions for those as well would be
> nicer, but I think that would just make the code even longer with no
> good reason.
Well the alternative is to replace the bitfields with an enum, but it's
not always that nice as a result. C bit-fields sucks when it comes to
address them, it's silly not to be able to have the same as offsetof in
"bits" for a structure, but oh well.
> diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
> index 4ba2702..e241cd1 100644
> --- a/builtin-checkout-index.c
> +++ b/builtin-checkout-index.c
> @@ -40,6 +40,7 @@
> #include "cache.h"
> #include "quote.h"
> #include "cache-tree.h"
> +#include "parse-options.h"
>
> #define CHECKOUT_ALL 4
> static int line_termination = '\n';
> @@ -153,11 +154,55 @@ static void checkout_all(const char *prefix, int prefix_length)
> exit(128);
> }
>
> -static const char checkout_cache_usage[] =
> -"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
> +static const char * const builtin_checkout_index_usage[] = {
> + "git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...",
> + NULL
> +};
Since git checkout-index -h will show you all the options, I usually
prefer to use "[options] [--] <file>...", it's 10x as readable, and the
user will have the [options] detail just below.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Ingo Molnar @ 2008-10-16 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andrew Morton, david, Git Mailing List
In-Reply-To: <7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> When aborting a failed merge that has brought in a new path using "git
> reset --hard" or "git read-tree --reset -u", we used to first forget
> about the new path (via read_cache_unmerged) and then matched the
> working tree to what is recorded in the index, thus ending up leaving
> the new path in the work tree.
i've met this problem in various variants in the past few months, and i
always assumed that it's "as designed" - as Git's policy is to never
lose information unless forced to do so. (which i find very nice in
general, and which saved modification from getting lost a couple of
times in the past)
the situations where i end up with a messed up working tree [using
git-c427559 right now]:
- doing a conflicted Octopus merge will leave the tree in some weird
half-merged state, with lots of untracked working tree files that not
even a hard reset will recover from. The routine thing i do to clean
up is:
git reset --hard HEAD
git checkout HEAD .
git ls-files --others | xargs rm # DANGEROUS
doing git checkout -f alone is not enough, as there might be various
dangling files left around.
- git auto-gc thinking that it needs to do another pass in the middle
of a random git operation, but i dont have 10 minutes to wait so i
decide to Ctrl-C it.
- doing the wrong "git checkout" and then Ctlr-C-ing it can leave the
working tree in limbo as well, needing fixups. If i'm stuck between
two branches that rename/remove files it might need the full fixup
sequence above.
- if a testbox has a corrupted system clock, its git repo and the
kernel build can get confused. This is to be expected i think - but
the full sequence above will recover the corrupted tree. Not much Git
can do about this i guess.
Does your fix mean that all i have to do in the future is a hard reset
back to HEAD, and that dangling files are not supposed to stay around?
Ingo
^ permalink raw reply
* Re: git-svnimport.perl bug when copy source path has a revision
From: Pete Harlan @ 2008-10-16 6:43 UTC (permalink / raw)
To: Karl Chen; +Cc: Git mailing list
In-Reply-To: <quack.20081015T1211.lth8wsp65dk@roar.cs.berkeley.edu>
Karl Chen wrote:
> This looks like a bug in git-svnimport.perl. If a tag (or
> branch?) is created retroactively, git-svnimport doesn't respect
> the copy source revision.
>
> To reproduce:
>
> svnadmin create somerepo; export R=file://$PWD/somerepo
>
> svn co $R wc && cd wc
>
> mkdir trunk tags && svn add trunk tags && svn commit -m "" # rev 1
>
> cd trunk
> echo a > a
> echo b > b
> echo c > c
>
> svn add a && svn commit -m "commit a" # rev 2
> svn add b && svn commit -m "commit b" # rev 3
> # Copy from revision 2 instead of HEAD:
> svn cp -m "tag rev 2" $R/trunk@2 $R/tags/mytag # rev 4
> svn add c && svn commit -m "commit c" # rev 5
>
> svn ls $R/tags/mytag
> # Lists only 'a'
>
> mkdir /tmp/gitrepo && cd /tmp/gitrepo
> perl /usr/share/doc/git-core/contrib/examples/git-svnimport.perl $R
>
> git log mytag
> # 'mytag' includes "commit b"; it was created as if it were tagged
> # at r3; the "@2" was ignored.
If you replace this:
> perl /usr/share/doc/git-core/contrib/examples/git-svnimport.perl $R
with:
git svn init -T trunk -t tags $R
git svn fetch
git log tags/mytag
you get a log that doesn't include "commit b". (And it does include the
tag commit, as svn does.) tags/mytag is a branch, visibile via "git
branch -r", instead of a tag. I'm not fluent enough in git svn to know
if this is a bug or a feature.
According to git logs (8cb070a4, fee9832a), git-svnimport.perl hasn't
been maintained in a while, presumably because git svn provides a
superset of its functionality.
HTH,
--Pete
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Junio C Hamano @ 2008-10-16 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810151615550.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 Oct 2008, Junio C Hamano wrote:
>>
>> When aborting a failed merge that has brought in a new path using "git
>> reset --hard" or "git read-tree --reset -u", we used to first forget about
>> the new path (via read_cache_unmerged) and then matched the working tree
>> to what is recorded in the index, thus ending up leaving the new path in
>> the work tree.
>
> Looks good to me. And from my tests, I think "git checkout -f" didn't have
> this problem at all, because it ends up using not got read-tree, but doing
> its own "reset_tree()" that uses unpack_trees().
>
> I do wonder if "git reset" should perhaps be written in those terms,
> instead of just being a wrapper around git read-tree. But the patch looks
> fine.
Let's do this for 'maint' and I'll let others think about possible
improvements, then ;-).
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Alex Riesen @ 2008-10-16 6:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <7vabd5r1ss.fsf@gitster.siamese.dyndns.org>
2008/10/15 Junio C Hamano <gitster@pobox.com>:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Junio C Hamano, Wed, Oct 15, 2008 01:17:52 +0200:
>>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>> >
>>> > Otherwise the function sometimes fail to resolve obviously correct refnames,
>>> > because the string data pointed to by "ref" argument were reused.
>>> >
>>> But your patch instead rewrites the computation of str2 by bypassing the
>>> call to "another_function_that_uses_get_pathname()" and duplicating its
>>> logic, which I do not think is a viable approach in the longer term.
>>
>> There is not enough logic to bypass there. It's just a dumb sprintf!
>
> But didn't you lose call to cleanup_path()?
>
In this case?
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Junio C Hamano @ 2008-10-16 6:15 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0810152254i615bca9dye0aedd8689c946e7@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>
>>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>>
> Would you prefer to leave -v out?
Not at all.
Perhaps there is a deeper misunderstanding.
It makes perfect sense _at the end user interface level_ to have -v and -q
as two separate options, perhaps with "later one wins" semantics. Another
possible semantics is "-q and -v are mutually incompatible", but I think
"later one wins" makes it much more usable from the end user's point of view.
The only thing I was objecting to was your repeated (verbose || !quiet)
expression in the _implementation_, which would have been much easier to
read and maintain, if it were expressed as a single variable "verbosity"
that can have one of three values.
IOW,
static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
...
if (!strcmp("--quiet", arg))
verbosity = QUIET;
else if (!strcmp("--verbose", arg))
verbosity = VERBOSE;
else ...
...
if (verbosity > QUIET)
print informational message;
if (verbosity > NORMAL)
print verbose message;
See?
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-16 5:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprm1pfmd.fsf@gitster.siamese.dyndns.org>
On Thu, Oct 16, 2008 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Wed, Oct 15, 2008 at 9:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>>>
>>>> Junio, what's the status here? Do you want me to rework it
>>>> all with a new verbose/quiet log infrastructure or
>>>
>>> Not really.
>>
>> OK, when do you expect to cut 1.6.0.3? It's so simple
>> that I'd like to have it included in that revision.
>
> Hmm, I did not think this was a breakage that needs to be fixed on the
> maintenance track. git-pull does not know -q nor -v and teaching these
> new options to the command would be a feature enhancement, which by
> definition won't be in 1.6.0.3.
It's no breakage as the options did not exist before :-), yes.
>>> Using two variables to keep track of what is conceptually a tristate
>>> (quiet, normal and verbose) is insane, and I'd like to see that insanity
>>> fixed first in the patch, regardless of an elaborate "log infrastructure"
>>> you mentioned.
>>
>> I see what you mean. What about all other modules
>> with quiet/verbose doing it with two variables?
>
> Are they broken? If not, let's not touch them. On the other hand, let's
> avoid adding more.
Not really. After I fixed -q in clone/fetch Miklos Vajna came up
with --verbose for clone. I just thought if we come up with a
new way to handle this we should fix it everywhere -v and
-q are available and make it consistent.
>> I guess doing it with a single variable in pull first
>> as an example is what you're after, right?
>
> I did not actually mind the ones in 'git-pull' that much, as eventually
> the script will be rewritten in C by somebody anyway. The patch to
> builtin-fetch.c/builtin-merge.c is different, as the repetition of
> (verbose || !quiet) was quite noticeable.
I've added -v as it was added to clone in "[PATCH] Implement
git clone -v" and I wanted to be fair to the IDE developers.
Would you prefer to leave -v out?
> Why have we gone off-list, by the way?
I was not sure this is of interest to everybody.
We are now on-list again :-).
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Junio C Hamano @ 2008-10-16 5:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matt McCutchen, git
In-Reply-To: <48F5A590.3050905@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>
>> If that is the case what difference does your suggestion of not putting it
>> in test-lib.sh make? We discourage users from playing ACL games, and we
>> protect ourselves from such by making sure the trash directory used for
>> running tests are not contaminated with ACL. Wouldn't it make more sense
>> to do so for all the tests, so that future test writers do not have to
>> worry about it?
>
> We have to decide case by case. In the case of shared directories it makes
> sense to suggest "do not play ACL games". In other cases, however, this
> suggestion could not work out that well, and a workaround in the code is
> the better solutions. But we do not know what those other cases are, and
> the test suite may be a tool to uncover them.
Although I am not particularly interested in hypothetical case that does
not have concrete examples, I do not care deeply enough either. So let's
take this patch (with updated/corrected log message) that minimally covers
the parts that can be broken by ACL games.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-16 2:00 UTC (permalink / raw)
To: gitzilla
Cc: Jonathan del Strother, Alex Riesen, Git Mailing List,
Johannes Sixt
In-Reply-To: <48F67E09.90202@gmail.com>
>> Any further comments? I'm more than willing to implement this, but I
>> won't bother if there's no chance of getting it accepted as a patch.
>> Does no one else feel like at least having the option to enforce
>> whitespace consistency in git is a good thing? If not, I guess I'll
>> just muddle along without this feature instead of implementing it.
>
> I'm against including this in except as a sample smudge/clean script. Git is
> a content tracker; not the enforcement mechanism for individual project
> policies.
Alright. Fair enough.
^ permalink raw reply
* [PATCH maint 1/2] t4018-diff-funcname: rework negated last expression test
From: drafnel @ 2008-10-16 0:58 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <7vljwpr6lr.fsf@gitster.siamese.dyndns.org>
This test used the non-zero exit status of 'git diff' to indicate that a
negated funcname pattern, when placed last, was correctly rejected.
The problem with this is that 'git diff' always returns non-zero if it
finds differences in the files it is comparing, and the files must
contain differences in order to trigger the funcname pattern codepath.
Instead of checking for non-zero exit status, make sure the expected
error message is printed.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
This is not really a series, but I expect you'll apply both, so this
seems easier for both of us.
-brandon
t/t4018-diff-funcname.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 99fff97..72076ec 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -65,7 +65,8 @@ test_expect_success 'custom pattern' '
test_expect_success 'last regexp must not be negated' '
git config diff.java.funcname "!static" &&
- test_must_fail git diff --no-index Beer.java Beer-correct.java
+ git diff --no-index Beer.java Beer-correct.java 2>&1 |
+ grep "fatal: Last expression must not be negated:"
'
test_expect_success 'alternation in pattern' '
--
1.6.0.2.101.gb844
^ permalink raw reply related
* [PATCH maint 2/2] t4018-diff-funcname: demonstrate end of line funcname matching flaw
From: drafnel @ 2008-10-16 0:58 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <1224118730-24711-1-git-send-email-drafnel@gmail.com>
Since the newline is not removed from lines before pattern matching, a
pattern cannot match to the end of the line using the '$' operator without
using an additional operator which will indirectly match the '\n' character.
Introduce a test which should pass, but which does not due to this flaw.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
t/t4018-diff-funcname.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 72076ec..40a805a 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -69,6 +69,12 @@ test_expect_success 'last regexp must not be negated' '
grep "fatal: Last expression must not be negated:"
'
+test_expect_failure 'pattern which matches to end of line' '
+ git config diff.java.funcname "Beer$" &&
+ git diff --no-index Beer.java Beer-correct.java |
+ grep "^@@.*@@ Beer"
+'
+
test_expect_success 'alternation in pattern' '
git config diff.java.xfuncname "^[ ]*((public|static).*)$" &&
git diff --no-index Beer.java Beer-correct.java |
--
1.6.0.2.101.gb844
^ permalink raw reply related
* Re: builtin conversion between tabs and spaces
From: A Large Angry SCM @ 2008-10-15 23:34 UTC (permalink / raw)
To: Stefan Karpinski
Cc: Jonathan del Strother, Alex Riesen, Git Mailing List,
Johannes Sixt
In-Reply-To: <d4bc1a2a0810151602j56550c3di2f59f92039fa8243@mail.gmail.com>
Stefan Karpinski wrote:
> Any further comments? I'm more than willing to implement this, but I
> won't bother if there's no chance of getting it accepted as a patch.
> Does no one else feel like at least having the option to enforce
> whitespace consistency in git is a good thing? If not, I guess I'll
> just muddle along without this feature instead of implementing it.
I'm against including this in except as a sample smudge/clean script.
Git is a content tracker; not the enforcement mechanism for individual
project policies.
^ 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