* Re: jgit and ignore
From: Ferry Huberts (Pelagic) @ 2009-03-04 17:50 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, Tor Arne Vestbø, Git Mailing List
In-Reply-To: <200903012124.46600.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> Shawn writes:
>> Tor Arne Vestbø <torarnv@gmail.com> wrote:
>>> To me that means that EGit should focus just as much on integrating with
>>> Eclipse properly as it does on keeping command line porcelain
>>> interoperability.
>> Yup, I agree completely. I think Robin would too.
> 100% (or close).
>
Hey guys
I'm currently refactoring the code to accomodate all of your wishes and
I've already come a long way.
==> The one thing that I still need to do is get to the global
core.excludefile setting. How can I do that?
How will it work? Read on... :-)
Suppose we have FILE in DIRECTORY and we want to see whether FILE is
ignored. (FILE can ofcourse also be a DIR)
The way in which ignores will be evaluated is:
1- See if there is a .gitignore file in DIRECTORY. if so, try to match.
when a match is found: FILE is ignored. if there is no .gitignore file or
when no match is found: go one directory up (towards the checkout
root/workdir) and repeat until a match is found or until the .gitignore in
the checkout root/workdir has been evaluated.
2- use the patterns from .git/info/exclude (if exists) and try to match.
when a match is found: FILE is ignored.
3- use the patterns from .git/config:core.excludesfile (when set) and try
to match. when a match is found: FILE is ignored.
4- when .git/config:core.excludesfile was not set, use the patterns from
global:core.excludesfile (when set) and try to match. when a match is
found: FILE is ignored.
5- try to match against the Eclipse global Team ignores. when a match is
found: FILE is ignored.
6- FILE is not ignored
hope this flow is what you want :-)
Ferry
^ permalink raw reply
* Re: [PATCH] Make the 'lock file exists' error more informative
From: Junio C Hamano @ 2009-03-04 17:55 UTC (permalink / raw)
To: Matthieu Moy; +Cc: John Tapsell, git
In-Reply-To: <vpqvdqpb7w6.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> John Tapsell <johnflux@gmail.com> writes:
>
>> It looks like someone did 90% of the work, then forgot to actually use
>> the function
>
> someone = me ;-).
>
> The message is a bit inacurrate: the function is already used in two
> places, I just didn't notice this one.
>
>> - if (errno == EEXIST) {
>> + if (err == EEXIST) {
>
> Oops, right.
>
>> - die("unable to create '%s.lock': %s", path, strerror(errno));
>> + unable_to_lock_index_die(path, errno);
>
> Actually, _this_ instance is still to be fixed in next. You probably
> looked at the other one that my original message fixes.
Not in 'next', but in the maintenance track of v1.6.2.X and merged
upwards, as v1.6.2~11^2~2 (More friendly message when locking the index
fails., 2009-02-19) is obviously in v1.6.2 just released.
John, congratulations for fixing the first bug immediately after a big
release. Please make it a habit to sign off your patches.
^ permalink raw reply
* Re: git as backup/DRP; also meta-question about Majordomo
From: Damon Getsman @ 2009-03-04 17:56 UTC (permalink / raw)
To: git
In-Reply-To: <274eb6f0903040951g27cb4956u1d101c84952d0090@mail.gmail.com>
Hello! :) I've got a couple of questions for y'all.
Q1: First of all, I'm being handed a project whereas I am to find and
implement some sort of backup system across a wide range of various
Linux hosts and a couple of windows machines. This backup system is
to basically be a 'pseudo-TimeVault' if you're familiar with Mac
OS/X's current backup system. I need to be able to roll back to any
particular revision.
A few of my first thoughts were pretty primitive, and included
basically doing periodic compressed tarballs with a rotator to make
sure that I don't run out of available space. These would hold the
commonly changing and most important data while a one time master
backup would hold the system configuration, etc, etc, so that
basically I could create a minimal install on a clone of the same
machine, throw on the master backup, then the most recent data, and
call it done. obviously this is an obtuse method for doing so; it is
also the method that we're trying to get away from as my predecessor
was using an even dumber version of the same scheme.
When I started digging, it seemed that 'svn' or 'git' might work
well, if able to handle binaries, and definitely for systemwide
configuration areas such as /etc. Finding git+etckeeper was a
treasure, especially as I realized that svn wasn't able to hold
anything binary at all. I'm working right now on implementing
etckeeper for system configuration repositories, but this still leaves
a large portion of what I'd like to work with to the 'dumb tarball'
scheme.
Since I've come in today I've run across a few blog articles that
seem to indicate that git + some customization might be able to handle
a larger portion of this for me, thus simplifying what I am trying to
do:
* http://eigenclass.org/hiki/gibak-backup-system-introduction <-
this link is a prime example
Does anybody have any resources or personal tips from utilizations
that they're working with to share? I'd be very much appreciative for
anything that can assist me in finding out exactly what I can deploy
and, obviously, the howtos (if they exist) for such a scheme.
Personal experience in the same areas would be great to hear, too.
Thanks in advance on that one!
Q2: I haven't found any way to tell the 'majordomo' mailing list
software running this list that I am not happy receiving 40-60 emails
in my business email inbox per day. Of course I can use google to
filter them, but I'd still rather just get a daily digest if this is
at all possible. Am I missing something obvious?
TIA again.
----------
Damon Getsman
-=-=-=-
ITRx http://www.itrx-nd.com/
Programmer/IT Customer Relations/Sys Admin
-=-=-=-
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Theodore Tso @ 2009-03-04 17:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0903031118280.6399@intel-tinevez-2-302>
On Tue, Mar 03, 2009 at 11:39:16AM +0100, Johannes Schindelin wrote:
> Only in this case, I would rephrase it to: "Is a usability wart really
> serious when the guy does not even bother to report it where it can be
> fixed?"
>
> It is much harder work to come up with solutions, and that is what I am
> interested in. So I'll try very hard to ignore everything else.
Well, I think there is a point hiding behind all of his whining, which
is that if you aren't joining a big established project, but are
rather the maintainer of an existing project that wants to move over
to git, or someone who is starting a new project, and decides to use
git because they've heard it's all the rage --- but the tutorials and
the documentation don't do that great of a job pointing people to the
right place.
For example, the git tutorial's "Using got for collaboration" assumes
that Alice and Bob have accounts on the same system. C'mon!
Time-sharing systems are so.... 1970's. Granted that arranging SSH
access is non-trivial, but there are plenty of web sites that offer
free git hosting services: repo.or.oz, gitorious, Github, and now
Sourceforge. The tutorial should at least point people at the git
hosting sites.
One of the advantages that bzr has is that it is integrated fairly
tightly with Launchpad, which has its own bzr hosting service. So the
documentation is easier, and with Launchpad's integration into bzr's
UI, a bzr user can publish a branch in a single command line (assuming
they are a registered launchpad user and have an account on launchpad):
bzr push lp:~userid/project-name/branch-name
It's going to be hard for git to be able to match this usability,
given that we need to do something that works with multiple hosting
facilities, and not just tie ourselves to a single system like
gitorious, Github, or Sourceforge. (Although I could imagine some
kind of plugin/hook system where once the plugin for a particular git
hosting facility was installed, git could be much more tightly
integrated with a particular hosting service.)
At the very least, though, it should be relatively easy to update our
documentation to at least acknowledge the many and varied free git
hosting services; it's not like we need to tell people that the only
way to share repositories involves setting up an ssh or Apache server.
- Ted
P.S. For more details about the bzr/Launchpad integration, see:
http://doc.bazaar-vcs.org/bzr.dev/en/tutorials/using_bazaar_with_launchpad.html
^ permalink raw reply
* Re: [RFC/PATCH 1/2] improve missing repository error message
From: Shawn O. Pearce @ 2009-03-04 18:57 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20090304083229.GA31798@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> Certain remote commands, when asked to do something in a
> particular directory that was not actually a git repository,
> would say "unable to chdir or not a git archive". The
> "chdir" bit is an unnecessary detail, and the term "git
> archive" is much less common these days than "git repository".
>
> So let's switch them all to:
>
> fatal: '%s' does not appear to be a git repository
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> On Tue, Mar 03, 2009 at 10:41:06AM -0800, Shawn O. Pearce wrote:
>
> > IMHO, maybe we also should change the error message that receive-pack
> > produces when the path its given isn't a Git repository. Its really
> > not very human friendly to say "unable to chdir or not a git archive".
> > Hell, we don't even call them archives, we call them repositories.
I really mean to write this patch myself, I haven't done much for
git lately. But I got sidetracked yesterday and forgot. Thank you
for doing it for me.
> Perhaps this should match the local "Not a git repository: %s". I prefer
> this text, but maybe there is value in consistency.
FWIW I also prefer the text you used in the patch...
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] make remote hangup warnings more friendly
From: Shawn O. Pearce @ 2009-03-04 19:04 UTC (permalink / raw)
To: Jeff King; +Cc: Theodore Tso, Junio C Hamano, git
In-Reply-To: <20090304084245.GB31798@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> When a user asks to do a remote operation but the remote
> side thinks the operation is invalid (e.g., because the user
> pointed to a directory which is not actually a repository),
> then we generally end up showing the user two fatal
> messages: one from the remote explaining what went wrong, and
> one from the local side complaining of an unexpected hangup.
>
> For example:
>
> $ git push /nonexistent master
> fatal: '/nonexistent' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
> In this case, the second message is useless noise, and the
> user is better off seeing just the first.
>
> This patch tries to suppress the "hung up" message when it
> is redundant (but still exits with an error code, of
> course).
Hmm. It would be nice to clean up these messages, but I
think the better way to do it is...
> I think this would be improved somewhat with stderr processing to:
>
> remote: sh: bogus: command not found
... because then we can have positive proof that the remote said
something to the user, and we tagged it as being from the remote
side, just like we do with progress data in sideband, and then the
user can work from that information. Any local side errors are
very likely caused by the remote errors, so we shouldn't bother
displaying them.
But its a lot more invasive of a patch to setup stderr processing
for pipe/SSH.
Actually, the remote stderr processing is desired for more than
just the bad path case. Its good for when the remote aborts with
a write error from a write_or_die(), at least we know it was on
the remote side and not the local. Its good for when the remote
shell says a "git-upload-pack: command not found". Its good for
when the remote hook prints output, the client knows it came from
the remote side and not something local, so its messages should be
read in the context of the remote side. Etc.
--
Shawn.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-04 19:27 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840903031618s5e0b6f24j64aade8d752fb11@mail.gmail.com>
On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:
> On Tue, Mar 3, 2009 at 5:36 PM, Josef Wolf wrote:
> >
> > I'd rather not let every clone talk to subversion for several reasons.
> > One of them is that it is very inconvenient (e.g. the password has to
> > be entered several times for every commit).
>
> Sounds like subversion isn't properly caching your credentials, or
> your admin is paranoid and turned off the svn credential cache. I
> can't remember the last time I had to enter a password.
What credential cache are you talking about? I don't know of any
worth to be mentioned. If you talk about "store-passwords=yes" in
subversion's config or about the .netrc file that has to be used for
git, you might be interested to read
http://curl.haxx.se/docs/adv_20090303.html
If you know about another method, please tell me.
BTW: The paranoid admin is myself. ;-)
BTW1: I know there's the possibility of client certificates. But AFAIK,
there's no equivalent to ssh-agent, so it's pointless.
> Of course, git-svn-repo can't cache credentials, since it has to
> impersonate different users. You are impersonating different users so
> that the svn author field is correct, aren't you? But that shouldn't
> be a problem for userN working on cloneN.
Ah, that would have been one of my next questions (I don't like to start
new threads as long as old threads are on-going ;-)
Within svn, the author field seems to be correct (at least, it is
identical to those of the commits that were done directly to svn)
But when the commits come back to git, it is set to
"jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>" with the host-part being
the uuid of the svn-repo.
Any ideas how to fix that?
Oh, and what happens if svn's rev-properties (commit log, author, date...)
are changed?
> > After all, the whole point
> > for having git-svn-repos is for the clone to avoid working directly
> > against the subversion repos. If every clone works against subversion
> > anyway, I can get rid of git-svn-repos as well.
>
> From my perspective, the main advantage of git-svn-repos is the inital
> clone. Subversion is way too slow to clone an entire project's history
> (days, vs minutes for git). Subsequent 'git pull --rebase's are faster
> than 'git svn rebase's, too, although not by the same ratio (except
> for large subtree moves, which really are that much faster).
Of course, initial clone is an argument. But you do this exactly once
per clone. And you can do that unattended over the weekend.
In contrast, working directly against an svn repository is _very_
tedious. With a dozen commits pending, you have to enter your password
about 30..50 times in "git svn dcommit". While you can run the initial
clone unattended over the weekend, there's currently no (sensible) way
to avoid this massive interactive password hammering. And you have to
do that on every dcommit.
> > On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote:
> >> Also, this line says "rebase my changes onto those of ../clone$clone",
> >> which isn't what you want. It will end up rebasing svn commits that
> >> the client didn't have on top of the client's commits, and will break
> >> git-svn's index. Don't use --rebase here.
> >
> > Hmm, I must have misunderstood Michael, then. Wasn't he suggesting
> > to rebase here? Here's the citation:
> >
> > |> (cd git-svn-repos; git pull ../clone1) # if this line is executed,
> > |
> > |That's the problem. This creates a merge after which you 1-2-3-4 and
> > |1-2'-3'-4' plus the merge of 4 and 4'.
> > |
> > |Instead, use git pull --rebase here. You don't want merges in the branch
> > |from which you dcommit.
>
> I think he meant to say "git pull ../cloneN && git rebase trunk".
Did you mean "git pull ../cloneN && git rebase master"? There's no
trunk in git, AFAIK?
So here's my current idea about the work flow. At the end of this mail,
I've attached the whole test-script again. But this time, I have
extracted the main tasks
1. work on some clones
2. move commits from clone to subversion
3. move commits received from subversion to clone
to make them more self-contained. Ideally, those three tasks would
be packed into shell functions or something...
# 1. work on some clones
#
cd clone$clone
git checkout master
git pull --rebase # need rebase?
git checkout -b topic-branch
for commit in 1 2 3; do
echo change $clone $commit >>test
git commit -a -m "commit $clone $commit"
done
# 2. move commits from clone to subversion
#
cd git-svn-repos
git svn rebase
git pull ../clone$clone topic-branch # need rebase?
# Check for conflict and pretend we have resolved it
grep change test >test.resolved
if diff test test.resolved ; then
rm test.resolved
else
mv test.resolved test
git add test
git commit -m "merge"
fi
git svn dcommit
# 3. move commits received from subversion to clone
#
cd clone$clone
git checkout master
git pull # need rebase?
git branch -D topic-branch
This work flow seems to generate a proper result and a sensible history.
But I am still not sure about when (and how) I have to rebase. I have
marked the lines in question with "#need rebase?".
#! /bin/sh
(
set -x
# create test directory
#
TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
rm -rf $TESTDIR
mkdir -p $TESTDIR
cd $TESTDIR
SUBVERSION_REPOS=file://`pwd`/subversion-repos
# create subversion repos with some history
#
svnadmin create subversion-repos
svn -m "create standard layout" mkdir \
$SUBVERSION_REPOS/trunk \
$SUBVERSION_REPOS/branches \
$SUBVERSION_REPOS/tags
svn co $SUBVERSION_REPOS/trunk subversion-wc
echo change1 >>subversion-wc/test
svn add subversion-wc/test
svn ci -m "commit 0" subversion-wc
# create git-svn-repos
#
git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
(cd git-svn-repos; git svn fetch)
# create some clones
#
git clone git-svn-repos clone1
git clone git-svn-repos clone2
git clone git-svn-repos clone3
for round in 1 2 3; do
for clone in 1 2 3; do
# work on clone
#
(
cd clone$clone
git checkout master
git pull --rebase
git checkout -b topic-branch
for commit in 1 2 3; do
echo change $round $clone $commit >>test
git commit -a -m "commit $round $clone $commit"
done
)
# move commits from clone to subversion
#
(
cd git-svn-repos
git svn rebase
git pull ../clone$clone topic-branch
grep change test >test.resolved
# Check for conflict and pretend we have resolved it
if diff test test.resolved ; then
rm test.resolved
else
mv test.resolved test
git add test
git commit -m "merge"
fi
git svn dcommit
)
# move commits from subversion to clone
(
cd clone$clone
git checkout master
git pull
git branch -D topic-branch
)
done
# commit from svn
#
(
cd subversion-wc
svn up
echo change $round s >>test
svn ci -m "commit $round s"
)
done
)
^ permalink raw reply
* RE: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: John Dlugosz @ 2009-03-04 19:34 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903041151440.8926@perkele.intern.softwolves.pp.se>
===Re:===
Yes, but I am unsure whether it [UTF-8] can be set as a thread locale
for the sake
of file APIs.
===end===
Why wouldn't it? If the ANSI forms simply allocate buffers and call
WideCharToMultiByte and MultiByteToWideChar, it should work with
anything those functions handles. My only concern would be with buffer
length when converting to MultiByte, if it assumes a limit based on 2
bytes max per character. But, it works with GB18030, which can have
4-byte characters.
It's certainly easy enough to try.
===Re:===
Yeah, but unfortunately it [GB18030] is explicitly documented that it is
only
supported in MultiByteToWideChar, WideCharToMultiByte and some text
painting
APIs in Windows, i.e the stdio functions and others may break horribly.
===end===
Code that works with the other multi-byte "ANSI" character sets, and GBK
in particular, will handle GB18030 "reasonably well" with no changes.
For example, printf ("xxx%sxxx", name), where each 'x' may actually be
any character, will work without problems -- it won't mis-identify the %
in the middle of a 4-byte character. But printf ("%5s",name) will count
some of the characters in 'name' as two, and print less than 5 of them;
or worse yet, break a character in half.
I can't think of anything that breaks horribly. Only situations that
involve counting them will have issues.
As empirical evidence, lots of Windows software works fine in China.
You need full GB18030 support to read a newspaper on the web, because
the 4-byte characters are mostly obscure and regional words, but also
proper nouns including the names of some prominent people (Prime
Minister or something like that; I don't remember exactly). But mostly
you don't encounter them and chug along with GBK and the occasional '?'
where some character did not work.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: git as backup/DRP; also meta-question about Majordomo
From: Jay Soffian @ 2009-03-04 19:36 UTC (permalink / raw)
To: Damon Getsman; +Cc: git
In-Reply-To: <274eb6f0903040956t36580a8ayd269f74882724637@mail.gmail.com>
On Wed, Mar 4, 2009 at 12:56 PM, Damon Getsman <dgetsman@amirehab.net> wrote:
> Hello! :) I've got a couple of questions for y'all.
>
> Q1: First of all, I'm being handed a project whereas I am to find and
> implement some sort of backup system across a wide range of various
> Linux hosts and a couple of windows machines. This backup system is
> to basically be a 'pseudo-TimeVault' if you're familiar with Mac
> OS/X's current backup system. I need to be able to roll back to any
> particular revision.
I think you may want something more like
http://www.mikerubel.org/computers/rsync_snapshots/
You're going to run into issues with git if you have to store very
large files. Also, if you need to delete a file from the backups for
some reason, you may find it more difficult than you'd like (you have
to use filter-branch and rewrite history).
I'm not saying it cannot be done with git, but you'll be using it for
a purpose for which it was not intended.
You might also consider a filesystem which offers snapshots.
> Q2: I haven't found any way to tell the 'majordomo' mailing list
> software running this list that I am not happy receiving 40-60 emails
> in my business email inbox per day. Of course I can use google to
> filter them, but I'd still rather just get a daily digest if this is
> at all possible. Am I missing something obvious?
vger.kernel.org does not offer its lists in digested form. You can try
reading the git mailing list via
http://dir.gmane.org/gmane.comp.version-control.git,
http://marc.info/?l=git, or consider signing up for a webmail account.
j.
^ permalink raw reply
* Re: [PATCH] Clarify the "cannot lock existing info/refs" error
From: Clemens Buchacher @ 2009-03-04 19:28 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <1236181026-15385-1-git-send-email-johnflux@gmail.com>
On Wed, Mar 04, 2009 at 03:37:06PM +0000, John Tapsell wrote:
> -fprintf(stderr, "Error: cannot lock existing info/refs\n");
> +error("cannot lock existing info/refs on remote server\nPerhaps the
> server is currently busy, or your ~/.netrc file is not configured
> correctly.");
In my experience this is usually caused by http-push crashing and leaving
stale locks behind until it times out after 10 minutes. I don't think we
should speculate here unless we can narrow down the error condition.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2009-03-04 19:52 UTC (permalink / raw)
To: git
Welcome to git community.
This message talks about how git.git is managed, and how you can work
with it.
* IRC and Mailing list
Many active members of development community hang around on #git
IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
The development however is primarily done on the git mailing list
(git@vger.kernel.org). If you have patches, please send them to the
list, following Documentation/SubmittingPatches.
I usually try to read all patches posted to the list, and follow
almost all the discussions on the list, unless the topic is about an
obscure corner that I do not personally use. But I am obviously not
perfect. If you sent a patch that you did not hear from anybody for
three days, that is a very good indication that it was dropped on the
floor --- please do not hesitate to remind me.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one.
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man". The first one was meant
to contain TODO list for me, but I am not good at maintaining such a
list and it is in an abandoned state. The branch mostly is used to
keep some helper scripts I use to maintain git and the regular "What's
in/cooking" messages these days.
The "html" and "man" are autogenerated documentation from the
tip of the "master" branch; the tip of "html" is extracted to be
visible at kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has
links to documentation of older releases.
The script to maintain these two documentation branches are
found in "todo" branch as dodoc.sh, if you are interested. It
is a good demonstration of how to use a post-update hook to
automate a task.
There are four branches in git.git repository that track the
source tree of git: "master", "maint", "next", and "pu". I may
add more maintenance branches (e.g. "maint-1.5.4") if we have
hugely backward incompatible feature updates in the future to keep
an older release alive; I may not, but the distributed nature of
git means any volunteer can run a stable-tree like that herself.
The "master" branch is meant to contain what are very well
tested and ready to be used in a production setting. There
could occasionally be minor breakages or brown paper bag bugs
but they are not expected to be anything major, and more
importantly quickly and trivially fixable. Every now and
then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The
last such release was 1.6.2 done on Mar 3rd 2009. You
can expect that the tip of the "master" branch is always more
stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off
from "master" at that point. Obvious, safe and urgent fixes
after a feature release are applied to this branch and
maintenance releases are cut from it. The maintenance releases
are named with four dotted decimal, named after the feature
release they are updates to; the last such release was 1.6.1.3.
New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master".
A new development, either initiated by myself or more often by
somebody who found his or her own itch to scratch, does not
usually happen on "master", however. Instead, a separate topic
branch is forked from the tip of "master", and it first is
tested in isolation; I may make minimum fixups at this point.
Usually there are a handful such topic branches that are running
ahead of "master" in git.git repository. I do not publish the
tip of these branches in my public repository, however, partly
to keep the number of branches that downstream developers need
to worry about low, and primarily because I am lazy.
The quality of topic branches are judged primarily by the mailing list
discussions. Some of them start out as "good idea but obviously is
broken in some areas (e.g. breaks the existing testsuite)" and then
with some more work (either by the original contributor's effort or
help from other people on the list) becomes "more or less done and can
now be tested by wider audience". Luckily, most of them start out in
the latter, better shape.
The "next" branch is to merge and test topic branches in the
latter category. In general, the branch always contains the tip
of "master". It might not be quite rock-solid production ready,
but is expected to work more or less without major breakage. I
usually use "next" version of git for my own work, so it cannot
be _that_ broken to prevent me from pushing the changes out.
The "next" branch is where new and exciting things take place.
The two branches "master" and "maint" are never rewound, and
"next" usually will not be either (this automatically means the
topics that have been merged into "next" are usually not
rebased, and you can find the tip of topic branches you are
interested in from the output of "git log next"). You should be
able to safely track them.
After a feature release is made from "master", however, "next"
will be rebuilt from the tip of "master" using the surviving
topics. The commit that replaces the tip of the "next" will
usually have the identical tree, but it will have different ancestry
from the tip of "master". An announcement will be made to warn
people about such a rebasing.
The "pu" (proposed updates) branch bundles all the remainder of
topic branches. The "pu" branch, and topic branches that are
only in "pu", are subject to rebasing in general. By the above
definition of how "next" works, you can tell that this branch
will contain quite experimental and obviously broken stuff.
When a topic that was in "pu" proves to be in testable shape, it
graduates to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so
good and the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be tweaked and fixed to
perfection before it is merged to "master" (that's why "master"
can be expected to stay very stable). Similarly to the above, I
do it with this:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
Note that being in "next" is not a guarantee to appear in the
next release (being in "master" is such a guarantee, unless it
is later found seriously broken and reverted), nor even in any
future release. There even were cases that topics needed
reverting a few commits in them before graduating to "master",
or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed
changes should be sent. As described in contrib/README, I would
delegate fixes and enhancements in contrib/ area to the primary
contributors of them.
Although the following are included in git.git repository, they
have their own authoritative repository and maintainers:
- git-gui/ comes from Shawn Pearce's git-gui project:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the
current shape. Especially I would like to thank the git list
regulars whose help I have relied on and expect to continue
relying on heavily:
- Linus on general design issues.
- Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King and Johannes Sixt on general
implementation issues.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong on git-svn.
- Simon Hausmann on git-p4.
- Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta
on gitweb.
- J. Bruce Fields on documentation (and countless others for
proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- Charles Bailey for git-mergetool (and Theodore Ts'o for creating
the tool).
- Johannes Schindelin, Johannes Sixt and others for their effort
to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on
portability; especially, Randal Schwartz, Theodore Ts'o,
Jason Riedy, Thomas Glanzmann, Brandon Casey, but countless
others as well.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-03-04 22:06 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090304192752.GC11278@raven.wolf.lan>
On Wed, Mar 4, 2009 at 2:27 PM, Josef Wolf wrote:
> On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:
>>
>> Sounds like subversion isn't properly caching your credentials, or
>> your admin is paranoid and turned off the svn credential cache. I
>> can't remember the last time I had to enter a password.
>
> What credential cache are you talking about? I don't know of any
> worth to be mentioned. If you talk about "store-passwords=yes" in
> subversion's config
Yes, that's the one.
> you might be interested to read
> http://curl.haxx.se/docs/adv_20090303.html
Not really, since I use svn:// :-)
> BTW: The paranoid admin is myself. ;-)
> BTW1: I know there's the possibility of client certificates. But AFAIK,
> there's no equivalent to ssh-agent, so it's pointless.
I thought that this was already a part of svn, but it appears in the
1.6 (not quite final yet) release notes: "SSL client certificate
passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,
a Windows CryptoAPI encrypted form or in plaintext form."
> Within svn, the author field seems to be correct (at least, it is
> identical to those of the commits that were done directly to svn)
> But when the commits come back to git, it is set to
> "jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>" with the host-part being
> the uuid of the svn-repo.
>
> Any ideas how to fix that?
"git help svn" and look for "--authors-file", maybe. I don't use it
myself, so I'm afraid I can't help with that one. Personally, I don't
mind user@uuid. Plus, user@uuid is so obviously different from git's
standard format that it is immediately obvious to me which commits are
in svn, and which aren't, when running gitk.
> Oh, and what happens if svn's rev-properties (commit log, author, date...)
> are changed?
Too late. git svn will ignore the change to the history, since git
forces you to rewrite your entire history if any part changes. Cue
standard "log messages should [not] be mutable" flamewar.
Ah, here it is... <flamebait version>: Nothing happens. git will
correctly store your *true* log/author/date, ignoring any and all
attempts by malicious parties to destroy useful historical
information.
Of course, you're a paranoid admin, so you already have a
pre-revprop-change hook in your svn server that prevents
log/author/date changes. Right? ;-)
> In contrast, working directly against an svn repository is _very_
> tedious.
Tell me about it. Fortunately, we have git-svn to save us from the
default svn client. ;-)
(Sorry, couldn't resist pulling that one out of context)
> With a dozen commits pending, you have to enter your password
> about 30..50 times in "git svn dcommit".
Maybe svn 1.6 will fix that for you?
>> I think he meant to say "git pull ../cloneN && git rebase trunk".
>
> Did you mean "git pull ../cloneN && git rebase master"? There's no
> trunk in git, AFAIK?
If a local branch isn't found, git will automatically look in remotes,
so it will use remotes/trunk (the svn tracking branch). Modify to suit
if you renamed remotes/trunk, of course.
"git branch -r" to see the remote branches git-svn has set up for you.
I'm pretty sure I didn't mean to suggest a no-op. Assuming you git
pull'd into master, "git rebase master" will be a no-op. rebase "all
commits in (current branch) that aren't in master" -> set operation
(master - master = empty set) -> rebase (empty set) -> done.
> # 2. move commits from clone to subversion
> #
> cd git-svn-repos
> git svn rebase
> git pull ../clone$clone topic-branch # need rebase?
Yeah, a "git svn rebase -l" after this line wouldn't hurt, and is
suggested by "git help svn". Or even reverse those two lines, to save
adding a third:
git pull ../clone$clone topic-branch
git svn rebase
Alternatively, you can avoid potential pull conflicts by using a
temporary branch to avoid the merge you are about to throw away with
rebase -- remember that 'pull' is short for 'fetch && merge':
git fetch ../clone$clone topic-branch:scratch
git checkout scratch
git rebase trunk
git svn dcommit
git checkout master
git svn rebase -l # fast-forward master to where scratch is
git branch -d scratch
...which should result in seeing only the rebase conflict(s). And
ought to work if cloneN's topic-branch is on a different svn branch
from master (although you'd need to -D scratch instead of -d).
Peter Harris
^ permalink raw reply
* Re: [PATCH] git-clone.txt: document that pushing from a shallow clone may work
From: Adeodato Simó @ 2009-03-04 22:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jay Soffian, Johannes Sixt, git, Mikael Magnusson, Joey Hess
In-Reply-To: <7vvdqp5zx9.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Wed, 04 Mar 2009 02:45:54 -0800]:
> Isn't the rule more or less like:
> If your shallow repository's history does not extend long enough and
> the other repository forked before your truncated history, wyou cannot
> compute the common ancestor and you cannot push out.
Ah, this is helpful, thanks for it and for the rest of the message.
Would you take a patch to include this in the git-clone manpage, maybe
with an alternative wording? Eg.:
Pushing from a shallow repository is not supported, but works when
you're pushing to branches with a common ancestor in your available
history (so pushing to the remote HEAD should always work).
I *think* the sentence in brackets is correct; I put it there because in
my experience is a feature a lot of people around me want.(¹)
(¹) I realize this may seem odd, people with push access wanting to be
able to push from a shallow repository. In case somebody is interested
in the details, there's been discussion in the debian-python lists
about a possible move to Git. There currently exists a Subversion
repository with a lot of packages; many people with access just work
on a few of them, but do the typical random fix on others from time to
time. And some of them were concerned about downloading all history
for over a hundred of repositories. (Which was another of the
conflicting points, how it's very easy to download all the packages in
Subversion.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
dozens.
-- Michel de Montaigne
^ permalink raw reply
* [PATCH] git-p4: improve performance with large files
From: Sam Hocevar @ 2009-03-04 21:54 UTC (permalink / raw)
To: git
The current git-p4 way of concatenating strings performs in O(n^2)
and is therefore terribly slow with large files because of unnecessary
memory copies. The following patch makes the operation O(n).
Using this patch, importing a 17GB repository with large files
(50 to 500MB) takes 2 hours instead of a week.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
contrib/fast-import/git-p4 | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9fdb0c6..09e9746 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -990,11 +990,12 @@ class P4Sync(Command):
while j < len(filedata):
stat = filedata[j]
j += 1
- text = ''
+ data = []
while j < len(filedata) and filedata[j]['code'] in ('text', 'unicode', 'binary'):
- text += filedata[j]['data']
+ data.append(filedata[j]['data'])
del filedata[j]['data']
j += 1
+ text = "".join(data)
if not stat.has_key('depotFile'):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH] git-p4: improve performance with large files
From: thestar @ 2009-03-04 23:05 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090304215438.GA12653@zoy.org>
Quoting Sam Hocevar <sam@zoy.org>:
> The current git-p4 way of concatenating strings performs in O(n^2)
> and is therefore terribly slow with large files because of unnecessary
> memory copies. The following patch makes the operation O(n).
The reason why it uses simple concatenation is to cut down on memory usage.
- It is a tradeoff.
I think the modification you have made below is reasonable, however be
aware that memory usage could double, which substantially reduce the
size of the changesets that git-p4 would be able to import /at all/,
rather than to merely be slow.
That said, you do need to delete the data temporary array to cut down
on memory.
-- I would do this immediately after the "".join(data).
>
> Using this patch, importing a 17GB repository with large files
> (50 to 500MB) takes 2 hours instead of a week.
>
> Signed-off-by: Sam Hocevar <sam@zoy.org>
> ---
> contrib/fast-import/git-p4 | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 9fdb0c6..09e9746 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -990,11 +990,12 @@ class P4Sync(Command):
> while j < len(filedata):
> stat = filedata[j]
> j += 1
> - text = ''
> + data = []
> while j < len(filedata) and filedata[j]['code'] in
> ('text', 'unicode', 'binary'):
> - text += filedata[j]['data']
> + data.append(filedata[j]['data'])
> del filedata[j]['data']
> j += 1
> + text = "".join(data)
>
> if not stat.has_key('depotFile'):
> sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
> --
> 1.6.1.3
> --
> 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: [Orinoco-users] linux-firmware binary corruption with gitweb
From: Dave @ 2009-03-04 23:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Pavel Roskin, git, linux-kernel, orinoco-users, dwmw2
In-Reply-To: <m3iqmqt9ox.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Dave <kilroyd@googlemail.com> writes:
>>> My strong impression is that the recoding takes place on the server. I
>>> think the bug should be reported to the gitweb maintainers unless it a
>>> local breakage on the kernel.org site.
>> Thanks Pavel.
>>
>> I just did a quick scan of the gitweb README - is this an issue with the
>> $mimetypes_file or $fallback_encoding configurations variables?
>
> First, what version of gitweb do you use? It should be in 'Generator'
> meta header, or (in older gitweb) in comments in HTML source at the
> top of the page.
Not sure where I'd find the meta header, but at the top of the HTML:
<!-- git web interface version 1.4.5-rc0.GIT-dirty, (C) 2005-2006, Kay
Sievers <kay.sievers@vrfy.org>, Christian Gierke -->
<!-- git core binaries version 1.6.1.1 -->
> Second, the file is actually sent to browser 'as is', using binmode :raw
> (or at least should be according to my understanding of Perl). And *.bin
> binary file gets application/octet-stream mimetype, and doesn't send any
> charset info. git.kernel.org should have modern enough gitweb to use this.
> Strange...
Dug around gitweb.perl in the main git repo. Then looked at the
git/warthog9/gitweb.git repo (after noting the Git Wiki says kernel.org
is running John Hawley's branch).
One notable change to git_blob_plain:
undef $/;
binmode STDOUT, ':raw';
- print <$fd>;
+ #print <$fd>;
+ $output .= <$fd>;
binmode STDOUT, ':utf8'; # as set at the beginning of gitweb.cgi
$/ = "\n";
close $fd;
+
+ return $output;
If that's the code that's running, doesn't that mean the output mode
change doesn't impact the concatenation to $output? So the blob gets utf
encoding when actually printed.
Regards,
Dave.
^ permalink raw reply
* Re: [PATCH] git-clone.txt: document that pushing from a shallow clone may work
From: Junio C Hamano @ 2009-03-05 0:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Adeodato Simó, Jay Soffian, Johannes Sixt, git,
Mikael Magnusson, Joey Hess
In-Reply-To: <alpine.DEB.1.00.0903041209070.8549@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 4 Mar 2009, Junio C Hamano wrote:
>
>> Isn't the rule more or less like:
>>
>> If your shallow repository's history does not extend long enough and
>> the other repository forked before your truncated history, wyou cannot
>> compute the common ancestor and you cannot push out.
>
> Exactly.
Actually, come to think of it, it is a lot stronger than "cannot compute
the common".
The history may look like this:
R---R---R
/
--R---R---X---X---S---S---S
where S are the commits you have in your shallow repository, and R are the
commits that exist in the repository that receives your push. Because
your history is shallow, neither repository has 'X' that are the commits
that need to exist in order to keep the history of recipient repository
complete; the recipient is not shallow to begin with, and we do not want
to make it shallow.
If you cloned shallowly some time ago, worked without communicating with
the other side while the other side progressed, *AND* if the other side's
progress included a rewind & rebuild of the history, you would see a
similar topology. The leftmost 'S' in the above picture might have been
the tip of the branch when you shallowly cloned with depth 1, and since
then the remote end may have discarded topmost three commits and have
rebuilt its history that leads to the rightmost 'R'. In such a case
pushing to the remote's HEAD will fail.
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Junio C Hamano @ 2009-03-05 0:41 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <6d937a859ca499f534eea08720fca84f3d4ded2f.1236187259.git.barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Change the source code such that when USE_NSEC is not defined,
> possible nanosecond timestamps will still be saved in the index file,
> but not used inside if-test's, and will therefore not affect the
> outcome of GIT commands, other than the saved nanosecond timestamps in
> the index file.
>
> This will make it easier to use a system with 2 versions of GIT, one
> with and one without USE_NSEC defined.
I take it that you are responding to my earlier question with this patch?
From: Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH/RFC v2 2/3] make USE_NSEC work as expected
Date: Fri, 20 Feb 2009 00:35:35 -0800
Message-ID: <7vab8hfqug.fsf@gitster.siamese.dyndns.org>
Kjetil Barvik <barvik@broadpark.no> writes:
> diff --git a/read-cache.c b/read-cache.c
> index 940ec76..ca4bec2 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -67,8 +67,15 @@ void rename_index_entry_at(struct index_state *istate,..
> */
> void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
> {
> - ce->ce_ctime = st->st_ctime;
> - ce->ce_mtime = st->st_mtime;
> + ce->ce_ctime.sec = (unsigned int)st->st_ctime;
> + ce->ce_mtime.sec = (unsigned int)st->st_mtime;
> +#ifdef USE_NSEC
> + ce->ce_ctime.nsec = (unsigned int)st->st_ctim.tv_nsec;
> + ce->ce_mtime.nsec = (unsigned int)st->st_mtim.tv_nsec;
> +#else
> + ce->ce_ctime.nsec = 0;
> + ce->ce_mtime.nsec = 0;
> +#endif
How does this affect a use case where the same index file used with two
instances of git (one compiled with and another without USE_NSEC)?
^ permalink raw reply
* ignored files stilll listed in git ls-files
From: David Shen @ 2009-03-05 1:31 UTC (permalink / raw)
To: git
Hi,
I add all the files to git before I learned the .gitignore file. Then
I remove those unwanted files from the index. But those files still
appear in git ls-files. This is really annoying. Is there any want to
prevent those ignored files from git ls-files?
--
Best Regards,
David Shen
^ permalink raw reply
* Re: ignored files stilll listed in git ls-files
From: Boyd Stephen Smith Jr. @ 2009-03-05 1:41 UTC (permalink / raw)
To: git; +Cc: David Shen
In-Reply-To: <53e35fd50903041731v1a3c10c9sbb9295f322a819ce@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 556 bytes --]
On Wednesday 04 March 2009 19:31:55 you wrote:
> I add all the files to git before I learned the .gitignore file. Then
> I remove those unwanted files from the index. But those files still
> appear in git ls-files. This is really annoying. Is there any want to
> prevent those ignored files from git ls-files?
git filter-branch
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] http authentication via prompts
From: Mike Gaffney @ 2009-03-05 1:07 UTC (permalink / raw)
To: git
Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
With the old .netrc working, this patch provides backwards compatibility while adding a more secure option for users whose http password may be sensitive (such as if its a domain controller password) and do not wish to have it on the filesystem.
Signed-off-by: Mike Gaffney <mike@uberu.com>
---
Documentation/config.txt | 7 +++
Documentation/howto/setup-git-server-over-http.txt | 38 ++++++++++++++++--
http.c | 41 ++++++++++++++++++-
http.h | 2 +
4 files changed, 81 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f5152c5..821bf48 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -920,6 +920,13 @@ help.autocorrect::
value is 0 - the command will be just shown but not executed.
This is the default.
+http.username, http.password:
+ The username and password for http authentication. http.username is
+ required, http.password is optional. If supplied, the .netrc file will
+ be ignored. If a password is not supplied, git will prompt for it.
+ Be careful when configuring a password as it will be stored in plain text
+ on the filesystem.
+
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index 622ee5c..462a9d4 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -189,8 +189,19 @@ Make sure that you have HTTP support, i.e. your git was built with
libcurl (version more recent than 7.10). The command 'git http-push' with
no argument should display a usage message.
-Then, add the following to your $HOME/.netrc (you can do without, but will be
-asked to input your password a _lot_ of times):
+There are 2 ways to authenticate with git http, netrc and via the git config.
+The netrc option requires that you put the username and password for the connection
+in $HOME/.netrc. The configuration method allows you to specify a username and
+optionally a password. If the password is not supplied then git will prompt you
+for the password. The downside to the netrc method is that you must have your
+username and password in plaintext on the filesystem, albeit in a protected file.
+If the username/password combo is a sensitive one, you may wish to use the
+git config method. The downside of the config method is that you will be prompted
+for your password every time you push or pull to the remote repository.
+
+Using netrc:
+
+Using your favourite ext editor, add the following to your $HOME/.netrc:
machine <servername>
login <username>
@@ -204,7 +215,7 @@ instead of the server name.
To check whether all is OK, do:
- curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD
+ curl --netrc --location -v http://<servername>/my-new-repo.git/HEAD
...this should give something like 'ref: refs/heads/master', which is
the content of the file HEAD on the server.
@@ -213,12 +224,31 @@ Now, add the remote in your existing repository which contains the project
you want to export:
$ git-config remote.upload.url \
- http://<username>@<servername>/my-new-repo.git/
+ http://<servername>/my-new-repo.git/
It is important to put the last '/'; Without it, the server will send
a redirect which git-http-push does not (yet) understand, and git-http-push
will repeat the request infinitely.
+Using git config:
+
+curl --user <username>:<password> --location -v http://<servername>/my-new-repo.git/HEAD
+
+...this should give something like 'ref: refs/heads/master', which is
+the content of the file HEAD on the server.
+
+Now, add the remote in your existing repository which contains the project
+you want to export:
+
+ $ git-config remote.upload.url \
+ http://<servername>/my-new-repo.git/
+
+Also, add in your username with:
+ $ git-config http.username <username>
+
+And optionally your password (you will be prompted for it if you do not):
+ $ git-config http.password <password>
+
Step 4: make the initial push
-----------------------------
diff --git a/http.c b/http.c
index ee58799..348b9fb 100644
--- a/http.c
+++ b/http.c
@@ -26,6 +26,9 @@ static long curl_low_speed_time = -1;
static int curl_ftp_no_epsv = 0;
static const char *curl_http_proxy = NULL;
+static const char *curl_http_username = NULL;
+static const char *curl_http_password = NULL;
+
static struct curl_slist *pragma_header;
static struct active_request_slot *active_queue_head = NULL;
@@ -153,11 +156,45 @@ static int http_options(const char *var, const char *value, void *cb)
return git_config_string(&curl_http_proxy, var, value);
return 0;
}
+ if (!strcmp("http.username", var)) {
+ if (curl_http_username == NULL)
+ {
+ return git_config_string(&curl_http_username, var, value);
+ }
+ return 0;
+ }
+ if (!strcmp("http.password", var)) {
+ if (curl_http_password == NULL)
+ {
+ return git_config_string(&curl_http_password, var, value);
+ }
+ return 0;
+ }
/* Fall back on the default ones */
return git_default_config(var, value, cb);
}
+static void init_curl_http_auth(CURL* result){
+#if LIBCURL_VERSION_NUM >= 0x070907
+ struct strbuf userpass;
+ strbuf_init(&userpass, 0);
+ if (curl_http_username != NULL) {
+ strbuf_addstr(&userpass, curl_http_username);
+ strbuf_addstr(&userpass, ":");
+ if (curl_http_password != NULL) {
+ strbuf_addstr(&userpass, curl_http_password);
+ } else {
+ strbuf_addstr(&userpass, getpass("Password: "));
+ }
+ curl_easy_setopt(result, CURLOPT_USERPWD, userpass.buf);
+ curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_IGNORED);
+ } else {
+ curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
+ }
+#endif
+}
+
static CURL* get_curl_handle(void)
{
CURL* result = curl_easy_init();
@@ -172,9 +209,7 @@ static CURL* get_curl_handle(void)
curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);
}
-#if LIBCURL_VERSION_NUM >= 0x070907
- curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
-#endif
+ init_curl_http_auth(result);
if (ssl_cert != NULL)
curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
diff --git a/http.h b/http.h
index 905b462..71320d1 100644
--- a/http.h
+++ b/http.h
@@ -5,6 +5,8 @@
#include <curl/curl.h>
#include <curl/easy.h>
+#include <termios.h>
+#include <stdio.h>
#include "strbuf.h"
#include "remote.h"
--
1.6.1.2
^ permalink raw reply related
* just curious: what influences a commit hash?
From: stoecher @ 2009-03-05 6:36 UTC (permalink / raw)
To: git
Hi,
being new to git I did some experiments with commits looking at the hashes. What I observed:
* The same commit (same file, same committer, same message) into different empty repositories (git init) gives different hashes. So I assume that also the time of the commit influences the hash. Is this intended? For what reason?
* Having created two repositories exactly the same way (the history is the same except for the commit times and hashes) I applied the same patch (using git am) and again I got different hashes for these commits. So in some way also the repository/branch influences the hash of a commit!?
From reading the Git user's manual, chapter 10, object storage format, I was not expecting this. Can someone explain or give a link to a more detailed description?
thank you,
Wolfgang
--
Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Christian Couder @ 2009-03-05 6:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgzdlom.fsf@gitster.siamese.dyndns.org>
Le mardi 3 mars 2009, Junio C Hamano a écrit :
> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
> - builtin-replace: use "usage_msg_opt" to give better error messages
> - parse-options: add new function "usage_msg_opt"
> - builtin-replace: teach "git replace" to actually replace
> - Add new "git replace" command
> - environment: add global variable to disable replacement
> - mktag: call "check_sha1_signature" with the replacement sha1
> - replace_object: add a test case
> - object: call "check_sha1_signature" with the replacement sha1
> - sha1_file: add a "read_sha1_file_repl" function
> - replace_object: add mechanism to replace objects found in
> "refs/replace/"
> - refs: add a "for_each_replace_ref" function
>
> I think the code is much cleaner than the first round, but I am not
> convinced it is doing the right thing in the connectivity traverser.
> Independent review sorely needed.
I haven't look much at connectivity traverser lately but I think I
should first describe some of the issues in other areas.
There are command to reproduce all the steps. (You have to use pu.)
#
# Let's start by creating a good environment to test a few things:
#
$ cd git/t
$ sed -e 's/test_done/exit 1\ntest_done/' t6050-replace.sh > tt.sh
$ ./tt.sh
* ok 1: set up buggy branch
* ok 2: replace the author
* ok 3: tag replaced commit
* ok 4: "git fsck" works
* ok 5: repack, clone and fetch work
* ok 6: "git replace" listing and deleting
* ok 7: "git replace" replacing
FATAL: Unexpected exit with code 1
$ cd trash\ directory.tt
#
# Now let's see what happens when we replace an object:
#
$ git rev-parse HEAD
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git cat-file commit ffccc
tree 5c37393794868bc8e708cccd7c9d9aaa7a5e53cb
parent 14ac020163ea60a9d683ce68e36c946f31ecc856
author A U Thor <author@example.com> 1112912353 -0700
committer C O Mitter <committer@example.com> 1112912353 -0700
hello: again 3 more lines
$ git ls-tree 5c37
100644 blob 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d hello
$ git cat-file blob 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d |
sed -e 's/line 7/changed line 7/' > new_hello
$ cat new_hello | git hash-object -t blob --stdin -w
201722c515afacad101b62525a9e57899eac5182
$ git replace 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d
201722c515afacad101b62525a9e57899eac5182
#
# So now the tree of the current commit has a blob that is replaced.
# The problem is that we don't see it, except if we "touch" the file:
#
$ git diff
$ touch hello
$ git diff
diff --git a/hello b/hello
--- a/hello
+++ b/hello
@@ -4,7 +4,7 @@ line 3
line 4
line 5
line 6
-changed line 7
+line 7
line 8
line 9
line 10
#
# And now we cannot create a commit with the above diff:
#
$ git commit hello
...
nothing added to commit but untracked files present (use "git add" to track)
$ git add hello
$ git status
...
nothing added to commit but untracked files present (use "git add" to track)
#
# So I am not sure if that is a big problem, because that happens only
# if we want to commit something exactly like what we replaced. And in
# this case the best thing to do might be to simply remove the replace
# ref.
#
$ git replace -d 47ea9c3df4682ae7d2c9139fa9ac6dbc9b6eb43d
$ git diff
$ touch hello
$ git diff
#
# We got back to a normal situation.
#
# Now let's try something different
# First let's replace the current commit:
#
$ git rev-parse HEAD
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git cat-file commit ffccc | sed -e "s/A U/O/" | git hash-object -t
commit --stdin -w
$ git cat-file commit dd1ca
tree 5c37393794868bc8e708cccd7c9d9aaa7a5e53cb
parent 14ac020163ea60a9d683ce68e36c946f31ecc856
author O Thor <author@example.com> 1112912353 -0700
committer C O Mitter <committer@example.com> 1112912353 -0700
hello: again 3 more lines
$ git replace HEAD dd1ca
#
# Let's create a commit based on the current one:
#
$ echo 'line 17' >> hello
$ git commit -m 'Add line 17' hello
[master 8f60c7e] Add line 17
1 files changed, 1 insertions(+), 0 deletions(-)
$ git rev-parse HEAD^
ffccc9d552388844dbe94a361c07e7cb1731e12f
$ git reset --hard HEAD^
HEAD is now at dd1ca8e hello: again 3 more lines
#
# We are now on the replacement commit, though before the last
# command we were on a commit on top of the original one.
#
$ echo 'line 17' >> hello
$ git commit -m 'Add line 17' hello
[master c4a823a] Add line 17
1 files changed, 1 insertions(+), 0 deletions(-)
#
# We build on top of the replacement commit, not the original one.
# This means that the original one may be dangling:
#
$ git fsck --full --no-reflogs
dangling commit 8f60c7ee5d6e0379ff813a26a2479289605eb935
...
#
# Of course on a published history, where "git replace" might
# be most usefull, you don't want to use "git reset --hard". So
# this might not be a big problem either.
#
Anyway, thanks in advance for advise/opinion about this.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Kjetil Barvik @ 2009-03-05 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5744x87.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kjetil Barvik <barvik@broadpark.no> writes:
>
>> Change the source code such that when USE_NSEC is not defined,
>> possible nanosecond timestamps will still be saved in the index file,
>> but not used inside if-test's, and will therefore not affect the
>> outcome of GIT commands, other than the saved nanosecond timestamps in
>> the index file.
>>
>> This will make it easier to use a system with 2 versions of GIT, one
>> with and one without USE_NSEC defined.
>
> I take it that you are responding to my earlier question with this
> patch?
Yes, you are correct.
[....]
> How does this affect a use case where the same index file used with two
> instances of git (one compiled with and another without USE_NSEC)?
If both persons in this use case use this patch, the one with USE_NSEC
defined will now be able to take full advantage of the nanosecond
timestamps at all times.
The one without USE_NSEC defined should not be able to tell the
difference (without looking into to details of the index file).
-- kjetil
^ permalink raw reply
* [PATCH] '%S' option for pretty printing to support --source
From: Petri Hodju @ 2009-03-05 7:18 UTC (permalink / raw)
To: git, gitster
From 79f817e25aada377ccb40ebf76c29af7f21e1ec4 Mon Sep 17 00:00:00 2001
From: Petri Hodju <petrihodju@yahoo.com>
Date: Thu, 5 Mar 2009 09:00:39 +0200
Subject: [PATCH] '%S' option for pretty printing to support --source
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Print out the ref name by which each commit was reached. Works only when --source option is used
Examples:
git-log --graph --pretty=format:"%h(%S) — %s (%cr)" --abbrev-commit --date=relative --source
Show ref by which each commit is reachable in current branch
git-log --graph --pretty=format:"%h(%S) — %s (%cr)" --abbrev-commit --date=relative --source --all
Show ref by which each commit is reachable globally
Signed-off-by: Petri Hodju <petrihodju@yahoo.com>
---
pretty.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 6cd9149..cf05b37 100644
--- a/pretty.c
+++ b/pretty.c
@@ -544,6 +544,12 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
+static void format_source(struct strbuf *sb, const struct commit *commit)
+{
+ if (commit->util)
+ strbuf_addstr(sb, (char *) commit->util);
+}
+
static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -650,6 +656,9 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'S':
+ format_source(sb, commit);
+ return 1;
}
/* For the rest we have to parse the commit header. */
--
1.6.2.rc2.22.g1d035.dirty
^ 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