* Re: [PATCH] gitk: Starting translation for Norwegian
From: Fredrik Skolmli @ 2008-12-08 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vvdtu7grc.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 08, 2008 at 08:50:47AM -0800, Junio C Hamano wrote:
> Even though "Subject" says gitk but it is not about git-gui, though ;-)
Oh, my bad. Shawn, do you mind correcting that? (If you got the file
correctly, that is..)
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH] gitk: Starting translation for Norwegian
From: Fredrik Skolmli @ 2008-12-08 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vvdtu7grc.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 08, 2008 at 08:50:47AM -0800, Junio C Hamano wrote:
> If the first non-ASCII character in the resulting file between "Bokm" and
> "l" should look like an angstrom, I think the copy I received was fine.
Fwiw.
I'm not quite sure what an angstrom is, but it should look like an a with a
small dot/circle on top of it.
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH] gitweb: Fix bug in insert_file() subroutine
From: Junio C Hamano @ 2008-12-08 17:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <20081208130905.15803.83149.stgit@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> +# ----------------------------------------------------------------------
> +# non-ASCII in README.html
> +
> +test_expect_success \
> + 'README.html with non-ASCII characters (utf-8)' \
> + 'echo "<b>UTF-8 example:</b><br />" > .git/README.html &&
> + cat "$TEST_DIRECTORY"/t3900/1-UTF-8.txt >> .git/README.html &&
> + gitweb_run "p=.git;a=summary"'
> +test_debug 'cat gitweb.log'
> +
Yup, a new test would certainly help to catch breakages ;-)
Thanks.
^ permalink raw reply
* Re: [PATCH] gitk: Starting translation for Norwegian
From: Junio C Hamano @ 2008-12-08 17:10 UTC (permalink / raw)
To: Fredrik Skolmli; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081208170417.GD23924@frsk.net>
Fredrik Skolmli <fredrik@frsk.net> writes:
> On Mon, Dec 08, 2008 at 08:50:47AM -0800, Junio C Hamano wrote:
>
>> If the first non-ASCII character in the resulting file between "Bokm" and
>> "l" should look like an angstrom, I think the copy I received was fine.
>
> Fwiw.
>
> I'm not quite sure what an angstrom is, but it should look like an a with a
> small dot/circle on top of it.
Yeah, that was what I saw in your original one which was encoded in 8859-1
and marked as 8859-1.
And I should have spelled the name of the letter "Ångström".
^ permalink raw reply
* Re: [PATCH] gitk: Starting translation for Norwegian
From: Junio C Hamano @ 2008-12-08 17:13 UTC (permalink / raw)
To: Fredrik Skolmli; +Cc: Shawn O. Pearce, git
In-Reply-To: <7viqpu7ftu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> And I should have spelled the name of the letter "Ångström".
Embarrassingly sorry for the noise, but what I meant was "Å" in
"Ångström", not "the name of the letter".
^ permalink raw reply
* Re: ETA for release of gjit 0.4?
From: Shawn O. Pearce @ 2008-12-08 17:13 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Farrukh Najmi, git
In-Reply-To: <20081208165234.GI31551@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> > It was a long time since we labeled anything. Shawn, how about merging
> > my recent close-file-patches, reverting 3ffa47d9294086fbd1cdeb9b1564f922a23e3c6f
> > and e7307f14c531d52cf231c39d844841c4adaf5e5a and then just call i 0.4 ?
>
> OK. I'm not a big fan of reverting code, but I see more value in
> doing it and getting a "more stable" 0.4 out. So I'll do these
> reverts and make the 0.4 tag this morning.
Err, uhm. I don't have access to my signing key from work.
I'll sign it tonight.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitk: Starting translation for Norwegian
From: Fredrik Skolmli @ 2008-12-08 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7viqpu7ftu.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 08, 2008 at 09:10:53AM -0800, Junio C Hamano wrote:
> And I should have spelled the name of the letter "Ångström".
Aha, a swedish unit. There you go, I learned something new today as well. :-)
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH] gitk: Starting translation for Norwegian
From: Shawn O. Pearce @ 2008-12-08 17:33 UTC (permalink / raw)
To: Fredrik Skolmli; +Cc: git
In-Reply-To: <20081208165338.GB23924@frsk.net>
Fredrik Skolmli <fredrik@frsk.net> wrote:
> On Mon, Dec 08, 2008 at 08:45:58AM -0800, Shawn O. Pearce wrote:
>
> > Looking at the MIME data mutt is reporting the attachment is
> > still iso-8859-1. I guess its time to fix your mail client,
> > or gzip the patch and send the .gz attachment instead...
>
> Oh, now I see. Sorry for the extra hassle, but at least my mutt now says the
> attachment is UTF-8.
Thanks, that applied clean and builds. I just pushed it out,
with a corrected subject line.
--
Shawn.
^ permalink raw reply
* Re: help needed: Splitting a git repository after subversion migration
From: Thomas Jarosch @ 2008-12-08 17:34 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, git
In-Reply-To: <20081208142447.GA20186@atjola.homenet>
On Monday, 8. December 2008 15:24:47 you wrote:
> If it's about huge objects, and not just lots of small objects, you can
> use this:
Thanks, those two commands have been really helpful. I've found some objects
that shouldn't be there and now I have two more questions:
1. When I run "git rev-list --all --objects", I can see file names that look
like "SVN-branchname/directory/filename". Is it normal that "git svn"
creates a directory with the name of the branch and puts files below it?
"git rev-list --all --objects |grep 5-0-3-hotfix":
5fe3265b6941c2fa74c12da799ea23e2801efa8a 5-0-3-hotfix/source
...
The branch in question existed for a limited time in branches/xyz
on the SVN tree and was deleted later on. Guessing the version number
from the filename, it looks like a copy of the files when I started the branch
as it's an old version number before I committed changes to it.
(f.e. upgraded libpng). When I just grep for "libpng" on the whole index,
I see all the various updates I made over the years.
2. Something goes wrong after the filter branch:
Output from the full 11GB tree:
git rev-list --all --objects |grep 5-0-3-hotfix |grep xyz
-> No match
Output from the filtered tree:
git rev-list --all --objects |grep 5-0-3-hotfix |grep xyz
3a13f87bc116aee96e031441eaafc416652ba4bd 5-0-3-hotfix/update_pkg/xyz
ebebb84ccff26c949fb1f803c60034074e6603fe 5-0-3-hotfix/update_pkg/xyz
5529ef51de887cc905fe460e4c4f6cd34b93b5a6 5-0-3-hotfix/update_pkg/xyz
c264a9d5db30ebb131c96c4f93192bfe9a5c0a7b 5-0-3-hotfix/update_pkg/xyz
I have no idea how those objects suddenly appeared there.
It feels like something was stitched together wrongly.
When I converted the SVN tag to a git tag, I tagged the branches
with a "branch-" prefix. Might that be a problem, is "branch-" reserved?
Cheers,
Thomas
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-12-08 18:13 UTC (permalink / raw)
To: Alexander Gavrilov
Cc: Michael J Gruber, Ondrej Certik, Git Mailing List, Fabian Seoane
In-Reply-To: <200812071425.52908.angavrilov@gmail.com>
Hi,
On Sun, 7 Dec 2008, Alexander Gavrilov wrote:
> On Wednesday 26 November 2008 20:08:54 Johannes Schindelin wrote:
> > On Wed, 26 Nov 2008, Michael J Gruber wrote:
> > > Looking at the source I suspect that fast-export fails to denote
> > > parenthood in the case of yet unmarked parents (last for-loop of
> > > handle_commit() in builtin_fast_export.c). But I don't really know
> > > that code at all.
> >
> > I strongly doubt so. Noticed the use of has_unshown_parent(commit) in
> > both cases before calling handle_commit()?
> >
> > In any case, here is a script that I wrote _long_ time ago, to be able
> > to reconstruct history from the output of "git rev-list --all
> > --parents". Maybe this helps you in reconstructing something that is
> > handled incorrectly by fast-export | fast-import, but is lighter than
> > a full-blown repository.
>
> Today I had time to investigate this problem, and found:
>
> 1) The root of the problem is that fast-export really wants to walk
> revisions in topological order, but actually receives them in date
> order.
Indeed. Can you submit this patch with a proper commit message, adding a
test for the issue by setting a bogus GIT_COMMITTER_DATE explicitly?
Thanks,
Dscho
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-08 18:26 UTC (permalink / raw)
To: Michael J Gruber, git
In-Reply-To: <493D1CC2.8050407@drmicha.warpmail.net>
Michael J Gruber pisze:
> Could it be as simple as a missing "cd cocoon" between git clone and git
> svn rebase? No, you probably did that.
That would be too easy.
> But note that you did not follow Peter's instructions. The point is that
> your clone creates "remotes/origin/trunk" whereas Peter's instructions
> mirror the source, creating "remotes/trunk", which is what git svn needs
> (unless you say "git svn init -s --prefix=origin/" or "git config
> svn-remote.svn.fetch trunk:refs/trunk" etc.). The prefix solution should
> be the best.
>
> Michael
>
> P.S.: Peter starts off a different layout (standard svn remotes, which
> need special instructions to be cloned). Ordinary clone + git svn init
> --prefix=origin/ should work fine for the cocoon layout.
This almost worked. Actually, Cocoon repository hosted on Jukka's server does not have local head
named "trunk" so there is no remotes/origin/trunk created during cloning process.
I had to run:
git update-ref refs/remotes/origin/trunk refs/heads/master
After doing that git svn rebase resulted in:
[really long list of revisions]
r707379 = f61a2d30b6ac5a5136b46fa2b9b5b91e4763feb1
r710118 = 40997fe552e8581b75b08fed41a6b63a33d58bdf
r720135 = a8160766ec40fd7ebf95bfa7cebfa50dfa2f9c3a
r720180 = b094a222bab3671c8277087e7a96589ec76dd5e4
r720182 = 736b8ed6519c64ad120de2ccf08f135062ee09db
Done rebuilding .git/svn/origin/trunk/.rev_map.13f79535-47bb-0310-9956-ffa450edef68
Current branch master is up to date.
Is this expected output?
> P.P.S.: We can't test cocoon unless we have an account on the apache
> server...
I guess this would be a big problem. Getting write-access access to our repository is rather formal
process and I would like to avoid it.
Since it looks I'm much closer to final solution (and better understanding of how our workflow
should look like) I hope any additional account for testing won't be needed.
Anyway, thanks again for your answer!
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* [PATCH] Define linkgit macro in [macros] section
From: Alexey Borzenkov @ 2008-12-08 18:29 UTC (permalink / raw)
To: git
Starting with asciidoc 8.3.0 linkgit macro is no longer recognized by
asciidoc and user guide suggests
(http://www.methods.co.nz/asciidoc/userguide.html#_macro_definitions)
that macros are supposed to be defined in [macros] section. I'm not
sure whether undefined linkgit macro was working by pure chance or it
is a regression in asciidoc 8.3.0, but this patch adds proper
definition for the linkgit macro, allowing it to work on 8.3.0.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
---
Documentation/asciidoc.conf | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 2da867d..1e735df 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -7,6 +7,9 @@
# Show GIT link as: <command>(<section>); if section is defined, else just show
# the command.
+[macros]
+(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]=
+
[attributes]
asterisk=*
plus=+
--
1.6.0.4
^ permalink raw reply related
* Re: How to clone git repository with git-svn meta-data included?
From: Peter Harris @ 2008-12-08 18:40 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: Michael J Gruber, git
In-Reply-To: <493D66BB.3060907@tuffmail.com>
On Mon, Dec 8, 2008 at 1:26 PM, Grzegorz Kossakowski wrote:
>
> After doing that git svn rebase resulted in:
> [really long list of revisions]
> r707379 = f61a2d30b6ac5a5136b46fa2b9b5b91e4763feb1
> r710118 = 40997fe552e8581b75b08fed41a6b63a33d58bdf
> r720135 = a8160766ec40fd7ebf95bfa7cebfa50dfa2f9c3a
> r720180 = b094a222bab3671c8277087e7a96589ec76dd5e4
> r720182 = 736b8ed6519c64ad120de2ccf08f135062ee09db
> Done rebuilding .git/svn/origin/trunk/.rev_map.13f79535-47bb-0310-9956-ffa450edef68
> Current branch master is up to date.
>
> Is this expected output?
Yes. The rfoo = sha1hash part is git-svn rebuilding its index.
"Current branch master is up to date" is git-svn calling "git rebase
<svn-branch>", and git saying that there is nothing to do, since there
have been no svn commits to that branch since the last time you ran
git svn rebase (or since you cloned the git mirror, or since the last
time the git mirror pulled from svn).
Peter Harris
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-08 18:43 UTC (permalink / raw)
To: Peter Harris; +Cc: Michael J Gruber, git
In-Reply-To: <eaa105840812081040s1036b79an9914c1f74d6d7f6a@mail.gmail.com>
Peter Harris pisze:
> On Mon, Dec 8, 2008 at 1:26 PM, Grzegorz Kossakowski wrote:
>> After doing that git svn rebase resulted in:
>> [really long list of revisions]
>> r707379 = f61a2d30b6ac5a5136b46fa2b9b5b91e4763feb1
>> r710118 = 40997fe552e8581b75b08fed41a6b63a33d58bdf
>> r720135 = a8160766ec40fd7ebf95bfa7cebfa50dfa2f9c3a
>> r720180 = b094a222bab3671c8277087e7a96589ec76dd5e4
>> r720182 = 736b8ed6519c64ad120de2ccf08f135062ee09db
>> Done rebuilding .git/svn/origin/trunk/.rev_map.13f79535-47bb-0310-9956-ffa450edef68
>> Current branch master is up to date.
>>
>> Is this expected output?
>
> Yes. The rfoo = sha1hash part is git-svn rebuilding its index.
> "Current branch master is up to date" is git-svn calling "git rebase
> <svn-branch>", and git saying that there is nothing to do, since there
> have been no svn commits to that branch since the last time you ran
> git svn rebase (or since you cloned the git mirror, or since the last
> time the git mirror pulled from svn).
Thanks for confirmation and explanation.
The remaining question is who should address this issue with non-existing trunk ref? Should I ask
Jukka, who maintains svn mirrors, to put instruction into his scripts that will add trunk reference?
Would it be the best practice?
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Re: How to clone git repository with git-svn meta-data included?
From: Grzegorz Kossakowski @ 2008-12-08 19:04 UTC (permalink / raw)
To: Shawn O. Pearce, git
In-Reply-To: <20081208161049.GB31551@spearce.org>
Shawn O. Pearce pisze:
> ASF probably has issues similar to that of the Android project.
>
> In Android we built Gerrit[1] to handle this validation of identity
> for us, and to keep track of the contributor agreements each
> individual and corporation has signed. Changes aren't accepted
> into Gerrit unless the user has an accepted CLA in the data store.
>
> *1* http://review.source.android.com/
I'm not an expert on legal issues at Apache but in general you might be right that ASF and Android
project have similar issues to tackle. I've brought this point because it was previously brought in
ASF discussion on Git. so I try to act more like a bridge between two parties.
> Gerrit 2 is actively under development and is being ported off of
> Google App Engine, into a pure Java webapp. I'm running it under
> Jetty, but it should work just as well under Tomcat. :-)
Is there any documentation outlining Gerrit's features and status of Gerrit 2 development?
> If the ASF becomes more committed to supporting Git, Gerrit may be
> a good way to answer some of the questions you are having about
> validating identity of changes. Plus its a handy source code
> review tool.
I guess it's rather long run before Apache Infrastructure team *officially* starts supporting Git.
This is my personal view and it's not official voice of ASF by any means. SVN to Git transition
(entirely) is complicated process for such a big organization like ASF.
Another option would be to let particular projects choose which SCM they prefer but that would mean
that our infra team has to support two different SCMs. This means some new folks interested in
supporting Git at ASF would have to join infra.
At this point, we chose to let people experiment with Git (so we are allowed to perform rather
expensive clone operations) in order to gain some experience and work out work-flow that suits ASF
model of development. This thread is part of described process.
On the other hand, if we find Gerrit useful for us we might try to set up it somewhere unofficially
and let people play with it.
>> Does it mean that with current Git design it's the best to not use advanced features of Git like
>> tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?
>
> Most Git projects rely on patches sent to an email list, with
> a single maintainer applying them to to his/her repository, and
> publishing the result. The maintainer is thus forced to keep track
> of the CLAs (if the project uses such things) and just trust the
> From address of the message.
It's rather important to keep in mind that at ASF we don't how practice of single maintainer so we
need solution that works for many committers that push to the same repo but I know Git supports this
rather easily.
> CLAs in the kernel and in git itself are less enforced than say
> what ASF or Android requires.
>
> Some Git projects give write access to the master repository to
> multiple trusted parties; SAMBA and X.org are good examples of this
> sort of strategy. But I think in these cases those who have write
> access are also very long standing members of the development
> community who have known each other in person for many years,
> perhaps far longer than a DVCS concept has existed. So trust
> between those with direct write access is slightly less of an
> issue for these projects.
That is a case for Apache to some extent. Someone is being nominated to become a committer after
some period of cooperation in terms of providing patch, participating in discussions etc. After such
period existing committers can rather reliably judge if they trust particular person or not.
Yet still signed CLA is required but we check this before someone is being granted write access so
this can be done by hand.
> So long story short, I think Gerrit may be worth the ASF's time,
> if Git is a serious consideration for replacing SVN. But while a
> project is based in SVN I think the best you can do with Git is
> publish an automatically updated git-svn mirror and permit only
> use of "git svn dcommit" to upload back into the SVN repository.
As I said, I don't think ASF will switch to Git any time soon due to many different reasons
including technical (IDE support), social (there are different opinions on DVCS in general) and
other. All of them have to be addressed but in order to have any meaningful discussion we need to
gather some experience.
Thanks for helping me with going through this process!
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Can someone confirm what the contents of refs/heads/master means?
From: davetron5000 @ 2008-12-08 19:23 UTC (permalink / raw)
To: git
I'm using git-svn to interact with an SVN repo that has branches.
After my clone via:
git svn clone $REPO/main -T trunk -b branches -t tags
my 'master' branch pointed to one of the branches in svn and not to
the main trunk. (my .git/config looked correct for svn interaction,
i.e. trunk pointed to the right place).
So, I overwrote refs/heads/master with the contents of refs/remotes/
trunk (i.e. the SHA-1 of the svn trunk).
Things seem to be working; git svn dcommit commits to the trunk and
git svn rebase updates from svn's trunk.
So, I want to make sure that refs/heads/master actuall does, in fact,
point to the head revision of whatever branch is considered "master".
Can someone comfirm this (or provide the actual explanation if I'm
wrong?)
Thanks!
Dave
^ permalink raw reply
* Re: Can someone confirm what the contents of refs/heads/master means?
From: Peter Harris @ 2008-12-08 19:35 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <f78b0fcc-6165-440a-b76b-b1b0a281b15c@k8g2000yqn.googlegroups.com>
On Mon, Dec 8, 2008 at 2:23 PM, davetron5000 wrote:
>
> So, I overwrote refs/heads/master with the contents of refs/remotes/
> trunk (i.e. the SHA-1 of the svn trunk).
>
> Things seem to be working; git svn dcommit commits to the trunk and
> git svn rebase updates from svn's trunk.
>
> So, I want to make sure that refs/heads/master actuall does, in fact,
> point to the head revision of whatever branch is considered "master".
I do believe so, yes. That, or an entry in packed-refs.
> Can someone comfirm this (or provide the actual explanation if I'm
> wrong?)
Overwriting internal files by hand feels a little too much like work
for my taste. I would have done something more like "git reset --hard
trunk" (or, if not on master, "git branch -D master; git branch master
trunk" ), but of course you can feel free to do things the hard way if
you prefer. :-)
Peter Harris
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Daniel Barkalow @ 2008-12-08 19:41 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812080451k6e213d0fo8d1da9bbac872649@mail.gmail.com>
On Mon, 8 Dec 2008, Nguyen Thai Ngoc Duy wrote:
> On 12/8/08, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > > This was discussed since the beginning of this feature. I recall that
> > > the index reflects worktree, and because we mark CE_NO_CHECKOUT on
> > > file basis, it's best to save the information there, not separately.
> > > We do save high level information to form the checkout area (sparse
> > > patterns) in the last half, but basically you should be able to live
> > > without that.
> >
> >
> > We need to mark in the index the information that reflects the worktree.
> >
> > If, however, we take CE_VALID to be the flag for "ignore the worktree
> > entirely at this path; act as it if contains what the index contains" (and
> > use this to cause that aspect of no-checkout), and we then entirely ignore
> > the worktree, including not caring whether there are files there or not
> > (except, of course, that in the transition from caring to not caring for
> > no-checkout, we make the worktree empty, while in the case for
> > "stat-is-expensive", we bring it into agreement with the index), then
> > there is no additional information that needs to be conveyed in the index.
>
> That's not enough. CE_VALID is "ignore the worktree files" while
> CE_NO_CHECKOUT is stricter: "those files does (or should) not exist".
> The difference is
>
> - for "git grep", we ignore path with CE_NO_CHECKOUT (while using
> cache version for CE_VALID)
Is this sufficient? I'd expect "git grep" to ignore paths that are outside
the checked-out region, even when searching an arbitrary tree, and even
when those files aren't in the index at all (i.e., the current commit
doesn't have them). That is, I'd expect core.defaultsparse or the
equivalent to limit the paths, normally giving this effect.
> - porcelain-level support to widen/narrow checkout area will need
> CE_NO_CHECKOUT, not CE_VALID
This isn't a meaningful difference between CE_NO_CHECKOUT and CE_VALID if
there aren't any other differences.
> > > > unless it's ever important to remember whether an entry is CE_VALID due to
> > > > having been outside the checkout when the index was written, even though
> > > > the checkout area now includes it. I don't have a good intuition as to
> > > > what ought to happen if the user manually changes what's specified for
> > > > checkout without actually updating the index and working tree.
> > >
> > > So if a user changes worktree without updating index, they will have
> > > the same results as they do now: files are shown as modified if they
> > > don't have CE_NO_CHECKOUT set. If those files do, they are considered
> > > 'orphaned' or staled and are recommended to be removed/updated to
> > > avoid unexpected consequences (not availble this this first half
> > > series because that belongs to "git status").
> >
> >
> > I was actually thinking that there would be a file for "this is what the
> > user wants to have checked out" (as opposed to the index, which must
> > contain "this is what is checked out"), and the porcelain would instruct
> > the plumbing as to what to do with the worktree (that the plumbing with
> > then ignore, due to the index bit) based on this information.
> >
> > The index obviously can't contain the user's full instructions for what
> > should be checked out, because the user will want to say "I don't care
> > about anything in Documentation/" and have this apply to
> > Documentation/some-file-not-in-the-index, so that if this file is in the
> > worktree, the user gets a warning.
> >
> > I think you're doing this with core.defaultsparse, although you seem to
> > allow the index to diverge from this easily.
>
> Yes they can.
>
> >
> > The question, then, is what happens when the index and core.defaultsparse
> > disagree, either because the porcelain supports causing it or because the
> > user has simply editting the config file or used plumbing to modify the
> > index. That is, (1) we have index entries that say that the worktree is
> > ignored, and the rules don't say they're outside the sparse checkout; do
> > we care whether we expect the worktree to be empty or match the index?
> > And, (2) we have index entries that say we do care about them, but the
> > rules say they're outside the sparse checkout; what happens with these?
>
> The rule is CE_NO_CHECKOUT is king. core.defaultsparse only helps
> setting CE_NO_CHECKOUT on new entries when they enter the index.
This seems like a really bad idea to me. If you ask for a file that's
outside your default area to be checked out, and then you switch branches
and switch back, the file may or may not disappear (depending on whether
the branch you switched to temporarily had it or not). Likewise, if you
remove files, and then switch branches and back, the files may or may not
reappear.
Of course, commands need to look at the index to determine what we've
actually done with the worktree and index, but I think there should be
some other location that is responsible for keeping track of what the user
has asked for.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Can someone confirm what the contents of refs/heads/master means?
From: David Copeland @ 2008-12-08 19:42 UTC (permalink / raw)
To: Peter Harris; +Cc: git
In-Reply-To: <eaa105840812081135p56eceb97yb968575b11a7f985@mail.gmail.com>
Thanks for the info :)
The reason I edited by hand is when I was on trunk (e.g. git checkout
trunk), I did a git svn dcommit and it worked, but said "you aren't on
a branch", so I was concerned I might be in some weird state (i.e. if
trunk isn't a branch, can I make a branch off of it?)
Dave
On Mon, Dec 8, 2008 at 2:35 PM, Peter Harris <git@peter.is-a-geek.org> wrote:
> On Mon, Dec 8, 2008 at 2:23 PM, davetron5000 wrote:
>>
>> So, I overwrote refs/heads/master with the contents of refs/remotes/
>> trunk (i.e. the SHA-1 of the svn trunk).
>>
>> Things seem to be working; git svn dcommit commits to the trunk and
>> git svn rebase updates from svn's trunk.
>>
>> So, I want to make sure that refs/heads/master actuall does, in fact,
>> point to the head revision of whatever branch is considered "master".
>
> I do believe so, yes. That, or an entry in packed-refs.
>
>> Can someone comfirm this (or provide the actual explanation if I'm
>> wrong?)
>
> Overwriting internal files by hand feels a little too much like work
> for my taste. I would have done something more like "git reset --hard
> trunk" (or, if not on master, "git branch -D master; git branch master
> trunk" ), but of course you can feel free to do things the hard way if
> you prefer. :-)
>
> Peter Harris
>
^ permalink raw reply
* Re: Can someone confirm what the contents of refs/heads/master means?
From: Peter Harris @ 2008-12-08 19:55 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890812081142k575264fctd77254ed3386a069@mail.gmail.com>
On Mon, Dec 8, 2008 at 2:42 PM, David Copeland wrote:
> Thanks for the info :)
>
> The reason I edited by hand is when I was on trunk (e.g. git checkout
> trunk), I did a git svn dcommit and it worked, but said "you aren't on
> a branch", so I was concerned I might be in some weird state (i.e. if
> trunk isn't a branch, can I make a branch off of it?)
Trunk is a "remote branch", so you can't check it out. If you try, you
get what is called a "detached HEAD".
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#detached-head
And, yes, you can make a local branch off of a remote branch.
Peter Harris
^ permalink raw reply
* Re: [PATCH] Define linkgit macro in [macros] section
From: Alexey Borzenkov @ 2008-12-08 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <e2480c70812081029s36eac963t76092c09af990ad@mail.gmail.com>
Alexey Borzenkov <snaury <at> gmail.com> writes:
> I'm not sure whether undefined linkgit macro was working by pure chance
> or it is a regression in asciidoc 8.3.0,
I now found that the change in question was made in
http://hg.sharesource.org/asciidoc/rev/82bdfd1a3674 and "catchall" macro is now
commented out by default, all the more reason for git to define linkgit macro
properly.
^ permalink raw reply
* [StGit] kha/{safe,experimental} updated
From: Karl Hasselström @ 2008-12-08 20:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Gustav Hållberg, David Kågedal
The "safe" branch has a whole bunch of stgit.el improvements by David
and Gustav. "experimental" has the same two patches that just sit
there waiting for the git features they depend on to be sufficiently
widely deployed.
-+-
The following changes since commit b9756849c9297b23f0628bcb08bad9a52a8aacf8:
Dan Williams (1):
fix export -s
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (6):
stgit.el: Try to make the point stay on the coalesced patch
stgit.el: Rename stgit-refresh to stgit-reload
stgit.el: Move stgit-rename to C-c C-r
stgit.el: Add the stgit-refresh command
stgit.el: Show running commands
Use separate column for zero in output of stg series -e
Gustav Hållberg (5):
stgit.el: Compact code for populating stgit-mode-map
stgit.el: Add 'q' for stgit-quit
stgit.el: Add 'm' as alias for stgit-mark
stgit.el: Add stgit-unmark-down
stgit.el: Fix some indentation
Karl Hasselström (1):
stg series: Explain the list format better
contrib/stgit.el | 155 ++++++++++++++++++++++++++++++----------------
stgit/commands/series.py | 34 +++++++----
2 files changed, 124 insertions(+), 65 deletions(-)
-+-
The following changes since commit 6fdc3442eda397a2c7ab999193cdcc156423f773:
Karl Hasselström (1):
stg series: Explain the list format better
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
Karl Hasselström (2):
Read several objects at once with git cat-file --batch
Diff several trees at once with git diff-tree --stdin
INSTALL | 5 +++-
stgit/lib/git.py | 79 +++++++++++++++++++++++++++++++++++++++++++++++++----
stgit/run.py | 19 +++++++++++++
3 files changed, 96 insertions(+), 7 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git-svn not working when parent of cloned dir requires auth
From: D. Stuart Freeman @ 2008-12-08 20:54 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
I'm trying to
'git svn clone https://mware.ucdavis.edu/svn/ucd-sakai/gradebook-gwt -s'
that repo is setup to allow anonymous reading of that directory tree, but
git-svn prompts me for a password. I think git-svn is traversing up the
directory tree and encountering a directory that needs authn, can I prevent
it from doing that?
--
D. Stuart Freeman
Georgia Institute of Technology
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Can someone confirm what the contents of refs/heads/master means?
From: Björn Steinbrink @ 2008-12-08 21:26 UTC (permalink / raw)
To: davetron5000; +Cc: git
In-Reply-To: <f78b0fcc-6165-440a-b76b-b1b0a281b15c@k8g2000yqn.googlegroups.com>
On 2008.12.08 11:23:46 -0800, davetron5000 wrote:
> I'm using git-svn to interact with an SVN repo that has branches.
>
> After my clone via:
>
> git svn clone $REPO/main -T trunk -b branches -t tags
>
> my 'master' branch pointed to one of the branches in svn and not to
> the main trunk. (my .git/config looked correct for svn interaction,
> i.e. trunk pointed to the right place).
Just to clear up that bit as well. when the "fetch" finishes (which is
part of the clone process), git-svn checks if there is a master branch,
and if not, it creates one from the last commit it created. So if your
last svn commit was to branch XYZ and not to trunk, master will
reference that commit on branch XYZ.
Björn
^ permalink raw reply
* Re: git-svn not working when parent of cloned dir requires auth
From: Junio C Hamano @ 2008-12-08 21:30 UTC (permalink / raw)
To: D. Stuart Freeman; +Cc: git, Eric Wong
In-Reply-To: <20081208205418.GA16418@cetel-004-xx6.admin.gatech.edu>
"D. Stuart Freeman" <stuart.freeman@et.gatech.edu> writes:
> I'm trying to
> 'git svn clone https://mware.ucdavis.edu/svn/ucd-sakai/gradebook-gwt -s'
> that repo is setup to allow anonymous reading of that directory tree, but
> git-svn prompts me for a password. I think git-svn is traversing up the
> directory tree and encountering a directory that needs authn, can I prevent
> it from doing that?
That sounds suspiciously similar to what I observed long time ago:
http://thread.gmane.org/gmane.comp.version-control.git/46361/focus=46558
And $gmane/47151 in the thread, aka dc43166 (git-svn: don't minimize-url
when doing an init that tracks multiple paths, 2007-05-19), supposed to
have fixed it.
Hmm... Eric?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox