* Re: [FEATURE REQUEST] - extend git request-pull to send email
From: Junio C Hamano @ 2011-02-03 22:59 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <AANLkTi=kXJF_rYGMyh1gj49J7fh-ZxD7Bo8o_ELHb-2M@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Specifying the "--to user@server.com" could be a trigger for this functionality.
> All additional parameters from git send-mail should be available.
>
> What do you think?
Horrible ;-).
If this were not about request-pull but some other command that produces a
summary of recent changes you have, which you might want to distribute to
people who are involved in the project (e.g. Meta/cook), it might make
sense to have "generate and then e-mail" feature inside the command,
because such a command needs to inspect the history and grab various kinds
of information anyway, and adding "people involved" to the mix might make
sense.
But you are talking about request-pull, which is by design is meant to be
sent to a single recipient. If the user has to say --to user@example.com,
how is it different from piping the output to "| mail to@example.com"?
^ permalink raw reply
* [FEATURE REQUEST] - extend git request-pull to send email
From: Eugene Sajine @ 2011-02-03 22:35 UTC (permalink / raw)
To: git
Hi,
The command "git request-pull" doesn't actually request anything but
just outputs a nice report about pending changes.
I would suggest to extend "git request-pull" to be able to send email
with the information generated by the command using "git send-mail"
functionality. By default it could take some values from the
environment, like the sender information, the subject and of course
the body of the message.
Specifying the "--to user@server.com" could be a trigger for this functionality.
All additional parameters from git send-mail should be available.
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Junio C Hamano @ 2011-02-03 22:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Joshua Jensen
In-Reply-To: <1296751106-15316-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> On top of nd/struct-pathspec, but requires jj/icase-directory. I can
> rebase the series on top of master if it causes too many conflicts.
I am in the middle of rewinding 'next' and have already rebased the topic;
I will queue the result in 'pu' so could you check the result when it is
pushed out later?
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Hilco Wijbenga @ 2011-02-03 21:42 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, George Spelvin, Eugene Sajine
In-Reply-To: <AANLkTimnMDuAX-Ctc5K3mt=b2bz2FTsb_P7Fs8RzVwpd@mail.gmail.com>
On 3 February 2011 10:46, Eugene Sajine <euguess@gmail.com> wrote:
> On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Tue, 1 Feb 2011, George Spelvin wrote:
>>
>>> For what it's worth, I don't see the "cleanup".
>>>
>>> If it significantly reduced the size of the largest directory,
>>> that would be a win. But moving everything into src/ doesn't
>>> do that.
>>>
>>> If there's a way to divide the source into cohesive subunits, that
>>> would be great. A programmer could ignore whole subdirectories
>>> when working on something.
>>>
>>> But just moving the whole existing pile into a subdirectory "because
>>> everyone else does it" is not a reason; that's superstition.
>>
>> There is no superstition here, simply basic elegance.
>>
>> When you pick up a book from a shelf, do you see the actual content of
>> the book printed right from the inside of the cover page, and the table
>> of content tossed in the margin? Would you construct a book yourself
>> that way?
>>
>> A nice source tree should be organized with a minimum of hierarchical
>> structure. To a newbie wanting to contribute to Git, it is rather
>> frightening to cd into the git directory and see that ls generates more
>> than 280 entries. That simply looks sloppy. And this gets much worse
>> after a make.
>>
>> The top directory should make different things stand out much more
>> clearly, like a preface and a table of content. You have the
>> documentation here, the source there, the tests there, a clearly visible
>> README file, etc. If the src directory has about the same relative
>> number of files after a move that's fine. At least you should expect
>> _only_ source files in there (and possibly their by-products), and not
>> other types of data buried into the mix.
>>
>>> Having to type "src/" a lot more often is definitely a downside.
>>
>> Come on. This is a rather egocentric argument without much substance.
>>
>>> Heck, that's one thing I actively dislike about GNU autoconf conventions.
>>
>> This has _nothing_ about any autoconf convention. GNU autoconf requires
>> stupid things like having a bunch of files such as CREDITS, INSTALL,
>> CHANGELOG, and other whatnots even if you have nothing to put in them,
>> in which case they still have to be there but empty. It also dictates
>> the exact name your directories must have, etc.
>>
>> I'm not proposing a tree reorganization because GNU autoconf commands
>> it, but rather because this is a sensible thing to do.
>>
>>> If there's a compelling reason to change, could someone please describe it?
>>
>> It's about the third time I'm putting forward arguments for this.
>> Please see the list archive.
>>
>> P.S. the netiquette on busy mailing lists recommends that you preserve
>> all the email addresses that were listed as recipients on the message
>> you reply to. That would be highly appreciated.
>>
>>
>> Nicolas
>> --
>> 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
>>
>
> I'm not a hacker, but a user who had sometimes peeked into the git
> sources. Unbelievable mess... Impossible to see the structure in
> command line interface.
> I totally agree with Nicolas here.
> Folders were invented for a reason.
>
> IMHO
> src for source code
> build for build by-products
> tests for tests
>
> Come on, give us some love, please!;)
Another one from the peanut gallery. :-) I wholeheartedly agree with
both Nicolas and Eugene.
Quite frankly, I'm surprised there are (presumably experienced)
developers who do not immediately see the value of a little
organization. Surely, given the use of code conventions, formatting
rules, etcetera, the obvious one step further is to also organize
where the files go?
(Given that I'm just a lurker I promise to leave it at this. I just
wanted to show Nicolas a little support.)
^ permalink raw reply
* Re: Narrow clone (Re: features from GitSurvey 2010)
From: Jonathan Nieder @ 2011-02-03 21:38 UTC (permalink / raw)
To: Geert Bosch
Cc: Nicolas Pitre, Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Dmitry S. Kravtsov, git
In-Reply-To: <5E0364BF-35CD-4797-BBAF-98A54D1F7F6E@adacore.com>
Geert Bosch wrote:
> Of course the resulting git repository will be less than useful.
> And that's where the narrow clone comes in handy...
Side note: while clearly I don't consider this particular use case to
be a strong motivation, there are other use cases that do strongly
motivate the feature. And if this particular use case happens to
motivate someone to work on it, I'd be happy for it still. I just
hope the documentation does not encourage people to do such things.
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-03 21:33 UTC (permalink / raw)
To: Geert Bosch
Cc: Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <FE2BDD68-9CFA-4CBB-9F66-32BE6CF3E174@adacore.com>
On Thu, 3 Feb 2011, Geert Bosch wrote:
>
> On Feb 1, 2011, at 16:51, Nicolas Pitre wrote:
>
> > Also... people interested in Narrow clones are likely to be shallow
> > clone users too, right?
>
> Not necessarily. Many corporate repositories are huge (caused by
> the concept of 1 central repository with everything in it) and have
> tons of crud (like marketing materials, media-heavy powerpoint
> presentations). Here you really want a narrow clone (such as the
> sources of the project you're working on), but don't mind having
> the whole history.
OK. I was asking just to see if the cache pack concept might have to
cater for that case too. but let's wait for proper narrow clone support
first.
Nicolas
^ permalink raw reply
* Re: Narrow clone (Re: features from GitSurvey 2010)
From: Jonathan Nieder @ 2011-02-03 21:33 UTC (permalink / raw)
To: Geert Bosch
Cc: Nicolas Pitre, Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Dmitry S. Kravtsov, git
In-Reply-To: <5E0364BF-35CD-4797-BBAF-98A54D1F7F6E@adacore.com>
Geert Bosch wrote:
> Some would rather
> spend 30+ days of CPU time to import an entire SVN repository with
> branch forests straight into git than considering organization.
> Of course the resulting git repository will be less than useful.
> And that's where the narrow clone comes in handy...
Right, narrow clone gives them an excuse to do it. Ergo we should
not have narrow clone. ;-)
^ permalink raw reply
* Re: Narrow clone (Re: features from GitSurvey 2010)
From: Geert Bosch @ 2011-02-03 21:23 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nicolas Pitre, Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Dmitry S. Kravtsov, git
In-Reply-To: <20110203173835.GC30341@elie>
On Feb 3, 2011, at 12:39, Jonathan Nieder wrote:
> Geert Bosch wrote:
>
>> These narrow clones are especially important for imports of unwieldy
>> svn repositories where there is a large amount of unstructured
>> branching.
>
> Wouldn't a more careful import be a better solution to that problem?
Yes.
> Practically speaking, I'd rather work with an enormous svn repo like
> that by using git-svn to extract subsets than with a botched import
> that treats it as one huge (git-managed) project.
Practically speaking, I don't always have a say in the organization
of repositories that I have to work with. Some would rather
spend 30+ days of CPU time to import an entire SVN repository with
branch forests straight into git than considering organization.
Of course the resulting git repository will be less than useful.
And that's where the narrow clone comes in handy...
-Geert
^ permalink raw reply
* git rebase conflicts?
From: KAJed @ 2011-02-03 21:06 UTC (permalink / raw)
To: git
If I'm rebasing the history on a project, basically squashing all commits to
a point, why are there conflicts?
Keep in mind this is a flat history. Basically the history came from SVN
and now I'm trying to squash that down to "this was the stable migration
from SVN".
So howcome when rebasing it causes a conflict?
Some times its files that are missing, or being deleted.
Some times I can see it's because an empty directory (at least that makes
sense with git).
Any other suggestions? What I really want is there to either be NO
conflicts, or simply conflict resolve with the correct (newer) file.
--
View this message in context: http://git.661346.n2.nabble.com/git-rebase-conflicts-tp5990493p5990493.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [msysGit] [PATCH 4/4] t5526: avoid dependency on submodule order
From: Johannes Sixt @ 2011-02-03 20:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pat Thoyts, msysgit, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.1102031426110.1541@bonsai2>
On Donnerstag, 3. Februar 2011, Johannes Schindelin wrote:
> On Thu, 3 Feb 2011, Johannes Sixt wrote:
> > Furthermore, just like Dscho, I'd rather prefer to know why the output
> > is not ordered as expected.
>
> Have you seen my response where I proved that it is a fflush() issue, most
> likely with mingw_spawn()?
Obviously, I haven't. Good catch!
-- Hannes
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Felipe Contreras @ 2011-02-03 20:34 UTC (permalink / raw)
To: Jeff King
Cc: J.H., Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano,
git
In-Reply-To: <20110203174518.GA14871@sigill.intra.peff.net>
On Thu, Feb 3, 2011 at 7:45 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 02, 2011 at 06:24:23PM -0800, J.H. wrote:
>
>> On 02/02/2011 01:55 AM, Vincent Hanquez wrote:
>> > On 01/02/11 22:48, J.H. wrote:
>> >> The wiki will almost universally have a "central site" no matter what
>> >> the backend. Personally I see little advantage to having a git backed
>> >> wiki myself.
>> > with git based wiki, you can clone the whole wiki on your local machine,
>> > and read/edit/commit on it locally using standard editor tool (i.e.
>> > $EDITOR). and the history/revision/diff is completely built-in.
>>
>> That would be fine for things like source code or documentation, but you
>> end up with a single person who would need to merge / push things to a
>> central location, a-la git.wiki.kernel.org. You are now taking
>> something, that is already editable by anyone, and making it only
>> editable by a single person.
>
> I don't think it makes sense to use the same workflow for the wiki as
> git.git itself uses. The point of having a wiki is to keep the barrier
> to editing extremely low; the point of source code control is to keep
> the quality of contributions high.
>
> But that doesn't mean they can't be accessed by the same tool.
>
> Forget about a git-backed wiki for a moment, and imagine a regular old
> Mediawiki. What are the operations you can perform? You can look at
> the current or any past version of a page, you can do diffs between
> versions of pages, and you can create a new version of a page. All
> through some CGI forms.
Howe about these?
1) Support for discussion; since changes can be controversial.
2) Support for article move; so everything is kept organized.
3) Support for "who is linking here". Also helps reorganization.
4) Support for categories. Ditto.
5) Support for watchlist, e-mail notifications. So that you are
up-to-date with the changes.
6) Support for contribution backtracking. So that it's easy to know who's who.
7) Personal wiki pages (with discussion). So you can put information
about yourself, and general notes.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/3] Fixes bug: git-svn: svn.pathnameencoding is not respected with dcommit/set-tree
From: Alexey Shumkin @ 2011-02-03 20:28 UTC (permalink / raw)
To: git
In-Reply-To: <20110104232029.GA15889@dcvr.yhbt.net>
Eric Wong <normalperson <at> yhbt.net> writes:
>
> Thomas Rast <trast <at> student.ethz.ch> wrote:
> > Zapped wrote:
> > > git-svn dcommit/set-tree fails when svn.pathnameencoding is set for native
OS encoding (e.g. cp1251
> for Windows) though git-svn fetch/clone works well
> >
> > I'll let Eric judge whether loading the encoding here is the right
> > fix, but here too the commit message states only what is broken, not
> > why you fixed it that way. Can you elaborate a bit?
> >
> > Also, this should be easy to cover with a test case, can you make one?
>
> I second Thomas's requests. I'm also a bit disappointed the original
> option is missing tests, especially since not many people are likely to
> use it.
>
Yes, I remember that, sorry, but I just have no enough time to get
into git tests and make my own ones.
^ permalink raw reply
* Re: [msysGit] [PATCH 4/4] t5526: avoid dependency on submodule order
From: Johannes Schindelin @ 2011-02-03 20:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Pat Thoyts, msysgit, Git Mailing List, Junio C Hamano
In-Reply-To: <201102032108.54811.j6t@kdbg.org>
Hi,
On Thu, 3 Feb 2011, Johannes Sixt wrote:
> On Donnerstag, 3. Februar 2011, Pat Thoyts wrote:
> > +test_cmp_unordered() {
> > + grep --line-regexp -f "$@" >&3
> > +}
>
> I don't think that this is sufficiently portable.
>
> Furthermore, just like Dscho, I'd rather prefer to know why the output
> is not ordered as expected.
Have you seen my response where I proved that it is a fflush() issue, most
likely with mingw_spawn()?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Johannes Sixt @ 2011-02-03 20:17 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Joshua Jensen
In-Reply-To: <1296751106-15316-1-git-send-email-pclouds@gmail.com>
On Donnerstag, 3. Februar 2011, Nguyễn Thái Ngọc Duy wrote:
> Commit 21444f1 (Add case insensitivity support when using git ls-files
> - 2010-10-03) teaches match_pathspec() to ignore case when
> core.ignorecase=true.
>
> match_pathspec_depth() is developed independently and does not have
> this feature. Teach it.
Is match_pathspec_depth() used to match names of files on the filesystem, or
names of files in the index or in the repository?
core.ignorecase should be honored only when files on the filesystem are
matched, IMO.
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH 4/4] t5526: avoid dependency on submodule order
From: Johannes Sixt @ 2011-02-03 20:08 UTC (permalink / raw)
To: Pat Thoyts; +Cc: msysgit, Git Mailing List, Junio C Hamano
In-Reply-To: <1296747105-1663-5-git-send-email-patthoyts@users.sourceforge.net>
On Donnerstag, 3. Februar 2011, Pat Thoyts wrote:
> +test_cmp_unordered() {
> + grep --line-regexp -f "$@" >&3
> +}
I don't think that this is sufficiently portable.
Furthermore, just like Dscho, I'd rather prefer to know why the output is not
ordered as expected.
I'm fine with the other patches as well.
A side note regarding SYMLINKS: It's actually possible to remove 70 of the 130
SYMLINKS checks from the test suite:
http://repo.or.cz/w/git/mingw/j6t.git/shortlog/refs/heads/war-on-symlinks
-- Hannes
^ permalink raw reply
* Re: git to p4 conversion
From: Endre Czirbesz @ 2011-02-03 19:50 UTC (permalink / raw)
To: Ian Wienand; +Cc: git@vger.kernel.org
In-Reply-To: <4D4AF29E.7070509@vmware.com>
Hello Ian,
Thanks for your reply.
2011/2/3 Ian Wienand <ianw@vmware.com>:
> What exactly did you try?
I am not at my work computer now, but as I remember:
cd workdir
git-p4 clone //depot/projectdir/...@all .
git clone myprojectrepo .
(Everything went fine till this point.)
git-p4 sync
git-p4 submit
Fatal error...
I don't remember the exact message, but it tried to reach a
non-existing git commit (HEAD~xx, where xx was count of my commits, so
it tried to refer to a commit before my initial commit).
I tried to change the order of the clone steps, but the result was the same.
Rgds,
Endre
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Sverre Rabbelier @ 2011-02-03 19:06 UTC (permalink / raw)
To: Jeff King
Cc: J.H., Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano,
git
In-Reply-To: <20110203174518.GA14871@sigill.intra.peff.net>
Heya,
On Thu, Feb 3, 2011 at 18:45, Jeff King <peff@peff.net> wrote:
> Most of us don't really care if git is the ultimate storage mechanism. I
> could even build the git interface as a purely client thing on top of
> the CGI interface; the problem is that scraping the wiki pages for new
> versions over the net would be horribly inefficient.
Note that MediaWiki has a stable API that you could use instead :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [1.8.0] Support quoting in .gitattributes, .gitignore
From: Junio C Hamano @ 2011-02-03 19:03 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <AANLkTikHNKmcapVWBAcufq8ONVWOWHbnL-H8Nf2WmKM5@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Migration plan:
>
> I think a release note mentioning this is enough. No migration needed.
>
> But to be safe, we can make post-1.7.5 warn users about patterns with
> leading double quote. By 1.8.0, the new behavior will be used.
That's obviously not a migration plan, and it is worse than not having the
warning at all. People with paths that begin with dq (which I suspect
would be an empty set) will get wraning every time they do anything with
git, and until 1.8.0 there is no way to turn that warnings off without
breaking their pattern (like removing the entry from the attributes file),
and when 1.8.0 comes their patterns will break.
How about introducing a new feature in .gitattributes file so that the
parser can tell if the file is (1) written pre-1.7.5 that depends on the
old behaviour, (2) written post-1.7.5 by a person who is aware of the dq
convention, but still relying on the old behaviour, (3) written post-1.7.5
to take advantage of the new behaviour? E.g., you can explicitly mark
your .gitattributes file by putting "# feature: no-cq-pattern" as the
first line that the patterns in the file relies on the traditional
behaviour, or "# feature: cq-pattern" to cause the parser to interpret
cquoted patterns, and the last 1.7.x will warn if a file does not have
this explicit marking, but has a pattern that would change the behaviour.
Then 1.8.0 would flip the default.
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Eugene Sajine @ 2011-02-03 18:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George Spelvin, git
In-Reply-To: <alpine.LFD.2.00.1102030036420.12104@xanadu.home>
On Thu, Feb 3, 2011 at 1:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Tue, 1 Feb 2011, George Spelvin wrote:
>
>> For what it's worth, I don't see the "cleanup".
>>
>> If it significantly reduced the size of the largest directory,
>> that would be a win. But moving everything into src/ doesn't
>> do that.
>>
>> If there's a way to divide the source into cohesive subunits, that
>> would be great. A programmer could ignore whole subdirectories
>> when working on something.
>>
>> But just moving the whole existing pile into a subdirectory "because
>> everyone else does it" is not a reason; that's superstition.
>
> There is no superstition here, simply basic elegance.
>
> When you pick up a book from a shelf, do you see the actual content of
> the book printed right from the inside of the cover page, and the table
> of content tossed in the margin? Would you construct a book yourself
> that way?
>
> A nice source tree should be organized with a minimum of hierarchical
> structure. To a newbie wanting to contribute to Git, it is rather
> frightening to cd into the git directory and see that ls generates more
> than 280 entries. That simply looks sloppy. And this gets much worse
> after a make.
>
> The top directory should make different things stand out much more
> clearly, like a preface and a table of content. You have the
> documentation here, the source there, the tests there, a clearly visible
> README file, etc. If the src directory has about the same relative
> number of files after a move that's fine. At least you should expect
> _only_ source files in there (and possibly their by-products), and not
> other types of data buried into the mix.
>
>> Having to type "src/" a lot more often is definitely a downside.
>
> Come on. This is a rather egocentric argument without much substance.
>
>> Heck, that's one thing I actively dislike about GNU autoconf conventions.
>
> This has _nothing_ about any autoconf convention. GNU autoconf requires
> stupid things like having a bunch of files such as CREDITS, INSTALL,
> CHANGELOG, and other whatnots even if you have nothing to put in them,
> in which case they still have to be there but empty. It also dictates
> the exact name your directories must have, etc.
>
> I'm not proposing a tree reorganization because GNU autoconf commands
> it, but rather because this is a sensible thing to do.
>
>> If there's a compelling reason to change, could someone please describe it?
>
> It's about the third time I'm putting forward arguments for this.
> Please see the list archive.
>
> P.S. the netiquette on busy mailing lists recommends that you preserve
> all the email addresses that were listed as recipients on the message
> you reply to. That would be highly appreciated.
>
>
> Nicolas
> --
> 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
>
I'm not a hacker, but a user who had sometimes peeked into the git
sources. Unbelievable mess... Impossible to see the structure in
command line interface.
I totally agree with Nicolas here.
Folders were invented for a reason.
IMHO
src for source code
build for build by-products
tests for tests
Come on, give us some love, please!;)
Thanks,
Eugene
^ permalink raw reply
* Re: git to p4 conversion
From: Ian Wienand @ 2011-02-03 18:23 UTC (permalink / raw)
To: Endre Czirbesz; +Cc: git@vger.kernel.org
In-Reply-To: <AANLkTi=0TSD6p7WtsVzx=pq8=GVu+jHUdxt1bnC++CT+@mail.gmail.com>
On 03/02/11 05:52, Endre Czirbesz wrote:
> I have some small (and flat) git repos, which I would like to migrate
> into a perforce depot keeping their histories. I tried git-p4 without
> any success, and I did not find a good manual for it.
What exactly did you try?
Theoretically, you could clone your new, empty, company-mandated p4
tree into a fresh git repo, get your existing code onto a new branch
in this fresh repo (it's already in git, right, so that should be
easy), then use 'git-p4 submit' to submit that branch back to p4.
> Is there any step-by-step tutorial out there? Is there any living human
> who ever made a successful conversion in this direction?
I'm not aware of an existing tutorial for this, sorry
-i
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Andreas Schwab @ 2011-02-03 18:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George Spelvin, git
In-Reply-To: <alpine.LFD.2.00.1102030036420.12104@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> This has _nothing_ about any autoconf convention. GNU autoconf requires
> stupid things like having a bunch of files such as CREDITS, INSTALL,
> CHANGELOG, and other whatnots even if you have nothing to put in them,
> in which case they still have to be there but empty. It also dictates
> the exact name your directories must have, etc.
That's automake, not autoconf (and only the default automake operation).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Jeff King @ 2011-02-03 17:45 UTC (permalink / raw)
To: J.H.; +Cc: Vincent Hanquez, Jay Soffian, Scott Chacon, Junio C Hamano, git
In-Reply-To: <4D4A11D7.4040103@eaglescrag.net>
On Wed, Feb 02, 2011 at 06:24:23PM -0800, J.H. wrote:
> On 02/02/2011 01:55 AM, Vincent Hanquez wrote:
> > On 01/02/11 22:48, J.H. wrote:
> >> The wiki will almost universally have a "central site" no matter what
> >> the backend. Personally I see little advantage to having a git backed
> >> wiki myself.
> > with git based wiki, you can clone the whole wiki on your local machine,
> > and read/edit/commit on it locally using standard editor tool (i.e.
> > $EDITOR). and the history/revision/diff is completely built-in.
>
> That would be fine for things like source code or documentation, but you
> end up with a single person who would need to merge / push things to a
> central location, a-la git.wiki.kernel.org. You are now taking
> something, that is already editable by anyone, and making it only
> editable by a single person.
I don't think it makes sense to use the same workflow for the wiki as
git.git itself uses. The point of having a wiki is to keep the barrier
to editing extremely low; the point of source code control is to keep
the quality of contributions high.
But that doesn't mean they can't be accessed by the same tool.
Forget about a git-backed wiki for a moment, and imagine a regular old
Mediawiki. What are the operations you can perform? You can look at
the current or any past version of a page, you can do diffs between
versions of pages, and you can create a new version of a page. All
through some CGI forms.
So what stops us from replacing the CGI interface with a git one (or
adding it alongside)? Given the ability to retrieve current and past
versions of all pages, I could surely build a git repository of the
whole wiki (and update it incrementally as new edits were made). And
pushing a set of commits is just a sequential series of page edits, no?
And I think that would be enough for the purposes of this discussion.
Most of us don't really care if git is the ultimate storage mechanism. I
could even build the git interface as a purely client thing on top of
the CGI interface; the problem is that scraping the wiki pages for new
versions over the net would be horribly inefficient.
But the point is that accessing the wiki via git is not about changing
the wiki workflow. It's about providing a richer set of tools for doing
those page views, diffs, and edits.
Getting back to git as the actual backend:
> You also have a scalability problem. Git is *VERY* memory and i/o
> intensive. While you basically have a cache of data that is static (the
> basic pages you are viewing) things like the history, edits, etc can be
> quite expensive to generate.
Sure. But is that any worse than running gitweb, which you already do?
Or a site like GitHub, which basically is just running git constantly on
a bunch of repos? Or how much worse is it than running regular wiki
software? I mean, Foswiki is backed by RCS, for god's sake. Surely git
is more efficient than that. ;)
If it sounds like I'm handwaving away scalability problems, I am. I'd be
curious to see some performance numbers for gollum or ikiwiki versus
more traditional wiki formats.
> Think about a site, we'll use git.wiki.kernel.org, where it's not
> running on a single machine, but a cluster of machines (how many web
> infrastructures, including git.wiki.kernel.org run) and now you have a
> problem of an edit happens and commits on node3, a different conflicting
> edit happens on node9 and when those try to merge - you get conflicts.
Don't you have the same problem with a regular wiki? Or with stock git
repos, for that matter? You need database consistency.
-Peff
^ permalink raw reply
* Narrow clone (Re: features from GitSurvey 2010)
From: Jonathan Nieder @ 2011-02-03 17:39 UTC (permalink / raw)
To: Geert Bosch
Cc: Nicolas Pitre, Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Dmitry S. Kravtsov, git
In-Reply-To: <FE2BDD68-9CFA-4CBB-9F66-32BE6CF3E174@adacore.com>
Geert Bosch wrote:
> These narrow clones are especially important for imports of unwieldy
> svn repositories where there is a large amount of unstructured
> branching.
Wouldn't a more careful import be a better solution to that problem?
Practically speaking, I'd rather work with an enormous svn repo like
that by using git-svn to extract subsets than with a botched import
that treats it as one huge (git-managed) project.
svn-all-fast-import, for example, has a fairly simple configuration
syntax allowing to extract whatever subrepositories are needed.
^ permalink raw reply
* Re: [PATCH] gitk: Honor encoding conversion in a sole place for all possible cases
From: Alexey Shumkin @ 2011-02-03 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <1296751353-8632-1-git-send-email-zapped@mail.ru>
> Still buggy on Cygwin 1.7: on a clear working copy shows
> non-latin named files as removed and not indexed
Oh! Fixed! The matter was in LC_ALL enviroment variable.
It is set in my cygwin.bat (or ~/.bashrc).
For some reason it is not set with bash when running "gitk" command
(moreover when I ran gitk with "%CYGPATH%\bin\wish84.exe %CYGPATH%\bin\gitk")
I set it in system environment. That fixes incorrect working copy
status detection.
^ permalink raw reply
* [PATCH] gitk: Honor encoding conversion in a sole place for all possible cases
From: Alexey Shumkin @ 2011-02-03 16:42 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin
Previously every bug concerning encoding conversion
was fixed with a particular patch in a particular line of code
(e.g. 1f2cecfd53137b76d39b2dcd7bcf7e918cd745b3)
regardless other similar situations.
This patch centralizes reencoding of displayed text
considering all the cases where non-latin encoding may be used:
filenames, submodule names, rename/copy files, diffs (hunks),
commits comparison
Also cleaned up global "diffencoding" variable
Tested on Cygwin 1.5 and Cygwin 1.7
Still buggy on Cygwin 1.7: on a clear working copy shows
non-latin named files as removed and not indexed
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
gitk | 24 ++++++++++--------------
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/gitk b/gitk
index 9cbc09d..1f9627d 100755
--- a/gitk
+++ b/gitk
@@ -5047,7 +5047,8 @@ proc dodiffindex {} {
proc readdiffindex {fd serial inst} {
global viewmainheadid nullid nullid2 curview commitinfo commitdata lserial
global vfilelimit
-
+ global gui_encoding
+
set isdiff 1
if {[gets $fd line] < 0} {
if {![eof $fd]} {
@@ -5069,6 +5070,9 @@ proc readdiffindex {fd serial inst} {
}
set fd [open $cmd r]
fconfigure $fd -blocking 0
+ if {$gui_encoding != {}} {
+ fconfigure $fd -encoding $gui_encoding
+ }
set i [reg_instance $fd]
filerun $fd [list readdifffiles $fd $serial $i]
@@ -7541,7 +7545,7 @@ proc getblobdiffs {ids} {
global ignorespace
global worddiff
global limitdiffs vfilelimit curview
- global diffencoding targetline diffnparents
+ global targetline diffnparents
global git_version currdiffsubmod
set textconv {}
@@ -7570,7 +7574,7 @@ proc getblobdiffs {ids} {
set diffnparents 0
set diffinhdr 0
set diffencoding [get_path_encoding {}]
- fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
+ fconfigure $bdf -blocking 0 -encoding $diffencoding -eofchar {}
set blobdifffd($ids) $bdf
set currdiffsubmod ""
filerun $bdf [list getblobdiffline $bdf $diffids]
@@ -7618,11 +7622,9 @@ proc setinlist {var i val} {
}
proc makediffhdr {fname ids} {
- global ctext curdiffstart treediffs diffencoding
+ global ctext curdiffstart treediffs
global ctext_file_names jump_to_here targetline diffline
- set fname [encoding convertfrom $fname]
- set diffencoding [get_path_encoding $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -7643,7 +7645,7 @@ proc getblobdiffline {bdf ids} {
global diffnexthead diffnextnote difffilestart
global ctext_file_names ctext_file_lines
global diffinhdr treediffs mergemax diffnparents
- global diffencoding jump_to_here targetline diffline currdiffsubmod
+ global jump_to_here targetline diffline currdiffsubmod
global worddiff
set nr 0
@@ -7655,7 +7657,6 @@ proc getblobdiffline {bdf ids} {
}
if {![string compare -length 5 "diff " $line]} {
if {![regexp {^diff (--cc|--git) } $line m type]} {
- set line [encoding convertfrom $line]
$ctext insert end "$line\n" hunksep
continue
}
@@ -7715,7 +7716,6 @@ proc getblobdiffline {bdf ids} {
} elseif {![string compare -length 2 "@@" $line]} {
regexp {^@@+} $line ats
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
if {[regexp { \+(\d+),\d+ @@} $line m nl]} {
set diffline $nl
@@ -7745,11 +7745,9 @@ proc getblobdiffline {bdf ids} {
}
} elseif {![string compare -length 3 " >" $line]} {
set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" dresult
} elseif {![string compare -length 3 " <" $line]} {
set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" d0
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
@@ -7757,7 +7755,6 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
- set fname [encoding convertfrom $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -7779,8 +7776,7 @@ proc getblobdiffline {bdf ids} {
$ctext insert end "$line\n" filesep
} else {
- set line [string map {\x1A ^Z} \
- [encoding convertfrom $diffencoding $line]]
+ set line [string map {\x1A ^Z} $line]
# parse the prefix - one ' ', '-' or '+' for each parent
set prefix [string range $line 0 [expr {$diffnparents - 1}]]
set tag [expr {$diffnparents > 1? "m": "d"}]
--
1.7.4
^ permalink raw reply related
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