* 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 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 12:37 UTC (permalink / raw)
To: Julian Phillips; +Cc: Marius Storm-Olsen, Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk>
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. So it would be some extension
that is triggered by something like
[core]
realGitDir = /bla/bla/.git/
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 12:28 UTC (permalink / raw)
To: Julian Phillips; +Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
>> 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*)
>
> Symref'ed isn't really the right term ... we're not talking about
> refs here. You would have to basically implement symlinks _inside_
> git ...
Yes, sorry for mixing up the terms here.
> New-workdir really _is_ all about symlinks. It already exists as a
> contrib feature - and moving it into core is (as I understand it)
> really just moving it, not redesigning.
Yes, if simply moving into is core is good enough. IMHO since its
based largely on FS symlinks it needs a slight redesign before it can
be moved into core to make it platform agnostic. If not, it should
remain contrib [again, IMHO].
> 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. I haven't looked at it, but it shouldn't
> be too hard to have a mechanism that automatically does
> GIT_DIR=<there> GIT_WORK_TREE==<here> when the appropriate setup is
> in place? Though you would have to get it into all the appropriate
> places ...
*nod*
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: StGIT (or guilt) + git-svn?
From: Steven Grimm @ 2007-07-24 12:19 UTC (permalink / raw)
To: Steven Walter; +Cc: 'git'
In-Reply-To: <20070724112706.GA9540@dervierte>
Steven Walter wrote:
> That said, I'm not sure that stgit will help you with "local versioning"
> of files (I'm not even sure what you mean). Perhaps you can elaborate
> on this point.
>
He wants to create some files in his git-svn clone and use git to manage
them -- checkpointing his work in progress, backing out changes, etc.,
without publishing those files to the svn repository. The files in
question are not already in svn. But he does want to work on other files
that *are* in the svn repository, and wants those changes to be
committed back.
So my assumption was that he would do something like maintain his
local-only changes as StGIT patches that never get committed to git. His
other changes would get committed from StGIT to git, and from there he'd
do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg
rebase since git-svn dcommit creates new revision IDs.
In any event, now that I know it's working successfully for at least one
person, I'll point him to stg and he can play with it a bit. Didn't want
to lead him into a dead end. Thanks!
-Steve
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Julian Phillips @ 2007-07-24 12:06 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <46A5DF1F.2030307@trolltech.com>
On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
>> I do not know this is an appropriate itch to scratch for a Windows
>> developer to begin with. The new-workdir setting *is* about
>> symlinked .git/ metainfo space. If somebody wants to work on a
>> filesystem without symlink, he should not be using new-workdir but
>> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
>> core.worktree comes to mind.
>
> That's is definitely an option, though it seems to me that its more like
> giving up than a finding a proper solution. In any case, it would result in
> two completely different workflows on systems with and without symlink
> support. I work on both, and would like my workflow to be consistent. Of
> course I could easily add my own scripts on top to achieve this, but then
> we're going back into h4x0r land and not making Git more 'available'.
>
> 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*)
Symref'ed isn't really the right term ... we're not talking about refs
here. You would have to basically implement symlinks _inside_ git ...
New-workdir really _is_ all about symlinks. It already exists as a
contrib feature - and moving it into core is (as I understand it) really
just moving it, not redesigning.
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. I
haven't looked at it, but it shouldn't be too hard to have a mechanism
that automatically does GIT_DIR=<there> GIT_WORK_TREE==<here> when the
appropriate setup is in place? Though you would have to get it into all
the appropriate places ...
--
Julian
---
<aav> coffee on an empty stomach is pretty nasy
<knghtbrd> aav: time to run to the vending machine for cheetos
<aav> cheetos? :)
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-24 12:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vfy3fkpr8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Offhand, an "interesting" side effect of the above I can see is
> that you will cry "wolf" if the only thing the user did is to
> add his own Signed-off-by: line ;-) But that is sane in the
> context of coming up with totally new commit log message.
>
Yes, that is intentional -- the existing git-commit code wasn't treating
Signed-off-by: as content when it checked for a commit message, so I
wanted to preserve that behavior.
> I am more worried about how this should interact with cases
> where you usually do not start the log message from scratch.
> For example, are there cases / policies where being able to use
> templates to leave comments on merge commits are needed?
> Squash-commits? Perhaps "apply this template but only when you
> have hand resolved a conflicting merges"?
>
Those are all valid cases. They also happen to be ones that are not
personally useful to me; none of the stuff in my company's commit
template would really apply to merges. I'm happy to do it if you think
those cases need to be handled before this can go in, but given there's
at least one user out there who doesn't need those things, I wonder if
this makes more sense to hold off on until someone actually asks for it.
> Or even the case of amending a commit made by somebody else,
> without changing the tree contents, in order to make the commit
> log message to conform to the company standard?
>
It's not clear to me that I can do anything useful in that case, given
that there's no way to tell in what way the commit message needs to be
fixed up. If it's a case of, "This engineer committed without using the
template at all," then I can see an argument for loading the template
above / below the existing comment, but IMO a more common case will be
something like, "The format is right, but the bug ID isn't filled in or
is incorrect," in which case any template I supply would be useless and
annoying.
Is your hunch about the common case different than mine? Again, I can go
address this if it'll actually be useful. Maybe by always including the
template if the command-line option is used, but skipping it in these
cases if the config option is used? Or something like that? (On the
other hand, if you have to specify the template on the command line,
maybe it's easier to just load it into the editor as needed.)
-Steve
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excluded bythe options
From: Johannes Schindelin @ 2007-07-24 11:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5E136.D413D3B7@eudaptics.com>
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
> > @@ -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.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] filter-branch: when dwim'ing a ref, only allow heads and tags
From: Johannes Schindelin @ 2007-07-24 11:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241218270.14781@racer.site>
Previously, we matched all refs that had /$ref in them. And tried to
verify the result as a ref. If more than one match was found, the result
was not a ref, though.
So only allow tags and heads to be dwim'ed. If both a tag and a head with
that name exist, it will be ignored again.
Caught by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Heh. I just realised that I managed to fsck up a one-line patch.
D'oh! Thanks for fixing it, Hannes.
git-filter-branch.sh | 2 +-
t/t7003-filter-branch.sh | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0ff3475..4fb3abe 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -193,7 +193,7 @@ do
;;
*)
ref="$(git for-each-ref --format='%(refname)' |
- grep /"$ref")"
+ grep -e "^refs/heads/$ref$" -e "^refs/tags/$ref$")"
esac
git check-ref-format "$ref" && echo "$ref"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index bc6e2dd..c9a820d 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -159,4 +159,9 @@ test_expect_success 'barf on invalid name' '
! git filter-branch -f HEAD^
'
+test_expect_success 'only dwim refs/heads/$ref or refs/tags/$ref' '
+ git update-ref refs/remotes/origin/master HEAD &&
+ git filter-branch -f master
+'
+
test_done
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* Re: StGIT (or guilt) + git-svn?
From: Steven Walter @ 2007-07-24 11:27 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <46A5D279.7060601@midwinter.com>
On Tue, Jul 24, 2007 at 06:20:41PM +0800, Steven Grimm wrote:
> Anyone have experience mixing git-svn with either StGIT or guilt? A
> coworker of mine was asking if he could do local versioning of files he
> has no intention of committing to svn. He wanted a ".git-svnignore" kind
> of scheme but I think his use case sounds like the sort of thing StGIT
> and guilt are designed for. What I'm not sure about is whether git-svn
> will confuse those tools or vice versa. I don't think I've ever seen
> that combo discussed on the list.
>
> -Steve
Well, I can say that stgit and git-svn in no way interfere with each
other. I tend to use stgit to clean up my patch sets before commiting
them, and have never had a problem. Thinking about what the tools do, I
can't imagine that it would cause a problem.
That said, I'm not sure that stgit will help you with "local versioning"
of files (I'm not even sure what you mean). Perhaps you can elaborate
on this point.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-24 11:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jon Smirl
In-Reply-To: <f84jh8$e27$2@sea.gmane.org>
Hi,
On Tue, 24 Jul 2007, Jakub Narebski wrote:
> [Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org]
Thanks.
> Johannes Schindelin wrote:
>
> > On Mon, 23 Jul 2007, Jon Smirl wrote:
> >
> >> Thanks for working on this. I'd like to see it added to git toolkit.
> >
> > I plan to submit it to patchutils instead, since this is not really
> > dependent on git.
>
> Could you also add it to contrib/ area, please?
Sure. Once it is really all fleshed out. But I really think that
patchutils is a better place. That way, the script also helps the poor
souls stuck with Mercurial or Darcs :-)
The really tedious part is the testing, and the verifying. Fortunately,
Jon made up for my incapability in both areas, with an incredible
patience.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excluded bythe options
From: Johannes Sixt @ 2007-07-24 11:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241205480.14781@racer.site>
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>
> @@ -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.)
-- Hannes
^ permalink raw reply
* Re: [PATCH] filter-branch: when dwim'ing a ref, only allow heads andtags
From: Johannes Schindelin @ 2007-07-24 11:20 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5DCBC.E585A69D@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > - grep /"$ref")"
> > + grep "refs/\(tags\|heads\)/$ref$")"
>
> Thanks, but I don't think that this is a portable grep pattern:
>
> $ echo "abc" | grep '\(a\|x\)'
> $ echo "abc" | egrep '(a|x)'
> abc
>
> But then, this is on some AIX 4.3. How about:
>
> fgrep -e "refs/heads/$ref" -e "refs/tags/$ref"
> or
> grep -e "^refs/heads/$ref" -e "^refs/tags/$ref"
Ah yes, I remember that Junio said some time ago that "\|" is not
portable.
But to be portable, let's stay with grep, and not use some fancy stuff
like egrep or fgrep.
Ciao,
Dscho
^ permalink raw reply
* Re: broken link - what is it?
From: Johannes Schindelin @ 2007-07-24 11:17 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070724102457.GB18701@mellanox.co.il>
Hi,
On Tue, 24 Jul 2007, Michael S. Tsirkin wrote:
> man git-fsck does not document what "broken link" is.
> Can someone enlighten me please?
A broken link is when an object references another object, and the
latter was not found in the object database.
For example, commits reference parent commits and a tree. A tree
references trees and blobs. A tag references arbitrary objects.
I am not very good in writing documentation... could you give it a try?
Thanks,
Dscho
^ permalink raw reply
* Re: copying objects from another repo?
From: Johannes Schindelin @ 2007-07-24 11:14 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070724103503.GC18701@mellanox.co.il>
Hi,
On Tue, 24 Jul 2007, Michael S. Tsirkin wrote:
> I had some missing objects that I managed to locate
> in another tree. So - how to get them to my repo?
> Here's what I came up with:
>
> cd ~/scm/good_tree
> git tag -f foo dfaa7049e9ebe227cfcffc49d3de16716764bcbd
> cd ~/scm/bad_tree
> git fetch-pack ~/scm/good_tree dfaa7049e9ebe227cfcffc49d3de16716764bcbd
>
> And I repeated this for all missing objects.
> But is there a better way to do this?
This is what I have done in such a case:
In the valid repo:
$ git gc
$ scp .git/objects/packs/* the-broken:repo.git/objects/packs/
In the broken repo:
$ git gc
Done.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 11:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <7vd4yigmla.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
Junio C Hamano said the following on 24.07.2007 11:47:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> While you guys are discussing this, please please keep in mind
>>> that there are Windows users (/me raises his hand) out there
>>> that really really want this too. So, please try to keep it
>>> light on the symlinks.
>> Easy: use cygwin.
>>
>> Okay, a bit more seriously again: in the recent weeks, it seems
>> that more and more Windows users are asking for features. Since
>> I guess you are a developer (why else would you want to use git),
>> IMHO it is your itch to scratch.
Yes, I fully agree with this, and I don't have the attitude that
others should work for me. I'm trying to free up some 'spare time'
resources so I can pitch in on the effort of making Git work neatly on
Windows. However, I feared I won't be able to get working on it before
you guys had decided on a design, so I just wanted voice my opinion on
the design, so Windows users are not lost in this.
> I do not know this is an appropriate itch to scratch for a Windows
> developer to begin with. The new-workdir setting *is* about
> symlinked .git/ metainfo space. If somebody wants to work on a
> filesystem without symlink, he should not be using new-workdir but
> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
> core.worktree comes to mind.
That's is definitely an option, though it seems to me that its more
like giving up than a finding a proper solution. In any case, it would
result in two completely different workflows on systems with and
without symlink support. I work on both, and would like my workflow to
be consistent. Of course I could easily add my own scripts on top to
achieve this, but then we're going back into h4x0r land and not making
Git more 'available'.
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*)
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 :-)
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.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] git log -g: Complain, but do not fail, when no reflogs are there
From: Johannes Schindelin @ 2007-07-24 11:11 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, gitster
In-Reply-To: <81b0412b0707240317q56e42a9bs44eb3e5ef9e796c6@mail.gmail.com>
Hi,
On Tue, 24 Jul 2007, Alex Riesen wrote:
> On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Tue, 24 Jul 2007, Alex Riesen wrote:
> > > On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > When asking "git log -g --all", clearly you want to see only those refs
> > > > that do have reflogs, but you do not want it to fail, either.
> > > >
> > > > So instead of die()ing, complain about it, but move on to the other
> > refs.
> > > >
> > >
> > > I believe you wont even see these complaints: the pager will start shortly
> > > afterwards and fill the screen with commits, completely hiding the errors.
> >
> > You can see it briefly, but it is hidden by default. Which is a good
> > thing. If you set the pager to "cat" (which is happily not the default!)
> > you can see them clearly. Until you are swamped by the rest of the
> > output.
> >
> > Maybe this is a feature?
> >
>
> Maybe. I can't see it at all. Should I downgrade something or propose
> a patch to put some delay after this error? I think not.
>
> I think second Junios suggestion, but this is of course no
> difference to me.
Okay, two votes are enough to make me reconsider. Junio, could you please
replace the two "error(...)"s by "-1"s? Only if you apply the patch, of
course...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-24 11:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marius Storm-Olsen, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <7vd4yigmla.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 24 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> While you guys are discussing this, please please keep in mind that there are
> >> Windows users (/me raises his hand) out there that really really want this
> >> too. So, please try to keep it light on the symlinks.
> >
> > Easy: use cygwin.
> >
> > Okay, a bit more seriously again: in the recent weeks, it seems that more
> > and more Windows users are asking for features. Since I guess you are a
> > developer (why else would you want to use git), IMHO it is your itch to
> > scratch.
>
> I do not know this is an appropriate itch to scratch for a
> Windows developer to begin with. The new-workdir setting *is*
> about symlinked .git/ metainfo space. If somebody wants to work
> on a filesystem without symlink, he should not be using
> new-workdir but something else. E.g. GIT_DIR + GIT_WORK_TREE,
> or perhaps GIT_DIR + core.worktree comes to mind.
... which reminds me that I wanted to overhaul that patch series.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] filter-branch: rewrite only refs which were not excluded by the options
From: Johannes Schindelin @ 2007-07-24 11:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5C615.24C24F0F@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.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
>
> > +# NEEDSWORK: we should sort the unmapped refs topologically first
> > +while read ref
> > +do
> > + sha1=$(git rev-parse "$ref"^0)
> > + test -f "$workdir"/../map/$sha1 && continue
> > + # Assign the boundarie(s) in the set of rewritten commits
> > + # as the replacement commit(s).
> > + # (This would look a bit nicer if --not --stdin worked.)
> > + for p in $((cd "$workdir"/../map; ls | sed "s/^/^/") |
> > + git rev-list $ref --boundary --stdin |
> > + sed -n "s/^-//p")
> > + do
> > + map $p >> "$workdir"/../map/$sha1
> > + done
> > +done < "$tempdir"/heads
>
> This logic seems to be borked, and I don't grok it. I was trying this:
>
> git-filter-branch -- --since=2007.01.10 \
> refs/heads/topic refs/heads/master
Actually, the error lay somewhere else. If excluded, topic should
not have been a rewrite candidate.
There might be something else looming here: what to do with
git filter-branch --subdir-filter subdir/ topic master \
^$(git merge-base topic master)
when topic has no changes to the subdirectory, but master has?
I guess the safest would be to 'test -f "$workdir"/../map/$p', and
if at least one is not there, leave 'topic' as is. If at least
one is there, however, we want to warn the user that this is not
possible. (Something like: this was an unchanged ancestor: $p1,
but that was a changed one: $p2. Make up your mind what you
want.)
git-filter-branch.sh | 9 ++++++++-
t/t7003-filter-branch.sh | 9 +++++++++
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 019a302..49b0f00 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -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
+
+ 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: when dwim'ing a ref, only allow heads andtags
From: Johannes Sixt @ 2007-07-24 11:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0707241134330.14781@racer.site>
Johannes Schindelin wrote:
> - grep /"$ref")"
> + grep "refs/\(tags\|heads\)/$ref$")"
Thanks, but I don't think that this is a portable grep pattern:
$ echo "abc" | grep '\(a\|x\)'
$ echo "abc" | egrep '(a|x)'
abc
But then, this is on some AIX 4.3. How about:
fgrep -e "refs/heads/$ref" -e "refs/tags/$ref"
or
grep -e "^refs/heads/$ref" -e "^refs/tags/$ref"
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFH] Mark user-manual as UTF-8
From: Thierry Parmentelat @ 2007-07-24 10:45 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, git, J. Bruce Fields, H. Peter Anvin
In-Reply-To: <4753DAE3-2F1F-49C0-906A-09CBAF240C87@wincent.com>
Hi there - I'm the wierd guy :-)
I've just reloaded the page and the weird stuff has gone.
Wincent Colaiuta wrote:
> El 24/7/2007, a las 9:46, Junio C Hamano escribió:
>
>> 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 doing this, Junio. I was one of the people who reported
> this (although never saw my mail get through to the list).
>
> Funnily, enough, about an hour after you posted your patch another
> email ("git documentation - user manual html version has wierd [sic]
> characters all over the place") was posted to the list...
>
> Cheers,
> Wincent
^ permalink raw reply
* Re: [PATCH/RFH] Mark user-manual as UTF-8
From: Wincent Colaiuta @ 2007-07-24 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields, Thierry Parmentelat, H. Peter Anvin
In-Reply-To: <7vwswqgs6c.fsf@assigned-by-dhcp.cox.net>
El 24/7/2007, a las 9:46, Junio C Hamano escribió:
> 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 doing this, Junio. I was one of the people who reported
this (although never saw my mail get through to the list).
Funnily, enough, about an hour after you posted your patch another
email ("git documentation - user manual html version has wierd [sic]
characters all over the place") was posted to the list...
Cheers,
Wincent
^ permalink raw reply
* [PATCH] filter-branch: when dwim'ing a ref, only allow heads and tags
From: Johannes Schindelin @ 2007-07-24 10:36 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A5C615.24C24F0F@eudaptics.com>
Previously, we matched all refs that had /$ref in them. And tried to
verify the result as a ref. If more than one match was found, the result
was not a ref, though.
So only allow tags and heads to be dwim'ed. If both a tag and a head with
that name exist, it will be ignored again.
Caught by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > +# These refs should be updated if their heads were rewritten
> > +
> > +git rev-parse --revs-only --symbolic "$@" |
> > +while read ref
> > +do
> > + # normalize ref
> > + case "$ref" in
> > + HEAD)
> > + ref="$(git symbolic-ref "$ref")"
> > + ;;
> > + refs/*)
> > + ;;
> > + *)
> > + ref="$(git for-each-ref --format='%(refname)' |
> > + grep /"$ref")"
> > + esac
> > +
> > + git check-ref-format "$ref" && echo "$ref"
> > +done > "$tempdir"/heads
>
> This does not work as I'd expected it: I can't successfully say:
>
> git-filter-branch master
>
> It tells me:
>
> Which ref do you want to rewrite?
I tried that, and happily got the same. The explanation: more
than one ref matched "/master". My pattern was extremely borked.
Thanks.
git-filter-branch.sh | 2 +-
t/t7003-filter-branch.sh | 5 +++++
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0ff3475..019a302 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -193,7 +193,7 @@ do
;;
*)
ref="$(git for-each-ref --format='%(refname)' |
- grep /"$ref")"
+ grep "refs/\(tags\|heads\)/$ref$")"
esac
git check-ref-format "$ref" && echo "$ref"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index bc6e2dd..c9a820d 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -159,4 +159,9 @@ test_expect_success 'barf on invalid name' '
! git filter-branch -f HEAD^
'
+test_expect_success 'only dwim refs/heads/$ref or refs/tags/$ref' '
+ git update-ref refs/remotes/origin/master HEAD &&
+ git filter-branch -f master
+'
+
test_done
--
1.5.3.rc2.32.g35c5b-dirty
^ permalink raw reply related
* copying objects from another repo?
From: Michael S. Tsirkin @ 2007-07-24 10:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
I had some missing objects that I managed to locate
in another tree. So - how to get them to my repo?
Here's what I came up with:
cd ~/scm/good_tree
git tag -f foo dfaa7049e9ebe227cfcffc49d3de16716764bcbd
cd ~/scm/bad_tree
git fetch-pack ~/scm/good_tree dfaa7049e9ebe227cfcffc49d3de16716764bcbd
And I repeated this for all missing objects.
But is there a better way to do this?
--
MST
^ permalink raw reply
* [PATCH] git.el: Pass an explicit argument to enable smerge-mode.
From: Alexandre Julliard @ 2007-07-24 10:02 UTC (permalink / raw)
To: git
Without argument the mode is toggled, which would do the wrong thing
if the file was already open.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 457f95f..d7f4316 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1038,7 +1038,7 @@ and returns the process output as a string."
(let ((info (ewoc-data (ewoc-locate git-status))))
(find-file (git-fileinfo->name info))
(when (eq 'unmerged (git-fileinfo->state info))
- (smerge-mode))))
+ (smerge-mode 1))))
(defun git-find-file-other-window ()
"Visit the current file in its own buffer in another window."
--
1.5.3.rc2.39.g82303f
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* broken link - what is it?
From: Michael S. Tsirkin @ 2007-07-24 10:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
I seem to have a corrupted repo:
>git-fsck --full
broken link from tree c907c09fee3e14adbc17c3e9d54c060b520303ba
to blob dfaa7049e9ebe227cfcffc49d3de16716764bcbd
broken link from tree 00c8e1ed2de45bb57bd5482bf258efdfc28d5192
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
broken link from tree ee2144e186e78ce1ebbecfe10a6551ebc407f025
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
missing blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
broken link from tree 79f14c41a69bf43069a6828769d8ee3ce86f6daf
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
missing blob dfaa7049e9ebe227cfcffc49d3de16716764bcbd
broken link from tree 5c3bb6f86743ced765fbcabe0ade6fc0a7e0f01a
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
broken link from tree 5f553908b5e2dfb6d53964c5e01ff596b91a61ba
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
broken link from tree 6f48bab6e09ae3d92cfdec8b6dec77b65a0968a7
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
broken link from tree 21fade55d91e78863920ecfe58767e007dcd4e74
to blob 5909ec5314cebf884c03b2d85c7919eb40b5b424
man git-fsck does not document what "broken link" is.
Can someone enlighten me please?
--
MST
^ 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