* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Junio C Hamano @ 2008-08-01 7:23 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <1217510434-94979-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
> ---
>
> Or was there a specific reason not to allow this?
I'll let Dscho answer that one.
> diff --git a/builtin-name-rev.c b/builtin-name-rev.c
> index 85612c4..0536af4 100644
> --- a/builtin-name-rev.c
> +++ b/builtin-name-rev.c
> @@ -266,8 +266,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
> if (!name)
> continue;
>
> - fwrite(p_start, p - p_start + 1, 1, stdout);
> - printf(" (%s)", name);
> + if (data.name_only) {
> + fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
> + printf(name);
> + }
> + else {
> + fwrite(p_start, p - p_start + 1, 1, stdout);
> + printf(" (%s)", name);
> + }
> p_start = p + 1;
> }
> }
Is it just me to find that this part is getting indented too deeply to be
readable?
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 7:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stephan Beyer, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <7vvdylv9zq.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Junio C Hamano wrote:
> Abdelrazak Younes<younes@lyx.org> writes:
>
>
>> I just had a look at the user manual and, well unless you have a
>> special emacs mode or whatever that can automate the markup tag
>> insertion, I wonder how can anybody think that writing with this
>> markup language is easier than within LyX, really (genuine question,
>> not sarcasm).
>>
>
> How greppable and "log -p"-able is the documentation written in LyX?
>
LyX format is plain text, loosely based on LateX. Here's attached a
sample .lyx file FYI. We have one tag per line and a maximum of 80 char
per line so that the format is easily parsable. Advanced users often use
unix tools (grep, sed, etc) to modify the .lyx file manually.
> * Where in the documentation do I have to change the description of
> "--parents" option?
>
You mean in a text editor, not within LyX? Just look for the string :-)
> * When did the description of "--cc" for diff families last changed, by
> whom and why?
>
Ditto.
> Eas of doing these is mostly why we chose AsciiDoc to begin with. Any
> alternative you are going to suggest should not make these two things
> impossible or very harder to do.
>
If you ignore the LyX tags, you can just do what you are used to do
without problem using a plain text editor. If you want to do something
more complicated stuff like choosing a different environment or creating
a nested enumerate list, it is easier to do that within LyX.
Abdel.
[-- Attachment #2: FAQ.lyx --]
[-- Type: application/lyx, Size: 35350 bytes --]
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-01 7:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160807311203o3fb4deb8u4a5ae57818c76fab@mail.gmail.com>
On Thu, 31 Jul 2008 21:03:26 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Thu, Jul 31, 2008 at 20:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com> wrote:
> >
> >> I see all OK. Can you provide a self consistent simple testcase that
> >> shows what is wrong?
> >
> > Yes. was rather easy.
> > http://www.xs4all.nl/~hmbrand/testcase.tgz
>
> It is because you cannot merge a branch with an empty branch. So, or
> you create an initial commit in the "superproject" or you create a
> commit just moving the files of the first module as in:
>
> http://article.gmane.org/gmane.comp.version-control.git/79887
Almost perfect now.
4gl/new 121 > git-ls-files | grep fnc_declare
include/fnc_declare.h
4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
Author: H.M. Brand <merijn@a5.(none)>
Date: Tue Jul 29 16:45:43 2008 +0200
Backward comp functie voor PV indicatie
diff --git a/fnc_declare.h b/fnc_declare.h
index acd686c..25d9a73 100644
--- a/fnc_declare.h
+++ b/fnc_declare.h
@@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
eaf_N pv_datum ($x1, $x2, $x3);
#endif
+#ifndef PV_INDICATIE
+#define PV_INDICATIE
+eaf_S pv_indicatie ($x1);
+#endif
+
#undef eaf_B
#undef eaf_N
#undef eaf_S
4gl/new 123 >
all the diffs are still showing as if they were against the folder they
were originally committed in. Is that correct? I would now have expected
something like
commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
Author: H.M. Brand <merijn@a5.(none)>
Date: Tue Jul 29 16:45:43 2008 +0200
Backward comp functie voor PV indicatie
diff --git a/include/fnc_declare.h b/include/fnc_declare.h
index acd686c..25d9a73 100644
--- a/include/fnc_declare.h
+++ b/include/fnc_declare.h
@@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
eaf_N pv_datum ($x1, $x2, $x3);
#endif
+#ifndef PV_INDICATIE
+#define PV_INDICATIE
+eaf_S pv_indicatie ($x1);
+#endif
+
#undef eaf_B
#undef eaf_N
#undef eaf_S
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply related
* Re: [ANN] git cola: a highly caffeinated git gui
From: David Aguilar @ 2008-08-01 6:52 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Git Mailing List, msysgit
In-Reply-To: <20080801083413.2ac1782b@pc09.procura.nl>
On Thu, Jul 31, 2008 at 11:34 PM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Thu, 31 Jul 2008 23:08:01 -0700, "David Aguilar" <davvid@gmail.com>
> wrote:
>
>> Greetings!
>>
>> The latest version of git cola is available for download from the
>> usual interwebs:
>>
>> http://cola.tuxfamily.org/
>> http://gitorious.org/projects/git-cola/
>
> Your dependencies don't match.
>
> # cola-1.1.1-2.noarch.rpm
sorry, I used alien to convert my .debs into an rpm. scripts/mkdeb.sh.
yum installing pyqt4 should fix it.
> ImportError: No module named PyQt4.QtCore
>
> --
> H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
> using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
> 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
> http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
> http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
>
--
David
^ permalink raw reply
* Re: [ANN] git cola: a highly caffeinated git gui
From: H.Merijn Brand @ 2008-08-01 6:34 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List, msysgit
In-Reply-To: <402731c90807312308l4870382dsb707fafd37f9b1d4@mail.gmail.com>
On Thu, 31 Jul 2008 23:08:01 -0700, "David Aguilar" <davvid@gmail.com>
wrote:
> Greetings!
>
> The latest version of git cola is available for download from the
> usual interwebs:
>
> http://cola.tuxfamily.org/
> http://gitorious.org/projects/git-cola/
Your dependencies don't match.
# cola-1.1.1-2.noarch.rpm
$ cola
Traceback (most recent call last):
File "/usr/bin/cola", line 112, in <module>
main()
File "/usr/bin/cola", line 53, in main
from cola.models import Model
File "../../cola/models.py", line 9, in <module>
File "../../cola/utils.py", line 9, in <module>
File "../../cola/defaults.py", line 4, in <module>
ImportError: No module named PyQt4.QtCore
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* [ANN] git cola: a highly caffeinated git gui
From: David Aguilar @ 2008-08-01 6:08 UTC (permalink / raw)
To: Git Mailing List, msysgit
Greetings!
The latest version of git cola is available for download from the
usual interwebs:
http://cola.tuxfamily.org/
http://gitorious.org/projects/git-cola/
git cola is a highly functional git gui licensed under the gpl.
It's written in Python/Qt4. In addition to its native platform
(Linux/Unix), cola also runs on OSX and Windows.
Although tarballs, .rpms and .deb packages are available, building it
from source is very easy.
On debian it's as simple as:
sudo apt-get install simplejson python-qt4 pyqt4-dev-tools python-pyinotify
git clone git://gitorious.org/git-cola/mainline.git cola
cd cola && ./configure && make && make install
Like git gui, it allows you to do very fine-grained commits. It has a
bunch of other random useful stuff, so I figured it was about time to
announce it here. It has inotify support on Linux, which is why
there's no rescan button in cola.
Hopefully the code isn't too rotten ;-)
CAVEATS:
i18n/l10n is incomplete. I used the latest .po files from git-gui,
but obviously there are a number of strings in git cola that don't
have translations. If there is an interest in cola from the user
community then I will need some advice on how to handle this
situation. I don't like having stolen the .po's from git-gui (sorry
Shawn!) but it did prove that the infrastucture for "LANG=ja git cola"
is working correctly.
cola works by parsing git commands. It's pretty fast despite the
process overhead, though it'll probably be a bit slower on windows. I
have no idea what cr/lf issues exist (if any), though I've tried to be
careful about it.
enjoy,
p.s. if you happen to prefer dark color themes you can run: git cola
--style=dark
--
David
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Junio C Hamano @ 2008-08-01 5:09 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Dmitry Potapov, git, Eric Wong
In-Reply-To: <200808011023.32139.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> writes:
> I dont think that disabling convertion is a good way. I really want to convert
> my files. Possible solution is to pass two file names to git-hash-object: the
> real file with content and the proposed file name in the working directory.
> In this case git-hash-object will be able to make correct convertion.
I think the optional parameter to say "pretend the content is from this
path" makes sense even for (and especially for) hashing --stdin.
^ permalink raw reply
* Re: git help broken
From: Christian Couder @ 2008-08-01 4:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Kevin Ballard, Git Mailing List
In-Reply-To: <20080731000454.GJ32057@genesis.frugalware.org>
Le jeudi 31 juillet 2008, Miklos Vajna a écrit :
> On Thu, Jul 31, 2008 at 01:44:36AM +0200, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> > > And from the patch, it is pretty obvious that it does not come close
> > > to the "man" code path.
> >
> > Oh, so it was involved?
>
> Yes. The command list is no longer loaded automatically and the default
> for non-git commands on git help foo was 'gitfoo', I guess for
> gittutorial and such manpages.
Yeah, and it seems that "git help help" doesn't work any more since my patch
that does that:
2dce956e397be8a769624e8693565b8a30056060 help: check early if we have a
command, if not try a documentation topic
I didn't realize that the function "is_git_command" would not work
for "help".
Perhaps there should be another function like is_git_command that could work
using the "struct cmd_struct commands" defined in "handle_internal_command"
in "git.c". That may be faster and more accurate.
Unfortunately I won't have time to work on this as I will leave for vacation
in a few hours. Sorry to leave this behind.
Best regards,
Christian.
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-08-01 3:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311956040.3277@nehalem.linux-foundation.org>
On Thu, 31 Jul 2008, Linus Torvalds wrote:
>
> Well, the difference really is the beefy box.
Btw, the fact that I have a beefy box really wasn't the point. The fact
that I can build the kernel three times quicker than I can build the git
documentation _was_ kind of the point. A lot of projects have horrible
build rules - makefiles that don't parallelize well or just tools that
suck dead baby donkeys through a straw.
I often get the feeling that I can compile the kernel faster than I can
run "./configure" on most of the other projects I ever compile.
So I'd heartily encourage projects to try to make their build lean and
mean. It actually then allows you to be more efficient, and gives the
option of using more efficient development models, where "use multiple
branches in the same tree" is just one example of that.
Of course, I have to admit that git itself isn't exactly a stellar
example. I can compile git itself in basically zero time, but those docs
really take a loooong time.
Just one more reason for me to stay away from documentation.
Linus
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-08-01 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vabfxv3px.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> It was even worse than that.
>
> The output from v3 is incorrect
Ok. I'm really not surprised. Incrementally is really hard. I'm reminded
of all the problems we had with just the "trivial" issue of just knowing
when to consider something uninteresting or not, that ended up depending
on commit timestamps etc, and had problems with people having their clocks
set incorrectly.
Doing the ops once you have the full DAG is usually _trivial_ by
comparison.
Linus
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 3:23 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Eric Wong
In-Reply-To: <20080731104529.GE7008@dpotapov.dyndns.org>
> It does not look to be true. I did the following test:
...
> which means that the autocrlf conversion is done for temporary
> files created by perl. (I tested it on Linux and Windows/Cygwin).
>
> In any case, I believe the right solution should be adding a
> new option to git-hash-object to disable any conversion.
My bad, I did not append full thoughts. git-hash-object DOES autocrlf
convertion but it cant do it correctly. All it can do - is to autodetect
text files. My setup has .git/info/attributes file where all files but .cpp
and .h are binary. While .cpp and .h are text files. In this case
git-hash-object do not know the real file name as far as git-svn use
temporary files.
I dont think that disabling convertion is a good way. I really want to convert
my files. Possible solution is to pass two file names to git-hash-object: the
real file with content and the proposed file name in the working directory.
In this case git-hash-object will be able to make correct convertion.
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-08-01 3:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <20080801025024.GA18529@anvil.corenet.prv>
On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > For example, for the kernel, I can literally rebuild my whole kernel
> > (which is just what I use on _that_ machine) in about 16 seconds. This is
> > _not_ using ccache or anything else - it's rebuilding the whole tree with
> > -j16.
>
> Is it after make mrproper (wow)?
Yeah. It's after doing
git clean -dqfx
make oldconfig
where I tend to use "git clean -dqfx" instead of "make mrproper" these
days.
Note that my "oldconfig" really only does the things I need, so this is
_not_ a "allmodconfig" or anything like that. That would take much longer.
It only has the drivers I use, and the stuff I actually need (it's not a
embedded kernel in any way, but it's definitely pared down config exactly
because I like being able to rebuild my kernels without wasting time on
thousands of drivers that I can't use anyway).
Other people can do the "does it compile?" testing. Not worth my time, I
feel ;)
> Because for me (and well, I dont have that beefy boxes as you do)
> swithing between "for-linus" and "next" that based off a revision in
> vicinity of 2.6.xx-rc1 and "work" which tracks the tip of your tree
> takes time to rebuild.
Well, the difference really is the beefy box. And the fact that I hate
modules, and I hate building stuff that I don't actually need.
I literally turn off CONFIG_MODULES entirely.
Linus
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-08-01 3:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807311513020.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Junio C Hamano wrote:
>>
>> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
>> it is much more expensive than the non-incremental one (v2), and about
>> three times more expensive than non-limiting --full-history for explaining
>> the history of kernel/printk.c.
>
> Hmm? Why is that, exactly? Does it walk over the same commit over and over
> and over again or something?
It was even worse than that.
The output from v3 is incorrect, as the place the new call is hooked into
knows only that the commit in question is not UNINTERESTING, but hasn't
inspected its parents, but the simplification logic needs to dig into the
parent chain deep enough, which it does not do correctly using the proper
simplification logic (i.e. add_parents_to_list()).
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Dmitry Torokhov @ 2008-08-01 2:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org>
On Thu, Jul 31, 2008 at 02:40:55PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 31 Jul 2008, Linus Torvalds wrote:
> >
> > Sure, if you want to keep the build tree around, you would probably not
> > use branches.
>
> Side note: it's often faster to recompile, if your project has a good
> build system.
>
> For example, for the kernel, I can literally rebuild my whole kernel
> (which is just what I use on _that_ machine) in about 16 seconds. This is
> _not_ using ccache or anything else - it's rebuilding the whole tree with
> -j16.
>
Is it after make mrproper (wow)? Or is it when your branches are
"recent"? Because for me (and well, I dont have that beefy boxes as you
do) swithing between "for-linus" and "next" that based off a revision in
vicinity of 2.6.xx-rc1 and "work" which tracks the tip of your tree
takes time to rebuild.
--
Dmitry
^ permalink raw reply
* email address handling
From: Andrew Morton @ 2008-08-01 2:40 UTC (permalink / raw)
To: git
A minor thing.
Commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 is displayed thusly:
commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2
Author: Zhang, Rui <rui.zhang@intel.com>
Date: Thu Apr 10 16:20:23 2008 +0800
ACPI: update thermal temperature
but that isn't a valid email address. Because it contains a comma it
must be quoted: "Zhang, Rui".
I assume that something in the git toolchain removed his quotes, and
that was arguably incorrect.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-08-01 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sverre, Dmitry Potapov, git
In-Reply-To: <alpine.LFD.1.10.0807311840240.3277@nehalem.linux-foundation.org>
> So it's very true that git in general is geared towards scripting (and
> we've often added things to make it even more so), but no, your particular
> complaint isn't true. gitk doesn't do anything really strange.
Yeah, I guess that's why I like using git so much; a few piped
commands and a script or two, and you can do some pretty rad stuff.
^ permalink raw reply
* stgit and rm a file
From: Jon Smirl @ 2008-08-01 2:02 UTC (permalink / raw)
To: Git Mailing List
Make a new patch, git rm a file, refresh. It won't pick up the rm. Do
something else besides just a rm and it will pick up the rm. Is it
already fixed in the much anticipated refresh rewrite?
jonsmirl@terra:~/fs$ stg --version
Stacked GIT 0.14.3.173.g2e37
git version 1.6.0.rc0
Python version 2.5.2 (r252:60911, Apr 21 2008, 11:17:30)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
jonsmirl@terra:~/fs$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Linus Torvalds @ 2008-08-01 1:54 UTC (permalink / raw)
To: cte; +Cc: sverre, Dmitry Potapov, git
In-Reply-To: <ac9f0f090807311817n551f53a5mb1270e6f4b2a058e@mail.gmail.com>
On Thu, 31 Jul 2008, cte wrote:
>
> Instead, git-log had to be altered to address gitk's needs, and an
> option was added that users don't typically use.
Actually, no.
I ended up doing a hack to add "git log --early-output", and some quick
hacks to make git use it. But I'm happy to say that gitk doesn't use it
any more. Gitk just parses the normal git log output, although obviously
it ends up needing enough data to be able to fill in the gaps (ie it uses
the "--parents" flag to get the rewritten parenthood info and the merges
to keep it together).
So yeah, we have some options that enable output that simply doesn't make
_sense_ to humans, but does when you are post-processing it (git has
always had those, since it very much was about scripting from day one),
but no, at least gitk doesn't use any really odd ones.
It literally does
git log --no-color -z --pretty=raw --parents --boundary
(plus the args the user gave it). The --no-color turns off color if it's
enabled by default.
The -z makes it the git log output a bit easier to parse by using a NUL
character between commits.
The --pretty=raw is just to give the full/raw commit info - like giving
the timestamps in the native raw format that is much easier to parse than
any human-readable format.
The --parents I already mentioned - it is what makes you able to stitch
the commits together (and it's useful for other things too: any scripts
that look for merges will tend to use it, for example)
And the --boundary is to show the commits that aren't part of the actual
selected set in gray.
It's all pretty generic, in other words. The -z option is purely for
machine parsing, the others _can_ actually be useful even for humans (eg,
--boundary together with --left-right and --pretty=oneline actually is
very readable if you are used to that format).
So it's very true that git in general is geared towards scripting (and
we've often added things to make it even more so), but no, your particular
complaint isn't true. gitk doesn't do anything really strange.
Linus
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-08-01 1:17 UTC (permalink / raw)
To: sverre; +Cc: Dmitry Potapov, git
In-Reply-To: <bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com>
> On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
>> Using output from the command line utilities as an API has its own set
>> of problems. For instance, check out some of the difficulties that
>> gitk and qgit have had to deal with:
>> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
>
> I beg to differ. If I skimmed the topic correctly, the problems there
> were not related to having to parse git's output, but due to the fact
> that '--topo-order' is a post-processing operation, which takes long.
> Do read the recent discussion between Linus and Roman about that.
Didn't mean to imply that somehow it is no longer a post-processing op if you
aren't using git plumbing. The discussion shows, however, that if gitk
was actually
doing the revision traversals, then it would be able to trigger events
that update the
gui whenever it wanted, which would have allowed it to implement the
early output
feature without changing any of the git source. Instead, git-log had
to be altered to
address gitk's needs, and an option was added that users don't
typically use. This is
not exactly what I would consider spartan programming
(http://www.codinghorror.com/blog/archives/001148.html),
plus there are already too many options to remember! Anyways, I
suppose it is pointless
to argue about which approach is better, because both have trade-offs,
and the correct
path depends on your use case.
>>> There is, use the plumbing, forward compatibility is 95% assured. With
>>> the exception of major releases, for which any plumbing
>>> output/behavior changes will be announced in the changelog, usually
>>> including an explanation on how to change your code to match.
>>
>> 95% assured != correct, IMO :)
>
> Why not? Junio has a very good reputation of keeping git backwards
> compatible. The 95% is of course not an actual figure but an
> expression meant to indicate "statement is true, minus a few rare case
> exceptions".
Definitely not questioning his ability to maintain backwards
compatibility; it was
merely an observation about your strange definition of correct. In school, when
I completed 95% of a proof, it was never marked as "correct", and I
was told that I hadn't actually proven anything. Those damn teachers :)
^ permalink raw reply
* What's cooking in git.git (Jul 2008, #11; Thu, 31)
From: Junio C Hamano @ 2008-08-01 1:03 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc2 (Aug 3)
- 1.6.0-rc3 (Aug 10)
----------------------------------------------------------------
[New Topics]
* rs/archive-parse-options (Fri Jul 25 12:41:26 2008 +0200) 1 commit
+ archive: allow --exec and --remote without equal sign
None of the following is for 1.6.0.
* mv/merge-custom (Thu Jul 31 00:38:07 2008 +0200) 5 commits
+ builtin-help: always load_command_list() in cmd_help()
+ Add a second testcase for handling invalid strategies in git-merge
+ Add a new test for using a custom merge strategy
+ builtin-merge: allow using a custom strategy
+ builtin-help: make some internal functions available to other
builtins
* cc/merge-base-many (Sun Jul 27 13:47:22 2008 -0700) 4 commits
- git-merge-octopus: use (merge-base A (merge B C D E...)) for
stepwise merge
+ merge-base-many: add trivial tests based on the documentation
+ documentation: merge-base: explain "git merge-base" with more than
2 args
+ merge-base: teach "git merge-base" to drive underlying
merge_bases_many()
* jc/simplify-merges (Thu Jul 31 01:17:41 2008 -0700) 1 commit
. revision traversal: show full history with merge simplification
"log --full-history" is with too much clutter, "log" itself is too cleverer
than some people, and here is the middle level of merge simplification.
----------------------------------------------------------------
[On Hold and/or Cooking]
None of the following is for 1.6.0.
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
+ Documentation: Improve documentation for git-imap-send(1)
+ imap-send.c: more style fixes
+ imap-send.c: style fixes
+ git-imap-send: Support SSL
+ git-imap-send: Allow the program to be run from subdirectories of
a git tree
Some people seem to prefer having this feature available also with gnutls.
Such an enhancement can be done in-tree on top of this series if they are
so inclined.
* cc/bisect (Fri Jul 25 05:36:37 2008 +0200) 2 commits
- bisect: only check merge bases when needed
- bisect: test merge base if good rev is not an ancestor of bad rev
* jc/add-addremove (Tue Jul 22 22:30:40 2008 -0700) 2 commits
+ builtin-add.c: optimize -A option and "git add ."
+ builtin-add.c: restructure the code for maintainability
* jk/pager-swap (Tue Jul 22 03:14:12 2008 -0400) 2 commits
+ spawn pager via run_command interface
+ run-command: add pre-exec callback
This changes the parent-child relationship between the pager and the git
process. We used to make pager the parent which meant that the exit
status from git is lost from the caller.
* ph/enable-threaded (Mon Jul 21 11:23:43 2008 +0200) 1 commit
+ Enable threaded delta search on *BSD and Linux.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
^ permalink raw reply
* What's in git.git (Jul 2008, #09; Thu, 31)
From: Junio C Hamano @ 2008-08-01 1:02 UTC (permalink / raw)
To: git
Some git-gui updates for 1.6.0 are included, and then many minor fixes.
Perhaps -rc2 this weekend.
* The 'master' branch has these since the last announcement.
Abhijit Menon-Sen (5):
git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
Clarify that "git log x.c y.h" lists commits that touch either file
`git submodule add` now requires a <path>
Make it clear that push can take multiple refspecs
Make the DESCRIPTION match <x>... items in the SYNOPSIS
Alex Riesen (1):
Make use of stat.ctime configurable
Alexander Gavrilov (7):
Fix pre-commit hooks under MinGW/MSYS
Add options to control the search for copies in blame.
Kill the blame back-end on window close.
Add a menu item to invoke full copy detection in blame.
git-gui: Fix the Remote menu separator.
git-gui: Preserve scroll position on reshow_diff.
Support copy and rename detection in fast-export.
Anders Melchiorsen (2):
Documentation: fix diff.external example
Advertise the ability to abort a commit
Björn Steinbrink (1):
rev-parse: Add support for the ^! and ^@ syntax
Brian Gernhardt (1):
Documentation: Remove mentions of git-svnimport.
Cesar Eduardo Barros (2):
Documentation/git-submodule.txt: fix doubled word
Documentation/git-rev-parse.txt: update for new git-describe output
format
Christian Couder (2):
merge-base: die with an error message if not passed a commit ref
documentation: user-manual: update "using-bisect" section
Jakub Narebski (1):
gitweb: More about how gitweb gets 'owner' of repository
Jeff King (2):
init: handle empty "template" parameter
Compact commit template message
Johannes Schindelin (1):
Avoid chdir() in list_commands_in_dir()
Johannes Sixt (2):
git-gui: Fix "Stage/Unstage Line" with one line of context.
git-gui: "Stage Line": Treat independent changes in adjacent lines better
Jonathan Nieder (1):
t6030 (bisect): work around Mac OS X "ls"
Junio C Hamano (11):
make sure parsed wildcard refspec ends with slash
GIT 1.6.0-rc1
Allow building without any git installed
Allow installing in the traditional way
ls-tree documentation: enhance notes on subdirectory and pathspec
behaviour
Documentation: clarify what is shown in "git-ls-files -s" output
t7001: fix "git mv" test
Teach gitlinks to ie_modified() and ce_modified_check_fs()
Fix merge name generation in "merge in C"
Fix test-parse-options "integer" test
Teach --find-copies-harder to "git blame"
Kevin Ballard (1):
format-patch: Produce better output with --inline or --attach
Lars Hjemli (3):
builtin-branch: remove duplicated code
builtin-branch: factor out merge_filter matching
builtin-branch: fix -v for --[no-]merged
Lee Marlow (1):
bash completion: Add completion for 'git help'
Olivier Marin (1):
builtin-verify-tag: fix -v option parsing
Petr Baudis (2):
git-mv: Remove dead code branch
git-mv: Keep moved index entries inact
Pierre Habouzit (1):
Allow "non-option" revision options in parse_option-enabled commands
Shawn O. Pearce (3):
git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
fsck: Don't require tmp_obj_ file names are 14 bytes in length
git-gui: Fix gitk search in $PATH to work on Windows
Steffen Prohaska (5):
Refactor, adding prepare_git_cmd(const char **argv)
run-command (Windows): Run dashless "git <cmd>"
git-gui: Correct installation of library to be $prefix/share
git-gui (Windows): Switch to relative discovery of oguilib
git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
Thomas Rast (1):
bash completion: Add long options for 'git describe'
Todd Zullinger (1):
Replace uses of "git-var" with "git var"
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-08-01 0:45 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: Stephan Beyer, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <4891CD34.1070308@lyx.org>
Abdelrazak Younes <younes@lyx.org> writes:
> I just had a look at the user manual and, well unless you have a
> special emacs mode or whatever that can automate the markup tag
> insertion, I wonder how can anybody think that writing with this
> markup language is easier than within LyX, really (genuine question,
> not sarcasm).
How greppable and "log -p"-able is the documentation written in LyX?
* Where in the documentation do I have to change the description of
"--parents" option?
* When did the description of "--cc" for diff families last changed, by
whom and why?
Eas of doing these is mostly why we chose AsciiDoc to begin with. Any
alternative you are going to suggest should not make these two things
impossible or very harder to do.
^ permalink raw reply
* [PATCH] git svn: should not display zombie externals
From: Eddy Petrișor @ 2008-07-31 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <48923DAF.7070900@gmail.com>
during the history of a repo a svn:external could be added and later
removed; such externals shouldn't be displayed since only the current
state is relevant
I have encountered the broken behaviour on a git-svn repo with the svn
origin a repo served via https (git 1:1.5.6-1~bpo40+1 from Debian Etch
backports.) I hope this bug doesn't have to do with the svn repo being
served via https.
Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
---
t/t9101-git-svn-props.sh | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index f420796..e5ab748 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -211,7 +211,28 @@ EOF
test_expect_success 'test proplist' "
git-svn proplist . | cmp - prop.expect &&
- git-svn proplist nested/directory/.keep | cmp - prop2.expect
+ git-svn proplist nested/directory/.keep | cmp - prop2.expect &&
+ cd ..
+ "
+
+test_expect_success 'show external' "
+ cd test_wc &&
+ svn propset svn:externals 'zombie file:///fake/external' . &&
+ svn ci -m 'added a fake svn:external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q 'zombie'
+ "
+
+test_expect_success 'remove external' "
+ cd test_wc &&
+ svn propdel svn:externals . &&
+ svn ci -m 'deleted the fake external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q -v 'zombie'
"
test_done
--
1.5.6.3
This one is properly formated (the previous one was a copy/paste from the output of the console).
^ permalink raw reply related
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807311513020.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Junio C Hamano wrote:
>>
>> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
>> it is much more expensive than the non-incremental one (v2), and about
>> three times more expensive than non-limiting --full-history for explaining
>> the history of kernel/printk.c.
>
> Hmm? Why is that, exactly? Does it walk over the same commit over and over
> and over again or something?
>
> Can you combine --simplify-merges and --topo-order to get a fast version
> again (since --topo-order will force a non-incrmental walk)?
Heh, nice try to make my head explode ;-) Not today, no, really, no...
^ permalink raw reply
* Re: [PATCH v2] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-07-31 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vd4kuzcst.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> If you look at the output from the "kernel/printk.c" with this patch, you
> would notice that there still are somewhat meaningless merges shown in the
> history (e.g. scroll down to 185a257f2f73bcd89050ad02da5bedbc28fc43fa).
They're not really meaningless.
Yes, they are pointless for the end result, but once you start showing
that whole pointless branch they very much are needed for a complete view
of the "shape" of history. The merges are real points on that branch where
printk changed because it got updates from mainlines.
So either you should have the full simplification (which only shows stuff
that is really meaningful for the end result), or you need for those
"pointless" merges to remain (because you show the changes that happened
on side branches).
I obviously believe that the full simplification is what you most often
want, but the --post-simplify thing does make sense.
(And yes, I agree that the name should be something else, and that
--simplify-merges makes more sense. The "post-simplify" thing is an
implementation issue, and doesn't describe what the effect is. And with
your incremental one, even that isn't true).
Linus
^ 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