* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Jeff King @ 2008-06-23 16:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Pierre Habouzit, Git Mailing List,
Junio C Hamano
In-Reply-To: <alpine.LFD.1.10.0806230912230.2926@woody.linux-foundation.org>
On Mon, Jun 23, 2008 at 09:25:10AM -0700, Linus Torvalds wrote:
> Could you handle the "recursive" use of parse_options() in builtin-blame.c
> by teaching it about recursion? Yes. But again, it's just _simpler_ to
> just teach parse_options() to parse the things it knows about, and leave
> the other things in place.
If I know that I have option "-a", what is the correct partial parsing
of:
git foo -b -a
?
-Peff
^ permalink raw reply
* Re: git blame for a commit
From: Jakub Narebski @ 2008-06-23 16:29 UTC (permalink / raw)
To: Ian Hilt; +Cc: Mircea Bardac, git
In-Reply-To: <alpine.LFD.1.10.0806231149470.27742@sys-0.hiltweb.site>
On Mon, 23 Jun 2008, Ian Hilt wrote:
> On Mon, 23 Jun 2008 at 3:01am -0700, Jakub Narebski wrote:
>
> > I think you could script it using "git diff", and "git blame -L m,n",
> > where line ranges would be calculated from git diff header for
> > post-image, or both pre-image and post-image (in the case of deletions).
>
> Maybe I'm missing something, but I thought git-blame only worked with
> the files in the Git working directory. Therefore, if a file had been
> deleted it would not be reachable with git-blame, whether you diff'ed
> the pre- and post-image or not.
You can give blame the revision to start blaming from; that's what
I meant the "pre-image" blame (staring from parent revision).
I'm not that sure if it is the best solution...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Johannes Schindelin @ 2008-06-23 16:25 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <20080623155315.GA18593@artemis.madism.org>
Hi,
On Mon, 23 Jun 2008, Pierre Habouzit wrote:
> On Mon, Jun 23, 2008 at 12:26:41PM +0000, Johannes Schindelin wrote:
>
> > On Mon, 23 Jun 2008, Pierre Habouzit wrote:
> >
> > > This "PARSE_OPT_IGNORE_UNRECOGNIZED" thing has been discussed many
> > > times in the past, but it just doesn't fly.
> > >
> > > Though to help migrations we can probably introduce a new parse
> > > option construct that would be a callback that is responsible for
> > > dealing with "things" the upper level parser doesn't know about,
> > > something where the callback could be:
> > >
> > > enum {
> > > FLAG_ERROR = -1,
> > > FLAG_NOT_FOR_ME,
> > > FLAG_IS_FOR_ME,
> > > FLAG_AND_VALUE_ARE_FOR_ME,
> > > }
> > >
> > > int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
> > > const char *value, void *priv);
> >
> > I believe that this is what Junio was talking about when he mentioned
> > callbacks.
> >
> > However, I think it buys us more trouble than it saves us.
> >
> > Thinking about the recursive approach again, I came up with this POC:
>
> Well I proposed something like that in the past, and we believed it to
> be too cumbersome.
IIRC your solution was a bit involved, while I think that mine is at least
small enough to be simple.
Note: it is a bit wasteful, allocating space for a new option table
in every case, even if there are no OPTION_OPTIONS, but I think that is
okay.
> I can live with it well fwiw, but it doesn't solve the issue of
> migrating a very complex option parsing chain to parse-options well
> IMHO. THe big problem with diff and rev opt parsing is that one you want
> to migrate _any_ of the commands, you have to migrate _all_ of them,
> which is huge.
I don't think you have to migrate all of them in one go. To the contrary,
if we have both "diff_opt_parse()" as well as a "struct options
*diff__options", it can be done one by one. During that time, though,
people would have to add new diff options to both places.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Linus Torvalds @ 2008-06-23 16:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0806231312130.6440@racer>
On Mon, 23 Jun 2008, Johannes Schindelin wrote:
>
> Thinking about the recursive approach again, I came up with this POC:
"recursive" is pointless.
The problem with the current "parse_options()" is not that it's recursive
(although that has been claimed multiple times!.
The problem with parse_options() is that it's currently impossible to
write something that handles _partial_ cases.
Let me explain.
Look at cmd_apply() in builtin-apply.c. Notice how it currently absolutely
CANNOT sanely be turned into using "parse_options()", not because it needs
any "recursive" handling, but simply because it wants to do *incremental*
handling.
It should be perfectly possible to change that argument loop from
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (strcmp(arg, "-")) {
.. handle <stdin> ..
continue;
}
...
to doing something like this:
for (;;) {
const char *arg;
argc = parse_options(argc, argv,
options, usage, PARSE_OPT_STOP_AT_UNKNOWN);
if (!argc)
break;
arg = argv[1];
argv++;
argc--;
if (strcmp(arg, "-")) {
.. handle <stdin> ..
continue;
}
...
or whatever. See?
Could you handle that with callbacks? Of course. "You can solve any
problem in computer science with an added level of indirection". But would
it be simpler to convert existing users? Hell no.
Could you handle the "recursive" use of parse_options() in builtin-blame.c
by teaching it about recursion? Yes. But again, it's just _simpler_ to
just teach parse_options() to parse the things it knows about, and leave
the other things in place.
Linus
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Daniel Barkalow @ 2008-06-23 16:14 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Paul E. McKenney, Mikael Magnusson, git, Thomas Gleixner
In-Reply-To: <20080623112233.GB7485@elte.hu>
On Mon, 23 Jun 2008, Ingo Molnar wrote:
> tags are mostly meant for release management - our use of tags to save
> the "merge base" of topic branches in -tip can be considered mild abuse.
>
> ( But we did not want to pullute the already crowded branch space with
> extra technical branches. -tip has 127 branches at this moment, 89 of
> which are topic branches - creating a base branch for each topic would
> add another 89 branches and bring it all up to 216 branches. )
If these are only internal details, and not something you expect other
people to use, you could get yourself a directory for refs that doesn't
mean anything to the rest of git. If you use "refs/bases/<something>", git
should (a) accept that as a name you can use for a commit; (b) preserve
anything referenced by it; (c) copy it in a "git clone --mirror"; and
pretty much ignore it otherwise.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] t9301-fast-export.sh: Remove debug line
From: Michele Ballabio @ 2008-06-23 16:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
t/t9301-fast-export.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 60b5ee3..f1bc5ce 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -83,7 +83,6 @@ test_expect_success 'import/export-marks' '
git checkout -b marks master &&
git fast-export --export-marks=tmp-marks HEAD &&
test -s tmp-marks &&
- cp tmp-marks ~ &&
test $(wc -l < tmp-marks) -eq 3 &&
test $(
git fast-export --import-marks=tmp-marks\
--
1.5.6
^ permalink raw reply related
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Linus Torvalds @ 2008-06-23 16:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20080623082223.GA12130@artemis.madism.org>
On Mon, 23 Jun 2008, Pierre Habouzit wrote:
>
> You can't, mainly because of option aggregation: if the parser1 knows
> about -a and -b, parser2 about -c, then, this kind of things is
> problematic: -acb because you need to go to the parser '2' to know about
> -c, and you can't filter the arguments and keep -c and give -b to
> parser1 again, *BECAUSE* 'b' could also be -c argument.
Sure you can. You just rewrite the arguments themselves.
That said, anybody who doesn't use parse_options() right now won't be
accepting something like "-abc" *anyway*, and people currently need to use
"-a -b -c".
> int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
> const char *value, void *priv);
This doesn't really change anything. It just makes it harder to write a
simple partial parser. Just passing in "IGNORE_UNKNOWN" (and probably
"STOP_AT_UNKNOWN") is the simplest way to have multiple passes.
Linus
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Ingo Molnar @ 2008-06-23 16:05 UTC (permalink / raw)
To: Jeff King; +Cc: Paul E. McKenney, Mikael Magnusson, git, Thomas Gleixner
In-Reply-To: <20080623151257.GC20902@sigill.intra.peff.net>
* Jeff King <peff@peff.net> wrote:
> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
>
> > Is there a Git way of finding the common ancestor of a topic branch,
> > when compared to upstream?
>
> Try:
>
> git merge-base topic upstream
small (and stupid) feature suggestion for git-merge-base.
i was working on a topic branch when i wanted to figure out its base to
linus/master, and i typed:
~/tip> git-merge-base linus
usage: git-merge-base [--all] <commit-id> <commit-id>
it might make sense to implicitly use the current 'HEAD' as a second,
default parameter to git-merge-base. (unless i'm missing some particular
detail about why that would be a bad idea)
Ingo
^ permalink raw reply
* Re: git blame for a commit
From: Ian Hilt @ 2008-06-23 15:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Mircea Bardac, git
In-Reply-To: <m3ve00lbby.fsf@localhost.localdomain>
On Mon, 23 Jun 2008 at 3:01am -0700, Jakub Narebski wrote:
> I think you could script it using "git diff", and "git blame -L m,n",
> where line ranges would be calculated from git diff header for
> post-image, or both pre-image and post-image (in the case of deletions).
Maybe I'm missing something, but I thought git-blame only worked with
the files in the Git working directory. Therefore, if a file had been
deleted it would not be reachable with git-blame, whether you diff'ed
the pre- and post-image or not.
--
Ian Hilt
Ian.Hilt (at) gmx.com
GnuPG key: 0x4AFC1EE3
^ permalink raw reply
* Re: [RFC] Re: Convert 'git blame' to parse_options()
From: Pierre Habouzit @ 2008-06-23 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0806231312130.6440@racer>
[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]
On Mon, Jun 23, 2008 at 12:26:41PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 23 Jun 2008, Pierre Habouzit wrote:
>
> > This "PARSE_OPT_IGNORE_UNRECOGNIZED" thing has been discussed many times
> > in the past, but it just doesn't fly.
> >
> > Though to help migrations we can probably introduce a new parse option
> > construct that would be a callback that is responsible for dealing with
> > "things" the upper level parser doesn't know about, something where the
> > callback could be:
> >
> > enum {
> > FLAG_ERROR = -1,
> > FLAG_NOT_FOR_ME,
> > FLAG_IS_FOR_ME,
> > FLAG_AND_VALUE_ARE_FOR_ME,
> > }
> >
> > int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
> > const char *value, void *priv);
>
> I believe that this is what Junio was talking about when he mentioned
> callbacks.
>
> However, I think it buys us more trouble than it saves us.
>
> Thinking about the recursive approach again, I came up with this POC:
Well I proposed something like that in the past, and we believed it to
be too cumbersome. I can live with it well fwiw, but it doesn't solve
the issue of migrating a very complex option parsing chain to
parse-options well IMHO. THe big problem with diff and rev opt parsing
is that one you want to migrate _any_ of the commands, you have to
migrate _all_ of them, which is huge.
I believe the callback proposal as an _intermediate_ step allows a
better "upgrade" path. We can then converge to this proposal, or a big
fat macro, I don't care what we do in the end, but as one guy that
migrated quite a few commands, I care about the work being doable in an
incremental way.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git remote branches oddies
From: Cyrill Gorcunov @ 2008-06-23 15:50 UTC (permalink / raw)
To: git; +Cc: Ingo Molnar
Hi git list,
could someone take a look please since I'm not
sure if that is right thing I'm doing with git ;)
I'm tracking a few linux kernel repos. Here is my git config:
--- git config ---
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[remote "x86"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
fetch = +refs/heads/*:refs/remotes/x86/*
[remote "tip"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
fetch = +refs/heads/*:refs/remotes/tip/*
[gui]
geometry = 1037x445+260+116 207 192
[remote "udf"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git
fetch = +refs/heads/*:refs/remotes/udf/*
------------------
By typing 'git remote update' I've got the following today
--- git remote update log ---
cyrill@cvg linux-2.6.git $ git remote update
Updating origin
Updating x86
From git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86
* [new branch] core/futexes -> x86/core/futexes
error: 'refs/remotes/x86/mm' exists; cannot create 'refs/remotes/x86/mm/xen'
* [new branch] mm/xen -> x86/mm/xen
d4abc23..ea71a54 sched-fixes-for-linus -> x86/sched-fixes-for-linus
error: unable to resolve reference refs/remotes/x86/sched/devel: Not a directory
* [new branch] sched/devel -> x86/sched/devel
error: unable to resolve reference refs/remotes/x86/sched/new-API-sched_setscheduler: Not a directory
* [new branch] sched/new-API-sched_setscheduler -> x86/sched/new-API-sched_setscheduler
error: unable to resolve reference refs/remotes/x86/sched/urgent: Not a directory
* [new branch] sched/urgent -> x86/sched/urgent
ffe6e1d..ebb9cfe x86-fixes-for-linus -> x86/x86-fixes-for-linus
error: Could not fetch x86
Updating tip
From git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* [new branch] core/futexes -> tip/core/futexes
d4abc23..ea71a54 sched-fixes-for-linus -> tip/sched-fixes-for-linus
error: unable to resolve reference refs/remotes/tip/sched/devel: Not a directory
* [new branch] sched/devel -> tip/sched/devel
error: unable to resolve reference refs/remotes/tip/sched/new-API-sched_setscheduler: Not a directory
* [new branch] sched/new-API-sched_setscheduler -> tip/sched/new-API-sched_setscheduler
error: unable to resolve reference refs/remotes/tip/sched/urgent: Not a directory
* [new branch] sched/urgent -> tip/sched/urgent
ffe6e1d..ebb9cfe x86-fixes-for-linus -> tip/x86-fixes-for-linus
error: Could not fetch tip
Updating udf
-----------------------------
I've asked Ingo what is happend with -tip tree. He answered:
| hm, this is due to a new 'sched/urgent' and 'sched/devel' branches being
| introduced, while the old ones were still around.
If I've recreated git repo from scratch - messages are gone. Not sure
how to react on this. Is that normal? (I would _not_ say that such
error messages annoying me but somehow a _bit_ unpleasant :-)
Please CC me since I'm not subscribed.
Btw the git I'm using is - git version 1.5.6.6.gd3e97.
- Cyrill -
^ permalink raw reply
* how to rewalk the commit list after rename detection
From: Don Zickus @ 2008-06-23 15:38 UTC (permalink / raw)
To: git
I am trying to find a way to handle a situation where I am looking for a
change in a particular file, but the filename is old and has since been
renamed.
Processing the commit list internally (using init_revisions,
setup_revisions, get_revision), I can easily find the rename of the file,
but that is usually the start of the walk for that file (as it was just
deleted for the rename). I do not know how to re-walk the commits list
armed with the new file name.
I tried rerunning the same commands as above (init_revisions,
setup_revisions, get_revision) but that commit list is empty for some
reason (I assume the UNINTERESTING flag is never un-set??).
For example, if I have a backported patch for the upstream kernel in say
the arch/i386 directory. I want to check to see if it is upstream. I
wouldn't be able to do that because arch/i386 was renamed to arch/x86.
Unless of course the patch matches identically upstream (in which case
git-cherry works fine), but that isn't always the case (usually it is a
combination of a couple of patches).
Anyone have some thoughts if this is possible?
Cheers,
Don
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Ingo Molnar @ 2008-06-23 15:31 UTC (permalink / raw)
To: Jeff King; +Cc: Paul E. McKenney, Mikael Magnusson, git, Thomas Gleixner
In-Reply-To: <20080623151257.GC20902@sigill.intra.peff.net>
* Jeff King <peff@peff.net> wrote:
> On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
>
> > Is there a Git way of finding the common ancestor of a topic branch,
> > when compared to upstream?
>
> Try:
>
> git merge-base topic upstream
turns out we already use that as a fallback:
if [ -z "$TREF" ]
then
echo "No topic reference found. Using git-merge-base"
MBASE=`git-merge-base linus HEAD`
TD=`get_date_for_tag`
TB=`echo $B | sed "s@/@-@"`
git-tag "tip-"$TB"-"$TD $MBASE
TREF="tip-"$TB"-"$TD
[...]
i guess we could use that unconditionally.
Ingo
^ permalink raw reply
* Re: git-rerere observations and feature suggestions
From: Ingo Molnar @ 2008-06-23 15:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Peter Zijlstra, Chris Mason, Thomas Gleixner
In-Reply-To: <20080623151201.GB20902@sigill.intra.peff.net>
* Jeff King <peff@peff.net> wrote:
> > ( and if i could configure git-commit to outright reject a commit like
> > that - i never want to commit lines with <<<<<< or >>>>> markers)
>
> The right place for this is in a pre-commit hook, which can look at
> what you are about to commit and decide if it is OK. In fact, the
> default pre-commit hook that ships with git performs this exact check.
> You just need to turn it on with:
>
> chmod +x .git/hooks/pre-commit
cool, thanks :-)
Ingo
^ permalink raw reply
* Re: about c8af1de9 (git status uses pager)
From: Jeff King @ 2008-06-23 15:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Engelhardt, Vegard Nossum, Bart Trojanowski, git
In-Reply-To: <7vtzfln5zw.fsf@gitster.siamese.dyndns.org>
On Sun, Jun 22, 2008 at 03:01:07AM -0700, Junio C Hamano wrote:
> Jeff had a patch to allow boolean configuration variable "pager.<command>"
> to override the built-in pager settings during 1.5.6 cycle, and I think it
> was a reasonable approach to take. People who want to page output from
> git-status can then set "pager.status = true" in their configuration (and
> then we can revert c8af1de (make git-status use a pager, 2008-04-23)).
> Alternatively we could keep the current status-quo for the default, and
> people can say "pager.status = false" in their configuration.
I have been running with the patch for a month or two, and it works fine
for controlling the pager. Unfortunately, there is a nasty interaction
in the git wrapper with reading the config file early, and we end up not
calculating the GIT_DIR and worktree in the same way. I think this is
part of a larger problem which needs solving, but everytime I look at
it, my eyes start bleeding (and I have to admit, since the patch does
work, I have forgotten how annoyed I was at the paging behavior in the
first place, and I don't have as much motivation to work on it).
I think this is deeply related to the "git config alias.st status && cd
.git && git st" problem, which is also on my long-term todo. So I'll see
if I can do something about it during this release cycle.
-Peff
^ permalink raw reply
* Re: linux-x86-tip: pilot error?
From: Jeff King @ 2008-06-23 15:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Paul E. McKenney, Mikael Magnusson, git, Thomas Gleixner
In-Reply-To: <20080623071441.GA28887@elte.hu>
On Mon, Jun 23, 2008 at 09:14:41AM +0200, Ingo Molnar wrote:
> Is there a Git way of finding the common ancestor of a topic branch,
> when compared to upstream?
Try:
git merge-base topic upstream
-Peff
^ permalink raw reply
* Re: git-rerere observations and feature suggestions
From: Jeff King @ 2008-06-23 15:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Junio C Hamano, git, Peter Zijlstra, Chris Mason, Thomas Gleixner
In-Reply-To: <20080623094906.GA8284@elte.hu>
On Mon, Jun 23, 2008 at 11:49:06AM +0200, Ingo Molnar wrote:
> another git-rerere observation: occasionally it happens that i
> accidentally commit a merge marker into the source code.
>
> That's obviously stupid, and it normally gets found by testing quickly,
> but still it would be a really useful avoid-shoot-self-in-foot feature
> if git-commit could warn about such stupidities of mine.
>
> ( and if i could configure git-commit to outright reject a commit like
> that - i never want to commit lines with <<<<<< or >>>>> markers)
The right place for this is in a pre-commit hook, which can look at what
you are about to commit and decide if it is OK. In fact, the default
pre-commit hook that ships with git performs this exact check. You just
need to turn it on with:
chmod +x .git/hooks/pre-commit
-Peff
^ permalink raw reply
* exit status 141 from git-svn
From: Frederik Hohlfeld @ 2008-06-23 15:00 UTC (permalink / raw)
To: git
Hi
I have init'ed a git repository with git svn init.
Now I'm using git svn fetch, but it stops after just a few files/revisions. The
exit status is 141.
What does this 141 want to tell me?
Thanks
Frederik Hohlfeld
^ permalink raw reply
* Re: Importing non-version controlled bits and pieces to Git
From: Peter Karlsson @ 2008-06-23 14:46 UTC (permalink / raw)
Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0806230732120.31319@ds9.cixit.se>
Peter Karlsson:
> That might work. My problem is the non-linearity of the data I want
> to import. But I might be able to massage the import-tars output
> before I feed it to git-fast-import to describe the history I need it
> to.
I ended up making a script that converted a description file that
described the hierarchy of versions and generated a fast-import file
from it. Good to have so that I could move stuff around a bit to make
up a version tree that looked somewhat reasonable (a lot of
cross-directory copying has been going on here, and no-one knows which
version is which).
I will try to make the script available.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git-rerere observations and feature suggestions
From: Peter Zijlstra @ 2008-06-23 14:26 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git, Chris Mason, Thomas Gleixner
In-Reply-To: <1214230796.3223.326.camel@lappy.programming.kicks-ass.net>
On Mon, 2008-06-23 at 16:20 +0200, Peter Zijlstra wrote:
> On Mon, 2008-06-23 at 11:49 +0200, Ingo Molnar wrote:
> > another git-rerere observation: occasionally it happens that i
> > accidentally commit a merge marker into the source code.
> >
> > That's obviously stupid, and it normally gets found by testing quickly,
> > but still it would be a really useful avoid-shoot-self-in-foot feature
> > if git-commit could warn about such stupidities of mine.
> >
> > ( and if i could configure git-commit to outright reject a commit like
> > that - i never want to commit lines with <<<<<< or >>>>> markers)
> >
> > Another merge conflict observation is that Git is much worse at figuring
> > out the right merge resolution than our previous Quilt based workflow
> > was. I eventually found it to be mainly due to the following detail:
> > sometimes it's more useful to first apply the merged branch and then
> > attempt to merge HEAD, as a patch.
> >
> > I've got a script for that which also combines it with the "rej" tool,
> > and in about 70%-80% of the cases where Git is unable to resolve a merge
> > automatically it figures things out. ('rej' is obviously a more relaxed
> > merge utility, but it's fairly robust in my experience, with a very low
> > false positive rate.)
> >
> > The ad-hoc "tip-mergetool" script we are using is attached below. It's
> > really just for demonstration purposes - it doesnt work when there's a
> > rename related conflict, etc.
> >
> > Peter Zijstra also wrote a git-mergetool extension for the 'rej' tool
> > btw., he might want to post that patch. I've attached Chris Mason's rej
> > tool too.
>
> This is what I run with.
>
> I added the cp to the 3-way merge tools because I think its stupid to
> see the messed up merge markers instead of the original file.
While we're on the subject, I only found one tool that 'digs' these
merge markers and that is xxdiff --unmerge.
One would think more tools understand these merge markers, but I
couldn't find any.
^ permalink raw reply
* Re: git-rerere observations and feature suggestions
From: Peter Zijlstra @ 2008-06-23 14:19 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git, Chris Mason, Thomas Gleixner
In-Reply-To: <20080623094906.GA8284@elte.hu>
On Mon, 2008-06-23 at 11:49 +0200, Ingo Molnar wrote:
> another git-rerere observation: occasionally it happens that i
> accidentally commit a merge marker into the source code.
>
> That's obviously stupid, and it normally gets found by testing quickly,
> but still it would be a really useful avoid-shoot-self-in-foot feature
> if git-commit could warn about such stupidities of mine.
>
> ( and if i could configure git-commit to outright reject a commit like
> that - i never want to commit lines with <<<<<< or >>>>> markers)
>
> Another merge conflict observation is that Git is much worse at figuring
> out the right merge resolution than our previous Quilt based workflow
> was. I eventually found it to be mainly due to the following detail:
> sometimes it's more useful to first apply the merged branch and then
> attempt to merge HEAD, as a patch.
>
> I've got a script for that which also combines it with the "rej" tool,
> and in about 70%-80% of the cases where Git is unable to resolve a merge
> automatically it figures things out. ('rej' is obviously a more relaxed
> merge utility, but it's fairly robust in my experience, with a very low
> false positive rate.)
>
> The ad-hoc "tip-mergetool" script we are using is attached below. It's
> really just for demonstration purposes - it doesnt work when there's a
> rename related conflict, etc.
>
> Peter Zijstra also wrote a git-mergetool extension for the 'rej' tool
> btw., he might want to post that patch. I've attached Chris Mason's rej
> tool too.
This is what I run with.
I added the cp to the 3-way merge tools because I think its stupid to
see the messed up merge markers instead of the original file.
The rej target basically takes the local version and takes the diff
between base and remote and applies that as a patch, upon failure it
invokes rej to fix up the mess.
--- /usr/bin/git-mergetool 2008-04-08 19:01:37.000000000 +0200
+++ git-mergetool 2008-06-02 19:00:55.000000000 +0200
@@ -214,12 +214,14 @@ merge_file () {
;;
meld|vimdiff)
touch "$BACKUP"
+ cp -- "$BASE" "$path"
"$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
+ cp -- "$BASE" "$path"
"$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
@@ -271,6 +273,13 @@ merge_file () {
status=$?
save_backup
;;
+ rej)
+ touch "$BACKUP"
+ cp -- "$LOCAL" "$path"
+ diff -up "$BASE" "$REMOTE" | patch "$path" || rej "$path"
+ check_unchanged
+ save_backup
+ ;;
esac
if test "$status" -ne 0; then
echo "merge of $path failed" 1>&2
@@ -311,7 +320,7 @@ done
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge | rej)
;; # happy
*)
return 1
^ permalink raw reply
* Re: Fwd: git status bug problem.
From: Jakub Narebski @ 2008-06-23 13:47 UTC (permalink / raw)
To: Ben Bennett; +Cc: git
In-Reply-To: <970bc7c80806230622x326c5cd3mbce57949255a067b@mail.gmail.com>
"Ben Bennett" <benbennett@gmail.com> writes:
> I can't seem to get git status to return that a file has changed. I
> think my environment is hosed up, but I don't know for sure. My
> machine is ubuntu 8.04 with kernel 2.6.24-17-generic #1 SMPx86_64
> GNU/Linux . I set up a test repo and it added one file to it ,
> modified the file and saved . Doing git status returns nothing, git
> gui finds no modified files. Doing git add * finds the modified file
> and stages it. I can get someone a strace for the git status it is
> only about a 1 page.
You should have got something like the following:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: bar
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: bar
#
BTW. you have made initial commit, did you?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v6] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Jakub Narebski @ 2008-06-23 13:31 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <1214183688-8544-1-git-send-email-LeWiemann@gmail.com>
Lea Wiemann wrote:
> +# We don't count properly when skipping, so no_plan is necessary.
> +use Test::More qw(no_plan);
I'd rather either skip this comment all together, or change it to
read something like that (I don't have good solution):
+# Counting tests upfront is difficult, as number of tests depends
+# on existence of several Perl modules, and is next to impossible
+# when spidering gitweb output (for --long-test). Additionally,
+# having number of tests planned stated at beginning is not necessary,
+# as this test is to be run from git test suite, and not to be
+# processed further by TAP (Test Anything Protocol) Perl modules.
See http://www.perlfoundation.org/perl5/index.cgi?testing for
explanation why (and when) 'plan' is useful:
TAP output usually starts with a plan line:
1..9
which specifies how many tests are to follow. The above example
specifies 9 tests.
This line is optional, but recommended. Should a test suite die
part-way through, the plan allows the testing framework to recognise
this situation, rather than assuming that all tests were completed.
> +our $long_tests = $ENV{GIT_TEST_LONG};
Here also it could be "my $long_tests"; but I am not a Perl hacker,
and do not know which is preferred.
> +eval { require Archive::Tar; };
> +my $archive_tar_installed = !$@
> + or diag('Archive::Tar is not installed; no tests for valid snapshots');
> +chomp(my @heads = map { (split('/', $_))[2] } `git-for-each-ref --sort=-committerdate refs/heads`);
> +chomp(my @tags = map { (split('/', $_))[2] } `git-for-each-ref --sort=-committerdate refs/tags`);
Wouldn't be easier to use '--format=%(refname)' in git-for-each-ref
invocation? Besides, gitweb now uses in link _full_ refname, i.e.
"refs/heads/<name>" and "refs/tags/<name>" to avoid branch / tag
ambiguity (when there are both branch and head with the same name).
> +# files and directories in HEAD root:
> +chomp(my @files = map { (split("\t", $_))[1] } `git-ls-tree HEAD`);
Wouldn't it be easier to use "git ls-tree --names-only HEAD"?
> +sub rev_parse (...)
> +sub get_type (...)
Nice.
> +my $gitweb = abs_path(File::Spec->catfile('..', '..', 'gitweb', 'gitweb.cgi'));
> +
> +# Thus subroutine was copied (and modified to work with blanks in the
> +# application path) from WWW::Mechanize::CGI 0.3, which is licensed
> +# 'under the same terms as perl itself' and thus GPL compatible.
Errr... I think that without my comment you removed it is hard to
understand what this comment talks about. "Thus ..." without any
preceding sentence?
> +my $cgi = sub {
> + # Use exec, not the shell, to support blanks in the path.
blanks = embedded whitespace?
path = path to gitweb?
> + my $status = system { $ENV{GITPERL} } $ENV{GITPERL}, $gitweb;
> + my $value = $status >> 8;
> +
> + croak( qq/Failed to execute application '$gitweb'. Reason: '$!'/ )
> + if ( $status == -1 );
> + croak( qq/Application '$gitweb' exited with value: $value/ )
> + if ( $value > 0 );
> +};
> +
> +my $mech = new Test::WWW::Mechanize::CGI;
> +$mech->cgi($cgi);
Looks good. Thanks.
> + # WebService::Validator::Feed::W3C would be nice to
> + # use, but it doesn't support direct input (as opposed
> + # to URIs) long enough for our feeds.
Could you tell us here what are the limitations? Are those limits
of W3C SOAP interface for web validation, or the CPAN package mentioned?
> + return 1
Style: "return 1;"
> +# RSS/Atom/OPML view. Simply retrieve and check.
> +{
> + # Broken link in Atom/RSS view -- cannot spider:
> + # http://mid.gmane.org/485EB333.5070108@gmail.com
> + local $long_tests = 0;
> + test_page('?p=.git;a=atom', 'Atom feed');
> + test_page('?p=.git;a=rss', 'RSS feed');
> +}
> +test_page('?a=opml', 'OPML outline');
This I think should be written using Test::More equivalent of
test_expect_failure in t/test-lib.sh, namely TODO block, either
as
TODO: {
local $TODO = "why";
...normal testing code...
}
or if it causes problem with t9503-gitweb-Mechanize.sh failing, perhaps
as
TODO: {
todo_skip "why", <n> if <condition>;
...normal testing code...
}
(And similarly for other pages).
> +# Blob view
I like those comments.
> diff --git a/t/test-lib.sh b/t/test-lib.sh
[...]
> +GITPERL=${GITPERL:-perl}
> +export GITPERL
How it is different from PERL_PATH?
--
Jakub Narebski
ShadeHawk on #git
Thorn, Poland
^ permalink raw reply
* Fwd: git status bug problem.
From: Ben Bennett @ 2008-06-23 13:22 UTC (permalink / raw)
To: git
In-Reply-To: <970bc7c80806230619i6c060c4eld329729ec7eef1da@mail.gmail.com>
I can't seem to get git status to return that a file has changed. I
think my environment is hosed up, but I don't know for sure. My
machine is ubuntu 8.04 with kernel 2.6.24-17-generic #1 SMPx86_64
GNU/Linux . I set up a test repo and it added one file to it ,
modified the file and saved . Doing git status returns nothing, git
gui finds no modified files. Doing git add * finds the modified file
and stages it. I can get someone a strace for the git status it is
only about a 1 page.
Thanks,
Ben
^ permalink raw reply
* Coming clean, after being stupid and ugly (or: globs and filtering with git-svn)
From: Michael J Gruber @ 2008-06-23 13:17 UTC (permalink / raw)
To: git
Hi there,
I've been a sinner regarding good repo structures: I lumped a lot of
stuff into one SVN repo. I blame SVN's clumsy admin commands and URLs
for that, of course... Along with my transition to git I want to change
this structure.
At the root of my SVN repo I have directories trunk/A, trunk/B and
trunk/C, say; similarly for branches/*/A etc.
I know how to "git-svn clone -s" the tree under A so that it becomes an
independent git repository (using "branches =
branches/*/A:refs/remotes/*" etc., i.e: git-svn init, edit config,
git-svn fetch).
But I want the trees under B and C to end up in the same git repository
(under B and C, of course). I could convert the whole SVN repo and
remove A afterwards using git-filter-branch, but this changes commit IDs
and leaves spurious branches, tags and commits which touch the tree
below A only, and would need to be removed also.
Is there any way to tell git-svn to do the filtering? It does some sort
of filtering already (evaluating the fetch, branches and tags glob
patterns). I would need something like
branches/*/{B,C}:refs/remotes/*
or
branches/*/{B,C}:refs/remotes/*/\1
to mean: treat only the trees below branches/something/B and
branches/something/C and put them into subdirs B resp. C of the same git
repo in branch something, for each something there is.
Alternatively: Where in git-svn should I look if I wanted to implement
something like that?
Cheers,
Michael
P.S.: Actually, the tree below A will end up in a tree of smaller repos,
and in my case I have more than just B and C which should end up in the
same repo. The description above is a minimal case.
^ 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