* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-11-03 9:48 UTC (permalink / raw)
To: git
In-Reply-To: <1225691960.20883.41.camel@maia.lan>
Sam Vilain wrote:
> On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>>> + * 'git push --matching' does what 'git push' does today (without
>>>> + explicit configuration)
>>>
>>> I think this is reasonable even without other changes, just to override
>>> any configuration.
>>
>> I don't. Can't you say "git push $there HEAD" these days? I vaguely
>> recall that there is a way to configure push that way for people too lazy
>> to type "origin HEAD" after "git push".
>
> I don't think it's about laziness, it's more about making sure that
> without specifying behaviour, the action of the command is conservative.
> Pushing all matching refs is not conservative; it's "magic". And in my
> experience, people get bitten by it, because they think, "ok, time to
> push this branch", type "git push" and then a lot more than they
> expected gets pushed.
>
> I can see that some people want this behaviour by default; but to me
> "push the current branch back to where it came from" seems like far more
> a rational default for at least 90% of users.
"git remote <remote> push" for push matching?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-03 9:49 UTC (permalink / raw)
To: Andy Parkins, git
In-Reply-To: <490E36C0.5040701@pcharlan.com>
Pete Harlan wrote:
> Sorry for the repeat emails....this first-time "git send-email" user was
> a little surprised that it appears to always cc git@vger...
No, Pete, it only cc'd the "Signed-of-by:" address, which you filtered
to your git-list mailbox.
Sorry for this noise. I'll get the hang of things sooner or later.
If you think the patch, or the idea, could be worth applying in some
form, I'd appreciate any feedback.
Thanks,
--Pete
>
> <hides behind rock>
>
> --Pete
>
> Pete Harlan wrote:
>> Add configuration option hooks.showrev, letting the user override how
>> revisions will be shown in the commit email.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sverre Rabbelier @ 2008-11-03 9:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gemhdp$lev$1@ger.gmane.org>
On Mon, Nov 3, 2008 at 10:48, Jakub Narebski <jnareb@gmail.com> wrote:
> "git remote <remote> push" for push matching?
Not another command that is made to perform yet another piece of
funcionality. Let's let remote handle (configuring, and maintaining
of) remote related things, not also make it do push stuff.
Unless ofcourse, you mean that "git remote push <remote>" (certainly
not the other way around) is for configuration only.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: why not TortoiseGit
From: Nigel Magnay @ 2008-11-03 10:00 UTC (permalink / raw)
To: Li Frank; +Cc: Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE961E728C@zch01exm23.fsl.freescale.net>
> I read some code of TortoiseSVN and TortoiseHg Code.
> At beginning, TortoiseGit can git command to get information like Qgit.
> After linkable library ready, replace "git command".
>
> I think TortoiseGit can start base on below way.
>
> 1. Base on TortoiseHg, It is python Script. Replace below hg operator
> with Git.
> 2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
> ToritoiseSVN provide some built in diff and merge tools.
> 3. Base on Qgit, which provide some basic UI, such comment dialogbox,
> history view and file annotate.
>
>
TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and
you might run out, and I'd imagine lots of people wanting both.
On the minus side, building (Tortoise)SVN requires a lot of
environment setup just to get it to build - most of which can be
immediately thrown away as it's specific to SVN.
But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows
if files are dirty.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-03 10:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081102015041.GG15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> Eh, I disagree here. In git.git today "struct commit" exposes its
>>> buffer with the canonical commit encoding. Having that visible
>>> wrecks what Nico and I were thinking about doing with pack v4 and
>>> encoding commits in a non-canonical format when stored in packs.
>>> Ditto with trees.
>> Err... isn't that backwards?
>
> No.
>
>> Surely you want to store stuff in the
>> canonical format so you're forced to do as few translations as
>> possible?
>
> No. We suspect that canonical format is harder to decompress and
> parse during revision traversal. Other encodings in the pack file
> may produce much faster runtime performance, and reduce page faults
> (due to smaller pack sizes).
>
> We hardly ever use the canonical format for actual output; most
> output rips the canonical format apart and then formats the data
> the way it was requested. If we have the data *already* parsed in
> the pack its much faster to output.
>
I'll have to look into the pack v4 stuff, as I can't get what you're
saying to make sense to me. Not canonicalizing the data when storing
it means you'll have to have conversion routines from all the various
encodings, unless you first canonicalize it and then encode it in the
way you need it in the pack way. Never using canonical format means
it has no potential for combinatorial explosion, and every converter
needs to know about every other format.
>> Or are you trying to speed up packing by skipping the
>> canonicalization part?
>
> Wrong; we're trying to speed up reading. Packing may go slower,
> especially during the first conversion of v2->v4 for any given
> repository, but packing is infrequent so the minor (if any) drop
> in performance here is probably worth the reading performance gains.
>
>> Well, if macro usage is adhered to one wouldn't have to worry,
>> since the macro can just be rewritten with a function later (if,
>> for example, translation or some such happens to be required).
>> Older code linking to a newer library would work (assuming the
>> size of the commit object doesn't change anyway),
>
> You are assuming too much magic. If the older ABI used a macro
> and the newer one (which supports pack v4) organized struct commit
> differently and the user upgrades libgit2.so the older applications
> just broke, horribly.
>
Naturally. Re-sizing objects that weren't previously protected by
accessor functions will always break the ABI unless the layout of
the previously existing items in the object doesn't change, which
is exactly what I said.
> We know we want to do pack v4 in the near future. Or at least
> experiment with it and see if it works. If it does, we don't
> want to have to cause a major ABI breakage across all those newly
> installed libgit2s... yikes.
>
That's not necessary, although it requires a bit more thought when
changing the objects.
> I'm really in favor of accessor functions for the first version of
> the library. They can always be converted to macros once someone
> shows that their git visualizer program saves 10 ms on a 8,000 ms
> render operation by avoiding accessor functions. I'd rather spend
> our brain cycles optimizing the runtime and the in-core data so
> we spend less time in our tight revision traversal loops.
>
I agree that for early versions they should definitely be functions,
but since we've been talking about "final design" earlier in the
thread, that's what I was referring to here to.
> Seriously. We make at least 10 or 11 function calls *per commit*
> that comes out of get_revision(). If the formatting application is
> really suffering from its 4 or 5 accessor function calls in order
> to get that returned data, we probably should also be looking at
> how we can avoid function cals in the library.
>
> Oh, and even with 4 or 5 accessor functions per commit in the
> application that is *still* better than the 10 or so calls the
> application probably makes today scraping "git log --format=raw"
> off a pipe and segment it into the different fields it needs.
>
Right.
> Unless pipes in Linux somehow allow negative time warping with
> CPU counters. Though on dual-core systems they might, since the
> two processes can run on different cores. But oh, you didn't want
> to worry about threading support too much in libgit2, so I guess
> you also don't want to use multi-core systems.
>
All comps where I use git today are multi-core systems, so I'm very
much in favour of parallell processing. Otoh, I also don't think it
makes sense to jump through hoops to make sure one can, fe, read and
parse all tags in multiple threads simultaneously. In other words, I
don't think we need to bother adding thread-safety for stuff that
really only should happen if the application is poorly designed
(unless it's straightforward to do so, ofcourse).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* how to ignore all .xvpics directories
From: Christoph Duelli @ 2008-11-03 10:11 UTC (permalink / raw)
To: git
Is it possible to ignore (once and for all) that directories like .pics
or .xvpics (that might occur all over the place where xv was called)
should be ignored?
[ Note: some time ago this issue has already popped up:
http://thread.gmane.org/gmane.comp.version-control.git/50504
However, adding a line with just .xvpics in the toplevel .gitignore does
not help. Neither does /**/.xvpics
]
Best regards
--
Christoph Duelli
^ permalink raw reply
* Re: git/lib and git/git-gui/lib merge mis-hap?
From: Andreas Ericsson @ 2008-11-03 10:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20081101202201.GA15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Settling down to get some libgit2 hacking done (adding build-rules
>> to git.git), I noticed that there's a file in git.git called
>> lib/remote_add.tcl, which looks as if it belongs in git-gui/lib.
>>
>> I don't know how this happened, but since I assume it's subtree
>> merged (thus requiring more work to correct than a simple patch),
>> it would be nifty if it could get corrected so as to make space
>> for the up-and-coming git library :-)
>
> That was a bad merge of git-gui on my part. I thought it was fixed.
> It only happened in next, and was there only for a day before
> someone pointed it out to me, and I fixed it in the tree.
>
> FWIW, "git mv lib/remote_add.tcl git-gui/lib" is all you need to
> fix it. There's nothing special about the subtree merge.
>
I just pulled latest next, and it's fixed now. Thanks.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-cvsimport.perl: use human readable names for option values
From: Francis Galiegue @ 2008-11-03 10:32 UTC (permalink / raw)
To: git
In-Reply-To: <200811031031.59196.fg@one2team.net>
Le Monday 03 November 2008 10:31:59 Francis Galiegue, vous avez écrit :
> Hello,
>
> As I am keen to make my company use git eventually, but they have a really,
> really messy CVS tree that git-cvs*.perl cannot handle right now, I've
> decided to have a serious look at the code.
>
As stated in one mail I sent earlier on, the real problem is that
git-cvsimport won't detect empty branches for two reasons:
* it relies on cvsps output, which doesn't tell about it either;
* however, it doesn't make use of another file that cvsps generates in
$HOME/.cvsps by default, which can help about giving this information.
I'll try the following:
* instead of capturing cvsps output directly, I'll use its -p option, which
has the advantage of generating one file per patchset;
* I'll consolidate the information of the other generated file in a hash and
correlate the information found in there with the individual patchset: my
hope is that I'll be able to detect so-far undetected branches and create
them.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Andreas Ericsson @ 2008-11-03 10:35 UTC (permalink / raw)
To: drafnel; +Cc: git, gitster, nico
In-Reply-To: <14536526.1225596838300.JavaMail.teamon@b301.teamon.com>
drafnel@gmail.com wrote:
> From: Brandon Casey <drafnel@gmail.com>
>
> Objects residing in pack files that have an associated .keep file are not
> supposed to be repacked into new pack files, but they are.
>
I think that's a misconception. Packfiles that are marked with .keep files
should never be deleted. There are, afaik, no rules against packing the
same objects into other packfiles as well. This is nifty for dumb ref
walkers, as they can use a small pack for incremental fetching while using
a mega-pack for initial cloning.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Offtopic [Re: Can't use gitk.]
From: Andreas Ericsson @ 2008-11-03 10:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <4d8e3fd30811021128q5f172a97pbc8e657d08f9ac8c@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On Mon, Nov 14, 2005 at 7:24 PM, Linus Torvalds <torvalds@osdl.org> wrote:
>> On Mon, 14 Nov 2005, Franck wrote:
>
> Sorry for commenting on this email only now but I found it in my
> archive while looking for a different thread :-)
>
>>> oops, sorry Andreas for that ! I use to spelling this name without 's'
>>> that's why I did the mistake I think.
>> In Finland and Sweden Andrea without the "s" is a girls name, while
>> Andreas with the "s" (or André without "-as") is a boy.
>>
>> It's not even very rare. "Andrea" was the 84th most popular female name in
>> Sweden in 2000.
>>
>> It can be confusing, since in Italy (and, I think, southern Germany and
>> much of Eastern Europe), "Andrea" is a boy, and in fact, the name
>> originally comes from the Greek meaning "man".
>
> In Italy Andrea might be a girl as well even if that name is often
> used for a boy.
>
Little did my parents know that the name they gave me would spawn a
discussion lasting very nearly three years.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Jakub Narebski @ 2008-11-03 11:49 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <490ECE54.5090505@melosgmbh.de>
Christoph Duelli <duelli@melosgmbh.de> writes:
> Is it possible to ignore (once and for all) that directories like
> .pics or .xvpics (that might occur all over the place where xv was
> called) should be ignored?
>
> [ Note: some time ago this issue has already popped up:
> http://thread.gmane.org/gmane.comp.version-control.git/50504
>
> However, adding a line with just .xvpics in the toplevel .gitignore
> does not help. Neither does /**/.xvpics
Could you reproduce the steps you tried? Because I have checked, and
putting .xvpics or .xvpics/ in top level .gitignore (or in
.git/info/excludes, or ~/.gitignore) works as expected: filename
without '/' in it is match agains _basename_.
Note that .gitignore is about contents which is not tracked (not known
to git). If you added .xvpics to commit by accident, .gitignore will
do nothing then.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Jakub Narebski @ 2008-11-03 12:06 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Nicolas Pitre
In-Reply-To: <1225701813.20883.85.camel@maia.lan>
Dnia poniedziałek 3. listopada 2008 09:43, Sam Vilain napisał:
> On Fri, 2008-10-31 at 08:36 +0100, Jakub Narebski wrote:
> > > > git checkout --track origin/wr34251-do-something
> > >
> > > Ah, that's a new feature. Still, I think it's poorly Huffman coded; far
> > > too verbose.
> >
> > Well, either you have a little bit more verbose, or you have to have
> > some DWIM-mery, which (as usual with DWIM) can go wrong.
>
> That's right, you need to choose when to assume that the user meant
> something that they didn't write very carefully.
>
> But look at this:
>
> git checkout origin/master
>
> git checkout -t origin/master
>
> The option is called "--track", yet in this case what it actually means
> in the default situation where you have autosetupmerge (or whatever it's
> really called) set to true, is that it modifies the command to imply "-b
> master". So, in this situation, that is clearly what was meant.
>
> Perhaps you can give an example of why this particular piece of DWIM
> might not be WYM?
I was not talking about "git checkout -t origin/master" being shortcut
for "git checkout -b master -t origin/master", but about proposed
DWIM-mery for "git checkout -b <branch>" which would be
{ git checkout -b <branch> -t <remote>/<branch>
git checkout -b <branch> = { if there exists <remote>/<branch>
{
{ git checkout -b <branch> HEAD
{ otherwise
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Christoph Duelli @ 2008-11-03 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4hdf2qp.fsf@localhost.localdomain>
Jakub Narebski schrieb:
>> [ Note: some time ago this issue has already popped up:
>> http://thread.gmane.org/gmane.comp.version-control.git/50504
>>
>> However, adding a line with just .xvpics in the toplevel .gitignore
>> does not help. Neither does /**/.xvpics
>
> Could you reproduce the steps you tried? Because I have checked, and
> putting .xvpics or .xvpics/ in top level .gitignore (or in
> .git/info/excludes, or ~/.gitignore) works as expected: filename
> without '/' in it is match agains _basename_.
>
> Note that .gitignore is about contents which is not tracked (not known
> to git). If you added .xvpics to commit by accident, .gitignore will
> do nothing then.
Thank you Jakub,
I checked that and indeed... someone left uncomitted changes (i.e.
deleted those (acc. commited) files without committing) and got me confused.
It *does* work for untracked files.
Sorry for the noise.
--
Christoph Duelli
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Matthieu Moy @ 2008-11-03 12:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20081102095152.GG4066@artemis>
Pierre Habouzit <madcoder@debian.org> writes:
> I don't know for others, but with those series, git-send-email is
> _REALLY_ what I would have wanted it to be from day 1.
Same for me. I didn't really understand why git was asking me to run
two separate commands to send a patch. Having git-send-email do
everything and ask me only the required is really the way I expected
it to be.
(probably not a coincidence that at least bzr and darcs have a "send"
command that does just this)
--
Matthieu
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Matthieu Moy @ 2008-11-03 12:53 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git
In-Reply-To: <d62af2d5-4ba4-4fe6-9ecb-6df007f87245@s9g2000prm.googlegroups.com>
Abhijit Bhopatkar <bain@devslashzero.com> writes:
> I have just tagged the teamgit repo as v0.0.4
You should include a short summary (teamgit is a .... for git) of what
teamgit does in such announcements.
AIUI, it's a GUI for git.
--
Matthieu
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-03 13:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081101204259.GC15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> During the GitTogether we were kicking around the idea of a ground-up
>>> implementation of a Git library.
>> Having looked briefly at the code, I've got a couple of comments:
>> * GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
>
> I feel the same way.
>
> But I was also under the impression that the brilliant engineers
> who work for Microsoft decided that on their platform special
> annotations have to be inserted on functions that a DLL wants to
> export to applications.
>
> Hence any cross-platform library that I have seen annotates their
> exported functions this way, with the macro being empty on POSIX
> and expanding to some magic keyword on Microsoft's OS. I think it
> goes between the return type and the function name too...
>
>> Instead it would be better to have GIT_PRIVATE(),
>
> I can see why you said this; needing GIT_PRIVATE() is a lot more
> rare than needing GIT_EXTERN(). Only a handful of cross-module,
> but private, functions are likely to exist, so it makes sense to
> mark the smaller subset. But see above. *sigh*
>
Thanks for the detailed explanation.
>> * Prefixing the files themselves with git_ is useless and only leads
>> to developer frustration. I imagine we'd be installing any header
>> files in a git/ directory anyway, so we're gaining absolutely
>> nothing with the git_ prefix on source-files.
>
> Yes, I realized that this morning. I plan on changing that mess
> around so we have "include/git/oid.h" and library and application
> code can use "#include <git/oid.h>". Library modules should just
> be "src/oid.c" then.
>
I noticed when I fetched the latest head today that it's already
done. I fail to understand why headers need to be in a separate
path so that oid.c can't just '#include "oid.h"'.
With the risk of nitpicking you to death, put public headers in a
separate dir (I'd suggest public/%.h in Make-speak, but I have no
strong preference) and keep private headers next to %.c. Always
#include the public header file from the private one (that should
probably be in CONVENTIONS).
>> Apart from that, it seems you've been designing a lot rather than
>> trying to use the API to actually do something.
>
> I wanted to get a solid idea of what our API conventions should be,
> before we started writing a lot of code around them. Part of the
> problem with the git.git code is we don't have conventions that are
> really suited for use in a shared library (assuming we even have
> conventions in there) so we can't use that code as a library today.
>
Right. I guess I'm too firm a believer in system evolution by constant
refactoring (with fluctuating api's, yes) rather than thinking initial
design can ever be done exactly right.
>> It would, imo, be
>> a lot better to start development with adding functionality shared
>> between all programs and then expand further on that, such as
>> incorporating all functions needed for manipulating tags into the
>> library and then modify existing code to use the library to get
>> tag-ish things done.
>
> Tags are mostly pointless. Its a tiny part of the code that isn't
> that interesting to most people. And it requires object database
> access anyway if you want to talk about parsing or reading a tag.
> There's almost no point in a git library that can't read the on
> disk object database, or write to it.
>
True, but designing top-down means you'll need to write one more
API to get the first stuff working, so you'll always be using the
new code you write immediately and for something real. IMO, that
makes it much more fun and productive to write the lib itself.
>> I also think it's quite alright to not strive *too* hard to make
>> all functions thread-safe, as very few of them will actually need
>> that. It's unlikely that a user program will spawn one thread to
>> write a lot of tags while another is trying to parse them, for
>> example.
>
> Oh really?
>
> Maybe true for tags, just because they are such an unimportant part
> of the git suite compared to everything else.
>
> But right now I'm running a production system using a threaded server
> process that is operating on Git repositories. Fortunately threads
> suck less on Java than they do on POSIX, and we have a 100% pure
> Java library available for Git.
>
> It would be nice if a library created in the late part of 2008
> recognized that threads exist, aren't going to disappear tomorrow,
> and that consumers of libraries actually may need to run the library
> within a threaded process.
>
> Or are you one of those developers who think threads only exist
> in the giant monolithic kernel land, and all user space should
> be isolated process? I often wonder who such people can justify
> the kernel address space being multi-threaded but userland being
> stuck to single threaded applications. Oh, right, the kernel has
> to go fast...
>
No, I'm one of those developers who think that if implementing a
function as thread-safe means it'll take 50 times longer than just
writing something that works, the right decision is to go with the
faster way to get the job done and then expand on it later when the
need arises. Reading my original post, I realize I should have made
that more clear. Sorry for making your gall rise unnecessarily.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: why not TortoiseGit
From: Johannes Schindelin @ 2008-11-03 13:26 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Li Frank, Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <320075ff0811030200q606b76a8i16496cf7b8b1b7d2@mail.gmail.com>
Hi,
On Mon, 3 Nov 2008, Nigel Magnay wrote:
> But it doesn't look like a hard project to me, just requires stripping
> out a lot of junk and re-patching callouts to a git executable (which
> could be the standard git tools) and a minimal git library that knows if
> files are dirty.
I only wish that people would put their code where there mouth is.
At least with GitCheetah, we have working code, _and_ an opportunity to go
cross-platform.
Ciao,
Dscho
^ permalink raw reply
* Re: how to ignore all .xvpics directories
From: Matthieu Moy @ 2008-11-03 13:03 UTC (permalink / raw)
To: Christoph Duelli; +Cc: git
In-Reply-To: <490ECE54.5090505@melosgmbh.de>
Christoph Duelli <duelli@melosgmbh.de> writes:
> Is it possible to ignore (once and for all) that directories like
> .pics or .xvpics (that might occur all over the place where xv was
> called) should be ignored?
in ~/.gitconfig:
[core]
excludesfile = /home/yourlogin/.gitignore
then, in ~/.gitignore:
.xvpics
and all your .xvpics will be ignored for all your projects.
(it's nice to keep such ignore list user-wide and not project-wide if
you don't want to bother your collaborators with your choice of
software).
--
Matthieu
^ permalink raw reply
* Re: [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-03 13:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqfxm9km1w.fsf@bauges.imag.fr>
>> I have just tagged the teamgit repo as v0.0.4
>
> You should include a short summary (teamgit is a .... for git) of what
> teamgit does in such announcements.
>
Ack,
teamGit is a GUI for git,
in its final roadmap it aims to aid small closed teams to use git,
currently its a pretty good frontend for basic git operations.
Abhijit
^ permalink raw reply
* [Q] Abbreviated history graph?
From: Brian Foster @ 2008-11-03 13:39 UTC (permalink / raw)
To: Git Mailing List
Hello,
A colleague and I recently wanted to examine the
history in a broad sense without worrying too much
about the individual commits. What we (think we)
wanted is a ‘gitk --all’ history graph showing only
“named” historical points; i.e., tags and branch
HEADs, perhaps with an indication of whether or not
it's a “linear” change sequence that leads from one
to another. That is, hypothetically, if the history
looks something like (where ‘A’ &tc has a name as
per above, and ‘*’ does not):
A--->*--->*--->C--->D--->*----->E
\ \ /
\->*-->B \->*--->*--->F
What we wanted to see is something like:
A------>C--->D--->E
\ \ /
\->B \-----/--->F
Is there some way of doing something similar to that
(git v1.6.0.2)? In addition to ‘gitk’, we also (rather
quickly!) tried both ‘qgit’ and ‘giggle’, but without
any apparent success.
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ permalink raw reply
* Re: why not TortoiseGit
From: Nigel Magnay @ 2008-11-03 13:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Li Frank, Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <alpine.DEB.1.00.0811031425080.22125@pacific.mpi-cbg.de.mpi-cbg.de>
>> But it doesn't look like a hard project to me, just requires stripping
>> out a lot of junk and re-patching callouts to a git executable (which
>> could be the standard git tools) and a minimal git library that knows if
>> files are dirty.
>
> I only wish that people would put their code where there mouth is.
>
> At least with GitCheetah, we have working code, _and_ an opportunity to go
> cross-platform.
>
Well, hey, I don't care there's no TortoiseGit. I looked at these
things back when I had colleagues stuck on Windows, and at the time
wanted to try and wean them off SVN.
The shell-icon overlay limit on Windows looked a significant problem
to me, and a good reason for at least re-using that bit of code (which
is common to even tortoiseCVS). It looked like it had been through a
significant number of iterations to get platform shell subtleties
right.
I even looked at wacky things, like using IKVM.Net and JGit to hack it
quickly, but that's a non-starter because of MS' stupid
one-clr-per-process.
That's what I found. Maybe it'll be useful for anyone else that wants
to continue. Since it's not an itch for me any more, and it won't feed
my children, until someone that cares enough does something there
won't be one.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-11-03 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <7vy70123rr.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
On Sun, Nov 02, 2008 at 09:53:44PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> > * git-send-email should be either more interactive, or less: either
> > just use the damn configuration, or propose a mode where it spawns
> > an editor for each patch so that you can add further comments.
>
> In principle I'd agree, but I use send-email non-interactively myself (I
> type Meta/SE where Meta is an independent checkout of my 'todo' branch),
> so I am not sure if the "just use the configuration" is an added
> requirement. I also have this in .git/config in the repo:
>
> [sendemail]
> smtpserver = /usr/bin/msmtp
> to = git@vger.kernel.org
> suppressfrom
> signedoffcc = false
Well with my patches it goes _more_ interactive on request only, so that
wouldn't break your setup (you have to explicitely pass --annotated
and/or --compose). Okay arguably not the feature that auto enables
--compose on series of more than 1 patch, but you can redirect
send-email to | cat or pass --no-compose for that. Or we can drop that
bit of the patch if people find it too cumbersome, I can put that in an
alias I don't really care.
I really _care_ about not breaking send-email for its previous uses.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Fetch via http and proxy which requires authentication
From: Dilip M @ 2008-11-03 14:02 UTC (permalink / raw)
To: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <4d8e3fd30808280313i70f572cfh9c14fbc2adbf5cea@mail.gmail.com>
On Thu, Aug 28, 2008 at 3:43 PM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
>> Hi all,
>> i'm looking for a way to use git behind a corporate proxy which
>> requires authentication.
>> i just need to be able to fetch/pull via http.
>> i'm using git on a win xp box.
>> Any hint?
>
> Yes, google for http_proxy ;-)
>
> export http_proxy=http://host:port
> git clone http://username:password@giturl
I tried setting, export http_proxy=http://<user>:<password>@host:port
But git clone failed!
$git clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git
clone http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/dilipm/bin/linux-2.6/.git/
fatal:
http://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/info/refs
download error - The requested file was not found
What may the problem? How can debug....
PS: wget works ...
--
Dilip
^ permalink raw reply
* Re: [Q] Abbreviated history graph?
From: Santi Béjar @ 2008-11-03 14:20 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List
In-Reply-To: <200811031439.12111.brian.foster@innova-card.com>
[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]
On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
>
> Hello,
>
> A colleague and I recently wanted to examine the
> history in a broad sense without worrying too much
> about the individual commits. What we (think we)
> wanted is a 'gitk --all' history graph showing only
> "named" historical points; i.e., tags and branch
> HEADs, perhaps with an indication of whether or not
> it's a "linear" change sequence that leads from one
> to another. That is, hypothetically, if the history
> looks something like (where 'A' &tc has a name as
> per above, and '*' does not):
>
> A--->*--->*--->C--->D--->*----->E
> \ \ /
> \->*-->B \->*--->*--->F
>
> What we wanted to see is something like:
>
> A------>C--->D--->E
> \ \ /
> \->B \-----/--->F
>
> Is there some way of doing something similar to that
> (git v1.6.0.2)? In addition to 'gitk', we also (rather
> quickly!) tried both 'qgit' and 'giggle', but without
> any apparent success.
Not in git.git but you can use the script at the bottom (also attached
in case it is whitespace damage).
It could be much faster if "git log" stops when finding a tag/branch.
HTH,
Santi
[git-overview]
#!/bin/sh
TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15
git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
while read hash ; do
# Independent tags/branches parents:
# Notes:
# * -n 1000 to limit the search, ideally "git log" could stop
# traversing the history when hits a tag/branch tip
# * head -n 25 because "git show-branch --independent" has this limit
ancestors=$(git log -n 1000 --pretty=short --decorate
--pretty=format:%H%d $hash^@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
if [ -n "$ancestors" ] ; then
echo $hash $(git show-branch --independent $ancestors)
else
echo $hash
fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d
[-- Attachment #2: git-overview --]
[-- Type: application/octet-stream, Size: 806 bytes --]
#!/bin/sh
TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15
git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
while read hash ; do
# Independent tags/branches parents:
# Notes:
# * -n 1000 to limit the search, ideally "git log" could stop
# traversing the history when hits a tag/branch tip
# * head -n 25 because "git show-branch --independent" has this limit
ancestors=$(git log -n 1000 --pretty=short --decorate --pretty=format:%H%d $hash^@ |\
awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
if [ -n "$ancestors" ] ; then
echo $hash $(git show-branch --independent $ancestors)
else
echo $hash
fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d
^ permalink raw reply
* Git SVN Rebranching Issue
From: Matt Kern @ 2008-11-03 14:07 UTC (permalink / raw)
To: git
I have a git-svn issue which keeps biting me.
My company uses svn as its primary version control system. We
frequently create branches, e.g. /branches/somebranch, by forking the
trunk to ensure stability over the "somebranch" code. The problem is
that we also frequently blow away /branches/somebranch and refork it
from the trunk.
git-svn does a good job for most work, but I notice that if you delete
the "somebranch" branch in svn and then refork it, also in svn, then
when you git-svn fetch, the git commit at the head of remotes/somebranch
will have two parents: the first is the previous head of
remotes/somebranch, and the second is the head of remotes/trunk. Surely
only the remotes/trunk parent should be listed? Any connection with the
previous remotes/somebranch is an accident of naming. The real problem
then comes when you come to look at the history in gitk. If
"somebranch" is rebranched many times, the git history starts looking
pretty complicated, when in fact it should simply be the linear history
of remotes/trunk up to the branch point followed by a few,
branch-specific commits. Is there any way to prevent (or modify) the
git history to remove the errant parent?
In the ideal world, we wouldn't reuse branch names in svn, but it is
convenient and doesn't cause problems for svn users. I can't force the
rest of the company to change to accommodate my use of git...
I am using git (svn) version 1.5.6.5 (svn 1.4.6) from Debian/Lenny and
can provide a trivial repository demonstrating the problem if anyone is
interested.
Matt
--
Matt Kern
http://www.undue.org/
^ 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