* Re: [RFC] Submodules in GIT
From: Uwe Kleine-Koenig @ 2006-12-05 15:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Martin Waitz, Andy Parkins, git
In-Reply-To: <45754AFE.1070207@op5.se>
Hella Andreas,
Andreas Ericsson wrote:
> >>The only problem I'm seeing atm is that the supermodule somehow has to
> >>mark whatever commits it's using from the submodule inside the submodule
> >>repo so that they effectively become un-prunable, otherwise the
> >>supermodule may some day find itself with a history that it can't restore.
> >One could circumvent that by creating a separate repo for the submodule
> >at checkout time and pull the needed objects in the supermodule's odb
> >when commiting the supermodule. This way prune in the submodule cannot
> >do any harm, because in it's odb are no objects that are important for
> >the supermodule.
>
> Yes, but then you'd lose history connectivity (I'm assuming you'd only
> pull in the tree and blob objects from the submodule, and prefix the
> tree-entrys with whatever directory you're storing the submodul in).
That's the reason for me prefering to pull in the complete commit.
I don't understand what you mean with "prefix the tree-entrys with
whatever directory you're storing the submodul in".
Maybe one of us doesn't understand tree objects correctly. AFAICT they
don't store the location where they occur, so there is no need to store
a prefix. E.g.
zeisberg@cepheus:/tmp$ mkdir test-repo
zeisberg@cepheus:/tmp$ cd test-repo/
zeisberg@cepheus:/tmp/test-repo$ git-init-db
defaulting to local storage area
zeisberg@cepheus:/tmp/test-repo$ echo LD_FLAGS=-ltest > Makefile
zeisberg@cepheus:/tmp/test-repo$ git add Makefile
zeisberg@cepheus:/tmp/test-repo$ git commit -m 'test1'
Committing initial tree 754eadab39642175748bb02155d2959176bcf014
zeisberg@cepheus:/tmp/test-repo$ mkdir subdir
zeisberg@cepheus:/tmp/test-repo$ cp Makefile subdir/
zeisberg@cepheus:/tmp/test-repo$ git add subdir/
zeisberg@cepheus:/tmp/test-repo$ git commit -m 'test2'
zeisberg@cepheus:/tmp/test-repo$ git ls-tree HEAD
100644 blob 610bafd79f92c7e546b104d5b22795df1f099723 Makefile
040000 tree 754eadab39642175748bb02155d2959176bcf014 subdir
So the tree that only contains the Makefile specifing LD_FLAGS has the
sha1id 754eadab39642175748bb02155d2959176bcf014 independent of being the
root of my project or a subtree.
But maybe I misunderstood you?
Best regards
Uwe
--
Uwe Kleine-Koenig
If a lawyer and an IRS agent were both drowning, and you could only save
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-05 15:30 UTC (permalink / raw)
To: Uwe Kleine-Koenig, Andreas Ericsson, Martin Waitz, Andy Parkins,
git
In-Reply-To: <20061205150217.GA5573@cepheus>
Uwe Kleine-Koenig wrote:
> Hella Andreas,
>
> Andreas Ericsson wrote:
>>>> The only problem I'm seeing atm is that the supermodule somehow has to
>>>> mark whatever commits it's using from the submodule inside the submodule
>>>> repo so that they effectively become un-prunable, otherwise the
>>>> supermodule may some day find itself with a history that it can't restore.
>>> One could circumvent that by creating a separate repo for the submodule
>>> at checkout time and pull the needed objects in the supermodule's odb
>>> when commiting the supermodule. This way prune in the submodule cannot
>>> do any harm, because in it's odb are no objects that are important for
>>> the supermodule.
>> Yes, but then you'd lose history connectivity (I'm assuming you'd only
>> pull in the tree and blob objects from the submodule, and prefix the
>> tree-entrys with whatever directory you're storing the submodul in).
> That's the reason for me prefering to pull in the complete commit.
>
> I don't understand what you mean with "prefix the tree-entrys with
> whatever directory you're storing the submodul in".
> Maybe one of us doesn't understand tree objects correctly. AFAICT they
> don't store the location where they occur, so there is no need to store
> a prefix. E.g.
>
> 100644 blob 610bafd79f92c7e546b104d5b22795df1f099723 Makefile
> 040000 tree 754eadab39642175748bb02155d2959176bcf014 subdir
>
> So the tree that only contains the Makefile specifing LD_FLAGS has the
> sha1id 754eadab39642175748bb02155d2959176bcf014 independent of being the
> root of my project or a subtree.
>
> But maybe I misunderstood you?
>
Nopes. I just didn't think of the fact that subtrees are trees and never
store any path-info no matter what. So basically the supermodule can
store all trees of all submodules for each commit adding a new submodule
revision (which is neat, since "casuals" never have to bother with
getting all the submodules if they want to see all the code used in any
particular revision), while we invent the new tree object "subm" that
points to a commit in the submodule repo. We then teach the tools to
recognize when the *real* submodule repo is present and just don't check
out trees from the supermodule odb that lead us to directories where
submodules reside. Simple and beautiful. Me likes.
*IF* we teach the history viewers about submodules is a different matter
though. I'm not sure it would make much sense to have simple text-mode
browsers show the submodule history, although I can imagine qgit and
gitk wanting to take advantage of their nice side-by-side DAG displaying
code to show all the repos in parallell, or link between them in some
point-and-click kind of way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-12-05 16:00 UTC (permalink / raw)
To: Uwe Kleine-Koenig, Andreas Ericsson, Martin Waitz, Andy Parkins,
git
In-Reply-To: <20061205090125.GA2428@cepheus>
On Tue, Dec 05, 2006 at 10:01:25AM +0100, Uwe Kleine-Koenig wrote:
> Hello,
>
> Andreas Ericsson wrote:
> > The only problem I'm seeing atm is that the supermodule somehow has to
> > mark whatever commits it's using from the submodule inside the submodule
> > repo so that they effectively become un-prunable, otherwise the
> > supermodule may some day find itself with a history that it can't restore.
> One could circumvent that by creating a separate repo for the submodule
> at checkout time and pull the needed objects in the supermodule's odb
> when commiting the supermodule. This way prune in the submodule cannot
> do any harm, because in it's odb are no objects that are important for
> the supermodule.
I _think_ Linus argued against doing this (for scalability reasons),
although he didn't actually answer my question when I asked him directly.
In his proposal you wouldn't need to do this, because the particular
checked-out copy of the submodule that is located in a subdirectory
of a superproject would not be allowed to be pruned and it seems that
Martin has also implemented it like this.
^ permalink raw reply
* Adding spell checker to GIT
From: Deepak Barua @ 2006-12-05 16:05 UTC (permalink / raw)
To: git
Hi All,
I am just thought of a idea to integrate a spell checker with
git so that when we check in the code the code comments are spell
checked before being put into the tree,maybe have a optimized
dictionary search.
what about this...? is it appropriate ...?
Regards
Deepak
--
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Jakub Narebski @ 2006-12-05 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <b5a19cd20612050805x309d667eq649ba7ef1b8109b7@mail.gmail.com>
Deepak Barua wrote:
> Hi All,
> I am just thought of a idea to integrate a spell checker with
> git so that when we check in the code the code comments are spell
> checked before being put into the tree,maybe have a optimized
> dictionary search.
> what about this...? is it appropriate ...?
As an example pre-commit/commit-msg hook? Take for example distributed
with git example of pre-commit hook ensuring that patch is whitespace
clean, and commit-msg hook which removes duplicated signoff lines.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Johannes Schindelin @ 2006-12-05 16:13 UTC (permalink / raw)
To: Deepak Barua; +Cc: git
In-Reply-To: <b5a19cd20612050805x309d667eq649ba7ef1b8109b7@mail.gmail.com>
Hi,
On Tue, 5 Dec 2006, Deepak Barua wrote:
> I am just thought of a idea to integrate a spell checker with git so
> that when we check in the code the code comments are spell checked
> before being put into the tree,maybe have a optimized dictionary search.
I think the best idea would be to put this into the pre-commit hook.
Hth,
Dscho
^ permalink raw reply
* Adding spell checker to GIT
From: Deepak Barua @ 2006-12-05 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <b5a19cd20612050805x309d667eq649ba7ef1b8109b7@mail.gmail.com>
Hi Jakub & Johannes,
Thank you for your help i will consider
the precommit-hook.
Regards
Deepak
---------- Forwarded message ----------
From: Deepak Barua <dbbarua@gmail.com>
Date: Dec 5, 2006 9:35 PM
Subject: Adding spell checker to GIT
To: git@vger.kernel.org
Hi All,
I am just thought of a idea to integrate a spell checker with
git so that when we check in the code the code comments are spell
checked before being put into the tree,maybe have a optimized
dictionary search.
what about this...? is it appropriate ...?
Regards
Deepak
--
Code Code Code Away
--
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Linus Torvalds @ 2006-12-05 16:47 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Eric Wong, git
In-Reply-To: <86odqjj70y.fsf@blue.stonehenge.com>
On Mon, 4 Dec 2006, Randal L. Schwartz wrote:
>
> It just hates me, perhaps.
This may be a great moment in time.
We may have reached the point where git is sentient, and passed the
Turing test without us even realizing.
Please, somebody tell Sarah Connor.
^ permalink raw reply
* Re: Adding spell checker to GIT
From: Andreas Ericsson @ 2006-12-05 17:08 UTC (permalink / raw)
To: Deepak Barua; +Cc: git
In-Reply-To: <b5a19cd20612050805x309d667eq649ba7ef1b8109b7@mail.gmail.com>
Deepak Barua wrote:
> Hi All,
> I am just thought of a idea to integrate a spell checker with
> git so that when we check in the code the code comments are spell
> checked before being put into the tree,maybe have a optimized
> dictionary search.
> what about this...? is it appropriate ...?
>
Sounds like a worthy project for a pre-commit hook, imo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Re: Moving a directory into another fails
From: Linus Torvalds @ 2006-12-05 17:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0612050831550.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, 5 Dec 2006, Johannes Schindelin wrote:
>
> On Mon, 4 Dec 2006, Linus Torvalds wrote:
>
> > [core]
> > escapefilenames = true
>
> I think this goes too far.
Sure., I agree that in _practice_ this isn't actually a problem, because
people have long since learnt to avoid strange filenames in SCM's, simply
because you can't get it right with insane filesystems.
That said, it might be a good idea to abstract out the create/read phase
for filenames in the working tree regardless, since that also tends to be
an area where other issues can come up (whoops - '/' vs '\' as the
directory separator etc).
^ permalink raw reply
* Re: [PATCH 1/3] Document some current bugs and add to the TODO list.
From: Catalin Marinas @ 2006-12-05 17:30 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061130002717.21981.38049.stgit@gandelf.nowhere.earth>
Hi Yann,
See some comments below (I removed those which I am OK with or I fixed).
On 30/11/06, Yann Dirson <ydirson@altern.org> wrote:
> +- numeric shortcuts for naming patches near top (eg. +1, -2)
We currently have the -n option for push and pop that accepts number.
Because of python, you can also, for example, push to the last but one
with "push -n -1" (similar for pop). Do you mean shortcuts for the
"goto" command?
> +- refuse to "stg init" a branch known as remote (through .git/remotes/,
> + .git/branches/ or any other info)
I think it is up to the user not to do this. You would first need to
check out such a branch anyway.
> +- cannot use "stg refresh file" after "cg-rm file"
It seems to work for me. Can you send some log messages?
> +- "stg goto $(stg top)" fails with unhandled exception
It works for me. What StGIT version do you use?
> +- at least "commit is not robust wrt out-of-diskspace condition:
> +|deps$ stg commit
> +|error: git-checkout-index: unable to write file MANIFEST
> +|error: git-checkout-index: unable to write file META.yml
> +|error: git-checkout-index: unable to write file Makefile.PL
> +|error: git-checkout-index: unable to write file doc/README.dbk.xml
> +|error: git-checkout-index: unable to write file graph-includes
> +|error: git-checkout-index: unable to write file lib/graphincludes/params.pm
> +|fatal: unable to write new index file
> +|stg commit: git-read-tree failed (local changes maybe?)
> +|Committing 4 patches...
> +(luckily nothing was really committed)
But that's the correct behaviour, not to commit anything. The only
problem I see (and I fixed) is the "Committing..." message on stdout
without flushing, causing it to appear afterwards. StGIT cannot know
how much space is needed by GIT to check this beforehand. It simply
exits when a GIT command failed.
Thanks.
--
^ permalink raw reply
* Re: [PATCH] git-explain
From: Horst H. von Brand @ 2006-12-05 17:34 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, J. Bruce Fields, Nicolas Pitre, git,
Linus Torvalds
In-Reply-To: <20061205072622.GA21839@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
[...]
> As long as the safety valves don't come up _routinely_ in certain
> workflows, it seems OK to bypass them with a '-f' force switch. I
> suspect the best way to figure out if such workflows are in use is to
> put in the safety valves and see who complains; otherwise we're stuck
> with brainstorming workflows and deciding whether they make sense.
Problem is that nobody reads the manuals, next to nobody complains, and
when it doesn't work out via road A you try plan B. A might have been
exactly right, but it is blocked, and you'll never know if it is because of
fundamental reasons or by decree.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Ramsay Jones @ 2006-12-05 17:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0612021131140.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Fri, 1 Dec 2006, Junio C Hamano wrote:
>> Linus Torvalds <torvalds@osdl.org> writes:
>>> On Thu, 30 Nov 2006, Wink Saville wrote:
>>>> Earlier had a problem with git wanting merge but didn't have it and
>>>> couldn't figure out which package it was in Ubuntu:( So I symlinked merge
>>>> to kdiff3 which worked at the time:
>>> Btw, what's the status of the xdl_merge() thing in "pu"?
>> I haven't looked at the code any further than minimally checking
>> its external interface to be able to interface it with
>> merge-recursive and no more. Namely:
>>
>> - I haven't read the algorithm to judge its correctness;
>
> With my track record of blamable patches, that should be done by somebody
> else than me.
>
Have you had time to look at my test cases?
As I said, I found them very useful when debugging
my git-diff3 code, and (hopefully) you will find them
to be equally useful.
> Ciao,
> Dscho
>
All the best,
Ramsay
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Linus Torvalds @ 2006-12-05 18:28 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <4575B32F.5060108@ramsay1.demon.co.uk>
On Tue, 5 Dec 2006, Ramsay Jones wrote:
>
> Have you had time to look at my test cases?
> As I said, I found them very useful when debugging
> my git-diff3 code, and (hopefully) you will find them
> to be equally useful.
It might be interesting to also do a simple test:
- take every single merge in git (or the kernel, if you want even more)
- ignore all the trivial ones that didn't have any file-level merging at
all (ie done entirely in the index)
- for all the rest, just compare what the end result is when re-doing the
merge with "xdl_merge" vs "external 3-way merge".
[ Side note: DO NOT COMPARE AGAINST THE ACTUAL RESULT IN GIT OR IN THE
KERNEL ARCHIVE! Those will obviously have been fixed up by humans in the
event of a data conflict, and sometimes even in the _absense_ of a data
conflict (ie "git commit --amend" to fix up something that got mismerged
perfectly automatically or whatever).
So a script should literally re-do the merge two ways, and compare the
end result ]
Is that any "proof"? Of course not. And it will probably show differences
due to any conflict handling, but a lot of the time you'd expect to get
exactly the same end result, so the occasional differences are going to be
just all the more interesting ("it resolved differently, but it was
an equally good resolve" is interesting data on its own).
Anybody want to write a small script to do this?
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Johannes Schindelin @ 2006-12-05 18:36 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git
In-Reply-To: <4575B32F.5060108@ramsay1.demon.co.uk>
Hi,
On Tue, 5 Dec 2006, Ramsay Jones wrote:
> Have you had time to look at my test cases?
Not really. Besides, I did _not_ implement a full diff3, but _just_ the
merge. I.e. my function does not output anything, but (in theory) fills a
buffer with what merge would have written into the first file.
However, once I understand how your tests work, I'll try to concoct a test
script for git-with-xdl_merge.
Ciao,
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Junio C Hamano @ 2006-12-05 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ramsay Jones, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0612051023460.3542@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 5 Dec 2006, Ramsay Jones wrote:
>>
>> Have you had time to look at my test cases?
>> As I said, I found them very useful when debugging
>> my git-diff3 code, and (hopefully) you will find them
>> to be equally useful.
>
> It might be interesting to also do a simple test:
>
> - take every single merge in git (or the kernel, if you want even more)
>
> - ignore all the trivial ones that didn't have any file-level merging at
> all (ie done entirely in the index)
>
> - for all the rest, just compare what the end result is when re-doing the
> merge with "xdl_merge" vs "external 3-way merge".
>
> [ Side note: DO NOT COMPARE AGAINST THE ACTUAL RESULT IN GIT OR IN THE
> KERNEL ARCHIVE! Those will obviously have been fixed up by humans in the
> event of a data conflict, and sometimes even in the _absense_ of a data
> conflict (ie "git commit --amend" to fix up something that got mismerged
> perfectly automatically or whatever).
>
> So a script should literally re-do the merge two ways, and compare the
> end result ]
>
> Is that any "proof"? Of course not. And it will probably show differences
> due to any conflict handling, but a lot of the time you'd expect to get
> exactly the same end result, so the occasional differences are going to be
> just all the more interesting ("it resolved differently, but it was
> an equally good resolve" is interesting data on its own).
>
> Anybody want to write a small script to do this?
>
> Linus
I was planning to do this today anyway. Thanks for the
reminder.
^ permalink raw reply
* For all you darcs lovers: git-hunk-commit
From: Johannes Schindelin @ 2006-12-05 18:48 UTC (permalink / raw)
To: git; +Cc: Han-Wen Nienhuys
[-- Attachment #1: Type: TEXT/PLAIN, Size: 926 bytes --]
Hi,
I was inspired by Han-Wen. This script allows you to commit selected hunks
from the current modifications.
It has two modes: darcs mode (--darcs) and normal mode (without
arguments).
In darcs mode, all hunks are presented one by one, and you are asked if
you want to commit this or not. If you make a mistake: ^C and back to
start. I do not really know darcs, so this might not be how it works -- I
did not find any good documentation how a "darcs record" looks like.
Normal mode shows you the list of modified files, and lets you choose one.
Then it shows you how many hunks there are, and lets you pick one for
inspection, after which you are asked if you want it or not.
Normal mode is chattier, but if you know which (of those thousands) hunk
you want to commit, it is faster. Besides, it was easier to debug.
Note that this script uses no temporary files, but rather bash array
variables.
Ciao,
Dscho
[-- Attachment #2: Type: TEXT/PLAIN, Size: 5604 bytes --]
#!/bin/bash
# Copyright (C) 2006 Johannes E. Schindelin
# Distributed under the same license as git.
# Use this command to commit just a few hunks of the current output
# of "git diff". For your security, it only works when the index matches
# HEAD.
# ensure that this is a git repository
. git-sh-setup
# the index must match the HEAD
if [ -n "$(git diff --index --name-only HEAD)" ]; then
echo "The staging area (AKA index) is already dirty."
exit 1
fi
# read the names of all modified files into the array "modified"
declare -a modified
filenr=1
while read -d $'\0' file; do
modified[$filenr]="$file"
filenr=$(($filenr+1))
done < <(git ls-files --modified -z)
if [ ${#modified[*]} = 0 ]; then
echo "No modified files."
exit 1
fi
declare -a hunks
# interactively show the hunks of a file and ask if they should be committed.
# 1st parameter is the index into the modified file list.
# 2nd parameter should be "true" for darcs mode, empty otherwise.
# Darcs mode means that all hunks are presented one after another.
# Normal mode means user can specify hunks interactively.
select_hunks () {
local index=$1
local darcs_mode=$2
local filename=${modified[$index]}
local -a diff
local -a hunk_start
local current_hunks=${hunks[$index]}
local lineno
local hunkno
local action
local i
local active
lineno=1
hunkno=0
while read line; do
diff[$lineno]="$line"
case "$line" in
@@*)
hunk_start[$hunkno]=$lineno
hunkno=$(($hunkno+1))
;;
esac
lineno=$(($lineno+1))
done < <(git diff "$filename")
hunk_start[$hunkno]=$lineno
action=""
while [ "$action" != commit -a "$action" != abort ]; do
case "$darcs_mode" in
'')
echo
echo "Current hunks: ($current_hunks) of $hunkno hunks"
echo "To show (and decide on) a hunk type in the number."
echo "To commit the current hunks, say 'commit', else 'abort'."
echo
echo -n "Your choice? "
read action
;;
[1-9]*)
darcs_mode=$(($darcs_mode+1))
if [ $darcs_mode -gt $hunkno ]; then
action=commit
else
action=$darcs_mode
fi
;;
*)
darcs_mode=1
action=1
;;
esac
case "$action" in
c) action=commit;;
q|a) action=abort;;
commit|abort) ;;
[1-9]*)
echo
for ((i=${hunk_start[$(($action-1))]}; i<${hunk_start[$action]}; i++)); do
if [ -n "$darcs_mode" -a $i = ${hunk_start[0]} ]; then
echo "File: $filename"
fi
echo ${diff[$i]}
done | less -FS
active=$(echo $current_hunks,$action | tr , '\n' | sort | uniq -u | tr '\n' , | sed -e "s/^,//" -e "s/,$//")
if [ ${#active} -lt ${#current_hunks} ]; then
i=yes
else
i=no
fi
echo
while [ -n "$action" -a "$action" != yes -a "$action" != no -a -n "$action" ]; do
echo -n "Commit this hunk (default is $i)? "
read action
case "$action" in
y) action=yes;;
n) action=no;;
esac
done
if [ -n "$action" -a $i != "$action" ]; then
current_hunks=$active
fi
;;
*) echo "Unknown command: $action";;
esac
done
if [ "$action" = commit ]; then
hunks[$index]=$current_hunks
fi
}
# Apply the hunks saved in the array hunks for the specified file.
# This means that the diff is rewritten to skip the unwanted hunks.
apply_hunks () {
local index=$1
local filename=${modified[$index]}
local -a current_hunks
local lineno
local lineno2
local linediff
local hunkno
local i
local active
i=0
while read hunkno; do
current_hunks[$i]=$hunkno
i=$(($i+1))
done < <(echo ${hunks[$index]} | tr , '\n')
linediff=0
hunkno=0
i=0
active=true
while read line
do
case "$line" in
@@*)
hunkno=$(($hunkno+1))
if [ $hunkno = "${current_hunks[$i]}" ]; then
active=true
i=$(($i+1))
if [ $linediff -ne 0 ]; then
lineno=$(echo "$line" | sed "s/^.*+\([0-9]*\)[, ].*$/\1/")
lineno2=$(($lineno+$linediff))
line="$(echo "$line" | sed "s/+$lineno/+$lineno2/")"
fi
else
active=
lineno=$(echo "$line" | sed -n "s/^.*-[0-9]*,\([0-9]*\) .*$/\1/p")
if [ -z "$lineno" ]; then
lineno=1
fi
lineno2=$(echo "$line" | sed -n "s/^.*+[0-9]*,\([0-9]*\) .*$/\1/p")
if [ -z "$lineno2" ]; then
lineno2=1
fi
linediff=$(($linediff+$lineno-$lineno2))
fi
;;
esac
if [ -n "$active" ]; then
echo "$line"
fi
done < <(git diff "$filename")
}
darcs_mode=
case "$1" in
--darcs) darcs_mode=true;;
esac
IFS=''
action=
i=
while [ "$action" != commit -a "$action" != abort ]; do
case "$darcs_mode" in
'')
echo
for ((i=1; i<$filenr; i++)); do
echo -n "$i ${modified[$i]}"
if [ -n "${hunks[$i]}" ]; then
echo " (${hunks[$i]})"
else
echo
fi
done | less -FS
echo
echo "To put one or more hunks of a file into the staging area (AKA"
echo "index), type in the number of the file."
echo "To commit, say 'commit', to abort, say 'abort'."
echo
echo -n "Your choice? "
read action
;;
true)
if [ -z "$i" ]; then
i=1
else
i=$(($i+1))
fi
if [ $i -ge $filenr ]; then
action=commit
else
action=$i
fi
;;
esac
case "$action" in
c) action=commit;;
q|a) action=abort;;
commit|abort) ;;
[0-9]*) select_hunks "$action" "$darcs_mode";;
*) echo "Unknown command." ;;
esac
done
if [ "$action" = commit ]; then
for ((i=1; i<$filenr; i++)); do
if [ -n "${hunks[$i]}" ]; then
apply_hunks $i
fi
done | tee a123 | git apply --cached
git commit
fi
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Johannes Schindelin @ 2006-12-05 18:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ramsay Jones, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0612051023460.3542@woody.osdl.org>
Hi,
On Tue, 5 Dec 2006, Linus Torvalds wrote:
> - take every single merge in git (or the kernel, if you want even more)
I tried that already. Only to find that the first merge I tested showed
one change between RCS merge and xdl_merge(): xdl_merge() does not yet
take context into account, so these two diffs
@@ bla
Ten
+weary
footsore
+wanderers
all
in
a
and
@@ blub
Ten
+weird
footsore
all
in
a
will conflict only for the weary/weird lines, _not_ for wanderers.
Besides, my recent patch series was gained exactly by that test. Though I
did not extend that test to the Linux repo, and I am by no means finished
with the git one.
Ciao,
^ permalink raw reply
* git 1.4.4.1.gba98 crash pulling tig
From: Horst H. von Brand @ 2006-12-05 19:25 UTC (permalink / raw)
To: git
On i686, Fedora rawhide fully up to date, git version 1.4.4.1.gba98,
compiled with the standard CFLAGS and all. It happens to me all the time
fetching via HTTP. Trying to clone tig gives:
[vonbrand@laptop13 tmp]$ PATH=~/bin:$PATH git clone http://jonas.nitro.dk/tig/tig.git
error: Unable to start request
error: Could not interpret heads/release as something to pull
On sparc (Aurora Corona up to date) it works fine. Trying to pull the same
repo crashes as below on i386, the pull works on sparc, and I can pull from
there to this machine via git+ssh. Any way I can debug this further?
[vonbrand@laptop13 tig]$ PATH=~/bin:$PATH git pull
Fetching refs/heads/master from http://jonas.nitro.dk/tig/tig.git using http
error: Request for 56e652be994f94b724f79cea0712663a62308034 aborted
*** glibc detected *** git-http-fetch: double free or corruption (fasttop): 0x08084b60 ***
======= Backtrace: =========
/lib/libc.so.6[0x4e2d8e3d]
/lib/libc.so.6(cfree+0x90)[0x4e2dc490]
git-http-fetch[0x804b2ec]
git-http-fetch[0x804c671]
git-http-fetch[0x804a0c7]
git-http-fetch[0x804b5a8]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4e288e5c]
git-http-fetch[0x8049ae1]
======= Memory map: ========
08048000-08062000 r-xp 00000000 fd:01 559254 /home/vonbrand/bin/git-http-fetch
08062000-08063000 rw-p 00019000 fd:01 559254 /home/vonbrand/bin/git-http-fetch
08063000-080ba000 rw-p 08063000 00:00 0 [heap]
4d8a2000-4d8bd000 r-xp 00000000 fd:00 33074 /lib/ld-2.5.90.so
4d8bd000-4d8be000 r--p 0001a000 fd:00 33074 /lib/ld-2.5.90.so
4d8be000-4d8bf000 rw-p 0001b000 fd:00 33074 /lib/ld-2.5.90.so
4d8c1000-4d9dd000 r-xp 00000000 fd:00 33087 /lib/libcrypto.so.0.9.8b
4d9dd000-4d9ef000 rw-p 0011c000 fd:00 33087 /lib/libcrypto.so.0.9.8b
4d9ef000-4d9f3000 rw-p 4d9ef000 00:00 0
4d9f5000-4da05000 r-xp 00000000 fd:00 33085 /lib/libresolv-2.5.90.so
4da05000-4da06000 r--p 0000f000 fd:00 33085 /lib/libresolv-2.5.90.so
4da06000-4da07000 rw-p 00010000 fd:00 33085 /lib/libresolv-2.5.90.so
4da07000-4da09000 rw-p 4da07000 00:00 0
4da53000-4da55000 r-xp 00000000 fd:00 33086 /lib/libcom_err.so.2.1
4da55000-4da56000 rw-p 00001000 fd:00 33086 /lib/libcom_err.so.2.1
4da8b000-4dab5000 r-xp 00000000 fd:03 502786 /usr/lib/libgssapi_krb5.so.2.2
4dab5000-4dab6000 rw-p 00029000 fd:03 502786 /usr/lib/libgssapi_krb5.so.2.2
4dab8000-4dabf000 r-xp 00000000 fd:03 502648 /usr/lib/libkrb5support.so.0.1
4dabf000-4dac0000 rw-p 00006000 fd:03 502648 /usr/lib/libkrb5support.so.0.1
4dac2000-4dae7000 r-xp 00000000 fd:03 502680 /usr/lib/libk5crypto.so.3.0
4dae7000-4dae8000 rw-p 00025000 fd:03 502680 /usr/lib/libk5crypto.so.3.0
4daea000-4db6f000 r-xp 00000000 fd:03 502695 /usr/lib/libkrb5.so.3.2
4db6f000-4db71000 rw-p 00084000 fd:03 502695 /usr/lib/libkrb5.so.3.2
4db73000-4dbb4000 r-xp 00000000 fd:00 33088 /lib/libssl.so.0.9.8b
4dbb4000-4dbb8000 rw-p 00040000 fd:00 33088 /lib/libssl.so.0.9.8b
4dbba000-4dbea000 r-xp 00000000 fd:03 505200 /usr/lib/libidn.so.11.5.22
4dbea000-4dbeb000 rw-p 0002f000 fd:03 505200 /usr/lib/libidn.so.11.5.22
4dc25000-4dc61000 r-xp 00000000 fd:03 505465 /usr/lib/libcurl.so.4.0.0
4dc61000-4dc62000 rw-p 0003c000 fd:03 505465 /usr/lib/libcurl.so.4.0.0
4e273000-4e3be000 r-xp 00000000 fd:00 33075 /lib/libc-2.5.90.so
4e3be000-4e3c0000 r--p 0014b000 fd:00 33075 /lib/libc-2.5.90.so
4e3c0000-4e3c1000 rw-p 0014d000 fd:00 33075 /lib/libc-2.5.90.so
4e3c1000-4e3c4000 rw-p 4e3c1000 00:00 0
4e3f1000-4e3f4000 r-xp 00000000 fd:00 33076 /lib/libdl-2.5.90.so
4e3f4000-4e3f5000 r--p 00002000 fd:00 33076 /lib/libdl-2.5.90.so
4e3f5000-4e3f6000 rw-p 00003000 fd:00 33076 /lib/libdl-2.5.90.so
4e412000-4e424000 r-xp 00000000 fd:03 498995 /usr/lib/libz.so.1.2.3
4e424000-4e425000 rw-p 00011000 fd:03 498995 /usr/lib/libz.so.1.2.3
4e636000-4e655000 r-xp 00000000 fd:00 33083 /lib/libexpat.so.0.5.0
4e655000-4e657000 rw-p 0001e000 fd:00 33083 /lib/libexpat.so.0.5.0
4ee44000-4ee4f000 r-xp 00000000 fd:00 33084 /lib/libgcc_s-4.1.1-20061130.so.1
4ee4f000-4ee50000 rw-p 0000a000 fd:00 33084 /lib/libgcc_s-4.1.1-20061130.so.1
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f6d000-b7fd5000 r--p 00000000 fd:01 955780 /home/vonbrand/tmp/tig/.git/objects/pack/pack-c1fd326a6b3d7c1aa4e1b542dd5f3aeb45eb6582.pack
b7fd5000-b7fdf000 r-xp 00000000 fd:00 33048 /lib/libnss_files-2.5.90.so
b7fdf000-b7fe0000 r--p 00009000 fd:00 33048 /lib/libnss_files-2.5.90.so
b7fe0000-b7fe1000 rw-p 0000a000 fd:00 33048 /lib/libnss_files-2.5.90.so
b7fe1000-b7fe6000 rw-p b7fe1000 00:00 0
b7ff4000-b7ffa000 r--p 00000000 fd:01 956575 /home/vonbrand/tmp/tig/.git/objects/pack/pack-c1fd326a6b3d7c1aa4e1b542dd5f3aeb45eb6582.idx
b7ffa000-b7ffb000 r-xp b7ffa000 00:00 0 /home/vonbrand/bin/git-fetch: line 300: 20236 Aborted git-http-fetch -v -a "$head" "$remote/"
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Randal L. Schwartz @ 2006-12-05 19:45 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <20061205121443.GB2428@cepheus>
>>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
Uwe> #! /bin/sh
Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
Ow. My eyes hurt from that. How about we rewrite that as a native Perl
script:
#!/usr/bin/perl
$^I = ""; # this is -i
while (<>) {
s/\$(Id|Revision):.*?\$/\$$1: \$/;
print;
}
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Johannes Schindelin @ 2006-12-05 19:48 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Uwe Kleine-Koenig, Jon Smirl, Git Mailing List
In-Reply-To: <86k616m8i9.fsf@blue.stonehenge.com>
Hi,
On Tue, 5 Dec 2006, Randal L. Schwartz wrote:
> >>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
>
> Uwe> #! /bin/sh
> Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
>
> Ow. My eyes hurt from that. How about we rewrite that as a native Perl
> script:
>
> #!/usr/bin/perl
> $^I = ""; # this is -i
> while (<>) {
> s/\$(Id|Revision):.*?\$/\$$1: \$/;
> print;
> }
Hey, that's better! All of a sudden, I understand everything!
Not,
Dscho
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Junio C Hamano @ 2006-12-05 19:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Ramsay Jones, git
In-Reply-To: <Pine.LNX.4.63.0612051949290.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 5 Dec 2006, Linus Torvalds wrote:
>
>> - take every single merge in git (or the kernel, if you want even more)
The attached is the script I am using. The test checks the
output from 'master' (merge from RCS) and 'next' (with xdl-merge)
and also tries to see how different the conflicts look like.
In the git.git archive, there is no "clean" merge on which
'master' and 'next' did not agree. It is not a proof of
correctness at all but it gives a sense of assurance.
However, the conflict 'next' leaves seems a bit suspicious.
Trying to reproduce
56f9686c4d1e1d586b731b815bd98d70f84ecda4
gives an interesting illustration.
Here is one conflicted hunk from that merge (RCS merge)
-- 8< -- RCS merge conflict hunk, diff from the 1st parent -- 8< --
--- a/Makefile
+++ b/Makefile
@@ -232,8 +232,13 @@ LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
LIB_H = \
+<<<<<<< HEAD/Makefile
archive.h blob.h cache.h commit.h csum-file.h delta.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h \
+=======
+ blob.h cache.h commit.h csum-file.h delta.h \
+ diff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \
+>>>>>>> d47f3db75c58139cdcbca5cc63b17bf5db293b6a/Makefile
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h
-- >8 -- RCS merge conflict hunk, diff from the 1st parent -- >8 --
-- 8< -- JS merge conflict hunk, diff from the 1st parent -- 8< --
--- a/Makefile
+++ b/Makefile
@@ -232,8 +232,14 @@ LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
LIB_H = \
+<<<<<<< HEAD/Makefile
archive.h blob.h cache.h commit.h csum-file.h delta.h \
diff.h object.h pack.h pkt-line.h quote.h refs.h \
+=======
+ blob.h cache.h commit.h csum-file.h delta.h \
+ diff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \
+>>>>>>> d47f3db75c58139cdcbca5cc63b17bf5db293b6a/Makefile
+ diff.h object.h pack.h pkt-line.h quote.h refs.h sideband.h \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h
-- >8 -- JS merge conflict hunk, diff from the 1st parent -- >8 --
Notice that there is one duplicated line after the closing
conflict marker?
-- 8< -- remerge.sh test script -- 8< --
#!/bin/sh
# Leaves things to be examined in /var/tmp/remerge-$$/
ogit=$HOME/git-master/bin/git
ngit=$HOME/git-next/bin/git
tmp=/var/tmp/remerge-$$-tmp
trap 'rm -f $tmp-*' 0
# Revlist
if ! test -f ./+RL
then
git rev-list --parents HEAD |
perl -n -e 'if (/^[0-9a-f]{40} [0-9a-f]{40} [0-9a-f]{40}$/) {
print;
}' >./+RL
fi
try_one () {
# should be on a discardable branch.
git=$1 parent1=$2 parent2=$3
$git reset --hard "$parent1"
if $git merge "$parent2"
then
echo clean merge
$git diff-tree -r --raw "$parent1" HEAD
else
echo conflicted merge
$git ls-files -u
$git diff --binary -p "$parent1"
fi
}
# Make sure we do not trash anything important
current=`git symbolic-ref HEAD`
if test "z$current" != zrefs/heads/remerge-test
then
git checkout -b remerge-test ||
git checkout remerge-test
current=`git symbolic-ref HEAD`
test "z$current" = zrefs/heads/remerge-test || exit
fi
while read result parent1 parent2
do
try_one $ogit $parent1 $parent2 >$tmp-1 2>/dev/null
try_one $ngit $parent1 $parent2 >$tmp-2 2>/dev/null
if diff $tmp-1 $tmp-2
then
echo "Ok"
else
echo "Bad $result"
mkdir -p $tmp/$result
mv $tmp-1 $tmp/$result/ogit
mv $tmp-2 $tmp/$result/ngit
fi
$git reset --hard
done < ./+RL
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Junio C Hamano @ 2006-12-05 19:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86k616m8i9.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
>
> Uwe> #! /bin/sh
> Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
>
> Ow. My eyes hurt from that. How about we rewrite that as a native Perl
> script:
>
> #!/usr/bin/perl
> $^I = ""; # this is -i
> while (<>) {
> s/\$(Id|Revision):.*?\$/\$$1: \$/;
> print;
> }
That's kinda surprising coming from the resident Perl guru.
I am so used to the command line "-i -p" that I did not even
know what $^I does, and I would have lost without your "# this
is -i" comment. That alone makes the Uwe's one more readable
for me ;-).
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Robin Rosenberg @ 2006-12-05 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7v64cqglsm.fsf@assigned-by-dhcp.cox.net>
tisdag 05 december 2006 20:55 skrev Junio C Hamano:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
> >>>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de>
> >>>>>> writes:
> >
> > Uwe> #! /bin/sh
> > Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
> >
> > Ow. My eyes hurt from that. How about we rewrite that as a native Perl
> > script:
> >
> > #!/usr/bin/perl
> > $^I = ""; # this is -i
> > while (<>) {
> > s/\$(Id|Revision):.*?\$/\$$1: \$/;
> > print;
> > }
>
> That's kinda surprising coming from the resident Perl guru.
>
> I am so used to the command line "-i -p" that I did not even
> know what $^I does, and I would have lost without your "# this
> is -i" comment. That alone makes the Uwe's one more readable
> for me ;-).
May I suggest a compromise? :
#!/usr/bin/perl -i -p
s/\$(Id|Revision):.*?\$/\$$1: \$/;
^ permalink raw reply
* Re: [PATCH] git-explain
From: J. Bruce Fields @ 2006-12-05 21:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0612050950450.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Dec 05, 2006 at 09:58:25AM +0100, Johannes Schindelin wrote:
> On Mon, 4 Dec 2006, Junio C Hamano wrote:
> > "J. Bruce Fields" <bfields@fieldses.org> writes:
> >
> > > On Mon, Dec 04, 2006 at 10:55:49PM -0500, Nicolas Pitre wrote:
> > >> ...
> > >> > [PATCH] git-explain
> > >> > ...
> > >>
> > >> What about calling it git-whatsup instead?
> > >
> > > No, clearly it should be git-wtf.
> >
> > Should I take these responses to mean that you two are negative
> > about the approach [...]
>
> I think they just were in the mood for some slashdot style
> unimportant-aspects-in-a-funny-way discussion.
Yeah, I was just being silly, apologies.
^ 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