* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Junio C Hamano @ 2009-01-21 8:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0901210209580.19014@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This patch adds the ability to use valgrind's memcheck tool to
> diagnose memory problems in git while running the test scripts....
Hmmm, why do I haf to suffer with these new warnings from the tests?
$ sh t2012-checkout-last.sh --valgrind -v -i
warning: templates not found /git/git.git/t/valgrind/bin/templates/blt/
Initialized empty Git repository in /git/git.git/t/trash directory.t2012-checkout-last/.git/
mv: cannot stat `.git/hooks': No such file or directory
* expecting success:
echo hello >world &&
Am I using the patch incorrectly somehow?
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Michael J Gruber @ 2009-01-21 9:13 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git, Junio C Hamano
In-Reply-To: <4976E059.6000404@telenor.com>
Knut Olav Bøhmer venit, vidit, dixit 21.01.2009 09:44:
> Junio C Hamano wrote:
>> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>>
>>> svnmerge.py can give us a list of revisions available for merging. The
>>> result is similar to "git log --chery-pick master..dev" The difference
>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>>> at the diffs. The result of that is that when we get a conflict when a
>>> patch is cherry-picked, it will still show up as "available" when I run
>>> "git log --cherry-pick master..dev"
>> I think you are looking at it a wrong way.
>>
>> Because subversion (at least the older one) does not keep track of merges,
>> you had to track cherry-picks. But cherry-pick is not how you usually do
>> things in git. You keep many topic branches with different doneness, and
>> you merge well-cooked ones to the more stable integration branch while
>> leaving others still cooking. So what you want to know is not cherry-pick
>> status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
In the transition phase, while you still have to work off your
un-gittish svn feature branches, you can mimick svnmerge.py's blocking
at least somewhat: If you merge that branch (or a commit on that branch,
i.e. that branch up to that commit) using "git merge -s ours" then git
records a merge but does not change your base branch. This effectively
blocks all commits up that one from being merged in subsequent merges:
They're recorded as merged, but they are not "applied".
The disadvantage is that you have to go through your svn feature branch
sequentially, merge what you want to keep, merge -s ours what you want
to block. You can't easily "unblock" later because that would mean
reverting a merge.
For sure, the better option is to rip your svn feature branch apart into
git feature branches as Junio suggests, maybe using one of the patch
queue like "extensions" to git.
Michael
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Thomas Rast @ 2009-01-21 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vwscpgi7t.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Junio C Hamano wrote:
> We only accept "checkout: moving from A to B" newer style reflog entries,
> in order to pick up A. There is no point computing where B begins at
> after running strstr to locate " to ", nor adding 4 and then subtracting 4
> from the same pointer.
[...]
> - len = target - match - 4;
> - if (target[len] == '\n' && !strncmp(match, target, len))
> - return 0;
> -
> + len = target - match;
Actually the point of that exercise was to ignore branch (non)switches
of the form
checkout: moving from A to A
I originally thought that this would be desirable behaviour, but now
that it causes so much trouble, I'm not that sure any more. I still
think it would be more intuitive to not count them as switches (after
all git-checkout says 'Already on "$branch"'), but OTOH 'cd .; cd -'
also stays in the same directory.
Thanks for all the work you (both) are doing on this. I hope to find
the time to read the current state of the series tonight.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Change the spelling of "wordregex".
From: Thomas Rast @ 2009-01-21 9:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boyd Stephen Smith Jr., Santi Béjar, git, Junio C Hamano,
Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901210925430.7929@racer>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Johannes Schindelin wrote:
> And Thomas just imitated "xfuncname", which just so happens to be without
> an "_".
Then again I ignored the 'x' for "extended regex", so it's not
entirely consistent.
[Mostly because I think the user expects a "<something>" whenever
there's an "x<something>", and "funcname" is actually deprecated/not
documented any more, so introducing a basic-regex version seemed
silly.]
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Junio C Hamano @ 2009-01-21 9:47 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git
In-Reply-To: <4976E059.6000404@telenor.com>
Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
> Junio C Hamano wrote:
>> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>>
>>> svnmerge.py can give us a list of revisions available for merging. The
>>> result is similar to "git log --chery-pick master..dev" The difference
>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>>> at the diffs. The result of that is that when we get a conflict when a
>>> patch is cherry-picked, it will still show up as "available" when I run
>>> "git log --cherry-pick master..dev"
>>
>> I think you are looking at it a wrong way.
>>
>> Because subversion (at least the older one) does not keep track of merges,
>> you had to track cherry-picks. But cherry-pick is not how you usually do
>> things in git. You keep many topic branches with different doneness, and
>> you merge well-cooked ones to the more stable integration branch while
>> leaving others still cooking. So what you want to know is not cherry-pick
>> status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
Maybe I should rephrase the answer, then.
I had an impression that you made it sound as if svnmerge.py is a tool
only meant for a workflow of always cherry-picking, but it actually is
not. It also enhances your SVN experience by giving something closer to
proper merge tracking. Even though you only mentioned cherry-picks and
merge blocking, if you like things offered by svnmerge.py other than these
two, you might find that git already has them natively.
When your workflow is based on a single large, unfocused, everything
mixed-in, playpen branch, plus one stable integration branch, you have to
cherry pick to keep the stable integration branch sane, and you need a
good tool to help you keep track of what is cherry picked and what isn't
(yet). Maybe your SCM has such a tool natively, or maybe it doesn't and
needs a third party tool support (similar to users of older SVN needed to
use svnmerge.py for merge tracking) bolted on.
---A1--B1--C1--A2--A3--C2--D1--... playpen kitchen-sink
---o---o---o---A1'--A2'--A3'... stable integration
The workflow when using git is typically merge based, and git lets you
manage topic branches well and helps you merge easily by keeping track of
merges.
I am reading from http://www.orcaware.com/svn/wiki/Svnmerge.py while I am
typing this, but here is a summary:
(1) Because merge tracking is built-in to git, you do not need "something
like svnmerge.py" bolted on. If you have been using topic branches
in your established SVN-based workflow, you can keep the same
workflow and git will do the right thing when you merge your
branches naturally.
(2) We didn't have need for "cherry-pick tracking" part of what
svnmerge.py offers, because we do not do cherry-picks as often.
You can call this shortcoming if you want, but it should be easy for
you to contribute a patch to add such a tool if you miss this part of
svnmerge.py; essentially, you need to keep a database of commit
object names on the "playpen branch" depicted above, and
corresponding commit objects cherry-picked from them into the
integration branch.
(3) We have "listing changes that are available for merging" natively, as
I've already explained in the previous message.
(4) Bidirectional merges, merging from multiple branches, reverting
merges, and merge commit message generation are all native features
of "git merge". If you have git, you already have them. If you do
not like the merge result, you can always amend it; commit-free-ness
is listed as if it is a feature but it does not matter here.
(5) We do not have "merge blocking". This falls into the same category
as (2) above.
^ permalink raw reply
* Re: how to git a read only directory
From: Michael J Gruber @ 2009-01-21 9:57 UTC (permalink / raw)
To: git, cbill.lam
In-Reply-To: <20090121083354.GG6970@b2j>
bill lam venit, vidit, dixit 21.01.2009 09:33:
> I want to use git to keep track of files inside /etc but do not want
> to do it as a super user. Is that possible to put GIT_DIR under my
> home directory and add public-read files inside /etc? Or that it could
> be done in some other ways.
>
> Thanks.
>
You can use the core.worktree config variable in order to specify a
worktree (/etc) which is not directly above .git. For your git commands
to find the .git dir you would need to set GIT_DIR or use the --git-dir
parameter.
I have found, though, that several git commands require you to be within
the worktree or else they become confused. I use a shell function for
that, doing something like "gg ~/path/project log" which requires
~/path/project.git to have its core.worktree set. Also, having a git
alias like "git view" set up for gitk helps calling gitk in that way.
git-gui makes unfounded assumptions and is completely unhappy in a
situation like that.
I think the situation around GIT_DIR and and worktree is a bit in the
flux at the moment (panta rhei..) but it works for me.
Cheers,
Michael
Here's the "git go" bash function. I'm not proud of it, it makes several
assumptions and does no error checking. Use it like "gg path/project
command parameters" if the git-dir is "path/project.git" or "gg
path/project/" if the git-dir is "path/project/.git". Have your
core.worktree set in the former case, and also in the latter if the
worktree is not "path/project".
I'm sure it can be done much better using helper functions from git's
bash-completion, e.g.
gg ()
{
local _gg="$1";
shift;
local _ggwt=`git --git-dir="${_gg}.git" config --get core.worktree`;
if [ -z "${_ggwt}" ]; then
_ggwt=$(cd ${_gg} 2> /dev/null && pwd -P);
fi;
local _gggd=$(cd ${_gg}.git 2> /dev/null && pwd -P);
pushd ${_ggwt} > /dev/null;
git --git-dir=${_gggd} "$@";
popd > /dev/null
}
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Junio C Hamano @ 2009-01-21 10:13 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johannes Schindelin, git, Johannes Sixt, Johan Herland
In-Reply-To: <200901211019.01493.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Actually the point of that exercise was to ignore branch (non)switches
> of the form
>
> checkout: moving from A to A
Ahhh, Ok, that is what I missed.
> I originally thought that this would be desirable behaviour, but now
> that it causes so much trouble, I'm not that sure any more. I still
> think it would be more intuitive to not count them as switches (after
> all git-checkout says 'Already on "$branch"'), but OTOH 'cd .; cd -'
> also stays in the same directory.
An entry of the form "from A to A" is made only when you explicitly ask to
checkout the current branch by name (i.e. "git checkout" without any
parameter won't add such an entry to the reflog), so I tend to agree with
"cd" that the users may find it more natural if we counted them.
Having said all that, I think Dscho's one had an off-by-one (but it is
getting late and it may be I who has one).
When parsing "checkout: moving from master to side\n", match points at
"master to...", target points at "side\n", and len is 6 (length of
"master"). We want to see if target is "master\n" and ignore such an
entry, so we should be checking if target is one longer than len.
sha1_name.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git c/sha1_name.c w/sha1_name.c
index 38c9f1b..9aed8ae 100644
--- c/sha1_name.c
+++ w/sha1_name.c
@@ -731,7 +731,10 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
return 0;
len = target - match - 4;
- if (target[len] == '\n' && !strncmp(match, target, len))
+ if (len + 1 == strlen(target) &&
+ target[len] == '\n' &&
+ !memcmp(target, match, len))
+ /* switching same branch "from A to A\n" */
return 0;
nth = cb->cnt++ % cb->alloc;
^ permalink raw reply related
* Re: [PATCH] [TOPGIT] make creating a commit from a topgit branch a function
From: Uwe Kleine-König @ 2009-01-21 10:16 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Petr Baudis
In-Reply-To: <20090121031913.GA7422@lapse.rw.madduck.net>
On Wed, Jan 21, 2009 at 02:19:13PM +1100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.01.15.0827 +1100]:
> > This helps avoiding code duplication for the next commit.
>
> What's the "next commit"?
oh, sorry. I intended to post my patch that implements `tg export
--linearize`, but then found a bug and so didn't send it.
You can find it in my pu branch at
git://git.pengutronix.de/git/ukl/topgit.git pu
. It's not yet ready for general use, but I look forward to any
constructive feedback.
Best regards and thanks for the reminder,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Junio C Hamano @ 2009-01-21 10:26 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901201921.10223.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Junio C Hamano, 17.01.2009:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> >>
>> >> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
>> >
>> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
>> >
>> >> I've just accidently read in the completion file itself, that
>> >> Shawn is the maintainer, so I give it a third try. The first two
>> >> haven't been sent to him.
>> >
>> > Sorry, I must have missed the other two attempts. :-)
>>
>> And I seem to have missed all three.
>
> I really don't like to bother you again, but compared to the inclusion
> of the other patches, I guess you have forgotten the third try of this
> patch.
>
> Thus this fourth try :)
I did not mean that I forgot by the above "I seem to have missed".
Literally none of your three attempts seem to have reached me. I can
guess what you wrote from the _included_ text in Shawn's response, but
that is not a good/right place for me to pick up a patch from, is it?
^ permalink raw reply
* Re: [PATCH] Fix naming scheme for configure cache variables.
From: Junio C Hamano @ 2009-01-21 10:26 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20090119203436.GB3539@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> In order to be cached, configure variables need to contain the
> string '_cv_', and they should begin with a package-specific
> prefix in order to avoid interfering with third-party macros.
> Rename ld_dashr, ld_wl_rpath, ld_rpath to git_cv_ld_dashr etc.
>
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Thanks.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Markus Heidelberg, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901202202370.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Subject: Rename diff.suppress-blank-empty to diff.suppressBlankEmpty
>
> All the other config variables use CamelCase. This config variable should
> not be an exception.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Thanks.
^ permalink raw reply
* Re: [PATCH] color-words: Support diff.wordregex config option
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: Johannes Schindelin, Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <200901202146.58651.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> When diff is invoked with --color-words (w/o =regex), use the regular
> expression the user has configured as diff.wordregex.
>
> diff drivers configured via attributes take precedence over the
> diff.wordregex-words setting. If the user wants to change them, they have
> their own configuration variables.
>
> Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
> ---
> This version is squashed into one patch and includes documentation and
> rewritten tests. It was generated against js/diff-color-words~2,
> 80c49c3d (color-words: make regex configurable via attributes), replacing
> my previous 2 patches. It uses "diff.wordregex" for reasons mention by
> Dscho and because that was already what the diff drivers were using.
Nicely done and very well described. I fixed the Subject: line, though ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Junio C Hamano @ 2009-01-21 10:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Linus Torvalds, git
In-Reply-To: <20090120155957.GA23237@atjola.homenet>
Thanks.
^ permalink raw reply
* Re: [PATCH] [TOPGIT] make tg remote idempotent
From: Uwe Kleine-König @ 2009-01-21 11:06 UTC (permalink / raw)
To: git; +Cc: martin f. krafft, Petr Baudis
In-Reply-To: <1231968443-13960-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
On Wed, Jan 14, 2009 at 10:27:22PM +0100, Uwe Kleine-König wrote:
> -git config --add "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*"
> -git config --add "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*"
> -git config --add "remote.$name.push" "+refs/heads/*:refs/heads/*"
> +git config --replace-all "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*" "+refs/top-bases/*:refs/remotes/$name/top-bases/*"
> +git config --replace-all "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*" "+refs/top-bases/*:refs/top-bases/*"
> +git config --replace-all "remote.$name.push" "+refs/heads/*:refs/heads/*" "+refs/heads/*:refs/heads/*"
It seems I sent an old version of this patch. Actually in the last
argument '+' and '*' have to be quoted to work.
I fixed this in my repo. Should I resend the fixed patch?
Best regards
Uwe
^ permalink raw reply
* Re: Few Questions
From: R. Tyler Ballance @ 2009-01-21 11:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, m.arya, git
In-Reply-To: <20090120160410.GI14053@spearce.org>
On Tue, 2009-01-20 at 08:04 -0800, Shawn O. Pearce wrote:
> <plug type="not-quite-ready-but-will-be-soon">
>
> Gerrit2 is also likely to enter this "market" soon. I'm trying to
> get it production ready and live for one major project before the
> end of this month. It embeds its own SSH daemon on a non-standard
> port, completely disconnected from the OS authentication. This may
> make it slightly more palatable in some enviroments then Gitosis,
> as you don't need a huge authorized_keys file, and you don't have
> to worry quite so much about attack vectors.
> </plug>
>
<plug type="not-really-existent-yet-but-gee-golly-i-wish-it-were"
variant="mildly-offtopic" unnecessary:attribute="is-unnecessary">
I talked with Chris Wanstrath (defunkt) of Git Hub once upon a time
about them open sourcing their additions onto the openSSH sshd(8) to
work public key lookup into a MySQL database instead of simply reading a
flat file.
It'd be nice to add some peer pressure to get them to release it
already ;)
</plug>
I read your thread(s) on groups.google.com regarding Gerrit2 and it
seems quite promising as well. Looking forward to it being ready ;)
Cheers
--
-R. Tyler Ballance
Slide, Inc.
^ permalink raw reply
* Re: feature request mergetool, skip, abort
From: Charles Bailey @ 2009-01-21 11:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901200839q361923f1xb25ddadfdac37981@mail.gmail.com>
On Tue, Jan 20, 2009 at 11:39:59AM -0500, Caleb Cushing wrote:
> firstly my patch sucks, and I know it. but hopefully it'll give some
> idea of what I'm trying to do and someone can implement it properly.
>
> basically there are some files, that I can't merge with git, but I
> need to merge other files before I can fix those and I like to use
> mergetool, so I want a way to skip the files I'm not going to be able
> to merge.
>
For some reason I couldn't see a patch, but I like the idea of this
from the description and I was at very early stage of working on
something similar myself but it stalled due to other commitments.
For the moment the only way to 'skip' files is by passing full paths
of what you *don't* want to skip to mergetool which isn't really the
same thing at all.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Johannes Schindelin @ 2009-01-21 11:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vwscpgi7t.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > sha1_name.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/sha1_name.c b/sha1_name.c
> > index 4d10705..803f9d2 100644
> > --- a/sha1_name.c
> > +++ b/sha1_name.c
> > @@ -735,7 +735,7 @@ static int grab_nth_branch_switch(unsigned char *osha1, unsigned char *nsha1,
> > if ((target = strstr(match, " to ")) != NULL) {
> > len = target - match;
> > target += 4;
> > - if (target[len] == '\n' && !strncmp(match, target, len))
> > + if (len == strlen(target) && !strncmp(match, target, len))
> > return 0;
> > }
> > else
>
> Actually, I think this patch to a884d0c (sha1_name: tweak @{-N} lookup,
> 2009-01-17) would make more sense.
>
> -- >8 --
> Subject: [PATCH] Simplify parsing branch switching events in reflog
>
> We only accept "checkout: moving from A to B" newer style reflog entries,
> in order to pick up A. There is no point computing where B begins at
> after running strstr to locate " to ", nor adding 4 and then subtracting 4
> from the same pointer.
Yeah, you're right.
Ciao,
Dscho
^ permalink raw reply
* Re: how to keeping track of cherry-pick?
From: Johannes Schindelin @ 2009-01-21 12:04 UTC (permalink / raw)
To: Knut Olav Bøhmer; +Cc: git, Junio C Hamano
In-Reply-To: <4976E059.6000404@telenor.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2356 bytes --]
Hi,
On Wed, 21 Jan 2009, Knut Olav Bøhmer wrote:
> Junio C Hamano wrote:
> > Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
> >
> >> svnmerge.py can give us a list of revisions available for merging. The
> >> result is similar to "git log --chery-pick master..dev" The difference
> >> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
> >> at the diffs. The result of that is that when we get a conflict when a
> >> patch is cherry-picked, it will still show up as "available" when I run
> >> "git log --cherry-pick master..dev"
> >
> > I think you are looking at it a wrong way.
> >
> > Because subversion (at least the older one) does not keep track of merges,
> > you had to track cherry-picks. But cherry-pick is not how you usually do
> > things in git. You keep many topic branches with different doneness, and
> > you merge well-cooked ones to the more stable integration branch while
> > leaving others still cooking. So what you want to know is not cherry-pick
> > status, but merge status.
>
>
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.
You could accomodate your workflow by having the newly introduced commit
notes provide a mapping of which commits reflect which patch, in a way
introducing equality classes of patches (thereby having the original SHA-1
of the commit as kind of a "patch id").
But believe me, you would regret it.
If you are working on different topics, and want to apply only some of
them, you really want to have different topic branches (it is even
relatively easy to create them using "git checkout -b <new-topic>
<miscellaneous-branch> && git rebase -i master" and then deleting the
commits not referring to a certain subject).
The problem with having a single branch is that patches which are
independent, can touch the same parts of the code, and are hard to manage
independently. If you had them in topic branches, merging them
individually, you could at least use the rerere mechanism to resolve merge
conflicts for such overlapping topics.
I speak of experience: my current workflow is exactly what you described,
and I feel the pain. That's why I said you would regret it, because I
sure do.
Ciao,
Dscho
^ permalink raw reply
* Re: [VALGRIND PATCH for nth_last patch series] Fix invalid memory access
From: Johannes Schindelin @ 2009-01-21 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Johannes Sixt, Johan Herland
In-Reply-To: <7vr62xezm8.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Having said all that, I think Dscho's one had an off-by-one (but it is
> getting late and it may be I who has one).
Yep, I missed the "\n" at the end.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2 v2] Add valgrind support in test scripts
From: Johannes Schindelin @ 2009-01-21 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vskndgi3c.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 21 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This patch adds the ability to use valgrind's memcheck tool to
> > diagnose memory problems in git while running the test scripts....
>
> Hmmm, why do I haf to suffer with these new warnings from the tests?
>
> $ sh t2012-checkout-last.sh --valgrind -v -i
> warning: templates not found /git/git.git/t/valgrind/bin/templates/blt/
> Initialized empty Git repository in /git/git.git/t/trash directory.t2012-checkout-last/.git/
> mv: cannot stat `.git/hooks': No such file or directory
> * expecting success:
> echo hello >world &&
>
> Am I using the patch incorrectly somehow?
Nope, I overlooked that GIT_EXEC_PATH was used by test-lib also to
determine the location of the templates. Will squash this in (which
makes a function out of the symlink business, and also fixes the error
that git-gui/ was tested if it is a script; "head" complained that it is
not a file):
-- snipsnap --
t/test-lib.sh | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f031905..6acc6e0 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -487,6 +487,14 @@ then
PATH=$TEST_DIRECTORY/..:$PATH
GIT_EXEC_PATH=$TEST_DIRECTORY/..
else
+ make_symlink () {
+ test -h "$2" &&
+ test "$1" = "$(readlink "$2")" || {
+ rm -f "$2" &&
+ ln -s "$1" "$2"
+ }
+ }
+
# override all git executables in PATH and TEST_DIRECTORY/..
GIT_VALGRIND=$TEST_DIRECTORY/valgrind/bin
mkdir -p "$GIT_VALGRIND"
@@ -498,12 +506,13 @@ else
while read file
do
# handle only executables
- test -x "$file" && test ! -d "$file" || continue
+ test -x "$file" || continue
base=$(basename "$file")
symlink_target=$TEST_DIRECTORY/../$base
# do not override scripts
if test -x "$symlink_target" &&
+ test ! -d "$symlink_target" &&
test "#!" != "$(head -c 2 < "$symlink_target")"
then
symlink_target=../valgrind.sh
@@ -513,19 +522,16 @@ else
symlink_target=../unprocessed-script
esac
# create the link, or replace it if it is out of date
- if test ! -h "$GIT_VALGRIND"/"$base" ||
- test "$symlink_target" != \
- "$(readlink "$GIT_VALGRIND"/"$base")"
- then
- rm -f "$GIT_VALGRIND"/"$base" || exit
- ln -s "$symlink_target" "$GIT_VALGRIND"/"$base"
- fi
+ make_symlink "$symlink_target" "$GIT_VALGRIND/$base" ||
+ exit
done
done
IFS=$OLDIFS
PATH=$GIT_VALGRIND:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND
export GIT_VALGRIND
+
+ make_symlink ../../../templates "$GIT_VALGRIND"/templates || exit
fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
--
1.6.1.442.g38a50
^ permalink raw reply related
* Re: how to git a read only directory
From: Boaz Harrosh @ 2009-01-21 12:34 UTC (permalink / raw)
To: git
In-Reply-To: <20090121083354.GG6970@b2j>
bill lam wrote:
> I want to use git to keep track of files inside /etc but do not want
> to do it as a super user. Is that possible to put GIT_DIR under my
> home directory and add public-read files inside /etc? Or that it could
> be done in some other ways.
>
> Thanks.
>
I did the really easy hack (on my /etc BTW) and it worked fine for me.
I created a master project folder under ~home, init a new git repo,
then symlink /etc/ onto an etc/ in the project dir, added all etc/
files. I like the extra a/etc/fstab in the patch files better then
a/fstab.
And it is a life saver, payed it's effortless in gold. Some shining
new distro should come up with a git based management system
and it will leave all the other distros in the dust.
Cheers
Boaz
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Björn Steinbrink @ 2009-01-21 12:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120212723.GA10967@coredump.intra.peff.net>
On 2009.01.20 16:27:23 -0500, Jeff King wrote:
> So I think your patch is absolutely the right thing to do. But I think
> from the commit message it isn't clear that it would not be equally
> correct to follow through on generating cnt_data instead of an early
> return (which _isn't_ right, because you might not need to generate
> cnt_data at all).
Yeah, the commit message wasn't exactly great, but after the fifth
attempt I decided to just sent the damn thing, to see whether at least
the patch itself makes sense.
Another possible solution would be to free the blob data only after the
loop in diffcore_rename has finished, but that's obviously quite bad WRT
memory consumption. :-)
Anyway, too late, yesterday's attempts 6 to 10 at writing a better
commit message didn't work out either, and Junio has applied the patch
by now.
Björn
^ permalink raw reply
* Deleting remote branch pointed by remote HEAD
From: Marc-André Lureau @ 2009-01-21 13:02 UTC (permalink / raw)
To: git
Hi
I deleted a remote branch which was pointed by HEAD, this way: "git
push origin :master"
Then for almost every git command, I get this error: "error:
refs/remotes/origin/HEAD points nowhere!".
I found this situation non-friendly. Fortunately, I could understand
what's going on. But a new user might be confused.
Shouldn't the remote HEAD branch be updated or "protected" in some
ways? Or should the "error" be considered as a "warning" (silently?)
What do you think?
regards,
--
Marc-André Lureau
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-21 13:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090121125619.GA523@atjola.homenet>
On Wed, Jan 21, 2009 at 01:56:19PM +0100, Björn Steinbrink wrote:
> Another possible solution would be to free the blob data only after the
> loop in diffcore_rename has finished, but that's obviously quite bad WRT
> memory consumption. :-)
Yeah, and it doesn't have the (admittedly smaller, but still there)
optimization of not loading the blob data at all if we will never need
to.
> Anyway, too late, yesterday's attempts 6 to 10 at writing a better
> commit message didn't work out either, and Junio has applied the patch
> by now.
I think that's fine. My message was more about convincing myself that
your change was the right thing (and hopefully helped convince others,
too).
-Peff
^ permalink raw reply
* Re: feature request mergetool, skip, abort
From: Caleb Cushing @ 2009-01-21 14:26 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090121112236.GC18488@hashpling.org>
patch was an attachement.
after looking through the list and seeing the conventions I've a fully
working one now, so I'm going to start a new thread with it.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ 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