* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 12:42 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <46A5DF1F.2030307@trolltech.com>
Hi,
On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
> The new-workdir feature doesn't *have* to be about symlinked .git/
> metainfo space, but could also be about symref'ed .git/ metainfo. (A
> discussion was done in 2005s "Getting rid of symlinks in .git?", but the
> conclusion was that it would slow it down too much? *ponder*)
Right. I would not do it as symrefs, but as a (potentially ugly, but
small) change to have the git_dir set to the shared one, and only in case
of config and HEAD resort to the new_worktree_git_dir.
This would probably be one variable in environment.c, exported in cache.h,
set in config.c (which would say "new_worktree_git_dir = get_git_dir();
setup_new_git_dir(value);"), and the appropriate special handling in
git_path() in path.c.
> I think you're right in that this is probably not the appropriate itch
> to scratch for a Windows developer to start with, and I have my own list
> of issues to work on when I get the time. File stat'ing
> (daemon/service), CRLF issues, de-SH'ifying commands, non-MinGW native
> build of Git, etc.. Lots to keep my fingers busy :-)
;-)
BTW a friend reported a CRLF issue on Windows, _in spite_ of setting the
gitattributes appropriately... Did you ever get something like that?
> Though, let me also say that I already love working with Git on Windows.
> And I thank each and every one who's working on it, for providing such
> an excellent tool.
Good to hear!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Robin Rosenberg @ 2007-07-24 12:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Simon 'corecode' Schubert, Jason Sewall, git, raa.lkml
In-Reply-To: <7v8x96glca.fsf@assigned-by-dhcp.cox.net>
tisdag 24 juli 2007 skrev Junio C Hamano:
> > Here CVS sleeps. The amount varies between invocations since it
> > only sleeps enough for the seconds to wrap.
>
> Makes one wonder what it would do if you are on a filesystem
> with coarser-than-a-second timestamp resolution.
Like fat, but then the last test fails on FAT, which wasn't the case. Any other reasonable file
systems that comes to your mind?
Jason, could you provide us with some more information on OS, fs, cvs version etc.
Whether timestamp granularity is larger than a second or not can be checked with this line, I think:
touch a && ls --full-time a && sleep 1 && touch a && ls --full-time a
Sample output where the timestamps are roughly one second apart.
-rw-r--r-- 1 me me 0 2007-07-24 14:15:47.330927250 +0200 a
-rw-r--r-- 1 me me 0 2007-07-24 14:15:48.338990250 +0200 a
-- robin
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-24 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0707241223440.14781@racer.site>
On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The really tedious part is the testing, and the verifying. Fortunately,
> Jon made up for my incapability in both areas, with an incredible
> patience.
I haven't finished checking every last line yet, if anything is left
it is small. We lost power here all evening last night. That's not
supposed to happen in urban Boston. It was black over a mile from me
in all directions.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* rfe: bisecting with a tristate
From: Jan Engelhardt @ 2007-07-24 13:21 UTC (permalink / raw)
To: git
Hi,
I have an idea about handling commits that do not compile at
all in git-bisect.
For example:
git bisect start
git bisect bad v2.6.23-rc1
# bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
git bisect good v2.6.22
# good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit
git bisect hands out. Now let's assume this commit would not compile.
What would the user do? git-bisect good or git-bisect bad?
Assume a commit previous to 1f..49 caused an oops (but the user does not
know yet), and the user said 'good' on 1f..49 because he did not know
what to say (since it did not compile). Then bisect would go the wrong
way, marking all left to 1f..49 as good.
Ideally, there should be like "git bisect dunno-try-left" and "git
bisect dunno-try-right", which allow the user to skip checking 1f..49
and instead try the next commit left or right of 1f..49 (to either go to
a commit before the compile failure, or after it).
[ What's `git-bisect next` for? ]
Jan
--
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 13:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <Pine.LNX.4.64.0707241337470.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]
> BTW a friend reported a CRLF issue on Windows, _in spite_ of
> setting the gitattributes appropriately... Did you ever get
> something like that?
Hmm, I haven't really had problems with the gitattributes files in the
directory of the file to be ignored, but rather .git/info/attributes.
There I have had problems with directories containing spaces. The
escaping of the spaces doesn't work, so even if you do
foo/bar\ baz/file.txt -crlf
it doesn't work. So, you have to do
foo/*/file.txt -crlf
instead.
I mainly have the problem with the following:
1) User on Windows is using MinGW port or Cygwin setup with
DOS EOL.
2) Has core.autocrlf=true
3) Files for XML testcases (for example) is checked into
repo on Linux (File contains CRLF EOL, since its crucial
for testing the XML parser)
4) git diff shows all lineending changed, since the
autocrlf tries to convert the files which are really
checked into the repo with DOS EOL.
5) You end up adding a bunch of
foo/bar/baz/* -crlf
into your .git/info/attributes file or the like.
So, it's look like this ('yes' mean CRLF EOL):
Repo | Working dir | Convert EOL?
---------------------------------
1) - LF no
2) - CRLF yes
3) LF LF no
4) LF CRLF yes
5) CRLF LF no
6) CRLF CRLF yes
The problem is that currently 6) is 'yes', and turns the file into a
LF file, which it shouldn't.
So, to fix the problem the crlf convertor should really check if the
file has crlf EOL in the repo, if so, avoid EOL conversion. (6) should
be 'no' :-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <46A5FDF0.3060801@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
Marius Storm-Olsen said the following on 24.07.2007 15:26:
> So, it's look like this ('yes' mean CRLF EOL):
Bah, ignore "('yes' mean CRLF EOL)". I rewrote the table and forgot to
nuke that part.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Sixt @ 2007-07-24 13:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241229170.14781@racer.site>
Johannes Schindelin wrote:
>
> Hi,
>
> On Tue, 24 Jul 2007, Johannes Sixt wrote:
>
> > Johannes Schindelin wrote:
> > > So really exclude excluded refs from being rewritten. This also allows
> > > you to safely call
> > >
> > > git filter-branch <some-filter> --all <rev-list options>
> > >
> > > to rewrite _all_ branches and tags.
> >
> > BTW, '--all' in the argument list of filter-branch works only if it is
> > preceded by '--':
> >
> > git filter-branch <some-filter> -- --all <rev-list options>
>
> Hmm. Maybe we should reconsider the logic. I.e. instead of
>
> *)
> usage
>
> *)
> break
That is not enough: This case block comes after a test that checks that
one additional argument is present, which would not be true anymore.
> > > @@ -181,6 +181,7 @@ export GIT_DIR GIT_WORK_TREE=.
> > >
> > > # These refs should be updated if their heads were rewritten
> > >
> > > +negatives="$(git rev-parse --revs-only "$@" | grep "^\^")"
> > > git rev-parse --revs-only --symbolic "$@" |
> > > while read ref
> > > do
> > > @@ -196,7 +197,13 @@ do
> > > grep "refs/\(tags\|heads\)/$ref$")"
> > > esac
> > >
> > > - git check-ref-format "$ref" && echo "$ref"
> > > + # make sure we have a valid ref
> > > + git check-ref-format "$ref" || continue
> > > +
> > > + # if the ref has been excluded by the other options, skip it
> > > + test -z "$(git rev-list -1 "$ref" $negatives)" && continue
> >
> > Does this catch my use-case with --since? I think not, because:
> >
> > $ git rev-parse --revs-only --since=2007.01.01 master topic
> > --max-age=1167606000
> > 257061f3323dc0162f731d934f0870e919211fdf
> > 3405729b94a654df8afbb9a1e13a4cf49a1c351c
> >
> > There are no negatives. Does it help to filter the non-positives?
> >
> > negatives=$(git rev-parse --revs-only "$@" | egrep -v '^[0-9a-f]{40}$')
> >
> > (Except the the '{40}' part is not portable. Hmpf.)
>
> To keep the "--since=..." we have to lose the "--revs-only"...
> Darn. I thought that "--since=" was expanded by rev-parse. FWIW this
> might work:
>
> negatives="$(git rev-parse "$@" | while read line
> do
> case "$line" in
> $_x40) ;;
> *) echo "$line";;
> esac
> done)"
>
> Can you please test? I am off for lunch.
This worked:
negatives=`git rev-parse --revs-only "$@" | while read line
do
case "$line" in
$_x40) ;;
*) echo "$line";;
esac
done`
i.e. the closing parenthesis in the case arms together with the opening
$( made for a syntax error. The --revs-only did not hurt in my tests,
but you may have other reasons to remove it.
But there's another problem. Consider this history:
---X--o--M <- master
\
...-o-...-o <- topic
Then this (rather contrieved) command:
$ git-filter-branch -n $n master topic --not X
If $n is small enough so that M is never rewritten, then
git rev-list -1 "$ref" $negatives
still expands to non-empty even for 'master' (= M), which then
incorrectly ends up in "$tempdir"/heads.
I think the decision whether a positive ref should be rewritten should
be postponed until the rewrite has completed. Because then we know for
certain which revs were treated and can pick the matching refs. We only
lose the check for the error "Which ref do you want to rewrite?"
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 13:33 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <46A5FDF0.3060801@trolltech.com>
Hi,
On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
> So, it's look like this ('yes' mean CRLF EOL):
> Repo | Working dir | Convert EOL?
> ---------------------------------
> 1) - LF no
> 2) - CRLF yes
> 3) LF LF no
> 4) LF CRLF yes
> 5) CRLF LF no
> 6) CRLF CRLF yes
>
> The problem is that currently 6) is 'yes', and turns the file into a LF file,
> which it shouldn't.
Shouldn't it? But then you should set core.autocrlf = false, no?
AFAIU the purpose of autocrlf is to _always_ have UNIX line endings in the
checked in stuff.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Sixt @ 2007-07-24 13:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241229170.14781@racer.site>
Johannes Schindelin wrote:
> negatives="$(git rev-parse "$@" | while read line
> do
> case "$line" in
> $_x40) ;;
> *) echo "$line";;
> esac
> done)"
Ah, and you must move the definition of _x40 up a couple of lines.
-- Hannes
^ permalink raw reply
* Re: rfe: bisecting with a tristate
From: Sean @ 2007-07-24 13:40 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707241459460.18990@fbirervta.pbzchgretzou.qr>
On Tue, 24 Jul 2007 15:21:19 +0200 (CEST)
Jan Engelhardt <jengelh@computergmbh.de> wrote:
Hi Jan,
> I have an idea about handling commits that do not compile at
> all in git-bisect.
> For example:
>
> git bisect start
> git bisect bad v2.6.23-rc1
> # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
> git bisect good v2.6.22
> # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
>
> Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit
> git bisect hands out. Now let's assume this commit would not compile.
> What would the user do? git-bisect good or git-bisect bad?
Check out the section "Avoiding to test a commit" in the git-bisect
man page; it addresses this issue. Basically you just use git-reset
to pick a different nearby commit to compile, and then continue with
git bisect good/bad.
>
> Assume a commit previous to 1f..49 caused an oops (but the user does not
> know yet), and the user said 'good' on 1f..49 because he did not know
> what to say (since it did not compile). Then bisect would go the wrong
> way, marking all left to 1f..49 as good.
>
> Ideally, there should be like "git bisect dunno-try-left" and "git
> bisect dunno-try-right", which allow the user to skip checking 1f..49
> and instead try the next commit left or right of 1f..49 (to either go to
> a commit before the compile failure, or after it).
>
Sean
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Schindelin @ 2007-07-24 13:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5FF69.F5D75C9E@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> >
> > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> >
> > > BTW, '--all' in the argument list of filter-branch works only if it
> > > is preceded by '--':
> > >
> > > git filter-branch <some-filter> -- --all <rev-list options>
> >
> > Hmm. Maybe we should reconsider the logic. I.e. instead of
> >
> > *)
> > usage
> >
> > *)
> > break
>
> That is not enough: This case block comes after a test that checks that
> one additional argument is present, which would not be true anymore.
Right.
> > > > @@ -181,6 +181,7 @@ export GIT_DIR GIT_WORK_TREE=.
> > > >
> > > > # These refs should be updated if their heads were rewritten
> > > >
> > > > +negatives="$(git rev-parse --revs-only "$@" | grep "^\^")"
> > > > git rev-parse --revs-only --symbolic "$@" |
> > > > while read ref
> > > > do
> > > > @@ -196,7 +197,13 @@ do
> > > > grep "refs/\(tags\|heads\)/$ref$")"
> > > > esac
> > > >
> > > > - git check-ref-format "$ref" && echo "$ref"
> > > > + # make sure we have a valid ref
> > > > + git check-ref-format "$ref" || continue
> > > > +
> > > > + # if the ref has been excluded by the other options, skip it
> > > > + test -z "$(git rev-list -1 "$ref" $negatives)" && continue
> > >
> > > Does this catch my use-case with --since? I think not, because:
> > >
> > > $ git rev-parse --revs-only --since=2007.01.01 master topic
> > > --max-age=1167606000
> > > 257061f3323dc0162f731d934f0870e919211fdf
> > > 3405729b94a654df8afbb9a1e13a4cf49a1c351c
> > >
> > > There are no negatives. Does it help to filter the non-positives?
> > >
> > > negatives=$(git rev-parse --revs-only "$@" | egrep -v '^[0-9a-f]{40}$')
> > >
> > > (Except the the '{40}' part is not portable. Hmpf.)
> >
> > To keep the "--since=..." we have to lose the "--revs-only"...
> > Darn. I thought that "--since=" was expanded by rev-parse. FWIW this
> > might work:
> >
> > negatives="$(git rev-parse "$@" | while read line
> > do
> > case "$line" in
> > $_x40) ;;
> > *) echo "$line";;
> > esac
> > done)"
> >
> > Can you please test? I am off for lunch.
>
> This worked:
>
> negatives=`git rev-parse --revs-only "$@" | while read line
> do
> case "$line" in
> $_x40) ;;
> *) echo "$line";;
> esac
> done`
>
> i.e. the closing parenthesis in the case arms together with the opening
> $( made for a syntax error. The --revs-only did not hurt in my tests,
> but you may have other reasons to remove it.
Funny. AFAIR something similar worked here, all the time. But I believe
you... you're on MinGW, right?
> But there's another problem. Consider this history:
>
> ---X--o--M <- master
> \
> ...-o-...-o <- topic
>
> Then this (rather contrieved) command:
>
> $ git-filter-branch -n $n master topic --not X
>
> If $n is small enough so that M is never rewritten, then
>
> git rev-list -1 "$ref" $negatives
>
> still expands to non-empty even for 'master' (= M), which then
> incorrectly ends up in "$tempdir"/heads.
Aaargh! Of course! Since I have to add --topo-order at the end.
Otherwise it makes no sense.
> I think the decision whether a positive ref should be rewritten should
> be postponed until the rewrite has completed. Because then we know for
> certain which revs were treated and can pick the matching refs. We only
> lose the check for the error "Which ref do you want to rewrite?"
No, that is not enough:
A - B - C
B touches the subdirectory sub/.
git filter-branch C -- sub/
will not rewrite C.
Besides, I really like the check for the error "Which ref do you want to
rewrite today?" early, instead of working for a long time, only to say
"there was nothing to rewrite, you idiot, you should have chosen the
arguments more carefully".
Ciao,
Dscho
^ permalink raw reply
* [REVISED PATCH] filter-branch: rewrite only unexcluded refs
From: Johannes Schindelin @ 2007-07-24 13:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5FF69.F5D75C9E@eudaptics.com>
The rev-list options can exclude some -- or all -- refs:
git filter-branch <some-filter> master ^master
Without this patch, these refs are assumed to be deleted, or worse, they
are rewritten to some bogus merge bases.
So really exclude excluded refs from being rewritten. This also allows
you to safely call
git filter-branch <some-filter> --all <rev-list options>
to rewrite _all_ branches and tags.
Thanks go to Johannes Sixt for help on the implementation and for testing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-filter-branch.sh | 16 +++++++++++++++-
t/t7003-filter-branch.sh | 9 +++++++++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 4fb3abe..3fa2f63 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -181,6 +181,14 @@ export GIT_DIR GIT_WORK_TREE=.
# These refs should be updated if their heads were rewritten
+negatives="`git rev-parse "$@" | while read line
+ do
+ case "$line" in
+ $_x40) ;;
+ *) echo "$line";;
+ esac
+ done`"
+
git rev-parse --revs-only --symbolic "$@" |
while read ref
do
@@ -196,7 +204,13 @@ do
grep -e "^refs/heads/$ref$" -e "^refs/tags/$ref$")"
esac
- git check-ref-format "$ref" && echo "$ref"
+ # make sure we have a valid ref
+ git check-ref-format "$ref" || continue
+
+ # if the ref has been excluded by the other options, skip it
+ test -z "$(git rev-list -1 "$ref" $negatives --topo-order)" && continue
+
+ echo "$ref"
done > "$tempdir"/heads
test -s "$tempdir"/heads ||
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index c9a820d..667eda7 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -164,4 +164,13 @@ test_expect_success 'only dwim refs/heads/$ref or refs/tags/$ref' '
git filter-branch -f master
'
+test_expect_success 'do not update uninteresting refs' '
+ branch=$(git rev-parse branch) &&
+ master=$(git rev-parse master) &&
+ git filter-branch -f --env-filter "GIT_AUTHOR_EMAIL=xy@probl.em" \
+ master ^removed-author branch &&
+ test $branch = $(git rev-parse branch) &&
+ test $master != $(git rev-parse master)
+'
+
test_done
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Schindelin @ 2007-07-24 13:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5FFBB.2F3B12CF@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > negatives="$(git rev-parse "$@" | while read line
> > do
> > case "$line" in
> > $_x40) ;;
> > *) echo "$line";;
> > esac
> > done)"
>
> Ah, and you must move the definition of _x40 up a couple of lines.
D'oh. Of course.
When I have more tests, and thought about the problem I hinted at in
another mail, I'll send a cleaned up patch series. Promised. Rebase -i
is good.
Ciao,
Dscho
---
git-filter-branch.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3fa2f63..8107a6c 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -11,6 +11,9 @@
USAGE="git-filter-branch [-d TEMPDIR] [FILTERS] DESTBRANCH [REV-RANGE]"
. git-sh-setup
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+
warn () {
echo "$*" >&2
}
@@ -322,8 +325,6 @@ done < "$tempdir"/heads
# Finally update the refs
-_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
-_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
count=0
echo
while read ref
^ permalink raw reply related
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Josef Weidendorfer @ 2007-07-24 13:47 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Julian Phillips, Marius Storm-Olsen, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707241336090.14781@racer.site>
On Tuesday 24 July 2007, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 24 Jul 2007, Julian Phillips wrote:
>
> > If you were going to avoid symlinks, then probably the cleanest way would be
> > to have an explict way to point at the actual repo - rather than making the
> > working look like a repo if you squint hard enough. Which sounds rather like
> > it would be an extension to GIT_DIR + GIT_WORK_TREE.
>
> Almost. .git/{config,HEAD} are not shared.
.git/index, too. And for .git/config, it would probably be better to merge the
two config's (the one from "realGitDir" with 2nd priority).
> So it would be some extension
> that is triggered by something like
>
> [core]
> realGitDir = /bla/bla/.git/
That is more or less almost exacty the last agreement about how to
implement the lightweight checkouts, a few months ago.
Should this even work recursively?
Josef
^ permalink raw reply
* Re: rfe: bisecting with a tristate
From: Johannes Schindelin @ 2007-07-24 13:52 UTC (permalink / raw)
To: Sean; +Cc: Jan Engelhardt, git
In-Reply-To: <20070724094017.d14688e5.seanlkml@sympatico.ca>
Hi,
On Tue, 24 Jul 2007, Sean wrote:
> > git bisect start
> > git bisect bad v2.6.23-rc1
> > # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
> > git bisect good v2.6.22
> > # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
> >
> > Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit
> > git bisect hands out. Now let's assume this commit would not compile.
> > What would the user do? git-bisect good or git-bisect bad?
>
> Check out the section "Avoiding to test a commit" in the git-bisect
> man page; it addresses this issue. Basically you just use git-reset
> to pick a different nearby commit to compile, and then continue with
> git bisect good/bad.
But a "git bisect dunno" would be handy.
However, it is a bit involved, since git-bisect.sh assumes that there is
only one bad commit, and with that, the outcome would be possibly a commit
range.
Two parts to it I see:
- builtin-rev-list.c:find_bisection() has to be told to ignore the dunno
commits when counting, in addition to uninteresting ones (but not stop
traversal). The easiest way I could see would be to add another option
to specify the dunno commits, and set a special flag on these.
- git-bisect.sh has to lose the assumption that there is only one bad
commit. Instead, it has to traverse the parent(s) of "the" bad commit,
until it finds either no parents, or a known good one. So maybe
something like
echo $(git rev-list --boundary $bad --not $good |
sed -n "s/^-/^/p") $bad
would be enough.
Hth,
Dscho
^ permalink raw reply
* workflow question
From: Patrick Doyle @ 2007-07-24 13:53 UTC (permalink / raw)
To: git
I'm still trying to figure out how to adapt my workflow to git or git
to my workflow, and I've come up with yet another question or two...
I tend to work detached from our central SVN server, and I'm attracted
to the fact that I can work on my laptop, commit changes as I go
along, and later synchronize them back to the server.
On my current project, I am sole developer (at present) and the
central SVN server serves primarly as an off-site backup and
historical archive.
Enough of the setup, here are the questions...
1) I would like to make a (git) branch on which I can commit
hourly/daily/periodically as I add in a new feature (so that I can
roll back to the "Gee, I thought it was behaving yesterday -- what
does that code look like?" commit when I need to), but I don't want to
send all of the "commit as of 12:32 on Thursday" commits back to the
SVN server when I'm done. Do I want to use a "squash" merge to merge
my changes back to the master branch before I synchronize with the
subversion server? Or do I use the "--no-commit" option to merge? Or
do I try something else? The first/last time I tried this, I ended up
with a fast-forward merge back into master, which included all of my
stupid little commit messages. I would rather one commit message that
read "Added XYZ feature".
2) When I don't fork a branch, and I don't commit until I've completed
the particular feature I'm working on, I can get a fairly good idea of
where I am and what I was doing last (which might be 5-7 days ago,
given high priority interrupts on other projects, summer vacations,
etc...) just by running a "git status". I see that there are 7 new
files, and 2 modified files. I know that, when I fork my branch, I
can use "git diff master" to see what's different between my branch
and the master, but then I get the diff of all of the changes as well,
which is too much information. "git diff --name-only" and "git diff
--summary" are closer, but I can't tell what's been added vs. what's
been changed. Any suggestions?
As an aside, is there an undocumented option to "git status" to
produce a less verbose report of what's been changed and what's not
checked in? Perhaps a single line per file with a one or two letter
indication of the status of the file followed by the name? If not,
would there be any violent objections to my submitting a patch to add
such a feature?
That's enough for now. Thanks for reading this far :-)
--wpd
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 13:54 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Julian Phillips, Marius Storm-Olsen, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <200707241547.16681.Josef.Weidendorfer@gmx.de>
Hi,
On Tue, 24 Jul 2007, Josef Weidendorfer wrote:
> On Tuesday 24 July 2007, Johannes Schindelin wrote:
>
> > On Tue, 24 Jul 2007, Julian Phillips wrote:
> >
> > > If you were going to avoid symlinks, then probably the cleanest way would be
> > > to have an explict way to point at the actual repo - rather than making the
> > > working look like a repo if you squint hard enough. Which sounds rather like
> > > it would be an extension to GIT_DIR + GIT_WORK_TREE.
> >
> > Almost. .git/{config,HEAD} are not shared.
>
> .git/index, too. And for .git/config, it would probably be better to merge the
> two config's (the one from "realGitDir" with 2nd priority).
I blame it on me being tired. .git/config _is_ shared, and I meant to
write "index" instead of "config" there. Not really a typo, is it?
> > So it would be some extension
> > that is triggered by something like
> >
> > [core]
> > realGitDir = /bla/bla/.git/
>
> That is more or less almost exacty the last agreement about how to
> implement the lightweight checkouts, a few months ago.
Oh? I saw no code... To me it is not an agreement, if no code comes out
of it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Sixt @ 2007-07-24 14:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241435290.14781@racer.site>
Johannes Schindelin wrote:
> On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > This worked:
> >
> > negatives=`git rev-parse --revs-only "$@" | while read line
> > do
> > case "$line" in
> > $_x40) ;;
> > *) echo "$line";;
> > esac
> > done`
> >
> > i.e. the closing parenthesis in the case arms together with the opening
> > $( made for a syntax error. The --revs-only did not hurt in my tests,
> > but you may have other reasons to remove it.
>
> Funny. AFAIR something similar worked here, all the time. But I believe
> you... you're on MinGW, right?
No. filter-branch is a shell script. I don't have time to waste ;)
It happens in bash 2.05b on Linux.
> > But there's another problem. Consider this history:
> >
> > ---X--o--M <- master
> > \
> > ...-o-...-o <- topic
> >
> > Then this (rather contrieved) command:
> >
> > $ git-filter-branch -n $n master topic --not X
> >
> > If $n is small enough so that M is never rewritten, then
> >
> > git rev-list -1 "$ref" $negatives
> >
> > still expands to non-empty even for 'master' (= M), which then
> > incorrectly ends up in "$tempdir"/heads.
>
> Aaargh! Of course! Since I have to add --topo-order at the end.
> Otherwise it makes no sense.
No, that was no my point: In my example above, if n=1, `git rev-list -1
"$ref" $negatives` evaluates to
$ git rev-list -1 "master" -n 1 ^X
which returns M, even though M is not going to be rewritten.
--topo-order changes nothing. The problem is that the -n is a relative
restriction. --since is turned into --max-age, which is absolute,
therefore, the test works as expected with --since.
> > I think the decision whether a positive ref should be rewritten should
> > be postponed until the rewrite has completed. Because then we know for
> > certain which revs were treated and can pick the matching refs. We only
> > lose the check for the error "Which ref do you want to rewrite?"
>
> No, that is not enough:
>
> A - B - C
>
> B touches the subdirectory sub/.
>
> git filter-branch C -- sub/
>
> will not rewrite C.
Fair enough.
-- Hannes
^ permalink raw reply
* SVN FAQ: svn revert replacement
From: Florian Weimer @ 2007-07-24 13:49 UTC (permalink / raw)
To: git
Just one nit: The correct replacement for "svn revert FILE" seems to
be:
$ git checkout HEAD -- FILE
The current suggestion, "git checkout FILE", does not work if the
modifications have been staged with "git add".
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Schindelin @ 2007-07-24 14:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A607EB.BA31D7C5@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> >
> > > But there's another problem. Consider this history:
> > >
> > > ---X--o--M <- master
> > > \
> > > ...-o-...-o <- topic
> > >
> > > Then this (rather contrieved) command:
> > >
> > > $ git-filter-branch -n $n master topic --not X
> > >
> > > If $n is small enough so that M is never rewritten, then
> > >
> > > git rev-list -1 "$ref" $negatives
> > >
> > > still expands to non-empty even for 'master' (= M), which then
> > > incorrectly ends up in "$tempdir"/heads.
> >
> > Aaargh! Of course! Since I have to add --topo-order at the end.
> > Otherwise it makes no sense.
>
> No, that was no my point: In my example above, if n=1, `git rev-list -1
> "$ref" $negatives` evaluates to
>
> $ git rev-list -1 "master" -n 1 ^X
>
> which returns M, even though M is not going to be rewritten.
> --topo-order changes nothing. The problem is that the -n is a relative
> restriction. --since is turned into --max-age, which is absolute,
> therefore, the test works as expected with --since.
So you think we have to say something like
git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue
?
I really should add a test case for that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Josef Weidendorfer @ 2007-07-24 14:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Julian Phillips, Marius Storm-Olsen, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707241453350.14781@racer.site>
On Tuesday 24 July 2007, Johannes Schindelin wrote:
> > > So it would be some extension
> > > that is triggered by something like
> > >
> > > [core]
> > > realGitDir = /bla/bla/.git/
> >
> > That is more or less almost exacty the last agreement about how to
> > implement the lightweight checkouts, a few months ago.
>
> Oh? I saw no code... To me it is not an agreement, if no code comes out
> of it.
Hmm. Probably depends on any real need for the feature agreed upon.
The new-workdir script simply was "good enough" with Linux.
Josef
^ permalink raw reply
* Re: [PATCH/RFH] Mark user-manual as UTF-8
From: J. Bruce Fields @ 2007-07-24 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin
In-Reply-To: <7vwswqgs6c.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 24, 2007 at 12:46:35AM -0700, Junio C Hamano wrote:
> There have been several complaints against k.org's user-manual
> page. The document is generated in ISO-8859-1 by the xsltproc
> toolchain (I suspect this is because released docbook.xsl we use
> has xsl:output element that says the output is ISO-8859-1) but
> server delivers it with "charset=UTF-8", and all h*ll breaks
> loose.
>
> This attempts to force UTF-8 on the generating end.
Thanks for looking into this! I've seen what I assume is the same
problem sporadically before and been unsuccesful at finding the
source....
--b.
^ permalink raw reply
* [PATCH] send-email: Update regex parsing for pine aliases
From: Kumar Gala @ 2007-07-24 14:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The pine address book format is tab seperated and the first field
is the nickname/alias and the third field is the email address as
per:
http://www.washington.edu/pine/tech-notes/low-level.html
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
git-send-email.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a09b1c9..f43f92f 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -237,7 +237,7 @@ my %parse_alias = (
$aliases{$1} = [ split(/\s+/, $2) ];
}}},
pine => sub { my $fh = shift; while (<$fh>) {
- if (/^(\S+)\s+(.*)$/) {
+ if (/^(\S+)\t.*\t(.*)$/) {
$aliases{$1} = [ split(/\s*,\s*/, $2) ];
}}},
gnus => sub { my $fh = shift; while (<$fh>) {
--
1.5.2.2
^ permalink raw reply related
* Re: git-send-email and pine alias format
From: Kumar Gala @ 2007-07-24 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodi2i97j.fsf@assigned-by-dhcp.cox.net>
On Mon, 23 Jul 2007, Junio C Hamano wrote:
> Kumar Gala <galak@kernel.crashing.org> writes:
>
> > I was wondering why we don't parse the pine alias format according to the
> > following spec:
> >
> > http://www.washington.edu/pine/tech-notes/low-level.html
> >
> > I'd expect something like, to get the address field.
>
> My guess is simply because we got a "works-for-us" regexp by
> observing the program's behaviour, done by real Pine users. On
> top of that, probably nobody knew and/or bothered to check if
> there is such "official spec" available.
>
> Could you send a signed and testable patch to the list so other
> Pine users can try it out please? After seeing a few Ack's on
> the list, I'd like to apply it and preferably do so before 1.5.3
> final.
Ok, done.
- k
^ permalink raw reply
* Re: [PATCH 1/5] Internationalization of git-gui
From: Shawn O. Pearce @ 2007-07-24 14:57 UTC (permalink / raw)
To: Christian Stimming; +Cc: Brett Schwarz, git, Paul Mackerras
In-Reply-To: <200707232123.01682.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:
> > > +## Internationalization (i18n) through msgcat and gettext. See
> > > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
> > > +package require msgcat
> > > +::msgcat::mcload [file join $oguilib msgs]
> > > +namespace import ::msgcat::mc
> >
> > Thanks. We'll probably also want to modify the lib/class.tcl to
> > import ::msgcat::mc ...
>
> As I was adding the markup in all the other files, I didn't have to add
> another import statement anywhere else. Seems like the global mc procedure
> works just fine.
>
> In other words, if you think the mc procedure should be imported in another
> place as well, please do so because I don't know your future plans with class
> structure (and I also don't need to know for adding the i18n support right
> now).
Hmm. Actually that makes sense. We probably don't need to make
any changes, other than to make sure we don't override the "mc"
definition in any of the other UI namespaces, since it is currently
being inherited from :: (the global namespace).
Thanks.
--
Shawn.
^ 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